{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-image-7.0.0-42-generic", "linux-main-modules-v4l2loopback-7.0.0-42-generic", "linux-main-modules-zfs-7.0.0-42-generic", "linux-modules-7.0.0-42-generic" ], "removed": [ "linux-image-7.0.0-38-generic", "linux-main-modules-zfs-7.0.0-38-generic", "linux-modules-7.0.0-38-generic" ], "diff": [ "apt", "base-files", "libapt-pkg7.0", "libpcre2-8-0", "linux-image-virtual", "xxd" ] } }, "diff": { "deb": [ { "name": "apt", "from_version": { "source_package_name": "apt", "source_package_version": "3.2.0", "version": "3.2.0" }, "to_version": { "source_package_name": "apt", "source_package_version": "3.2.1ubuntu0.1", "version": "3.2.1ubuntu0.1" }, "cves": [ { "cve": "CVE-2026-109518", "url": "https://ubuntu.com/security/CVE-2026-109518", "cve_description": "On Debian, Ubuntu, and derivative Linux distributions, an on-path attacker who can manipulate the HTTP traffic (including a malicious mirror or proxy) between an APT client and an archive server triggered by a package install can trick the client into installing an attacker-controlled unverified package and achieve remote code execution with root privileges. The vulnerability is caused by the reuse of hard links and requires the client to follow redirects and retry the download of package files. It requires the client to have a non-zero Acquire::Retries configuration setting; the value 3 is the default starting with Debian 12 (bookworm) and Ubuntu 22.04 LTS (Jammy Jellyfish), so older releases are unaffected in a default configuration.", "cve_priority": "high", "cve_public_date": "2026-11-04 12:00:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-109518", "url": "https://ubuntu.com/security/CVE-2026-109518", "cve_description": "On Debian, Ubuntu, and derivative Linux distributions, an on-path attacker who can manipulate the HTTP traffic (including a malicious mirror or proxy) between an APT client and an archive server triggered by a package install can trick the client into installing an attacker-controlled unverified package and achieve remote code execution with root privileges. The vulnerability is caused by the reuse of hard links and requires the client to follow redirects and retry the download of package files. It requires the client to have a non-zero Acquire::Retries configuration setting; the value 3 is the default starting with Debian 12 (bookworm) and Ubuntu 22.04 LTS (Jammy Jellyfish), so older releases are unaffected in a default configuration.", "cve_priority": "high", "cve_public_date": "2026-11-04 12:00:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Download verification bypass", " - methods/*.cc: Open target files exclusively", " - CVE-2026-109518", " * SECURITY UPDATE: Out-of-bounds accesses", " - deb: guard against unsigned underflow when trimming control newlines", " - gpgv: don't advance past the null terminator in PushEntryWithKeyID", " - debDebFileParser: reject .deb without a Version field", " - srvrec: reject res_query answers bigger than our buffer", " - tagfile: fix unbounded backward scan in Fill()'s trailing-newline check", " - solver: Ensure workLess is a strict weak ordering", " * Test suite reliability:", " - test: Limit valgrind to 1024 open files", "" ], "package": "apt", "version": "3.2.1ubuntu0.1", "urgency": "medium", "distributions": "resolute-security", "launchpad_bugs_fixed": [], "author": "Julian Andres Klode ", "date": "Mon, 02 Nov 2026 14:39:50 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "base-files", "from_version": { "source_package_name": "base-files", "source_package_version": "14ubuntu6.2", "version": "14ubuntu6.2" }, "to_version": { "source_package_name": "base-files", "source_package_version": "14ubuntu6.3", "version": "14ubuntu6.3" }, "cves": [], "launchpad_bugs_fixed": [ 2131303 ], "changes": [ { "cves": [], "log": [ "", " * debian/preinst: remove dangling multilib aliasing symlinks (/lib32,", " /libo32, /libx32) instead of failing (LP: #2131303)", "" ], "package": "base-files", "version": "14ubuntu6.3", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 2131303 ], "author": "Nadzeya Hutsko ", "date": "Fri, 16 Oct 2026 10:37:50 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "libapt-pkg7.0", "from_version": { "source_package_name": "apt", "source_package_version": "3.2.0", "version": "3.2.0" }, "to_version": { "source_package_name": "apt", "source_package_version": "3.2.1ubuntu0.1", "version": "3.2.1ubuntu0.1" }, "cves": [ { "cve": "CVE-2026-109518", "url": "https://ubuntu.com/security/CVE-2026-109518", "cve_description": "On Debian, Ubuntu, and derivative Linux distributions, an on-path attacker who can manipulate the HTTP traffic (including a malicious mirror or proxy) between an APT client and an archive server triggered by a package install can trick the client into installing an attacker-controlled unverified package and achieve remote code execution with root privileges. The vulnerability is caused by the reuse of hard links and requires the client to follow redirects and retry the download of package files. It requires the client to have a non-zero Acquire::Retries configuration setting; the value 3 is the default starting with Debian 12 (bookworm) and Ubuntu 22.04 LTS (Jammy Jellyfish), so older releases are unaffected in a default configuration.", "cve_priority": "high", "cve_public_date": "2026-11-04 12:00:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-109518", "url": "https://ubuntu.com/security/CVE-2026-109518", "cve_description": "On Debian, Ubuntu, and derivative Linux distributions, an on-path attacker who can manipulate the HTTP traffic (including a malicious mirror or proxy) between an APT client and an archive server triggered by a package install can trick the client into installing an attacker-controlled unverified package and achieve remote code execution with root privileges. The vulnerability is caused by the reuse of hard links and requires the client to follow redirects and retry the download of package files. It requires the client to have a non-zero Acquire::Retries configuration setting; the value 3 is the default starting with Debian 12 (bookworm) and Ubuntu 22.04 LTS (Jammy Jellyfish), so older releases are unaffected in a default configuration.", "cve_priority": "high", "cve_public_date": "2026-11-04 12:00:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Download verification bypass", " - methods/*.cc: Open target files exclusively", " - CVE-2026-109518", " * SECURITY UPDATE: Out-of-bounds accesses", " - deb: guard against unsigned underflow when trimming control newlines", " - gpgv: don't advance past the null terminator in PushEntryWithKeyID", " - debDebFileParser: reject .deb without a Version field", " - srvrec: reject res_query answers bigger than our buffer", " - tagfile: fix unbounded backward scan in Fill()'s trailing-newline check", " - solver: Ensure workLess is a strict weak ordering", " * Test suite reliability:", " - test: Limit valgrind to 1024 open files", "" ], "package": "apt", "version": "3.2.1ubuntu0.1", "urgency": "medium", "distributions": "resolute-security", "launchpad_bugs_fixed": [], "author": "Julian Andres Klode ", "date": "Mon, 02 Nov 2026 14:39:50 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpcre2-8-0", "from_version": { "source_package_name": "pcre2", "source_package_version": "10.46-1build1", "version": "10.46-1build1" }, "to_version": { "source_package_name": "pcre2", "source_package_version": "10.46-1ubuntu0.1", "version": "10.46-1ubuntu0.1" }, "cves": [ { "cve": "CVE-2026-103111", "url": "https://ubuntu.com/security/CVE-2026-103111", "cve_description": "PCRE2 before 10.49, when there is an attacker-controlled regular expression and certain JIT API usage, allows an out-of-bounds write with arbitrary data.", "cve_priority": "medium", "cve_public_date": "2026-09-30 05:16:00 UTC" }, { "cve": "CVE-2026-86145", "url": "https://ubuntu.com/security/CVE-2026-86145", "cve_description": "PCRE2 before 10.48 allows a pcre2_dfa_match out-of-bounds write because reuse of a cached workspace block, in a recursive DFA matching workspace, lacks a size check (even though a newly allocated block, for the same purpose, does have a size check). This outcome requires an attacker-controlled regular expression, or a recursive pattern in conjunction with a small heap limit (this can be set through the API).", "cve_priority": "medium", "cve_public_date": "2026-09-05 06:17:00 UTC" }, { "cve": "CVE-2026-89156", "url": "https://ubuntu.com/security/CVE-2026-89156", "cve_description": "PCRE2 before 10.48 has a pcre2_match out-of-bounds read after a JIT fallback when an attacker can provide invalid UTF data.", "cve_priority": "medium", "cve_public_date": "2026-09-11 04:18:00 UTC" }, { "cve": "CVE-2026-89157", "url": "https://ubuntu.com/security/CVE-2026-89157", "cve_description": "PCRE2 before 10.48, on 32-bit platforms, has a pcre2_pattern_convert out-of-bounds write when an attacker can provide a large pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-11 04:18:00 UTC" }, { "cve": "CVE-2026-89158", "url": "https://ubuntu.com/security/CVE-2026-89158", "cve_description": "PCRE2 before 10.48, on 32-bit platforms, has a pcre2_compile_32 integer overflow and resultant out-of-bounds write.", "cve_priority": "medium", "cve_public_date": "2026-09-11 04:18:00 UTC" }, { "cve": "CVE-2026-89160", "url": "https://ubuntu.com/security/CVE-2026-89160", "cve_description": "PCRE2 before 10.48 has a pcre2_match out-of-bounds read during the PCRE2_MATCH_INVALID_UTF matching of an invalid UTF subject.", "cve_priority": "medium", "cve_public_date": "2026-09-11 04:18:00 UTC" }, { "cve": "CVE-2026-89161", "url": "https://ubuntu.com/security/CVE-2026-89161", "cve_description": "In PCRE2 before 10.48, pcre2_jit_match mishandles a previously copied subject being passed in as a context. An incorrect free operation can occur.", "cve_priority": "medium", "cve_public_date": "2026-09-11 04:18:00 UTC" }, { "cve": "CVE-2026-89162", "url": "https://ubuntu.com/security/CVE-2026-89162", "cve_description": "In PCRE2 before 10.48, pcre2_serialize_encode might disclose two bytes to an adversary, typically in a situation where the access available to the adversary is already unsafe.", "cve_priority": "medium", "cve_public_date": "2026-09-11 05:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-103111", "url": "https://ubuntu.com/security/CVE-2026-103111", "cve_description": "PCRE2 before 10.49, when there is an attacker-controlled regular expression and certain JIT API usage, allows an out-of-bounds write with arbitrary data.", "cve_priority": "medium", "cve_public_date": "2026-09-30 05:16:00 UTC" }, { "cve": "CVE-2026-86145", "url": "https://ubuntu.com/security/CVE-2026-86145", "cve_description": "PCRE2 before 10.48 allows a pcre2_dfa_match out-of-bounds write because reuse of a cached workspace block, in a recursive DFA matching workspace, lacks a size check (even though a newly allocated block, for the same purpose, does have a size check). This outcome requires an attacker-controlled regular expression, or a recursive pattern in conjunction with a small heap limit (this can be set through the API).", "cve_priority": "medium", "cve_public_date": "2026-09-05 06:17:00 UTC" }, { "cve": "CVE-2026-89156", "url": "https://ubuntu.com/security/CVE-2026-89156", "cve_description": "PCRE2 before 10.48 has a pcre2_match out-of-bounds read after a JIT fallback when an attacker can provide invalid UTF data.", "cve_priority": "medium", "cve_public_date": "2026-09-11 04:18:00 UTC" }, { "cve": "CVE-2026-89157", "url": "https://ubuntu.com/security/CVE-2026-89157", "cve_description": "PCRE2 before 10.48, on 32-bit platforms, has a pcre2_pattern_convert out-of-bounds write when an attacker can provide a large pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-11 04:18:00 UTC" }, { "cve": "CVE-2026-89158", "url": "https://ubuntu.com/security/CVE-2026-89158", "cve_description": "PCRE2 before 10.48, on 32-bit platforms, has a pcre2_compile_32 integer overflow and resultant out-of-bounds write.", "cve_priority": "medium", "cve_public_date": "2026-09-11 04:18:00 UTC" }, { "cve": "CVE-2026-89160", "url": "https://ubuntu.com/security/CVE-2026-89160", "cve_description": "PCRE2 before 10.48 has a pcre2_match out-of-bounds read during the PCRE2_MATCH_INVALID_UTF matching of an invalid UTF subject.", "cve_priority": "medium", "cve_public_date": "2026-09-11 04:18:00 UTC" }, { "cve": "CVE-2026-89161", "url": "https://ubuntu.com/security/CVE-2026-89161", "cve_description": "In PCRE2 before 10.48, pcre2_jit_match mishandles a previously copied subject being passed in as a context. An incorrect free operation can occur.", "cve_priority": "medium", "cve_public_date": "2026-09-11 04:18:00 UTC" }, { "cve": "CVE-2026-89162", "url": "https://ubuntu.com/security/CVE-2026-89162", "cve_description": "In PCRE2 before 10.48, pcre2_serialize_encode might disclose two bytes to an adversary, typically in a situation where the access available to the adversary is already unsafe.", "cve_priority": "medium", "cve_public_date": "2026-09-11 05:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Fix large JIT stack allocation.", " - src/pcre2_jit_compile.c: Track oversized stack allocations and compute", " the growth threshold from the stack top instead of assuming the stack", " starts near its base, preventing an out-of-bounds write.", " - Authors: Zoltan Herczeg, Nicholas Wilson", " - 2b4038298072684b0fae29b15bedfb1a75bda46d", " - 6f9d7c1373262c541324a16a358785b33ef116cf", " - CVE-2026-103111", " * SECURITY UPDATE: Fix DFA workspace overflows", " - src/pcre2_dfa_match.c: Size new workspace blocks to fit the current", " ovector request and stop reusing a next block that is too small,", " preventing workspace overflow past the heap limit.", " - testdata/testinput6, testdata/testoutput6: Regression tests for the", " workspace overflow cases.", " - Author: Nicholas Wilson", " - c932e70451eafef922ebef364ac25042f0031135", " - CVE-2026-86145", " * SECURITY UPDATE: Fix pcre2_match to check for JIT support before JIT", " validation & execution", " - src/pcre2_internal.h: Declare the new jit_check_exec() helper.", " - src/pcre2_jit_misc.c: Add jit_check_exec() to verify the requested", " matching mode is compiled in before running JIT code.", " - src/pcre2_match.c: Gate the JIT fast path on jit_check_exec() so a", " missing JIT mode falls through to the interpreter's own UTF validation", " instead of skipping it.", " - Author: Zoltan Herczeg", " - f67db227af31bba7cdf2a7a00b97af91b588c2f5", " - CVE-2026-89156", " * SECURITY UPDATE: Use CU2BYTES for byte sizing in two allocation sites", " - src/pcre2_convert.c, src/pcre2_substring.c: Size allocations with", " CU2BYTES() instead of multiplying by PCRE2_CODE_UNIT_WIDTH, and reject", " lengths that would overflow the size calculation.", " - Author: Ilia Alshanetsky", " - 8156b3989a82f2ddf9504d8248496e9b124be7f3", " - CVE-2026-89157", " * SECURITY UPDATE: Fix compiler integer overflows", " - src/pcre2_compile.c: Guard pattern length accumulation against", " OFLOW_MAX and MAX_PATTERN_SIZE overflow.", " - src/pcre2_compile_class.c: Fix class list sizing overflow.", " - Author: Nicholas Wilson", " - ec9c286d5c10cf1c388b58a442ccefded42254fd", " - CVE-2026-89158", " * SECURITY UPDATE: Fix invalid UTF backwards-scan reads", " - src/pcre2_extuni.c, src/pcre2_match.c: Bound backwards scans at", " check_subject rather than start_subject so they cannot read into an", " invalid UTF prefix before it has been validated.", " - testdata/testinput10, testdata/testoutput10, testdata/testinput12,", " testdata/testoutput12-16, testdata/testoutput12-32: Regression tests", " for backwards scans over invalid UTF prefixes.", " - Author: Nicholas Wilson", " - 4889caf31a4c5a6b3c051f0031bf2dbd78f2c287", " - CVE-2026-89160", " * SECURITY UPDATE: Fix leak & stale PCRE2_MD_COPIED_SUBJECT if", " pcre2_jit_match used with existing match context.", " - src/pcre2_jit_match.c: Free a previously copied subject and clear the", " PCRE2_MD_COPIED_SUBJECT flag before reusing a match data block.", " - src/pcre2test.c: Detect a wrongly-set or wrongly-cleared copied-subject", " state after a JIT match.", " - doc/pcre2jit.3, doc/pcre2.txt, doc/html/pcre2jit.html: Document the", " pcre2_jit_match() fast-path limitations.", " - testdata/testinput17, testdata/testoutput17: Test the copied-subject", " handling on the JIT fast path.", " - Author: Nicholas Wilson", " - 1dcd0cf42a6a7cb62cc9a7c024196733abcfda95", " - CVE-2026-89161", " * SECURITY UPDATE: Write padding values to ensure pcre2_serialize_encode()", " outputs defined values.", " - src/pcre2_compile_class.c: Initialize the class-list alignment padding", " so serialized output contains no uninitialized bytes.", " - src/pcre2test.c: Verify the compiled pattern serializes without", " undefined memory.", " - Author: Nicholas Wilson", " - edc111a6831591f68b5355a08cc9df8be8f35304", " - CVE-2026-89162", "" ], "package": "pcre2", "version": "10.46-1ubuntu0.1", "urgency": "medium", "distributions": "resolute-security", "launchpad_bugs_fixed": [], "author": "Kyle Kernick ", "date": "Thu, 15 Oct 2026 15:15:22 -0600" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "7.0.0-38.38", "version": "7.0.0-38.38" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "7.0.0-42.42", "version": "7.0.0-42.42" }, "cves": [], "launchpad_bugs_fixed": [ 2168012 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-42.42", "" ], "package": "linux-meta", "version": "7.0.0-42.42", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Thu, 15 Oct 2026 09:49:31 +0300" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-41.41", "" ], "package": "linux-meta", "version": "7.0.0-41.41", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Mon, 12 Oct 2026 10:07:22 +0300" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-40.40", "" ], "package": "linux-meta", "version": "7.0.0-40.40", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Fri, 09 Oct 2026 19:56:38 +0300" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-39.39", "", " * Include v4l2loopback in default modules set for 26.04 (LP: #2168012)", " - [Packaging] Add dependencies for v4l2loopback", "" ], "package": "linux-meta", "version": "7.0.0-39.39", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 2168012 ], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 11:56:23 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "xxd", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.2141-1ubuntu4.9", "version": "2:9.1.2141-1ubuntu4.9" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.2141-1ubuntu4.10", "version": "2:9.1.2141-1ubuntu4.10" }, "cves": [], "launchpad_bugs_fixed": [ 2161203 ], "changes": [ { "cves": [], "log": [ "", " * Get the list of supported and unsupported Debian/Ubuntu codenames from", " distro-info, keeping the hard-coded list as fallback (LP: #2161203)", " - d/p/debversions-try-getting-data-from-distro-info.patch: adapt from", " 2:9.2.0858-1ubuntu2", " - d/t/debversions, d/t/control: add autopkgtest checking the codename", " lists with and without distro-info, and highlighting of the devel", " series in debian/changelog", "" ], "package": "vim", "version": "2:9.1.2141-1ubuntu4.10", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 2161203 ], "author": "Nadzeya Hutsko ", "date": "Tue, 13 Oct 2026 14:47:02 +0200" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-image-7.0.0-42-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "7.0.0-38.38", "version": null }, "to_version": { "source_package_name": "linux-signed", "source_package_version": "7.0.0-42.42", "version": "7.0.0-42.42" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1786013, 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-42.42", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "7.0.0-42.42", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Mehmet Basaran ", "date": "Thu, 15 Oct 2026 09:50:14 +0300" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-41.41", "" ], "package": "linux-signed", "version": "7.0.0-41.41", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Mon, 12 Oct 2026 10:07:49 +0300" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-40.40", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "7.0.0-40.40", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Mehmet Basaran ", "date": "Fri, 09 Oct 2026 19:57:15 +0300" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-39.39", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "7.0.0-39.39", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 11:55:49 +0200" } ], "notes": "linux-image-7.0.0-42-generic version '7.0.0-42.42' (source package linux-signed version '7.0.0-42.42') was added. linux-image-7.0.0-42-generic version '7.0.0-42.42' has the same source package name, linux-signed, as removed package linux-image-7.0.0-38-generic. As such we can use the source package version of the removed package, '7.0.0-38.38', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-main-modules-v4l2loopback-7.0.0-42-generic", "from_version": { "source_package_name": "linux-main-signed", "source_package_version": "7.0.0-38.38", "version": null }, "to_version": { "source_package_name": "linux-main-signed", "source_package_version": "7.0.0-42.42", "version": "7.0.0-42.42" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1786013, 1786013, 1786013, 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-38.38", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-main-signed", "version": "7.0.0-38.38", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Fri, 04 Sep 2026 11:06:20 +0300" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-37.37", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", " - [Packaging] debian/dkms-versions -- update from kernel-versions", " (main/2026.08.31)", "" ], "package": "linux-main-signed", "version": "7.0.0-37.37", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Wed, 02 Sep 2026 13:57:27 +0300" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-33.33", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-main-signed", "version": "7.0.0-33.33", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Sat, 29 Aug 2026 12:12:29 +0300" }, { "cves": [], "log": [ "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- update from kernel-versions", " (main/2026.08.03)", "" ], "package": "linux-main-signed", "version": "7.0.0-31.31+2", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Mon, 17 Aug 2026 14:28:21 +0200" }, { "cves": [], "log": [ "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", " - [Packaging] debian/dkms-versions -- update from kernel-versions", " (main/2026.08.03)", "", " * Miscellaneous Ubuntu changes", " - [Packaging]: lmm: Add a symbol to use a local signed.tar.gz file", " - [Packaging]: lmm: Allow DKMS to be cross compiled", " - [Packaging]: lmm: Add a method to create unsigned packages", " - [Packaging]: lmm: Install DKMSs in ubuntu/dkms", " - [Packaging]: Update manifest file with new patches", " - Ubuntu-7.0.0-31.31", "" ], "package": "linux-main-signed", "version": "7.0.0-31.31+1", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Sat, 01 Aug 2026 04:12:29 +0200" } ], "notes": "linux-main-modules-v4l2loopback-7.0.0-42-generic version '7.0.0-42.42' (source package linux-main-signed version '7.0.0-42.42') was added. linux-main-modules-v4l2loopback-7.0.0-42-generic version '7.0.0-42.42' has the same source package name, linux-main-signed, as removed package linux-main-modules-zfs-7.0.0-38-generic. As such we can use the source package version of the removed package, '7.0.0-38.38', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-main-modules-zfs-7.0.0-42-generic", "from_version": { "source_package_name": "linux-main-signed", "source_package_version": "7.0.0-38.38", "version": null }, "to_version": { "source_package_name": "linux-main-signed", "source_package_version": "7.0.0-42.42", "version": "7.0.0-42.42" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1786013, 1786013, 1786013, 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-38.38", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-main-signed", "version": "7.0.0-38.38", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Fri, 04 Sep 2026 11:06:20 +0300" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-37.37", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", " - [Packaging] debian/dkms-versions -- update from kernel-versions", " (main/2026.08.31)", "" ], "package": "linux-main-signed", "version": "7.0.0-37.37", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Wed, 02 Sep 2026 13:57:27 +0300" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-33.33", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-main-signed", "version": "7.0.0-33.33", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Sat, 29 Aug 2026 12:12:29 +0300" }, { "cves": [], "log": [ "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- update from kernel-versions", " (main/2026.08.03)", "" ], "package": "linux-main-signed", "version": "7.0.0-31.31+2", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Mon, 17 Aug 2026 14:28:21 +0200" }, { "cves": [], "log": [ "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", " - [Packaging] debian/dkms-versions -- update from kernel-versions", " (main/2026.08.03)", "", " * Miscellaneous Ubuntu changes", " - [Packaging]: lmm: Add a symbol to use a local signed.tar.gz file", " - [Packaging]: lmm: Allow DKMS to be cross compiled", " - [Packaging]: lmm: Add a method to create unsigned packages", " - [Packaging]: lmm: Install DKMSs in ubuntu/dkms", " - [Packaging]: Update manifest file with new patches", " - Ubuntu-7.0.0-31.31", "" ], "package": "linux-main-signed", "version": "7.0.0-31.31+1", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Sat, 01 Aug 2026 04:12:29 +0200" } ], "notes": "linux-main-modules-zfs-7.0.0-42-generic version '7.0.0-42.42' (source package linux-main-signed version '7.0.0-42.42') was added. linux-main-modules-zfs-7.0.0-42-generic version '7.0.0-42.42' has the same source package name, linux-main-signed, as removed package linux-main-modules-zfs-7.0.0-38-generic. As such we can use the source package version of the removed package, '7.0.0-38.38', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-modules-7.0.0-42-generic", "from_version": { "source_package_name": "linux", "source_package_version": "7.0.0-38.38", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "7.0.0-42.42", "version": "7.0.0-42.42" }, "cves": [ { "cve": "CVE-2026-98163", "url": "https://ubuntu.com/security/CVE-2026-98163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup: Avoid iteration of dying tasks with zero refcount The commit 260fbcb92bbea (\"cgroup: Move dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()\") extended the lifetime of tasks on the dying_tasks list. The iterators have provision to go through dying_tasks because of dying threadgroup leaders or explicit CSS_TASK_ITER_WITH_DEAD, however, it was expected that such tasks can obtain a new reference (that is possible before cgroup_task_release()/put_task_struct_rcu_user()). The tasks after cgroup_task_release() and before cgroup_task_free() are subject to race when they may or may not have ->usage count > 0. The race window is between css_task_iter_next() invocations when css_set_lock is released and we may arrive at a new ->task_pos. The iterator should not attempt to resurrect tasks whose ->usage count dropped to zero. (When that happens, __put_task_struct_rcu_cb() is already imminent and the returned task_struct would could be used after free.) As for the fix, we cannot simply check the signal->live count of a task on the dying list because that won't distinguish regular zombies waiting to be reaped from RCU remnant tasks that are going to be free'd. Therefore add an extra check to rule out ->usage==0 tasks from any iteration. The repeat: loop in css_task_iter_advance() doesn't consider ->usage count, so add a new loop to css_task_iter_next() to skip de-used tasks on the dying_list. Rough illustration of the possible race R (reader of cgroup.procs) T (thread) L (group leader) --------------------------------- -------------------------------- -------------------------------- L exits, signal->live > 0 cgroup_task_dead(L) css_set_skip_task_iters() // skips only cset->tasks list_add_tail(&L->cg_list, &cset->dying_tasks) css_task_iter_next() take css_set_lock css_task_iter_advance() leader && signal->live != 0 => it->task_pos = &L->cg_list release css_set_lock T exits --signal->live == 0 \t\t\t\t cgroup_task_dead(T) // css_set_lock release_task(T) cgroup_task_release(T) release_task(L) // zap_leader cgroup_task_release(L) put_task_struct_rcu_user(L) ...RCU... put_task_struct(L) L->usage = 0 /* L still on dying_tasks */ ...RCU... __put_task_struct(L) css_task_iter_next() // another iteration take css_set_lock it->task_pos = &L->cg_list get_task_struct(L) => addition on 0 drop css_set_lock cgroup_task_free(L) css_set_skip_task_iters() // dying skip comes too late free_task(L) cgroup_procs_show() task_pid_vnr(L)", "cve_priority": "medium", "cve_public_date": "2026-09-26 09:16:00 UTC" }, { "cve": "CVE-2026-90061", "url": "https://ubuntu.com/security/CVE-2026-90061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: skip double clone set expressions on element insert Both the dynset and newsetelem path clone the existing set expressions when setting set element expressions if no override expressions are provided. This results in a double clone, once to clone the template set expressions then another clone on the new element. Add a flag to annotate if userspace provides a override expression (ie. expression of the same type of the set but different configuration), otherwise borrow the existing expression from the set. Add conditionals to release expression iif they represent an override. Use this new override_exprs flag to dump the dynset expression override to userspace. This simplifies the existing logic and it also fixes a bug with the connlimit expression which results in a module refcount imbalance WARNING splat when resorting on the default set expressions.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90079", "url": "https://ubuntu.com/security/CVE-2026-90079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: fix cn20k mailbox lifetime on repeated rvu_mbox_init() rvu_mbox_init() is called separately for AF-PF mailboxes during probe and for AF-VF mailboxes when SR-IOV is enabled. Each call used to allocate a new ng_rvu object, leaking the first allocation when the pointer was overwritten on the second call. Sharing one ng_rvu across both paths exposed several teardown bugs: the error path freed all cn20k mailbox DMA and kfree()d ng_rvu even when only the failing init type should be unwound, leaving live AF-PF mailbox memory in use after an AF-VF init failure. mutex_init() was also re-run on the AF-VF path while AF-PF mailbox handlers could still hold rvu->mbox_lock. Probe and SR-IOV failure paths did not release cn20k mailbox DMA either, since cleanup only happened in rvu_remove(). Allocate ng_rvu once with devm_kzalloc(), initialize mbox_lock in the same block, unwind only the mailbox memory for the failing init type, and free cn20k mailbox DMA from the probe and pci_enable_sriov() error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90082", "url": "https://ubuntu.com/security/CVE-2026-90082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Cap MSI-X vectors to the device MSI-X table size mana_gd_query_max_resources() sizes gc->num_msix_usable from resp.max_msix and the CPU count, but never from the device MSI-X table. On a 1792 vCPU M-series VM that yields 1793 while the table has 1024 entries, and mana_gd_setup_remaining_irqs() then walks indices 1..1792, running off the end of the region mapped by msix_map_region(): BUG: unable to handle page fault for address: ff8e347f8b99800c RIP: 0010:msix_prepare_msi_desc+0x7a/0x90 RAX: 0000000000004000 RBX: ff4330cb164ea780 RCX: ff8e347f8b998000 Call Trace: __msi_domain_alloc_irqs+0x13a/0x440 msi_domain_alloc_irq_at+0x149/0x1b0 mana_gd_setup+0x351/0x890 mana_gd_probe+0x274/0x390 RAX is index 1024 * PCI_MSIX_ENTRY_SIZE, one entry past the table. msi_insert_desc() does range check the index, but only against the MSI domain hwsize, which matches the table only for devices on an MSI parent domain. With a global PCI/MSI domain hwsize is MSI_XA_DOMAIN_SIZE, so nothing bounds the request. Cap num_msix_usable with pci_msix_vec_count().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90087", "url": "https://ubuntu.com/security/CVE-2026-90087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: do not leak an hci_conn when a second LE connect is rejected create_le_conn_complete() decides whether the failed connection is still pending by comparing it against hci_lookup_le_connect(), which returns the first LE connection in BT_CONNECT. That is the same connection only while at most one is pending. Two can be pending. Connections created on the passive scan path sit in BT_CONNECT with HCI_CONN_SCANNING set and are invisible to hci_lookup_le_connect() until hci_le_create_conn_sync() clears the flag when their command is issued, so the -EBUSY guard in hci_connect_le() does not prevent a second connection from being queued while the first is still on the scan path. Whenever two connections are in BT_CONNECT at once, the lookup may return one connection while create_le_conn_complete() is reporting the failure of the other; the early exit then drops the error and hci_conn_failed() never runs on the connection that failed. The controller also rejects a second HCI_OP_LE_CREATE_CONN issued while another connection creation is still outstanding, per Core Spec Vol 4, Part E. The spec calls for Command Disallowed there; the bcm43438 observed here answers with an LMP/LL error code instead, which bt_to_errno() maps to the -EPROTO (-71) in the log below. The leaked connection stays in BT_CONNECT forever, and because hci_connect_le() refuses to dial while hci_lookup_le_connect() finds anything, every subsequent attempt to reach any peer fails with -EBUSY and no command reaches the controller at all. Seen on a bcm43438 with two BLE peers polled on the same interval (state 5 is BT_CONNECT; both handles are UNSET ones, allocated from the ida above HCI_CONN_HANDLE_MAX): Bluetooth: hci1: Opcode 0x2013 failed: -71 # hcitool con < LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL < LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL A btmon capture across the next ten minutes of connect attempts contains no HCI_OP_LE_CREATE_CONN at all; outgoing LE connections do not recover until the adapter is reset. With this change the same scenario fails the rejected connection cleanly and further connects to both peers go through. Ask about the connection itself instead of about the device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90093", "url": "https://ubuntu.com/security/CVE-2026-90093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: access chan->conn safely in get/setsockopt Since commit b66774b48dd9 (\"Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref\") l2cap_chan::conn has held reference and remains non-NULL also after the corresponding hci_conn is deleted. In this state accessing various fields eg. hci_conn::hdev is invalid, which leads to KASAN crash in l2cap_sock_setsockopt() access of conn->hcon->hdev. Check l2cap_chan::conn.hcon corresponds to an alive hci_conn before trying to use it in l2cap_sock.c. Hold l2cap_chan_lock() in getsockopt/setsockopt to ensure it stays alive, and to avoid data races in l2cap_chan fields.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90095", "url": "https://ubuntu.com/security/CVE-2026-90095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: Fix the condition to enable over-io-uring The existing condition in fuse_uring_cmd() is there only to avoid disabling io-uring for connections that already run with it, missing was a condition to refuse any IORING_OP_URING_CMD if the connection/channel didn't get enabled because of missing FUSE_INIT reply flag FUSE_OVER_IO_URING. Without the reply flag the barrier in fuse_uring_ready() doesn't work and IO could already be going on and cause deadlock states (at a minimum one between fch->bg_lock and queue->lock). The change itself is trivial, but brings behavior change, FUSE_OVER_IO_URING has to be set in the FUSE_INIT_REPLY by fuse servers to accept any IORING_OP_URING_CMD. Libfuse does that and the only non-libfuse implementation I found (fractal-fuse) also does it. Qemu patches for fuse-io-uring are not merged yet, as far as I know. Moved up is the smp_load_acquire(&fch->initialized) check, as a fuse-server implementation might try to setup io-uring before FUSE_INIT is processed and might have gotten -EOPNOTSUPP instead of -EAGAIN. Also fixed is a stale comment that explains the handling of the FUSE_OVER_IO_URING flag in early RFC versions. If there should be a report from any library or application we probably need to revert this commit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90099", "url": "https://ubuntu.com/security/CVE-2026-90099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: account classifier filter allocations to memcg Allocations in the tc classifier *_change() paths (filter objects, per-CPU counters, and per-filter aux data) use plain GFP_KERNEL without __GFP_ACCOUNT, allowing unprivileged users to pin kernel memory outside memcg charging. The shared tcf_exts_init_ex() action array allocation in cls_api.c was also uncharged; this patch closes it along with the per-classifier filter-object/percpu/aux allocations that remain unaccounted. Add GFP_KERNEL_ACCOUNT to: - the shared tcf_exts_init_ex() action array (cls_api.c), common to every filter of every classifier (32 pointers, 256 bytes); - the filter-object, per-CPU-counter, and per-filter aux allocations in cls_basic, cls_bpf, cls_cgroup, cls_flow, cls_flower, cls_fw, cls_matchall, cls_route and cls_u32; - the u32_init_knode() replace-path knode allocation (cls_u32.c), which allocates the same struct tc_u_knode + sel.keys on every replace of an existing knode and was missed by the create-path-only conversion. Also fix the cls_basic error path: basic_change() inserts fnew into the IDR before allocating the per-CPU counter. If alloc_percpu() fails the errout path kfree'd fnew without idr_remove, leaving a dangling pointer in the IDR. With GFP_KERNEL_ACCOUNT the percpu alloc becomes failable on demand (memcg at memory.max), making the dead path attacker-reachable and burning the handle permanently. Add the idr_remove on the percpu failure path, matching the basic_set_parms failure-path pattern. Note: vega@nebusec.ai provided a poc for basic_cls, but it was easy to extend to the other classifiers. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_CLS_* (the classifier being used), CONFIG_NET_CLS_ACT, CONFIG_MEMCG, CONFIG_USER_NS, CONFIG_NET_NS. - Unprivileged user in a fresh user+network namespace (unshare -Urn), or root with CAP_NET_ADMIN. - Create a large number of tc filters (e.g. tc filter add dev lo ingress ... ...) while watching a memcg-limited cgroup: system slab grows far faster than memory.current, pinning kernel memory outside memcg charging.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90104", "url": "https://ubuntu.com/security/CVE-2026-90104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.1: zero referring call lists before decoding decode_cb_sequence_args() allocates csa_rclists with kmalloc_objs(), so each referring_call_list starts uninitialized. decode_rc_list() assigns rcl_refcalls only when rcl_nrefcalls is nonzero. A valid list with zero referring calls therefore leaves the pointer uninitialized, and nfs4_callback_sequence() later passes stale slab contents to kfree(). Allocate csa_rclists with kzalloc_objs() so every rcl_refcalls member is NULL from the beginning, including valid empty referring call lists.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90105", "url": "https://ubuntu.com/security/CVE-2026-90105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: fix reading neigh ha Currently arp/neigh_reduce read neigh ha directly which can lead to partial reads while the neigh is being updated. Use neigh_ha_snapshot to take a stable snapshot of the address similar to route_shortcircuit which already does the right thing.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90106", "url": "https://ubuntu.com/security/CVE-2026-90106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: arp/nd proxy: fix reading neigh ha Currently neigh ha address is read directly, but that can result in torn/partial reads if the neigh is being updated. Use neigh_ha_snapshot to take a stable snapshot of the address.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90111", "url": "https://ubuntu.com/security/CVE-2026-90111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6mr: do not clone dst in ip6mr_cache_report() IPv6 input attaches a non-refcounted (NOREF) dst to skbs under RCU. When an ingress multicast packet misses MFC lookup, ip6mr_cache_unresolved() places the skb onto the unresolved queue, escaping the receive-side RCU grace period. If the underlying route is deleted and freed, and the MFC queue is later resolved with a wrong parent interface, ip6_mr_forward() invokes ip6mr_cache_report(..., MRT6MSG_WRONGMIF), which executes dst_clone(skb_dst(pkt)) on the freed dst entry, triggering a slab use-after-free. Report packets queued to mroute6_sk (a raw socket) and netlink notifications do not require an attached dst entry. Fix this by: 1. Removing dst_clone() in ip6mr_cache_report() and ensuring report skbs do not hold a dst. 2. Dropping skb_dst before queuing unresolved skbs in ip6mr_cache_unresolved(), matching the fact that multicast forwarding resolves outgoing routes anew via ip6_route_output().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90120", "url": "https://ubuntu.com/security/CVE-2026-90120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v5: Check get_logical_index() return value in MADT IAFFID parsing In gic_acpi_parse_iaffid() a given MADT GICC entry might not correspond to a logical cpu recognized by the kernel, resulting in the cpu variable initialization to an error value. Currently, the get_logical_index() return value is not checked for failure, which might result in out-of-bounds memory corruption while trying to index a per_cpu variable array. Add a check to evaluate get_logical_index() return value.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90121", "url": "https://ubuntu.com/security/CVE-2026-90121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v5: Clear per-CPU IRS data on teardown IRS affinity setup publishes an IRS pointer and IAFFID state in the per-CPU data before the remaining IRS initialization can fail. The error path then frees the IRS data without clearing that published state, leaving CPUs associated with freed memory. On initialization failure and normal IRS teardown, clear the per-CPU IRS association by removing the stale pointer to irs_data. Also invalidate the per-CPU IAFFID state for any CPUs that were tied to the IRS before it was freed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90142", "url": "https://ubuntu.com/security/CVE-2026-90142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Fix resize of the RX ring When a AF_XDP socket is attached, the virtnet_rx_resize should resize the rq->xsk_buffs XSK buffer array. Otherwise, when the size grows, the virtnet_rx_resume() causes a write past the end of the array. This is easily reproducable with ethtool -G ens3 rx 32 ./xdpsock -i eth0 -q 0 -r -z & ethtool -G eth0 rx 256", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90154", "url": "https://ubuntu.com/security/CVE-2026-90154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: scope session state changes to bound connections ksmbd_all_conn_set_status() treats every connection whose transient binding flag is set as belonging to the target SessionId. A logoff or session replacement can consequently move an unrelated connection to NEED_RECONNECT or NEED_SETUP. Pass the target session itself and select connections using either the connection-local session xarray or the session's permanent channel list. Use the same association test while waiting for requests to drain. Serialize session-wide status changes under request_lock and do not overwrite EXITING or RELEASING. Protect the shutdown transition with the same lock so a concurrent session update cannot revive a closing connection.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90156", "url": "https://ubuntu.com/security/CVE-2026-90156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: safely discard unregistered deferred locks When vfs_lock_file() defers a lock, smb2_lock() puts its ksmbd_lock on rollback_list before allocating and registering the asynchronous work. If either operation fails, rollback assumes that smb_lock->conn is initialized and dereferences NULL. The deferred file_lock also remains linked into the VFS blocked-lock state while it is freed. Keep the lock off rollback_list until async setup succeeds. On setup failures, explicitly unblock and wake the deferred lock before freeing it and its ksmbd wrapper.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90163", "url": "https://ubuntu.com/security/CVE-2026-90163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: call ksmbd_proc_cleanup() on module init failure When a later initializer fails, the unwind chain releases resources created after procfs and then jumps directly to class_unregister(). Returning an error from module_init() leaves the proc tree and its per-CPU counters allocated.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90164", "url": "https://ubuntu.com/security/CVE-2026-90164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: abort initialization when proc setup fails ksmbd_server_init() calls ksmbd_proc_init() before creating the remaining proc entries and server subsystems. ksmbd_proc_init() tears down partial state on a procfs or percpu_counter allocation failure, but returns void, so ksmbd_server_init() continues as if the counters were usable. Once userspace starts the server, server_ctrl_handle_init() calls ksmbd_proc_reset(), which reaches percpu_counter_set() with a NULL per-CPU counters pointer on SMP systems. The later ksmbd_proc_create() calls also receive a NULL parent and may create entries in the /proc root; ksmbd_proc_cleanup() cannot remove those entries because ksmbd_proc_fs is NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90174", "url": "https://ubuntu.com/security/CVE-2026-90174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-out-of-bounds read in ksmbd_alloc_user() ksmbd_alloc_user() copies resp->hash_sz bytes out of the mountd IPC login response with \tuser->passkey_sz = resp->hash_sz; \tuser->passkey = kmalloc(resp->hash_sz, KSMBD_DEFAULT_GFP); \tif (user->passkey) \t\tmemcpy(user->passkey, resp->hash, resp->hash_sz); resp->hash_sz is a __u16 supplied by the response, but resp->hash[] is only KSMBD_REQ_MAX_HASH_SZ bytes. A malformed or malicious login response can set hash_sz well beyond that (up to 65535), so the memcpy() reads past the end of the response object. ipc_validate_msg() does not bound hash_sz, so reject any response whose hash_sz exceeds the on-stack hash[] buffer before allocating and copying. [ 2030.238706] BUG: KASAN: slab-out-of-bounds in ksmbd_alloc_user+0x278/0x680 [ 2030.240549] Read of size 65535 at addr ffff888121bb6680 by task kworker/4:1/18611 [ 2030.242296] [ 2030.242710] CPU: 4 UID: 0 PID: 18611 Comm: kworker/4:1 Not tainted 7.1.0-next-20260623-virtme #96 PREEMPT(lazy) [ 2030.242732] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 2030.242743] Workqueue: ksmbd-io handle_ksmbd_work [ 2030.242763] Call Trace: [ 2030.242769] [ 2030.242776] dump_stack_lvl+0xa2/0xd0 [ 2030.242794] print_address_description+0x77/0x200 [ 2030.242815] ? ksmbd_alloc_user+0x278/0x680 [ 2030.242831] print_report+0x58/0x70 [ 2030.242848] kasan_report+0x117/0x150 [ 2030.242869] ? ksmbd_alloc_user+0x278/0x680 [ 2030.242888] kasan_check_range+0x3c7/0x3f0 [ 2030.242908] ? ksmbd_alloc_user+0x278/0x680 [ 2030.242925] __asan_memcpy+0x29/0x70 [ 2030.242942] ksmbd_alloc_user+0x278/0x680 [ 2030.242960] ksmbd_login_user+0xc3/0x120 [ 2030.242978] ntlm_authenticate+0x5e6/0x1b00 [ 2030.243017] ? __pfx_ntlm_authenticate+0x10/0x10 [ 2030.243035] ? ksmbd_session_lookup+0x188/0x1d0 [ 2030.243054] ? __pfx_ksmbd_session_lookup+0x10/0x10 [ 2030.243090] ? __sanitizer_cov_trace_switch+0x7b/0x140 [ 2030.243108] smb2_sess_setup+0x1e4a/0x27b0 [ 2030.243126] ? copy_from_kernel_nofault+0x199/0x300 [ 2030.243156] ? __pfx_smb2_sess_setup+0x10/0x10 [ 2030.243173] ? get_smb2_cmd_val+0xe3/0x1c0 [ 2030.243208] handle_ksmbd_work+0x954/0x1280 [ 2030.243230] ? __pfx_handle_ksmbd_work+0x10/0x10 [ 2030.243249] ? process_scheduled_works+0xa07/0x1490 [ 2030.243270] ? process_scheduled_works+0xa07/0x1490 [ 2030.243291] process_scheduled_works+0xa70/0x1490 [ 2030.243320] ? __pfx_process_scheduled_works+0x10/0x10 [ 2030.243340] ? do_raw_spin_lock+0x130/0x300 [ 2030.243358] ? lock_is_held_type+0x7b/0x110 [ 2030.243388] worker_thread+0x932/0xe20 [ 2030.243415] kthread+0x38a/0x470 [ 2030.243431] ? __pfx_worker_thread+0x10/0x10 [ 2030.243451] ? __pfx_kthread+0x10/0x10 [ 2030.243467] ret_from_fork+0x484/0x910 [ 2030.243485] ? __pfx_ret_from_fork+0x10/0x10 [ 2030.243501] ? __switch_to+0xc77/0x12c0 [ 2030.243523] ? __pfx_kthread+0x10/0x10 [ 2030.243540] ret_from_fork_asm+0x1a/0x30 [ 2030.243564] [ 2030.243570] [ 2030.290164] Allocated by task 19279: [ 2030.290911] kasan_save_track+0x3e/0x80 [ 2030.292179] __kasan_kmalloc+0x72/0x90 [ 2030.293217] __kvmalloc_node_noprof+0x3ff/0x6b0 [ 2030.294467] handle_generic_event+0x59b/0x750 [ 2030.295345] genl_family_rcv_msg_doit+0x238/0x340 [ 2030.296553] genl_rcv_msg+0x606/0x7b0 [ 2030.297129] netlink_rcv_skb+0x22b/0x4a0 [ 2030.298500] genl_rcv+0x2d/0x40 [ 2030.299273] netlink_unicast+0x7ba/0x930 [ 2030.300019] netlink_sendmsg+0x8c3/0xb00 [ 2030.301073] __sock_sendmsg+0xec/0x140 [ 2030.301579] __sys_sendto+0x357/0x470 [ 2030.302255] __x64_sys_sendto+0xe3/0x100 [ 2030.303425] do_syscall_64+0x135/0x460 [ 2030.304763] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2030.305594] [ 2030.305819] The buggy address belongs to the object at ffff888121bb6640 [ 2030.305819] which belongs to the cache kmalloc-192 of size 192 [ 2030.309595] The buggy address ---truncated---", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90177", "url": "https://ubuntu.com/security/CVE-2026-90177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check pointer type for all atomic RMW paths Atomic RMW verification records an instruction pointer type only when the current destination is PTR_TO_ARENA. A second path can therefore reach the same instruction with an ordinary pointer without comparing it against the saved arena type. The post-verification fixup uses the saved type to rewrite the instruction to BPF_PROBE_ATOMIC for every path. Record the actual destination type for all atomic RMW paths so the existing mismatch check rejects incompatible uses of one instruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90182", "url": "https://ubuntu.com/security/CVE-2026-90182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-iocost: clear delay state when freeing policy data iocg_kick_delay() turns sufficiently large debt into an explicit block-cgroup delay with blkcg_set_delay(), setting blkg->use_delay to -1 and incrementing blkcg->congestion_count. Clearing it again depends on iocg_kick_delay() running from the period timer, the waitq timer or the issue path. ioc_pd_free() removes the iocg from active_iocgs and cancels its waitq timer, and no further bios can arrive, so once it has run nothing is left which can reduce the debt and clear the delay. The blkcg stays marked congested for the rest of its life. blk_cgroup_congested() then returns true for every task in that cgroup and its descendants: page_cache_sync_ra() cuts readahead to a single page, page_cache_async_ra() skips it altogether, and __folio_throttle_swaprate() takes swap_avail_lock and schedules a throttle on anonymous folio allocation. Clear it explicitly, after the list removal and the synchronous hrtimer_cancel() so that neither timer processing nor an I/O path can re-arm it. The free callback can also see policy data which was never attached to a blkg, hence the pd->blkg check.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90183", "url": "https://ubuntu.com/security/CVE-2026-90183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: clear delay state when freeing policy data io.latency can throttle a group which has no latency target of its own. When a sibling misses its target, check_scale_change() scales down its peers, and a peer that reaches queue depth one gets blkcg_use_delay() called on it on every further scale-down, even with min_lat_nsec == 0. iolatency_pd_offline() resets the target through iolatency_set_min_lat_nsec(), which clears the delay only on a nonzero to zero transition, so it never clears such a peer. Freeing the policy data then leaves blkg->use_delay set and blkcg->congestion_count elevated with nothing left that can drop it. blk_cgroup_congested() then returns true for every task in that cgroup and its descendants for as long as the cgroup lives: page_cache_sync_ra() cuts readahead to a single page, page_cache_async_ra() skips it altogether, and __folio_throttle_swaprate() takes swap_avail_lock and schedules a throttle on anonymous folio allocation. Clear the delay in iolatency_pd_free(). By then bio-held blkg references have drained, or the queue is frozen for policy deactivation, so check_scale_change() cannot re-arm it. The free callback can also see policy data which was never attached to a blkg, hence the pd->blkg check.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90206", "url": "https://ubuntu.com/security/CVE-2026-90206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix max_qid race between configfs and controller allocation The function nvmet_subsys_attr_qid_max_store() can race against nvmet_alloc_ctrl() when a subsystem's max_qid limit is modified. Suppose max_qid is currently 64. If nvmet_alloc_ctrl() executes: ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1); and at this exact point, a userspace process changes max_qid to 128, nvmet_subsys_attr_qid_max_store() will set the new max_qid value. It attempts to delete active controllers to force a reconnect, but the new controller won't be deleted because it hasn't been added to the subsys->ctrls list yet. nvmet_alloc_ctrl() then proceeds and adds the new controller to the subsys->ctrls list. Later, when nvmet_install_queue() is called, it will see max_qid set to 128, but the memory allocated for sqs is only sized for 64 entries. This results in a KASAN out-of-bounds warning and potential memory corruptions. Fix this by protecting the queue allocations and list insertion in nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem) to modify the attribute, this safely prevents the configfs writer from modifying max_qid during controller creation. Copy the max_qid from the subsystem to the controller's structure during the allocation; ctrl->max_qid never changes as long as the controller remains in LIVE state, so this will prevent similar race conditions.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90208", "url": "https://ubuntu.com/security/CVE-2026-90208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/samsung_pwm: Switch to raw_spinlock_t type Samsung PWM timer might be used as a clock source on some legacy systems. When PREEMPT_RT is enabled on ARM, regular spinlock is converted to a sleeping lock (mutex-based), which must not be used in atomic context such as hard interrupt handlers. Switch the samsung_pwm_lock to the raw_spinlock, which remains a true non-sleeping spinlock even under PREEMPT_RT.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90211", "url": "https://ubuntu.com/security/CVE-2026-90211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, s390: Clear fetch destination on faulting arena atomic Same missing register clear as on riscv64. A RMW atomic on an arena pointer is converted to BPF_PROBE_ATOMIC and gets an exception table entry, but bpf_jit_probe_atomic_pre() only fills in the arena base and the probe offset, leaving probe->reg at the -1 that bpf_jit_probe_init() set, which bpf_jit_probe_post() writes into the entry and ex_handler_bpf() then reads back as \"there is nothing to clear\". That is right for a plain BPF_{ADD,AND,OR,XOR}, which only writes memory, but an RMW carrying BPF_FETCH also reads the old value into a register: src_reg for BPF_{ADD,AND,OR,XOR} | BPF_FETCH and BPF_XCHG, and r0 for BPF_CMPXCHG. So on a fault over an unmapped arena page the program resumes at the landing pad with whatever that register held before the atomic instead of the 0 that every other BPF_PROBE_* access delivers. Fill probe->reg in from bpf_atomic_load_reg(). Unlike x86-64 and arm64, s390x does not report arena violations from its exception handler, so there is no access direction to correct here, only the missing register clear.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90212", "url": "https://ubuntu.com/security/CVE-2026-90212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/efi: Avoid voluntary preemption with efi_mm installed Gus reports a bad kernel memory access when using software PAN (CONFIG_ARM64_SW_TTBR0_PAN=y) on a machine with support for EFI runtime services: Unable to handle kernel access to user memory outside uaccess routines at virtual address 00000000f322ff30 Mem abort info: ESR = 0x0000000096000004 FSC = 0x04: level 0 translation fault Internal error: Oops: 0000000096000004 [#1] SMP Workqueue: efi_rts_wq efi_call_rts pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : efi_call_rts+0xd8/0x288 Call trace: efi_call_rts+0xd8/0x288 (P) process_one_work+0x178/0x4f8 worker_thread+0x194/0x328 This is because the fpsimd context management code called from __efi_fpsimd_begin() can preempt voluntarily, returning later to the EFI code with an incorrect value for TTBR0_EL1 thanks to the deferred mm switching used by the software PAN implementation. Since EFI runtime services cannot preempt voluntarily and because the fpsimd switching code does not rely on the TTBR0_EL1 mappings, simply reorder the fpsimd switch so that it occurs before we change the page-table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90217", "url": "https://ubuntu.com/security/CVE-2026-90217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Compare iterator types during state pruning An iterator stack slot can be MEM_RCU or PTR_UNTRUSTED. These states must not be equal, or the verifier can prune an unsafe path. Compare the pointer type for STACK_ITER slots.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90231", "url": "https://ubuntu.com/security/CVE-2026-90231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix unconfined user namespace restriction forced stack If a task is already confined by a stack the unprivileged transition restriction on unconfined is not correctly, applied. This results in an escape if two transitions through an unconfined profile can be executed. Fix this by pushing the check into the per profile label build. The check will always be done against unconfined and result in a stack of just the unconfined component when necessary.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90234", "url": "https://ubuntu.com/security/CVE-2026-90234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Return a delegation the client fails to record When an NFS server grants a delegation in an OPEN reply, nfs_inode_set_delegation() records it on the client. However, three of its error flows return without sending DELEGRETURN. A delegation can be relinquished only by DELEGRETURN (RFC 8881 Section 20.2.4), so dropping one silently leaves the server believing the client still holds it. If the server happens to recall that delegation, the client answers CB_RECALL with NFS4ERR_BADHANDLE because it has no record of the stateid. The server revokes the delegation and moves it onto its cl_revoked list, because the client never sends the FREE_STATEID that would drain it. Every subsequent SEQUENCE reply then carries SEQ4_STATUS_RECALLABLE_STATE_REVOKED, and the client's state manager loops issuing TEST_STATEID across its delegations without ever clearing the condition. The window is easy to reach now that a server offers a write delegation on any write OPEN: a delegation recalled for one opener races a re-open that the server answers with a fresh write delegation. Instead of dropping it, hand the delegation back during these error flows.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90237", "url": "https://ubuntu.com/security/CVE-2026-90237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: move custom expectation support to helper Originally, the ct expectation support called nf_ct_helper_ext_add() for confirmed conntracks, which is invalid, triggering a splat. This was fixed by commit 1710eb913bdc (\"netfilter: nft_ct: skip expectations for confirmed conntrack\") which restricted it to unconfirmed conntracks. However, early insertion of expectations into the expectations list when the conntrack is unconfirmed leads to stale entries pointing to the wrong hlist_head through .pprev due to ct extension reallocation. Commit 7c9664351980 (\"netfilter: move nat hlist_head to nf_conn\") moved the nat hlist_head to nf_conn for this reason: 1. ... 2. When reallocation of extension area occurs we need to fixup the bysource hash head via hlist_replace_rcu. I'd rather not increase the size of the struct nf_conn for this feature has very limited scope: only one expectation can be created at a time given expect_clash() will make nf_ct_expect_related() reports EBUSY. For this reason, relax nf_ct_expect_related() not to drop packets in case expectation creation fails, therefore, expectation creation becomes best effort. To address this issue, add an internal ct helper and attach it to the conntrack entry to streamline the custom ct expectation support with existing ct helpers. Expose a new nf_conntrack_helper_release() function to release the internal helper that is allocated and attached to the conntrack entry to create the custom expectations. The nft_ct module removal always waits for rcu grace period, then the NULL helper callback is observed after this. This patch also restricts the creation of expectations to different helpers other than this custom helper that is created for this type of expectations.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90242", "url": "https://ubuntu.com/security/CVE-2026-90242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix iopf_refcount leak on RID domain replacement intel_iommu_attach_device() enables IOPF for the new domain but never disables it for the old one. device_block_translation(), called at the start of the function, tears down translation but does not touch any IOPF state; blocking_domain_attach_dev() has to call iopf_for_domain_remove() explicitly before invoking it for exactly this reason. identity_domain_attach_dev() has the same problem. Its comment claims that no PRI handling is needed because the device has been put in the blocking state, but the blocking state and the IOPF reference count are independent of each other. As a result, replacing a domain that has an iopf_handler with another domain at RID level leaks a reference in info->iopf_refcount. The count never drops back to zero, so iopf_queue_remove_device() is never called and iommu_disable_pci_pri() triggers its WARN_ON(info->iopf_refcount) when the device is released. The PASID paths already handle this correctly by way of iopf_for_domain_replace(); convert the two RID paths to do the same. Using the replace helper rather than a bare remove keeps the enable before the disable, so the reference count does not transiently reach zero and evict the device from the IOPF queue.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90246", "url": "https://ubuntu.com/security/CVE-2026-90246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix integer overflow in verify_tags() bounds check verify_tags() validates the tagset table unpacked from a policy blob. For each set it reads a count and checks that advancing the index by that count stays inside sets.table[]: \tu32 cnt = tags->sets.table[i]; \tif (i+cnt >= tags->sets.size) { i, cnt and sets.size are all u32, so i+cnt is evaluated modulo 2^32. sets.table[] is filled by unpack_tagsets() with aa_unpack_u32(), so every entry is a raw unbounded 32-bit word taken from the policy blob, and verify_tags() is the function that is supposed to validate it. A count close to U32_MAX makes the sum wrap to a small value, the guard passes, and the inner loop then walks sets.table[++i] past the end of the kcalloc(size, sizeof(u32)) allocation. Note that sets.size is bounded by 65535, because unpack_tagsets() reads it with aa_unpack_array() as a u16, so the wrap cannot be reached by growing the table; it is reached purely through the attacker-supplied count. With sets.size = 2 and sets.table = { 0, 0xffffffff }: i = 0: cnt = 0, guard 0 + 0 >= 2 is false, inner loop does not run i = 1: cnt = 0xffffffff, guard (1 + 0xffffffff) mod 2^32 == 0 >= 2 is false, so the guard is bypassed and the inner loop reads sets.table[2] -- one element past a two element allocation The walk continues until an out-of-bounds value happens to be >= hdrs.size or the access faults, so a crafted policy yields an out-of-bounds read on the policy load path (aa_replace_profiles -> aa_unpack -> unpack_policydb -> unpack_tags -> verify_tags). unpack_tags() runs before the perms and DFA tables are unpacked, so no other table needs to be well formed to reach it. Policy load is gated by aa_may_manage_policy(), which checks CAP_MAC_ADMIN relative to the subject's own user namespace rather than the init user namespace, so with the default unprivileged_userns_apparmor_policy=1 the path is reachable from an unprivileged task in a matched-level nested namespace, not only by a globally privileged one. Perform the addition in u64 so that it cannot wrap, restoring the intended i + cnt < sets.size guarantee.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90256", "url": "https://ubuntu.com/security/CVE-2026-90256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use proto_lock for l2cap_data to fix l2cap_disconn_ind hci_conn::l2cap_data is accessed without locks in l2cap_disconn_ind via hci_conn_timeout (disc_work) -> hci_proto_disconn_ind -> l2cap_disconn_ind. This is UAF if the l2cap_conn is deleted concurrently. disc_work is disabled sync in hci_conn_del(), so we cannot take hci_dev_lock in disc_work. Fix by using proto_lock to guard l2cap_data, in addition to hdev->lock which is held in other access paths.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90261", "url": "https://ubuntu.com/security/CVE-2026-90261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: flush active metadata block group at btree_writepages() start btree_writepages() writes the btree inode's dirty metadata in ascending logical address order. On a zoned filesystem only one metadata and one system block group is active for writing at a time, and check_bg_is_active() (via btrfs_check_meta_write_pointer()) pivots the active block group as writeback moves from one block group to the next. If the active block group sits at a higher logical address than another block group that also holds dirty metadata, the ascending walk reaches the lower one first and, to write it, has to finish the active block group and activate the lower one. It cannot finish a block group that still has unsent IO, and during WB_SYNC_ALL && !for_sync (commit) writeback it deliberately refuses to wait for that IO under fs_info->zoned_meta_io_lock, as that can deadlock. The pivot thus cannot issue the submission itself either, so it gives up: btrfs_check_meta_write_pointer() returns -EAGAIN, which btrfs_write_and_wait_transaction() treats as fatal and aborts the transaction, forcing the filesystem read-only. This happens intermittently under metadata-heavy relocation (e.g. fstests btrfs/187). Flush the active metadata and system block groups at the start of btree_writepages(), under the fs_info->zoned_meta_io_lock it already holds, so they have no unsent IO left and the later pivot can finish them and make forward progress.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90263", "url": "https://ubuntu.com/security/CVE-2026-90263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: check if root is readonly when setting posix acl For a filesystem which has btrfs read-only property set to true, all write operations including acl and xattr should be denied. However, acl can still be set even if btrfs ro property is true. This happens because no function on the set_acl code path checks the root is readonly or not. It was checked in btrfs_setxattr_trans() but got removed in commit 353c2ea735e4 (\"btrfs: remove redundant readonly root check in btrfs_setxattr_trans\") That commit didn't check if all the callers properly check the root's read-only flag. A previous fix is commit b51111271b03 (\"btrfs: check if root is readonly while setting security xattr\"). Always check if the root is read-only before performing the set acl operation.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90267", "url": "https://ubuntu.com/security/CVE-2026-90267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix special_vec mempool leak when scsi_alloc_sgtables() fails sd_set_special_bvec() allocates a special payload page for UNMAP and WRITE SAME commands. If scsi_alloc_sgtables() fails afterward in sd_setup_unmap_cmnd() or sd_setup_write_same{10,16}_cmnd(), the SCSI midlayer does not call uninit_command() because RQF_DONTPREP is not set yet, leaking the page. Call sd_uninit_command() on error, and clear RQF_SPECIAL_PAYLOAD after freeing the page.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90270", "url": "https://ubuntu.com/security/CVE-2026-90270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: Disable driver unbind to avoid UAF When a user unbinds an MSC and that MSC is the only MSC left for a component then the corresponding mpam_component will be freed. If the user then goes on to read the schemata file in the resctrl filesystem then the mpam_component will be accessed from resctrl_arch_get_config() leading to a use after free. As the MPAM driver is not a module the unbind sysfs interface is the only way to trigger the remove. Instead of dealing with the complexity of allowing some unused MSC to unbind just remove the unbind sysfs interface.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90271", "url": "https://ubuntu.com/security/CVE-2026-90271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: Fix a NULL pointer dereference on unbinding after an error interrupt If a user unbinds an MSC after mpam_disable() has been run in response to an error interrupt then a dereference of a NULL pointer occurs as mpam_disable() sets the drvdata to NULL. Add an early return to the driver remove callback to avoid this.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90273", "url": "https://ubuntu.com/security/CVE-2026-90273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable In the perf enable path, there are missing cases where cscfg_csdev_disable_active_config() is not called: - Branch broadcast is selected but not supported by the hardware - etm4_enable_hw() fails This can lead to a leak of config_desc->active_cnt. Fix this by properly calling cscfg_csdev_disable_active_config() in these error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90288", "url": "https://ubuntu.com/security/CVE-2026-90288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: renesas: rcar-gen2: Fix double of_node_put on phy creation failure for_each_child_of_node_scoped() releases the node reference on scope exit, so the explicit of_node_put(np) in the devm_phy_create() error path drops it twice. Drop the redundant of_node_put() and let the scoped cleanup handle it.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90289", "url": "https://ubuntu.com/security/CVE-2026-90289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Resize MST HDCP per-connector arrays to 32 AMDGPU_DM_MAX_DISPLAY_INDEX is 31. It suggest a maximum number of 32 connectors. But the way it's used is like MAX_DISPLAY_COUNT. Hence we're off by one with DRM core, which supports a max of 32 connectors. Rename AMDGPU_DM_MAX_DISPLAY_INDEX to AMDGPU_DM_MAX_DISPLAY_COUNT to match its actual use, and increase the size to 32 to match the originally intended size.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90300", "url": "https://ubuntu.com/security/CVE-2026-90300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Clear buf on error in __bpf_get_task_stack Both bpf_get_task_stack and bpf_get_task_stack_sleepable helpers that use __bpf_get_task_stack have buf defined as ARG_PTR_TO_UNINIT_MEM argument and we should initialize the buf on every return path. Adding missing buf memset for __bpf_get_task_stack fail paths. This provides deterministic buffer contents, which is useful when the buffer is used directly as a map key.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90301", "url": "https://ubuntu.com/security/CVE-2026-90301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: o2hb: quiesce negotiate handlers and timeout work Heartbeat regions publish struct o2hb_region as the private data for the NEGO_TIMEOUT and NEGO_APPROVE o2net handlers as soon as make_item() creates the configfs region. The approve handler can call o2hb_arm_timeout(), so a peer can touch the region timeout work before dev_store() has finished building the heartbeat runtime, or after teardown has started to shut that runtime back down. The final configfs put also has to keep reg alive until the last in-flight o2net callback drops its handler reference. o2net_unregister_handler_list() blocks future handler lookups, but it does not wait for sc_rx_work that already passed o2net_handler_get(). That drain needs to cover local listener teardown as well, where the o2net ordered workqueue may already be inside destroy_workqueue(). Fix the lifetime rule in both directions. Initialize the region delayed works before publishing reg through the o2net handler table, keep new or stopping regions non-armable with hr_stopping, and quiesce both delayed works on failed-start and teardown paths even when no heartbeat thread is left to call o2hb_disarm_timeout(). Then unregister handlers before tearing down handler-visible region state and make the drain wait for the active or destroying o2net ordered workqueue before release frees reg. The buggy scenario involves two paths, with each column showing the order within that path: region lifecycle: late negotiate callback: 1. make_item() registers the 1. o2net_process_message() gets a region handlers before heartbeat handler for reg. dev_store() has built a 2. The callback runs after the lookup runnable heartbeat context. lock is dropped and dereferences reg. 2. A failed start or rmdir 3. An approve or timeout path tries to stops the heartbeat thread, queue reg's delayed work, or release quiesces existing work, and races the callback body after handler drops the final configfs ref. unregister. 3. region_release() must drain 4. The callback or delayed work can handler-visible o2net rx work outlive reg unless lifecycle code before freeing reg. keeps the region non-armable and drains the active-or-destroying o2net workqueue. Validation reproduced this kernel report: KASAN slab-use-after-free in __run_timers+0x22c/0x5b0 Write of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __run_timers+0x22c/0x5b0 kasan_report+0xe0/0x110 _raw_spin_unlock_irqrestore+0x27/0x60 try_to_wake_up+0x191/0xf70 timer_expire_remote+0xae/0xf0 run_timer_softirq+0x19b/0x1a0 handle_softirqs+0x156/0x660 __irq_exit_rcu+0xc4/0x160 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x6c/0x80 asm_sysvec_apic_timer_interrupt+0x1a/0x20 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 o2hb_heartbeat_group_make_item+0x3c/0x600", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90310", "url": "https://ubuntu.com/security/CVE-2026-90310", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90311", "url": "https://ubuntu.com/security/CVE-2026-90311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: hwmon: Remove hwmon class device along with its parent The current code creates one hwmon device per thermal zone type and that device is registered under the first thermal zone of the given type. That turns out to be problematic when the thermal zone holding the hwmon device is removed. For example, say that there are two ACPI thermal zones on a system /sys/devices/virtual/thermal/thermal_zone0/ /sys/devices/virtual/thermal/thermal_zone1/ The current code registers a hwmon class device for thermal_zone0 only: /sys/devices/virtual/thermal/thermal_zone0/hwmon0/ because the type is \"acpitz\" for both of them, but it adds a sysfs attribute that belongs to thermal_zone1 under it: /sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp2_input There is also /sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input which belongs to thermal_zone0. When thermal_zone0 is removed, say because the ACPI thermal driver is unbound from the underlying platform device, thermal_remove_hwmon_sysfs() skips the removal of hwmon0 because of the temp2_input attribute belonging to thermal_zone1 which effectively prevents thermal_zone0 removal from making progress. Address this by making thermal_remove_hwmon_sysfs() remove the entire hwmon class device interface for the given thermal zone type when the thermal zone device holding it is removed. To prevent races with thermal_add_hwmon_sysfs() that may interfere with this, carry out the entire addition and removal of hwmon sysfs interfaces for thermal zones under thermal_hwmon_list_lock. Also adjust the layout of the labels in thermal_add_hwmon_sysfs() to the current kernel coding style to align with the new \"unlock\" label.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90315", "url": "https://ubuntu.com/security/CVE-2026-90315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI/sysfs: Add lockdown checks to legacy I/O and memory handlers Currently, the legacy I/O and memory sysfs handlers do not check security_locked_down(LOCKDOWN_PCI_ACCESS), leaving the legacy_io and legacy_mem files unprotected when the kernel is locked down. Commit eb627e17727e (\"PCI: Lock down BAR access when the kernel is locked down\") added the check to pci_write_config(), pci_mmap_resource(), and pci_write_resource_io() to prevent userspace from programming DMA-capable hardware that could be used to modify kernel code, but did not cover the legacy handlers. As a result, root can still write arbitrary I/O ports and map the legacy I/O and memory spaces while the kernel is locked down, which is the same capability the lockdown is meant to remove. Add the same check to pci_write_legacy_io(), pci_mmap_legacy_mem(), and pci_mmap_legacy_io(). These generic handlers cover both architectures that define HAVE_PCI_LEGACY (such as Alpha and PowerPC). [bhelgaas: add Link]", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90320", "url": "https://ubuntu.com/security/CVE-2026-90320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate external xattr entries when reading metadata ocfs2_validate_xattr_block() checks the xattr block header before the block reaches higher-level xattr users, but it does not verify that a non-indexed block's xh_count and entry offsets fit inside the block. Indexed buckets likewise reach list/get consumers after ECC without an entry-bounds check. Use the flat xattr entry validator for non-indexed external xattr blocks, and use a bucket-specific validator for indexed buckets at metadata read time. The bucket validator keeps the entry array bounded by the first bucket block while checking name/value offsets against the bucket block they target. Reject corrupted external xattr metadata before listxattr() or getxattr() can walk out-of-range entry arrays or name/value offsets. Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2_xattr_list_entries+0xd7/0x190 Read of size 1 at addr ffff88810a654007 by task ocfs2_xattr_lis/630 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 kasan_report+0xe0/0x110 ocfs2_xattr_list_entries+0xd7/0x190 ocfs2_listxattr+0x3f6/0x610 listxattr+0x90/0xe0 path_listxattrat+0xed/0x220 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90321", "url": "https://ubuntu.com/security/CVE-2026-90321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate inline xattrs during inode block validation Patch series \"ocfs2: validate xattr entry bounds\", v7. This series validates OCFS2 xattr entry name/value bounds when xattr metadata is read and validated, before getxattr() or listxattr() can walk out-of-range entry arrays or offsets from corrupted metadata. This patch (of 2): ocfs2_validate_inode_block() verifies a dinode before OCFS2 users walk metadata from it, but inline xattr metadata is still checked only in operation-specific consumers. The existing ibody lookup helper validates inline header placement and entry count, but inode block validation does not reject entry name/value bounds. Add a flat xattr entry validator and call it from inode block validation for inline xattrs. Keep the operation paths on their existing header/count lookup checks; the full entry bounds check now runs when the inode block is validated at read time. Reject corrupted inline xattr metadata before ocfs2_xattr_ibody_get() or listxattr() can walk past the inline storage. Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2_xattr_find_entry+0x5a/0x170 Read of size 2 at addr ffff8881242a2000 by task python3/529 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 kasan_report+0xe0/0x110 ocfs2_xattr_find_entry+0x5a/0x170 ocfs2_xattr_get_nolock+0x20a/0x820 ocfs2_xattr_get+0x10c/0x1e0 __vfs_getxattr+0xe2/0x130 vfs_getxattr+0x185/0x1b0", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90323", "url": "https://ubuntu.com/security/CVE-2026-90323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: validate auto buf reg before taking uring_cmd With UBLK_F_AUTO_BUF_REG, invalid sqe->addr can fail after ublk_fill_io_cmd() has set UBLK_IO_FLAG_ACTIVE. The uring_cmd is completed while the tag stays active, which can hang teardown. Split validation from buffer apply so the check has no side effects, then take the uring_cmd and store the already-validated buffer. Apply the same order in FETCH so io->buf is not written before __ublk_fetch() state checks.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90330", "url": "https://ubuntu.com/security/CVE-2026-90330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix FF device cleanup on init failure hidpp_ff_init() creates the input force-feedback device with input_ff_create(), then allocates the HID++ FF private data, effect ID array, and workqueue. If any of those allocations fail after input_ff_create() succeeds, the function returns an error without destroying the FF device. Add an unwind path that frees the private allocations made by hidpp_ff_init() and calls input_ff_destroy() for failures after input_ff_create() succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90331", "url": "https://ubuntu.com/security/CVE-2026-90331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: asus: refactor the two workqueues and init sequence Multiple issues have been found within the hid-asus driver: - unchecked size in asus_raw_event() - unclean teardown of asus_probe on failure - possible use-after-free in asus_probe - multiple workqueue used for jobs where one was enough - sleeping calls in atomic context - packets of incorrect size being sent to the keyboard controller Join the two workqueues into one reusing the stopping mechanism of the brightness workqueue, use the joined workqueue to also move the asus_wmi_send_event() sleeping call away from atomic context and add a size check in asus_raw_event().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90332", "url": "https://ubuntu.com/security/CVE-2026-90332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: ep: Flush cached MSI write before unmapping the iATU The MSI-X path already flushes any posted MSI-X write before tearing down its iATU mapping. That was added by commit c22533c66cca (\"PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry\") to make sure the write reaches the Root Complex before the outbound window that translates it disappears. The MSI path has the same problem but no equivalent flush. When the Endpoint driver caches an MSI target address and later observes that the Root Complex has changed it, dw_pcie_ep_raise_msi_irq() unmaps the existing iATU entry and reprograms it for the new address. Between the last MSI writel() and the unmap there may still be a posted write sitting in the fabric, and unmapping the iATU entry can drop or misroute that write. Fix this by reading back from the mapped MSI window before the unmap. The readback drains any posted MSI writes through the same iATU entry that mapped them, which is the same logic the MSI-X path uses. [mani: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90335", "url": "https://ubuntu.com/security/CVE-2026-90335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: skip cdev_del() when no cdev is registered TTY device registration can fail before a cdev is allocated. Serial core keeps the port so setserial can still use it, and later removal passes the NULL cdev slot to cdev_del(), causing a NULL-pointer dereference. Only delete the cdev when the slot is not NULL.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90336", "url": "https://ubuntu.com/security/CVE-2026-90336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: core: clear freed pointers on uart_register_driver() failure uart_register_driver() leaves drv->state pointing to freed memory when tty_alloc_driver() fails. If tty_register_driver() fails, drv->tty_driver also retains a pointer after its reference is dropped. Drivers that use drv->state as an \"already registered\" flag can then skip registration on the next probe and pass the freed state to uart_add_one_port(). This issue was found with failslab on QEMU's raspi1ap board by failing registration and binding the PL011 port again. Clear both pointers on their failure paths, as uart_unregister_driver() already does.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90337", "url": "https://ubuntu.com/security/CVE-2026-90337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: core: do fallible allocations before the console can be registered serial_core_add_one_port() allocates uport->tty_groups after uart_configure_port(), which may register the console. If the allocation fails, the driver unwinds the port while its console remains registered. The earlier uport->name allocation has a related failure path that leaves state->uart_port linked to a port being freed. Failslab reproduced a NULL dereference in PL011 console output and a KASAN use-after-free in i.MX console output after failed binds. Allocate the name and tty_groups before linking the port and configuring it. Reserve space for the optional driver attribute group because config_port() may populate uport->attr_group during configuration.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90342", "url": "https://ubuntu.com/security/CVE-2026-90342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix mmap_lock deadlock on arena lock failure Reported by the Sashiko AI review. arena_vm_fault() returns VM_FAULT_RETRY when it can't take arena->spinlock, but it never took mmap_lock. The fault path assumes a VM_FAULT_RETRY handler already dropped mmap_lock and re-takes it on the retry, so mmap_lock gets taken twice and can deadlock: \tdo_user_addr_fault() \t{ \t\tfault = handle_mm_fault(...); // calls arena_vm_fault() \t\tif (fault & VM_FAULT_RETRY) \t\t\tgoto retry; // re-locks mmap_lock \t\tmmap_read_unlock(mm); \t} Return VM_FAULT_SIGBUS instead, for two reasons: 1. We could keep VM_FAULT_RETRY, but then we'd have to drop the fault lock first and cap the retry ourselves, the way __folio_lock_or_retry() does. 2. A failed raw_res_spin_lock_irqsave() already means a possible deadlock was detected, so retrying just hits the same lock again. So returning VM_FAULT_RETRY here is overkill.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90345", "url": "https://ubuntu.com/security/CVE-2026-90345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix P2P action frame handling without device vif Some P2P action frame paths assume the P2P device vif is always available. That is not true when userspace sends non-P2P public action frames through the primary interface, or when action-frame abort runs after the P2P device vif has not been created. Fall back to the primary vif when aborting an action frame without a P2P device vif, and guard P2P device saved IE access before using it for peer channel search.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90346", "url": "https://ubuntu.com/security/CVE-2026-90346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: clean up color-change beacon data on errors nl80211_color_change() calls nl80211_parse_beacon() for the beacon_next template, which can allocate params.beacon_next.mbssid_ies and .rnr_ies. A parsing failure returned directly instead of using the out: cleanup, leaking any allocations completed before the error. Allocate the nested attribute table before parsing beacon_next. Its allocation failure can then return before beacon data exists, while a later parsing failure uses out: to release the parsed data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90347", "url": "https://ubuntu.com/security/CVE-2026-90347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry Commit e057b9477232 (\"arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates\") attempted to resolve a long-standing issue with syscall entry tracing, where a tracer is able to manipulate the first syscall argument without being subjected to seccomp or audit checking. Unfortunately, that fix was incomplete [1], as it failed to update 'orig_x0' between a tracer updating x0 during a seccomp ptrace exit (SECCOMP_RET_TRACE) and the seccomp filter being re-evaluated. Rather than add hooks to the core seccomp code, instead move the synchronisation code into the ptrace GPR and syscall setting code so that 'orig_x0' is kept up to date with x0 whenever we're stopped on the syscall entry path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90355", "url": "https://ubuntu.com/security/CVE-2026-90355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: clear stale link state on full reset After a full chip reset, mac80211 reconfig replays interface, link and channel context setup. mt7996_vif_link_add() short-circuits when the link_id is still marked in mvif->valid_links, a state introduced for postponing link teardown to interface removal. The reset path frees the link structures without clearing those bits, so the replayed setup never re-creates dev_info/bss_info/STA records in the restarted firmware and never re-registers the link wcid, leaving the device inoperative. The reset path also leaks every allocated MLD index: per-link indices and the per-vif group/remap indices are re-allocated from scratch during reconfig, but the old bits stay set in the masks, so repeated full resets exhaust the index space. Clear valid_links in the reset vif iterator and reset the MLD index masks alongside the existing omac_mask clearing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90359", "url": "https://ubuntu.com/security/CVE-2026-90359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject >8 byte return values on return-reading trampoline paths btf_distill_func_proto() builds the function model used for the fentry/fexit/fmod_ret/fsession trampolines and struct_ops. It has accepted a 16-byte __int128 return value since the trampoline was introduced: __get_type_size() returns the integer's type size, and the return-type check only rejected ret < 0. But the BPF trampoline preserves only 8 bytes of the return value (RAX on x86, i.e. R0). For an attach type that reads the target's return value the second half (RDX / R3) is neither saved nor restored, so a program attached to a function returning a 16-byte value corrupts the value seen by the real caller and itself observes only half of it. struct_ops trampolines have the same limitation. This affects the attach types that read the target's return value: fexit, fmod_ret and fsession (plus the _multi variants of fexit and fsession), and struct_ops. fentry/fentry_multi run before the target returns and are unaffected. Reject a >8 byte return value for these attach types in bpf_check_attach_target() and bpf_check_attach_btf_id_multi(), and for struct_ops in bpf_struct_ops_desc_init().", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90365", "url": "https://ubuntu.com/security/CVE-2026-90365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: cancel reset and rc work on device unregister Both drivers cancelled dump_work on unregister but left reset_work and rc_work to be flushed only by destroy_workqueue() in mt76_free_device(), which runs after the hw is unregistered and the hardware stopped. A reset_work that fires in that window calls ieee80211_restart_hw() and re-arms mac_work on an unregistered hw, and rc_work touches station state being torn down. Cancel both up front, alongside dump_work.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90369", "url": "https://ubuntu.com/security/CVE-2026-90369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix out-of-bounds access in mmio copy helpers mt76_mmio_write_copy() and mt76_mmio_read_copy() iterate up to ALIGN(len, 4), so a length that is not a multiple of four reads past the source buffer (write_copy) or writes past the destination (read_copy). Copy the aligned body in the loop and handle the remaining tail through a 4-byte bounce buffer, keeping the register access width unchanged.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90380", "url": "https://ubuntu.com/security/CVE-2026-90380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt792x: fix use-after-free in mt76_rx_poll_complete A use-after-free issue occurs in mt76_rx_poll_complete due to a race condition. The STA has already been removed, but the rx_status still had a pointer to the wcid in the STA. Set the links' wcid pointers to be NULL for a MLD in mt7925_sta_pre_rcu_remove() BUG: KASAN: invalid-access in mt76_rx_poll_complete+0x280/0x470 Call trace: dump_backtrace+0xec/0x128 show_stack+0x18/0x28 dump_stack_lvl+0x40/0xc8 print_report+0x1b8/0x710 kasan_report+0xe0/0x144 do_bad_area+0x120/0x260 do_tag_check_fault+0x20/0x34 do_mem_abort+0x54/0xa8 el1_abort+0x3c/0x5c el1h_64_sync_handler+0x40/0xcc el1h_64_sync+0x7c/0x80 mt76_rx_poll_complete+0x280/0x470 mt76_dma_rx_poll+0x114/0x51c mt792x_poll_rx+0x60/0xf8 napi_threaded_poll_loop+0xe0/0x450 napi_threaded_poll+0x80/0x9c kthread+0x11c/0x158 ret_from_fork+0x10/0x20", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90381", "url": "https://ubuntu.com/security/CVE-2026-90381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix handling channel context with different bands in mt76_switch_vif_chanctx() When performing channel switches on different radios within a short timeframe, channel contexts with different bands can be carried for each struct ieee80211_vif_chanctx_switch. Rework mt76_switch_vif_chanctx() to properly handle this scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90384", "url": "https://ubuntu.com/security/CVE-2026-90384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: release the folio batch on iomap callback failures A sashiko review of an unrelated patch points out that the folio batch mechanism used for iomap zero range fails to release the batch in a couple error scenarios. If either calls to ->iomap_end() or ->iomap_begin() fail, the direct return paths bypass the batch cleanup. The ->iomap_end() case is not a practical issue at the moment because there is no user of the mechanism that returns an error from this path. The ->iomap_begin() case is theoretically possible because XFS can invoke the fill helper and error out at various points thereafter. This subtly complicates things because XFS does not transfer iomap_flags to the iomap data structure in the error path. To deal with both of these issues, first make sure to invoke the cleanup helper in the error path for either fs callback. Second, update the helper to clear the flag unconditionally and release the batch so long as it is populated. This more clearly delineates the purpose of the flag to control the I/O path and not necessarily the status of the fbatch, so add a comment around this as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90401", "url": "https://ubuntu.com/security/CVE-2026-90401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: remove REQ_NOWAIT support from raid1/10/456 REQ_NOWAIT support in md personalities that can block internally is fundamentally incomplete. While reads can avoid some blocking paths, write requests can still encounter cases where one mirror succeeds while another returns -EAGAIN. At that point md cannot distinguish queue pressure from a real device failure, so it can neither record a bad block nor safely retry the write without REQ_NOWAIT, leaving mirrors with divergent data. Rather than continue advertising REQ_NOWAIT support for personalities that cannot implement it correctly, remove it from raid1, raid10 and raid456. Keep REQ_NOWAIT for linear and raid0, which only remap bios to their underlying devices; stacked limits will still clear the feature if any component device lacks REQ_NOWAIT support.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90408", "url": "https://ubuntu.com/security/CVE-2026-90408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix overreads in ath12k_wmi_process_csa_switch_count_event() There is no policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, so the parse infrastructure does not enforce a minimum length for the event struct. Additionally, the num_vdevs field is taken directly from firmware and used as a loop bound over the vdev_ids array without checking that it fits within the TLV payload. Either condition can cause an out-of-bounds read. Add a TLV policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT so the parse infrastructure enforces a minimum length for the fixed-size event struct. Add a helper ath12k_wmi_tlv_data_len() to recover the payload length of a parsed TLV from the header preceding its data pointer. Use it in ath12k_wmi_process_csa_switch_count_event() to bound num_vdevs before the loop. Compile tested only.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90409", "url": "https://ubuntu.com/security/CVE-2026-90409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Add vm_bind region with kbo range overlap check When a VM is created, caller has to specify the range of the address space carve-out set aside for mapping kernel BO's. That means vm_bind mappings of UM-exposed BO's should not intersect with that region, but at the moment we're not checking this. At first, I thought of giving these values to drm_gpuvm_init() through its reserve_{offset, range} arguments, but it turns out that is meant for VM address spans that are not managed through the usual drm_gpuvm split/merge circuit, so storing the end of the user VA range at VM creation time and doing a quick check in the vm_bind ioctl path was the simplest workaround. The new check also makes sure vm_bind range doesn't overflow the size of a 64-bit unsigned integer. That was already being done further down the call stack inside drm_gpuvm_sm_map -> drm_gpuvm_range_valid, but it's best to fail early in the driver before GPUVM functions are invoked so that we won't waste time allocating vm_bind context resources.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90412", "url": "https://ubuntu.com/security/CVE-2026-90412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix return status of RMI log page on allocation failure nvmet_execute_get_log_page_rmi() leaves 'status' holding NVME_SC_SUCCESS (set by the successful nvmet_req_find_ns() call) when the kzalloc() for the log buffer fails. It then jumps to the out label and completes the request with a success status, so the host is told the command succeeded while no data was transferred. Initialize 'status' to NVME_SC_INTERNAL, matching the smart log handler, so an allocation failure is reported as an internal error.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90417", "url": "https://ubuntu.com/security/CVE-2026-90417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Fix dereg_skb leak and double free in write_tpt_entry() When the device is in the fatal error state, write_tpt_entry() returns -EIO before handing the caller's preallocated skb to the transmit path; its allocation-failure returns do the same. c4iw_dereg_mr() ignores the error and frees mhp, leaking mhp->dereg_skb. c4iw_get_dma_mr() instead frees the skb a second time after dereg_mem() already consumed it, a double free. Make write_tpt_entry() the sole owner of a non-NULL skb, freeing it on every return preceding handoff to c4iw_ofld_send(): fatal error, tpt and stag allocation failure. c4iw_ofld_send() consumes the skb on success and error alike, so drop the redundant kfree_skb() in c4iw_get_dma_mr() after dereg_mem().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90421", "url": "https://ubuntu.com/security/CVE-2026-90421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: Fix UAF when probe runs concurrent to dyn ID removal Dynamic IDs are only guaranteed to be valid when dynids.lock is held, as remove_id_store() can free the node. Thus, make a copy in pci_match_device(). Also, clarify that the id parameter is only valid during probe.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90427", "url": "https://ubuntu.com/security/CVE-2026-90427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Don't fall back to a freed smmu after devm_krealloc() __tegra241_cmdqv_probe() uses devm_krealloc() to grow @smmu into the larger tegra241_cmdqv, which frees the original @smmu once it relocates. A failure after that returned NULL, and the caller then dereferenced the freed @smmu on its fallback path. Return an int and take @smmu by reference instead, then update *smmu to the reallocated pointer after devm_krealloc() succeeds, so the caller and its fallback path both use the live @smmu rather than the freed original.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92479", "url": "https://ubuntu.com/security/CVE-2026-92479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: Avoid NULL CQE dereference when reporting invalid tags The single-doorbell completion path can call ufshcd_compl_one_cqe() with a NULL CQE. If no command is associated with the completion tag, the warning message dereferences the CQE while reporting the error. Avoid that dereference and include the invalid tag in the warning.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92480", "url": "https://ubuntu.com/security/CVE-2026-92480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Validate string descriptors The string descriptor length includes a two-byte header while the UTF-16 payload starts after it. utf16s_to_utf8s() expects a count of UTF-16 code units, not bytes. Passing the payload byte count can make it read beyond the descriptor buffer. Validate that the payload has an even byte count, pass a code-unit count to the converter, and allocate sufficient UTF-8 output space. The raw string buffer starts after the descriptor header but its size is bLength. Copying bLength bytes from that pointer can read beyond the response buffer. Allocate a zeroed bLength-sized buffer and copy only the UTF-16 payload. This preserves the raw buffer size consumed by the RPMB device-ID ABI while avoiding the overread.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92482", "url": "https://ubuntu.com/security/CVE-2026-92482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: use devm_gpiochip_add_data() for GPIO chip The gpio_chip is allocated with device-managed memory but registered with the non-managed gpiochip_add_data(). This was harmless while the drivers were built-in, but once they can be built as modules and unbound/rmmod'd, devm frees the gpio_chip's memory while it is still registered, causing a use-after-free. Register it with devm_gpiochip_add_data() so it shares the same device-managed lifecycle, which also lets the manual gpiochip_remove() error paths go away.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92483", "url": "https://ubuntu.com/security/CVE-2026-92483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: liveupdate: Remember FLB retrieve() status LUO keeps track of successful retrieve attempts on an FLB. It does so to avoid multiple retrievals of the same FLB. Multiple retrievals cause problems because once the FLB is retrieved, the serialized data structures are likely freed and the FLB is likely in a very different state from what the code expects. All this works well when retrieve succeeds. When it fails, luo_flb_retrieve_one() returns the error immediately, without ever storing anywhere that a retrieve was attempted or what its error code was. If the user attempts to retrieve another file registered with the same FLB, LUO will attempt to call the FLB's retrieve() callback again. The retry is problematic for much of the same reasons listed above. The FLB is likely in a very different state than what the retrieve logic normally expects (e.g. some KHO pages may have already been restored and freed). There is no sane way of attempting the retrieve again. Remember the error retrieve returned and directly return it on a retry. This is done by changing the retrieved bool to a retrieve_status integer. A value of 0 means retrieve was never attempted, a positive value means it succeeded, and a negative value means it failed and the error code is the value. This is similar to commit f85b1c6af5bc (\"liveupdate: luo_file: remember retrieve() status\") which did the same for LUO files.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92485", "url": "https://ubuntu.com/security/CVE-2026-92485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix WARNING in bpf_tracing_link_release The trampoline could be corrupted by the blindly 'tr->flags = BPF_TRAMP_F_TAIL_CALL_CTX' in verifier. 1. A fexit attached to a tail_call_reachable prog. 'tr->flags' became 'BPF_TRAMP_F_CALL_ORIG | BPF_TRAMP_F_TAIL_CALL_CTX'. And, the trampoline would poke the target prog's nop insn using jmp insn instead of call insn. 2. Another fexit loaded with the same tail_call_reachable prog target. 'tr->flags' became 'BPF_TRAMP_F_TAIL_CALL_CTX'. 3. Close the first fexit link. Due to no BPF_TRAMP_F_CALL_ORIG in 'tr->flags', the trampoline will fail to restore the prog's nop insn using call insn. [ 3.410719] WARNING: kernel/bpf/syscall.c:3551 at bpf_tracing_link_release+0x53/0x60, CPU#1: test_progs/98 ... [ 3.428793] bpf_link_free+0x58/0x130 [ 3.429293] bpf_link_release+0x23/0x30 Fix the warning by updating 'tr->flags' with '|=' and lock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92503", "url": "https://ubuntu.com/security/CVE-2026-92503", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix ABBA deadlock in ext4_xattr_inode_cache_find() Syzbot/stress-ng reported an ABBA deadlock in ext4 when exercising concurrent xattr workloads (using the ea_inode mount/format option). The deadlock occurs between the running transaction and the eviction thread: - Task 1 (stress-ng): Holds a reference to a shared mbcache_entry (ce) and calls ext4_xattr_inode_cache_find() -> ext4_iget() to retrieve the corresponding EA inode. Since the EA inode is currently being evicted, ext4_iget() blocks in __wait_on_freeing_inode() waiting for eviction to complete. - Task 2 (eviction thread): Currently evicting the same EA inode in ext4_evict_ea_inode(). It calls mb_cache_entry_wait_unused(oe) which blocks waiting for Task 1 to release the reference to the mbcache_entry. To break this deadlock, implement a new ext4_iget() configuration flag named EXT4_IGET_NOWAIT. When set, perform a non-blocking lookup of the inode via VFS's find_inode_nowait() API. If the inode is currently being evicted (marked with I_FREEING or I_WILL_FREE) or created (I_CREATING), or if it is not present in the VFS inode cache (cache miss), simply skip it (returning -ENOENT) rather than waiting for eviction/creation to complete, breaking the ABBA cycle. Since we return -ENOENT immediately on a cache miss, we never attempt to allocate a new inode or call iget_locked(), completely eliminating any TOCTOU race window. If the returned inode is I_NEW, wait for its initialization to clear via wait_on_new_inode(). If initialization fails and the inode is unhashed during wait_on_new_inode() waking up (e.g., due to an I/O read error in another thread), safely drop the reference and return -ENOENT. This unhashed check is executed unconditionally on all cache-hit pathways to properly handle concurrent initialization failures. Finally, standard validation checks (including is_bad_inode, EXT4_EA_INODE_FL, file_acl, and xattr flags) are executed as normal inside check_igot_inode() to fully guarantee VFS-layer safety. In ext4_xattr_inode_cache_find(), invoke ext4_iget() with the new EXT4_IGET_NOWAIT flag to perform the non-blocking cache search.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93043", "url": "https://ubuntu.com/security/CVE-2026-93043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disallow interpreter fallback for gotox insn The interpreter does not recognize the BPF_JMP|BPF_JA|BPF_X insn, which is used for insn_array map. Thereafter, it would hit the BUG_ON() in ___bpf_prog_run() at run time. [ 2.563726] BPF interpreter: unknown opcode 0d (imm: 0x0) [ 2.564557] ------------[ cut here ]------------ [ 2.565206] kernel BUG at kernel/bpf/core.c:2349! [ 2.565882] Oops: invalid opcode: 0000 [#1] SMP PTI Set jit_required as true when insn_array map is used in the prog in order to disallow interpreter fallback for gotox insn in core.c::__bpf_prog_select_runtime().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93044", "url": "https://ubuntu.com/security/CVE-2026-93044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disallow interpreter fallback for arena-related insns Since the interpreter does not support the arena-related insns, interpreter fallback should not be allowed for these insns in core.c::__bpf_prog_select_runtime(). Currently, when the interpreter executes the arena ST/LDX/STX insns, it would hit the BUG_ON() in ___bpf_prog_run() at run time. [ 2.579196] BPF interpreter: unknown opcode a2 (imm: 0x0) [ 2.579998] ------------[ cut here ]------------ [ 2.580652] kernel BUG at kernel/bpf/core.c:2349! [ 2.581314] Oops: invalid opcode: 0000 [#1] SMP PTI Set jit_required as true when arena map is used in the prog to disallow interpreter fallback for arena-related insns.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93047", "url": "https://ubuntu.com/security/CVE-2026-93047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Associate BOs with every job that accesses them A submission can expand into a chain of jobs (e.g. bin + render + cache clean). Implicit synchronization in v3d_submit_lock_reservations() is gated on each job's bo[], but the BO list was only ever attached to the last job of the chain. When that last job is a trailing CACHE_CLEAN job, the job that actually consumes the BOs (that is, a RENDER or CSD job) was left with bo_count == 0 and picked up no implicit dependencies. It could therefore be dispatched to the hardware and read a BO while another context was still writing it, leading to data corruption. Attach the BOs to the job that consumes them, so (1) it acquires the correct implicit dependencies during reservation locking and (2) they are kept mapped until the end of the submission. Give it references to all consuming job's BOs through v3d_job_reference_bos() instead of looking the handles up a second time; that avoids a redundant lookup and guarantees both jobs reference the exact same objects. As the CACHE_CLEAN job now carries a BO array as well, add a per-job `has_implicit_dep` flag so that only the consuming jobs take implicit dependencies. The CACHE_CLEAN job (a global flush) and the BIN job (binning waiting on another context is not a realistic scenario) are excluded.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93069", "url": "https://ubuntu.com/security/CVE-2026-93069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: OPP: Fix cleanup ordering Commit 173e02d67494 (\"OPP: Initialize scope-based pointers inline\") added initialization for all pointers. In some cases, the ordering was changed so that *opp_table was initialized after *opp. This also changes the order of the registered cleanup functions. When the cleanup happens, this can cause use-after-free errors when the last reference is released and the release function _opp_kref_release tries to access the already freed opp->opp_table. Initialize *opp_table before *opp again to fix this and ensure the correct cleanup order.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93081", "url": "https://ubuntu.com/security/CVE-2026-93081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix SCMI device destroy lifetimes scmi_child_dev_find() drops the reference returned by device_find_child() before returning the scmi_device pointer. A concurrent unregister can then release the device while the destroy path is still using the returned pointer. Make the lookup helper return the device_find_child() reference and keep it until scmi_device_destroy() has finished unregistering the child. Also split device_unregister() in __scmi_device_destroy() so the SCMI bus ID is not made reusable until after device_del() has removed the old scmi_dev.N name from sysfs. This avoids a new SCMI device reusing the same ID while the old device is still registered. The final device release callback is also a possible cleanup path when SCMI children are deleted by driver core recursion rather than __scmi_device_destroy(). Release the SCMI bus ID from a common helper used by destroy, register-failure and final-release paths, and clear scmi_dev->id after freeing it so the final release cannot free the same ID again.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93094", "url": "https://ubuntu.com/security/CVE-2026-93094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix dp_link_peer dangling references on AP vdev rollback ath12k_mac_vdev_create() for an AP vdev creates the bss self-peer via ath12k_peer_create(), which finishes by calling ath12k_dp_link_peer_assign() to publish the dp_link_peer in the dp_hw->dp_peers[peerid_index] RCU table, in the dp_peer's link_peers[] array, and in the per-addr rhashtable. If a step after ath12k_peer_create() fails the function jumps to err_peer_del, which open-codes a WMI peer_delete and waits for the unmap / delete_resp events. The wait_for_peer_delete_done() path relies on ath12k_dp_link_peer_unmap_event() freeing the dp_link_peer when the unmap arrives, but err_peer_del never calls ath12k_dp_link_peer_unassign() first. The published references in the dp_hw RCU table, dp_peer->link_peers[] and the rhashtable are left pointing at the dp_link_peer that unmap_event then frees, producing dangling pointers and use-after-free on subsequent lookups. Replace the open-coded sequence with a call to ath12k_peer_delete(), which already does ath12k_dp_link_peer_unassign() before sending the WMI command. This drops the published references before the dp_link_peer is freed, in the same order as the normal teardown path in ath12k_mac_remove_link_interface(). Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93096", "url": "https://ubuntu.com/security/CVE-2026-93096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/features: Serialize multi-part Get/Set Feature transfers A Get or Set Feature payload larger than the mailbox payload size is split into several mailbox commands. mbox_mutex only serializes individual mailbox commands and is dropped between iterations of these loops. Nothing serializes the multi-part transfer as a whole. cxl_get_feature() and cxl_set_feature() are reachable concurrently from fwctl (per-fd RPCs run under a read-held registration lock) and from the EDAC scrub/ECS/repair paths, so two transfers to the same mailbox can interleave their parts and corrupt the device's transfer context. Add a per-mailbox feat_mutex and hold it across the whole transfer in both functions. It nests outside mbox_mutex (which is taken inside cxl_internal_send_cmd()), and is taken nowhere else, so no lock-ordering inversion is introduced.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93099", "url": "https://ubuntu.com/security/CVE-2026-93099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix UAF from worker threads when domains are removed The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters and may sleep while doing so. They are scheduled via delayed_work embedded in struct rdt_l3_mon_domain. Architecture allocates and frees these domains from CPU hotplug callbacks under cpus_write_lock(), and the workers acquire cpus_read_lock() to keep the domain alive across their access. A use-after-free can occur when a worker is blocked waiting for cpus_read_lock() while the hotplug core holds cpus_write_lock(): the architecture frees the rdt_l3_mon_domain that contains the worker's work_struct. When the worker unblocks, the container_of() it performs on the embedded work pointer dereferences freed memory. Drop cpus_read_lock() from the workers and instead drain pending and in-flight work synchronously before the architecture can free the domain. Since architecture offlines the domain under cpus_write_lock() after it has been unlinked from the RCU list and a grace period has elapsed, no new work can be scheduled. The cancel only needs to wait out existing work. Drop rdtgroup_mutex during CPU offline around cancel_delayed_work_sync() so that a worker waiting on the mutex can complete before re-pinning the work on a different CPU. When offlining a CPU the architecture may iterate over resources in any order. For example, the MBA control domain may be offlined before or after a corresponding L3 monitor domain. Ensure that resctrl fs cancels the workers no matter what order the architecture offlines the domains.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93104", "url": "https://ubuntu.com/security/CVE-2026-93104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rvt: Return NULL after port allocation failure rvt_alloc_device() deallocates the IB device when its port array cannot be allocated but then returns the pointer to the released allocation. Callers treat any non-NULL value as valid and dereference it, resulting in a use-after-free. Return NULL immediately after deallocation so callers can propagate the allocation failure.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93105", "url": "https://ubuntu.com/security/CVE-2026-93105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: esp: do not unref managed frag pages in esp_ssg_unref() esp_ssg_unref() releases the page references held on the source scatterlist after the AEAD operation completes. It calls skb_page_unref() on every frag page for an out-of-place transform (req->src != req->dst), and in the error path of esp_output_tail() (already_unref == true) on the request's own scatterlist. This is wrong when the skb carries managed frags (SKBFL_MANAGED_FRAG_REFS). Managed frags are owned by a zerocopy ubuf and the skb does not hold a per-frag page reference; io_uring SEND_ZC with a registered buffer attaches the bvec pages this way via io_sg_from_iter(). The rest of the stack honours this invariant: skb_release_data() skips the per-frag unref when SKBFL_MANAGED_FRAG_REFS is set, and skb_zcopy_managed() is the guard used at the other unref sites. esp_ssg_unref() is missing that guard, so for a managed-frag skb it drops a page reference the skb never acquired. This can underflow the page reference count and free a page that is still in use. Guard the function with skb_zcopy_managed() so both unref paths are skipped for managed-frag skbs, matching skb_release_data().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93116", "url": "https://ubuntu.com/security/CVE-2026-93116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: asus-wmi: fix resource leaks on probe failure During driver initialization in asus_wmi_add(), various subsystems are registered sequentially. However, the error path labels are out of order relative to the registration sequence. Specifically: 1. If asus_wmi_custom_fan_curve_init() fails, the driver jumps to fail_custom_fan_curve. Because this label is placed below fail_sysfs, it bypasses the cleanup calls for the input device and sysfs groups, which were successfully registered before, leaking those resources. 2. If asus_screenpad_init() fails, the driver jumps to fail_screenpad. Because fail_screenpad is placed below fail_backlight, it bypasses the cleanup calls for backlight and rfkill, leaking those resources. Fix these resource leaks by reordering the error path labels in asus_wmi_add() to match the exact reverse order of the resource allocations.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93122", "url": "https://ubuntu.com/security/CVE-2026-93122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uac: validate rate list length before storing UAC1 and UAC2 configfs rate-list attributes parse a comma-separated list of sampling rates and store each parsed value in fixed-size arrays. The arrays have UAC_MAX_RATES entries, but the store paths do not check that the input contains at most that many tokens before writing through opts->name##s[i++]. Writing more than ten rates therefore writes past the end of the p_srates[] or c_srates[] array in struct f_uac1_opts or struct f_uac2_opts. With CONFIG_UBSAN_BOUNDS enabled, writing an 11-entry rate list to the UAC1 p_srate attribute reports: UBSAN: array-index-out-of-bounds drivers/usb/gadget/function/f_uac1.c:1669:1 index 10 is out of range for type 'int [10]' __ubsan_handle_out_of_bounds.cold f_uac1_opts_p_srate_store configfs_write_iter vfs_write ksys_write do_syscall_64 The same reproducer against the UAC2 p_srate attribute reports: UBSAN: array-index-out-of-bounds drivers/usb/gadget/function/f_uac2.c:2087:1 index 10 is out of range for type 'int [10]' __ubsan_handle_out_of_bounds.cold f_uac2_opts_p_srate_store configfs_write_iter vfs_write ksys_write do_syscall_64 Reject additional tokens once UAC_MAX_RATES entries have been parsed. Also keep the original kstrdup() pointer for kfree(), because strsep() advances the parsing cursor. Freeing the advanced cursor leaks the original buffer on successful parses and can free an interior pointer on some error paths.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93125", "url": "https://ubuntu.com/security/CVE-2026-93125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max check_kfunc_args() detects a kfunc argument named rdonly_buf_size or rdwr_buf_size and stores reg->var_off.value into meta->r0_size, a u64, and does not bound it. check_kfunc_call() later copies that value into the returned register's mem_size field: meta->r0_size = reg->var_off.value; ... regs[BPF_REG_0].mem_size = meta.r0_size; regs[BPF_REG_0].mem_size is u32. A constant whose upper 32 bits are set gets truncated instead of causing a load-time rejection, so the verifier records a PTR_TO_MEM register with an approximately 4 GiB mem_size for whatever allocation the kfunc returned. A later access check against that register uses the truncated, wrong bound. Reject rdonly_buf_size/rdwr_buf_size values that exceed U32_MAX at the point meta->r0_size is set.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93127", "url": "https://ubuntu.com/security/CVE-2026-93127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Drop scalar id on sign-extending narrowing stack fills When a spilled scalar is filled back with a sign-extending narrowing load (BPF_MEMSX), check_stack_read_fixed_off() copies the spilled register including its scalar id, but coerce_reg_to_size_sx() then sign-extends the filled register's value. If the same slot is also filled with a plain zero-extending load (BPF_MEM), both destination registers share the id yet hold different values. A later 'if == const' then refines the sign-extended register through sync_linked_regs() to a value it does not have at runtime (e.g. the verifier believes 0x80000000 while the register is 0xffffffff80000000), which can be turned into an out-of-bounds access. Drop the shared scalar id at the sign-extension site in check_mem_access() when sign extension actually changes the value, mirroring the BPF_MOVSX handling in check_alu_op() (no_sext = reg_umax < 2^(size*8-1)).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93129", "url": "https://ubuntu.com/security/CVE-2026-93129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-base: Fix handling of ultra performance key The commit message of commit 5fbd827eb9c2 (\"platform/x86: dell-wmi: Recognise or support new switches\") states that the ultra performance key contains additional data after the type and code fields. The event data passed to dell_wmi_process_key() is already parsed, so \"buffer\" already starts after those two fields. Use the correct index for accessing the first data field to avoid a potential buffer overread.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93135", "url": "https://ubuntu.com/security/CVE-2026-93135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject programs with inlined helpers if JIT is not available When an architecture (such as LoongArch, ARM64, and RISC-V) implements bpf_jit_inlines_helper_call(), the verifier skips rewriting the helper call offset (insn->imm) in bpf_do_misc_fixups(). This is because the helper is expected to be inlined by the JIT compiler later. Therefore, insn->imm remains as the raw helper enum ID. However, if JIT is disabled at runtime (net.core.bpf_jit_enable=0) or if JIT compilation fails dynamically (e.g., due to OOM), the program falls back to the BPF interpreter. When the interpreter executes (__bpf_call_base + insn->imm) with the unpatched raw ID, it jumps into an invalid address space, triggering an instruction alignment fault or a kernel panic. Although these helpers have valid C implementations in the kernel, the omission of offset rewriting makes runtime interpreter fallback fatal. Fix this by setting 'prog->jit_required = 1' when helper call rewriting is skipped for JIT inlining. This ensures that such programs are safely rejected if JIT is not available, preventing the runtime kernel panic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93144", "url": "https://ubuntu.com/security/CVE-2026-93144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject writes through untrusted BTF pointers check_ptr_to_btf_access() lets program-type btf_struct_access callbacks validate writes before the default BTF access path rejects non-read accesses. That bypasses the read-only policy for untrusted BTF pointers created by helpers such as bpf_rdonly_cast(). Reject non-read accesses through PTR_UNTRUSTED BTF pointers at the common entry point, before the callback branch to handle all cases.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93148", "url": "https://ubuntu.com/security/CVE-2026-93148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject MEM_ALLOC BTF accesses past object bounds BTF struct walks relax the struct-size check for accesses through a trailing flexible array. That is valid for ordinary BTF type walking, but PTR_TO_BTF_ID | MEM_ALLOC values point to objects allocated with the static BTF type size. When walking a MEM_ALLOC object, reject the access before applying the flexible-array relaxation if the access range extends past the struct size. Apply the same policy to struct ID matching so kfunc and kptr type checks do not walk past the allocated object bounds either.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93153", "url": "https://ubuntu.com/security/CVE-2026-93153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bng_re: return a timeout when firmware responses stall __wait_for_resp() documents that it returns a non-zero error when a firmware command does not complete, and bng_re_rcfw_send_message() already marks the firmware as stalled when the helper returns -ENODEV. However, the helper ignores wait_event_timeout() expiry. If the response slot remains in use after the timeout and after the polled CREQ service attempt, the loop starts another full timeout period and can repeat forever. Return -ENODEV after a timed out wait that still has no response. The existing caller then marks FIRMWARE_STALL_DETECTED and returns -ETIMEDOUT to the command issuer.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93164", "url": "https://ubuntu.com/security/CVE-2026-93164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes/x86: Move optimized uprobe from nop5 to nop10 Andrii reported an issue with optimized uprobes [1] that can clobber redzone area with call instruction storing return address on stack where user code may keep temporary data without adjusting rsp. Fixing this by moving the optimized uprobes on top of 10-bytes nop instruction, so we can squeeze another instruction to escape the redzone area before doing the call, like: lea -0x80(%rsp), %rsp call tramp Note the lea instruction is used to adjust the rsp register without changing the flags. We use nop10 and following transformation to optimized instructions above and back as suggested by Peterz [2]. Optimize path (int3_update_optimize): 1) Initial state after set_swbp() installed the uprobe: cc 2e 0f 1f 84 00 00 00 00 00 From offset 0 this is INT3 followed by the tail of the original 10-byte NOP. After a previous unoptimization bytes 5..9 may still contain the old call instruction, which remains valid for threads already there. 2) Rewrite the LEA tail and call displacement: cc [8d 64 24 80 e8 d0 d1 d2 d3] From offset 0 this traps on the uprobe INT3. Bytes 1..9 are not executable entry points while byte 0 is trapped. 3) Publish the first LEA byte: [48] 8d 64 24 80 e8 d0 d1 d2 d3 From offset 0 this is: lea -0x80(%rsp), %rsp call Unoptimize path (int3_update_unoptimize): 1) Initial optimized state: 48 8d 64 24 80 e8 d0 d1 d2 d3 Same as 3) above. 2) Trap new entries before restoring the NOP bytes: [cc] 8d 64 24 80 e8 d0 d1 d2 d3 From offset 0 this traps. A thread that had already executed the LEA can still reach the intact CALL at offset 5. 3) Restore bytes 1..4 of the original NOP while keeping byte 0 trapped and byte 5 as CALL. cc [2e 0f 1f 84] e8 d0 d1 d2 d3 From offset 0 this still traps. Offset 5 is still the CALL for any thread that was already past the first LEA byte. 4) Publish the first byte of the original NOP: [66] 2e 0f 1f 84 e8 d0 d1 d2 d3 From offset 0 this is the restored 10-byte NOP; the CALL opcode and displacement are now only NOP operands. Offset 5 still decodes as CALL for a thread that was already there. Tthere is only a single target uprobe-trampoline for the given nop10 instruction address, so the CALL instruction will not be changed across unoptimization/optimization cycles. Therefore, any task that is preempted at the CALL instruction is guaranteed to observe that CALL and not anything else. Note as explained in [2] we need to use following nop10: PF1 PF2 ESC NOPL MOD SIB DISP32 NOP10: 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00 -- cs nopw 0x00000000(%rax,%rax,1) which means we need to allow 0x2e prefix which maps to INAT_PFX_CS attribute in is_prefix_bad function. Also changing the uprobe syscall error when called out of uprobe trampoline to -EPROTO, so we are able to detect the fixed kernel. The optimized uprobe performance stays the same: uprobe-nop : 3.129 ± 0.013M/s uprobe-push : 3.045 ± 0.006M/s uprobe-ret : 1.095 ± 0.004M/s --> uprobe-nop10 : 7.170 ± 0.020M/s uretprobe-nop : 2.143 ± 0.021M/s uretprobe-push : 2.090 ± 0.000M/s uretprobe-ret : 0.942 ± 0.000M/s --> uretprobe-nop10: 3.381 ± 0.003M/s usdt-nop : 3.245 ± 0.004M/s --> usdt-nop10 : 7.256 ± 0.023M/s [1] https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/ [2] https://lore.kernel.org/bpf/20260518104306.GU3102624@noisy.programming.kicks-ass.net/#t", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93168", "url": "https://ubuntu.com/security/CVE-2026-93168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a condition that is never fulfilled, the CPU busy-waits for prolonged time and the timeout triggers only with a massive delay causing a CPU stall. This happens due to a huge underestimation of wall clock time in poll_timeout_us_atomic. Commit 7349a69cf312 (\"iopoll: Do not use timekeeping in read_poll_timeout_atomic()\") changed the behavior to no longer use ktime_get at the expense of underestimation of wall clock time which appears to be very large for delay_us=0. Instead of timing out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for loop in poll_timeout_us_atomic takes) which is in the range of several minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero value for delay_us. Use delay_us=10 to keep the delay in the hot path of starting DMA transfers minimal but still avoid CPU stalls in case of unexpected hardware failures. One-off measurement with delay_us=0 causes the cpu to busy wait around 7 minutes in the timeout case. After applying this patch with delay_us=10 the measured timeout was 1053428 microseconds which is roughly equivalent to the expected 1000000 microseconds specified in XILINX_DMA_LOOP_COUNT. Add a constant XILINX_DMA_POLL_DELAY_US for delay_us value.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93176", "url": "https://ubuntu.com/security/CVE-2026-93176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix dangling pointer in plane reset function amdgpu_dm_plane_drm_plane_reset() frees the old state before allocating a new one. If kzalloc() fails, the function returns without updating the state pointer, leaving a dangling pointer to already freed memory. Fix this by allocating the new state first. On allocation failure, the old state remains untouched and the function safely returns. Found by Linux Verification Center (linuxtesting.org) with SVACE. [adjust for movement around current amd-staging-drm-next]", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93179", "url": "https://ubuntu.com/security/CVE-2026-93179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/powerplay: fix VoltageObjectInfo zero-stride loop and OOB read Reject voltage objects whose usSize is smaller than the header or would advance the cursor past the table end, preventing an infinite loop or heap OOB read when the VBIOS supplies a malformed VoltageObjectInfo table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93181", "url": "https://ubuntu.com/security/CVE-2026-93181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Fix uncore_box ref/unref ordering In uncore_event_cpu_online(), uncore_box_ref() was called before uncore_change_context(). uncore_box_ref() gates on box->cpu >= 0, but box->cpu is still -1 at that point because uncore_change_context() has not run yet. As a result, the box is never initialized on the first CPU to come online in a die, leaving it permanently uninitialized in the single-CPU-per-die case. Thus, box->refcnt is one count below the true value, and in the CPU offline path, the box will be torn down on the second-to-last CPU. In uncore_event_cpu_offline(), uncore_box_unref() was called after uncore_change_context(), so box->cpu is already -1 when the collector CPU goes offline, which prevents it from tearing down the box. Fix by swapping the call order in both paths so that uncore_box_{ref,unref}() runs at the point where box->cpu reflects the correct context. Move allocate_boxes() out of uncore_box_ref() to enable this reordering.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89788", "url": "https://ubuntu.com/security/CVE-2026-89788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix tree connection use-after-free in smb2_tree_connect() ksmbd_tree_conn_connect() publishes a new tree connection in sess->tree_conns with a single reference and returns its pointer to smb2_tree_connect(). The handler continues to initialize the object and build the response after publication. A concurrent session logoff can erase the connection and drop that reference, freeing the object while the handler still uses it. BUG: KASAN: slab-use-after-free in smb2_tree_connect+0xe3d/0xf90 smb2_tree_connect (fs/smb/server/smb2pdu.c:2872) handle_ksmbd_work process_one_work worker_thread kthread After xa_store() succeeds, take a second reference before releasing tree_conns_lock. The original reference belongs to the xarray entry and the second belongs to the creating smb2_tree_connect() handler. Keep the references balanced in every path: - On normal exit or an error after publication, smb2_tree_connect() drops its creator reference. Error cleanup also calls ksmbd_tree_conn_disconnect(), which drops the xarray reference only if it removes the exact entry. - SMB2 TREE_DISCONNECT uses the same helper to remove the entry and drop its xarray reference. The request's existing lookup reference remains owned by the request and is released by the existing cleanup. - Session LOGOFF removes each entry and drops its xarray reference. If it wins the race, later cleanup sees that the entry is gone and does not drop that reference again. To enforce this ownership, claim the disconnected state and erase the exact entry atomically under tree_conns_lock. This guarantees one drop for the xarray reference and one drop by each in-flight user, regardless of which teardown path wins. If logoff removes the entry before initialization completes, fail the connect instead of marking the detached object TREE_CONNECTED.", "cve_priority": "high", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93201", "url": "https://ubuntu.com/security/CVE-2026-93201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-pcache: validate seg_id fields from persistent memory cache_pos_decode(), cache_key_decode() and the last-kset branches of cache_replay(), the writeback worker and the GC worker take a cache segment id from the cache device metadata and index cache->segments[] with it without checking it against cache->n_segs. That metadata is only CRC-protected with a fixed public seed, so whoever supplies the cache device on a table load (CAP_SYS_ADMIN) controls the id; an out-of-range value forms a wild pcache_cache_segment pointer that is dereferenced and written through -- an out-of-bounds read and write driven by on-disk data. Add cache_seg_id_valid() and reject an out-of-range id at each decode site, failing the operation with -EIO instead of indexing past the array. Bound the id against the initialized-segment count (cache_info.n_segs) rather than the physical device total. A forged cache_info.n_segs below seg_num otherwise leaves segments[cache_info.n_segs..seg_num) as zeroed structs whose data pointer is NULL, so a forged id in that window would still be dereferenced. A later patch guarantees cache_info.n_segs <= seg_num, and a driver-created cache sets the two equal, so valid images are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89792", "url": "https://ubuntu.com/security/CVE-2026-89792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds reads in share config responses Validate IPC share configuration payload sizes before consuming variable-length fields. Bound veto list parsing and account for the separator byte when deriving the path length.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90051", "url": "https://ubuntu.com/security/CVE-2026-90051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: reject non zerocopy devmem tx Devmem tcp tx doesn't work without zero-copy, however it's not currently enforced if NETIF_F_SG isn't present. In this case, tcp_sendmsg_locked() will try the copy path and try to copy data from an iovec which consists of offsets into the dma-buf and would normally fail. Moreover, d9c56501c72fd (\"net: tcp: block mixing readable and unreadable frags\") relies on that and assumes that the devmem binding is present IFF we're using the zero-copy path, which can be used to mix net-iov and pages in a single skb, and break invariants. Let's reject devmem tx without zero-copy. Note, the parameter check the patch is modifying is too loose, we can create an io_uring request with dmabuf_id and all ZC flags, but which won't have the binding. We replace it with stricter validation.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90053", "url": "https://ubuntu.com/security/CVE-2026-90053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_htb: limit htb_classify inner-class filter hops htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet. Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at the point the inner filter chain is picked up, after the TC_ACT_* switch has consumed the classifier verdict, so a terminal TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr to __NET_XMIT_STOLEN and the packet is not charged as a drop by this qdisc or its parent. The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than from the qdisc hierarchy depth limit. Class levels run from 0 to TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can take at most TC_HTB_MAXDEPTH hops. That descent is what a sane configuration does, but it is assumed here rather than enforced: htb_find() resolves a classid against every class in the qdisc, so a filter may equally select a sibling or an ancestor. The normal root -> inner -> leaf path takes a single hop, so the bound does not affect legitimate classification. htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT, whereas previously every NULL return sat inside that ifdef. The NULL handler in htb_enqueue() therefore cannot stay conditional either, so drop the ifdef around it. This matches hfsc_enqueue(), which has always handled a NULL class unconditionally. Without it, a kernel built without actions would dereference a NULL class instead of dropping. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Create an HTB qdisc on a device (e.g. lo), add an inner class 1:1 with a leaf child 1:10, install a root u32 filter selecting 1:1, and an inner-class u32 filter on 1:1 also selecting 1:1. - Send one packet (ping). On the unfixed kernel the classify loop spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90054", "url": "https://ubuntu.com/security/CVE-2026-90054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix corruption of urgent data on multi-segment retransmit On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: \t/* tcp_write_xmit() */ \tlimit = mss_now; \tif (tso_segs > 1 && !tcp_urg_mode(tp)) \t\tlimit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: \t/* __tcp_retransmit_skb() */ \tlen = cur_mss * segs;\t\t/* segs > 1, no urg_mode check */ \t... \t/* tcp_gso_segment(): bumps seq only, urg_ptr is copied */ urg_ptr is an offset from the segment's own seq, so a copied value points at a different place on each segment. The receiver rebuilds the absolute urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead of the one OOB byte: \tseg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok) \tseg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS) \tseg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS) The real OOB byte is never pointed at, so the receiver stops splicing it out and delivers it as normal in-band data, corrupting the stream. Guard the retransmit length like the xmit path: keep segs = 1 while in urgent mode.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90055", "url": "https://ubuntu.com/security/CVE-2026-90055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90056", "url": "https://ubuntu.com/security/CVE-2026-90056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: only stop PTP if it was initialized fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90057", "url": "https://ubuntu.com/security/CVE-2026-90057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: remove slip_hangup() to fix use-after-free in slip_receive_buf() Jaeyoung Chung and Eulgyu Kim reported a slab-use-after-free read in slip_receive_buf() when racing against tty hangup. tty_ldisc_hangup() calls ld->ops->hangup() while holding only a read lock on tty->ldisc_sem (via tty_ldisc_ref()). Because slip_hangup() simply called slip_close(), it ran concurrently with reader functions such as slip_receive_buf(). slip_close() unregisters and frees the net device and its private struct slip, causing concurrent reader threads in slip_receive_buf() to dereference freed memory. Line discipline close() is already guaranteed to be called under the write lock of tty->ldisc_sem during hangup processing (in tty_ldisc_reinit() or tty_ldisc_kill()). Remove slip_hangup() so teardown is serialized cleanly by slip_close().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90058", "url": "https://ubuntu.com/security/CVE-2026-90058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai. Cap the final qdisc_pkt_len() to QDISC_PKT_LEN_MAX so the size-table amplification cannot drive deficit schedulers into an unbounded loop. A legitimate size table (e.g. qfq's overhead 999999999, which is handled by dropping) is still accepted. Introduce cap QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSO_MAX_SIZE (524280), and an ATM-style size table (53/48 cell tax) amplifies that to ~578 KB, both comfortably below 1 MiB. At the same time, 1 MiB bounds the deficit refill loop to ~1M iterations per packet with quantum=1, which completes in a few milliseconds well under the demonstrated softlockup threshold (~10^9 iterations). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=15, data=[32768]). - Add a class with a tiny quantum of 1 and send one small packet; the deficit loop spins billions of times under the qdisc lock and trips the softlockup detector (panic with kernel.softlockup_panic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90059", "url": "https://ubuntu.com/security/CVE-2026-90059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: restore NET_IP_ALIGN in the RX DMA offset Since the RX path was converted to zero-copy, the page pool page is handed to the stack directly as the skb head, and the offset the DMA engine writes at is what determines the alignment of the packet headers. Before the conversion the payload was copied into an skb obtained from napi_alloc_skb(), which reserves NET_SKB_PAD + NET_IP_ALIGN. The conversion moved the headroom into stmmac_rx_offset() but did not carry over NET_IP_ALIGN, so on architectures where NET_IP_ALIGN is 2 the IP header now lands misaligned: 64 (NET_SKB_PAD) + 14 (ethernet) + 20 (IP) = 98 Same for the XDP branch: 256 (XDP_PACKET_HEADROOM) + 14 (ethernet) + 20 (IP) = 290 On ARM32 this is fatal, because ldm and ldrd trap on unaligned addresses even when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set. Any received echo request panics the machine, e.g: Unhandled fault: alignment exception (0x001) at 0x81873062 Internal error: : 1 [#1] SMP ARM Hardware name: Altera SOCFPGA Arria10 PC is at icmp_echo+0x38/0xa8 LR is at icmp_rcv+0x22c/0x370 Call trace: icmp_echo from icmp_rcv+0x22c/0x370 icmp_rcv from ip_protocol_deliver_rcu+0x2c/0x224 ip_protocol_deliver_rcu from ip_local_deliver+0xc8/0x1a0 ip_local_deliver from ip_sublist_rcv_finish+0x3c/0x50 ip_sublist_rcv_finish from ip_list_rcv_finish+0x110/0x118 ip_list_rcv_finish from ip_list_rcv+0xc8/0xdc ip_list_rcv from __netif_receive_skb_list_core+0x170/0x1c0 ... napi_complete_done from stmmac_napi_poll_rx+0xcb0/0x1030 Code: e24dd068 e59020a0 e28dc010 e0822001 (e8920003) Kernel panic - not syncing: Fatal exception in interrupt The faulting instruction is the ldm of *icmp_hdr(skb) in icmp_echo(). Fix by adding NET_IP_ALIGN back to the RX offset, which restores the alignment the stack used to get. Note that commit a955318fe67e (\"stmmac: align RX buffers\") made a similar change in 2021 and was reverted by commit 12d125b4574b (\"stmmac: Revert \"stmmac: align RX buffers\"\") because it caused packet corruption. That patch raised the offset from 0 without adjusting the buffer size accounting, so the DMA engine could arguably write past the end of the RX buffers, though this was never root caused. Commit df542f669307 (\"net: stmmac: Switch to zero-copy in non-XDP RX path\") since derives the page pool allocation from stmmac_rx_offset(), so the extra bytes are accounted for.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90060", "url": "https://ubuntu.com/security/CVE-2026-90060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Don't add invalid kcontrols to LED layer The kcontrol LED state layer tries to track the all associated kcontrol elements with naive assumptions that they are readable. But one can create a write-only element that has no get callback (even a user element can do it), and this may lead to a NULL dereference at the call chain of snd_ctl_led_notify(), as found by syzkaller. For avoiding the Oops, add a sanity check of the kcontrol's info and get callbacks, and just skip the invalid kcontrols before assigning the kctl to the LED layer.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90062", "url": "https://ubuntu.com/security/CVE-2026-90062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: move hardware offload step after building the chain blob Allocate the chain blob before the ruleset offload to reduce chances of entering an inconsistent state where the offloaded ruleset in the nic and the software ruleset differ.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90063", "url": "https://ubuntu.com/security/CVE-2026-90063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90065", "url": "https://ubuntu.com/security/CVE-2026-90065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: release the internal TCP sock on IPPROTO_SMC socket creation failure IPPROTO_SMC sockets create an internal TCP sock (\"clcsock\") from the proto->init hook. When socket creation fails after proto->init has run - e.g. a cgroup BPF program attached to BPF_CGROUP_INET_SOCK_CREATE denies the socket - sk_common_release() only invokes sk_prot->destroy if it is set, but neither smc_inet_prot nor smc_inet6_prot defines it, and smc_destruct() returns early unless sk_state is SMC_CLOSED. As a result, every failing socket(AF_INET, SOCK_STREAM, IPPROTO_SMC) call leaks one tcp_sock, so an unprivileged task able to attach a deny-all BPF_CGROUP_INET_SOCK_CREATE program to its own cgroup can grow kernel memory unboundedly. Add a .destroy hook to both protos that releases the clcsock via smc_clcsock_release(). smc_sk_init() hashes the sock into the smc hashinfo before the clcsock is created, and smc_diag dumps walk that hash dereferencing smc->clcsock without taking clcsock_release_lock, while sk_common_release() calls .destroy before .unhash. Unhash the sock before releasing the clcsock, as __smc_release() does, so a concurrent dump cannot observe the release; the second unhash in sk_common_release() is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90066", "url": "https://ubuntu.com/security/CVE-2026-90066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-multi-modify ftrace_direct_multi_init() assigns kthread_run()'s return value to simple_tsk without an IS_ERR() check. When kthread_run() fails it returns ERR_PTR(-ENOMEM), but init still returns 0, so the module loads with simple_tsk holding an error pointer. On unload, ftrace_direct_multi_exit() then passes that ERR_PTR to kthread_stop(), leading to a null-pointer-dereference. Check the return value of kthread_run() with IS_ERR(); on failure, unregister the ftrace direct call and propagate the error code.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90067", "url": "https://ubuntu.com/security/CVE-2026-90067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: validate banner payload length When parsing the Ceph messenger v2 protocol banner, the `payload_len` field is decoded from the banner prefix. If a client sends a banner with a `payload_len` of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in `populate_in_iter()`: ------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 According to the msgr2 protocol specification, the banner payload is expected to contain at least two 64-bit integers (`server_feat` and `server_req_feat`). Therefore, `payload_len` must be at least 16 bytes. Fix this by adding a check in `process_banner_prefix()` to reject a `payload_len` smaller than 16 bytes. This prevents the 0-length read and correctly aborts the connection with a protocol error.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90068", "url": "https://ubuntu.com/security/CVE-2026-90068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: Fix off-by-one check on the second enum channel The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to snd_soc_enum_item_to_val(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end. The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used >= there, and the snd_soc_put_enum_double() in soc-ops.c still does. Only adav80x pairs a value table with two shifts, and its second channel looks accidental, but the control does report two values. Writing three into it reads off the end of adav80x_mux_values. The core catches that only under CONFIG_SND_CTL_INPUT_VALIDATION, which defaults off.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90069", "url": "https://ubuntu.com/security/CVE-2026-90069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: acomp - allocate async request context when cloning ACOMP_REQUEST_ON_STACK() reserves only enough storage for the synchronous fallback. When an async implementation is selected, callers clone that stack request before retrying, but acomp_request_clone() currently copies only the stack-sized object. The clone therefore has no storage for the async provider request context, and providers such as QAT write past the allocation through acomp_request_ctx(). KASAN does report a slab OOB write. Allocate a zeroed clone large enough for the runtime acomp request size, copy only the bytes present in the source object, and preserve the existing fallback-on-allocation-failure behavior. Use the runtime reqsize because an implementation may adjust it during tfm initialization.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90070", "url": "https://ubuntu.com/security/CVE-2026-90070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Return zero on status read failure st33zp24_status() ignores the result of the transport read and returns data even when no byte was received. The I2C transport, for example, skips i2c_master_recv() when the register-select write is short or fails, leaving data uninitialized. The resulting stack value can be interpreted as TPM_STS flags and let status checks complete spuriously. The status callback cannot propagate a transport error. Return zero unless recv() reports exactly one byte. With no status bits set, callers retry or take their existing timeout or error path instead of acting on an invalid status value. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90071", "url": "https://ubuntu.com/security/CVE-2026-90071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: restore skb->dev on the slave failure path teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6377 mm/slub.c:6692) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90072", "url": "https://ubuntu.com/security/CVE-2026-90072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90073", "url": "https://ubuntu.com/security/CVE-2026-90073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare \"tc qdisc add ... hhf\" succeeds with a clamped quantum but \"tc qdisc add ... hhf limit 1000\" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90074", "url": "https://ubuntu.com/security/CVE-2026-90074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp default quantum to avoid signed overflow fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(), causing an infinite loop and soft lockup. Emulate fq_pie_policy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90075", "url": "https://ubuntu.com/security/CVE-2026-90075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_codel: clamp default quantum and mtu fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(), causing an infinite loop and soft lockup. Emulate fq_codel_change() and constrain to [256, FQ_CODEL_QUANTUM_MAX]. The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit below, and fq_codel_change() never updates it. codel_should_drop() tests \"*backlog <= params->mtu\"; with mtu == 0x80000000 (~2 GiB) and the default 32 MiB memory_limit, the test is always true, so CoDel is silently and completely disabled (no drops, no ECN). Declare a single clamped mtu and assign both q->quantum and q->cparams.mtu from it, which also removes the double psched_mtu() call. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90076", "url": "https://ubuntu.com/security/CVE-2026-90076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq: add overflow bounds to quantum and initial quantum fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 * psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill loop adds 0 to f->credit (which stays <= 0) and goto begin loops forever under the qdisc lock, creating a soft lockup. Clamp psched_mtu() to [1, 1 << 20] before multiplying so the product cannot wrap, then cap the result at 1 << 20, matching the bound already enforced on TCA_FQ_QUANTUM in fq_change(). Conditions to recreate the bug: a device whose MTU (plus hard_header_len) is large enough that 2 * psched_mtu() wraps (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90077", "url": "https://ubuntu.com/security/CVE-2026-90077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix a resource leak in copy_net_ns() error handling path Currently, preinit_net() does two things: (1) call ns_common_init() which might fail (2) initialize resources which does not fail However, preinit_net() is returning early when (1) fails, and copy_net_ns() is jumping to the dec_ucounts: label. As a result, resources allocated by net_alloc() are leaking. We need to call key_remove_domain() and net_passive_dec() in order to release resources allocated by net_alloc(). We cannot simply jump to the put_userns: label when preinit_net() failed, for (2) is not yet done. But we can reorder (1) and (2), for there is no dependency between (1) and (2). Therefore, this patch decouples (1) from preinit_net() and changes preinit_net() back to a void function, and calls ns_common_init() after preinit_net() succeeded. Then, we can jump to immediately after ns_common_free() of the put_userns: label.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90078", "url": "https://ubuntu.com/security/CVE-2026-90078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: fix length calculations and avoid invalid header warnings syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act(): !skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55 There are a few issues in tcf_skbmod_act(): 1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress. 2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length. 3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets). Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90080", "url": "https://ubuntu.com/security/CVE-2026-90080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup af_xdp_zc_qidx tracks receive queues using AF_XDP zero-copy and is allocated during PF/VF probe. Representors and other non-AF_XDP paths leave the pointer NULL, but several call sites used test_bit() on it unconditionally. Switching to devlink eswitch mode creates representors and runs otx2_init_hw_resources(), which reaches otx2_pool_aq_init() and oopses when dereferencing the NULL bitmap. Add NULL checks before every af_xdp_zc_qidx test_bit() use in the RSS, ethtool, XSK, and pool init paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90081", "url": "https://ubuntu.com/security/CVE-2026-90081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in rds_cong_map_updated() rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued. rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90083", "url": "https://ubuntu.com/security/CVE-2026-90083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ife: Only operate on Ethernet frames act_ife encapsulates/decapsulates the original Ethernet header and uses skb->dev->hard_header_len as the length of that header. That is only correct for Ethernet devices: on a device where hard_header_len does not match the L2 header that was actually pulled (PPP reports PPP_HDRLEN while nothing is stripped on ingress), the ingress skb_push()/skb_pull() use the wrong length and can hit skb_under_panic when headroom is tight. IFE is Ethernet-only by design - it builds an outer ethhdr, rewrites h_source/h_dest/h_proto, and calls eth_type_trans() on decode - so instead of trying to make the offsets work for arbitrary link types, simply drop packets that do not carry an Ethernet header. Checking skb->dev->type alone is not enough. We have to cater for a corner case where mirred can redirect an skb from a non-Ethernet device to an Ethernet one, and skb->dev then says nothing about the framing the skb actually has: an skb redirected from ppp0 reaches the target's ingress hook with mac_len 0 and no Ethernet header at all. So at ingress also require mac_len to be ETH_HLEN. On egress mac_len is not maintained, so the device type is all we have; a bogus redirect there yields a malformed frame rather than an out-of-bounds push, and it would be malformed with or without IFE. That corner case is not theoretical - redirecting from ppp0 into a veth that has an ife encode action on its ingress hook panics without this patch: skbuff: skb_under_panic: len:98 put:14 head:ffff88800e410000 data:ffff88800e40fff5 tail:0x57 end:0x640 dev:veth3 kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:224 net/core/skbuff.c:2657) tcf_ife_act (net/sched/act_ife.c:829 net/sched/act_ife.c:874) tc_run (net/core/dev.c:4463) netif_receive_skb (net/core/dev.c:6463 net/core/dev.c:6522) tcf_mirred_to_dev (net/sched/act_mirred.c:248 net/sched/act_mirred.c:328) tcf_mirred_act (net/sched/act_mirred.c:489) tc_run (net/core/dev.c:4463) process_backlog (net/core/dev.c:6728) With Ethernet framing guaranteed, use ETH_HLEN instead of hard_header_len.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-89780", "url": "https://ubuntu.com/security/CVE-2026-89780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: restore skb->dev on deaggregated frames rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90084", "url": "https://ubuntu.com/security/CVE-2026-90084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-vf: fix workqueue and netdev race in probe/remove Initialize the VF workqueue before register_netdev() so ndo_set_rx_mode does not queue work on a NULL workqueue. Unregister the netdev before destroying the workqueue, and add proper probe error cleanup.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90085", "url": "https://ubuntu.com/security/CVE-2026-90085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: fix NULL deref in NIX TM tree debugfs read path rvu_dbg_nix_tm_tree_display() dereferences pfvf->sq_ctx without checking whether the SQ context has been allocated. Reading /sys/kernel/debug/octeontx2/nix/tm_tree for a NIX LF whose transmit queues are not set up triggers a kernel oops. Guard the read path the same way rvu_dbg_nix_tm_tree_write() already does and return -EINVAL with a seq_file message when sq_ctx is NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-89789", "url": "https://ubuntu.com/security/CVE-2026-89789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free gtp_newlink()'s error path frees tid_hash and addr_hash without waiting for an RCU grace period after clearing sk_user_data. A concurrent gtp_encap_recv() in softirq may still hold the gtp_dev pointer obtained via rcu_dereference_sk_user_data() and access the freed memory. BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152) Call Trace: gtp0_pdp_find+0x1f6/0x200 gtp_encap_recv+0x527/0x24b0 udp_queue_rcv_one_skb+0x75f/0xc10 Add synchronize_net() before the kfree calls in out_hashtable, which covers all error paths from both gtp_encap_enable() and gtp_create_sockets().", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90086", "url": "https://ubuntu.com/security/CVE-2026-90086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: honor XDP_TX_METADATA in zero-copy path The zero-copy path reads TX metadata whenever the UMEM has metadata space, even if the descriptor does not set XDP_TX_METADATA. Pass descriptor options through the metadata helpers and ignore metadata unless the option is set. This does not fix the existing per-WQE metadata handling for mlx5 MPWQEs. Only the descriptor that starts a session passes through xsk_tx_metadata_request() and configures offload state shared by the batch. Metadata on descriptors joining an open session is therefore not validated and does not configure its requested offloads. In addition, a non-NULL metadata pointer from such a descriptor is treated as a timestamp completion request even when XDP_TXMD_FLAGS_TIMESTAMP is not set, so its metadata union can be overwritten with an unrequested timestamp. Fixing mixed metadata states within one MPWQE requires a separate change.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90088", "url": "https://ubuntu.com/security/CVE-2026-90088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90089", "url": "https://ubuntu.com/security/CVE-2026-90089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Validate the FW dump header length nxp_process_fw_dump() pulls the ACL header off the frame and then reads seq_num and buf_len from a struct nxp_fw_dump_hdr placed at skb->data, without checking that the ACL payload is long enough to contain it. h4_recv_buf() collects HCI_ACL_HDR_SIZE bytes of header followed by the number of payload bytes named in that header, so skb->len is 4 + dlen with dlen supplied by the controller and possibly smaller than the 8 byte dump header, or zero. A short frame with connection handle 0xfff therefore reads both fields from beyond the received data. Beyond the read itself, buf_len is what terminates a dump: a value of zero makes the driver call hci_devcd_complete() and reset the controller, so a truncated frame can end a dump early. Use skb_pull_data() to validate and pull the FW dump header before accessing its fields. Warn and reject the chunk if the header is truncated.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90090", "url": "https://ubuntu.com/security/CVE-2026-90090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size of 256 bytes, but hands the host controller the SKB buffer as is: \terr = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data, \t\t\t round_up(skb->len, MTK_SDIO_BLOCK_SIZE)); Only skb->len bytes hold packet data, so the controller reads up to 255 bytes of uninitialised memory and sends it to the device over the SDIO bus. Depending on how much tailroom slack the SKB allocation happens to carry, that read can also extend past the end of the buffer. Compute the padded length up front, ensure the SKB has tailroom for it, and zero-fill the padding with skb_put_zero(). skb->len then covers the padding, so sdio_writesb() no longer needs to round up. byte_tx keeps counting the header and the payload only, and the error path restores the SKB so that the caller can requeue it. Writing behind skb->tail is only safe because the driver owns the buffer, which \"Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX\" ensures.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90091", "url": "https://ubuntu.com/security/CVE-2026-90091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan For L2CAP sockets without owning sk->sk_socket, reading l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() -> l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks, but access in l2cap_sock_cleanup_listen() has unsafe lockless read. [Task 1] [Task 2 (hdev->workqueue)] l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref) Task 1 may observe NULL which causes null-ptr-deref. Fix the race by taking lock_sock() in l2cap_sock_kill() to synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL. Clarify code comments vs. locking.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90092", "url": "https://ubuntu.com/security/CVE-2026-90092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN New sk should not be added to parent socket accept queue after last l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and state set to BT_CLOSED, as that can result to UAF on dereferencing the dangling parent reference. l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown, due to chan->state accessed without consistent locking: [Task 1] [Task 2] l2cap_sock_release(parent) l2cap_connect l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm l2cap_chan_lock(pchan) l2cap_chan_close l2cap_sock_teardown_cb pchan->state = BT_CLOSED l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan) l2cap_new_connection l2cap_sock_new_connection_cb l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan) l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */ Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in l2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes where missing, to avoid data races. Although the data races on pchan->state should be fixed too, this defensive sk_state check probably makes sense in any case.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90094", "url": "https://ubuntu.com/security/CVE-2026-90094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: process: Fix context switching MTE store-only tag check SCTLR_EL1.TCSO0 is set when user opt-in for MTE store-only tag check mode. However, it is not part of SCTLR_USER_MASK which imply that on context switch we never clear SCTLR_EL1.TCSO0, so we are leaking that setting into another task. Fix that by including SCTLR_EL1_TCSO0_MASK into SCTLR_USER_MASK", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90097", "url": "https://ubuntu.com/security/CVE-2026-90097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition The VMBus module initialization function, hv_acpi_init(), currently does nothing when running in the root partition and root is not nested in another VM. But the initialization function reports success, so the VMBus module is indeed loaded. VMBus functionality is not actually needed, but the VMBus module must be loaded so that hv_vmbus_exists() can answer correctly. Furthermore, the mshv_root dependency on the VMBus module is needed as described in the commit message for 840b740a35bf (\"mshv: Add conditional VMBus dependency\"). Loading the VMBus module without actually initializing it causes failures if the module should later be unloaded. The module unload code tries to clean up things that were never initialized, resulting in memory faults and a panic. Fix this by having VMBus module exit function perform the same check for non-nested root partition, and do nothing in such a case, just like hv_acpi_init(). In the long run, the code that manages the Hyper-V provided SynIC should be refactored to better coordinate the requirements of root partition scenarios and normal VM scenarios, and to hopefully remove the hv_vmbus_exists() dependnecy between mshv_root and VMBus modules. Preventing the current unload failure scenario is an expediency until such a refactoring is done.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90100", "url": "https://ubuntu.com/security/CVE-2026-90100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: netc: fix period truncation and potential divide-by-zero in PEROUT The max_period bound in net_timer_enable_perout() was computed as: max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period; which exceeds U32_MAX when integral_period > 0 (e.g. 0x100000002 for the default 333333333 Hz clock). A period_ns that passes this check but exceeds U32_MAX is then silently truncated when stored into the u32 struct netc_pp::period field. A truncated value of zero can reach netc_timer_set_perout_alarm(), where the local u32 period variable would also be 0, causing a divide-by-zero in roundup_u64(delta, period) whenever the stime < min_time branch is taken (which always happens for a start time of {0, 0}). Additionally, netc_timer_enable_periodic_pulse() and netc_timer_enable_fiper() both compute: fiper = pp->period - integral_period; A zero pp->period results in an unsigned wraparound to 0xFFFFFFFD, mis-programming the FIPER hardware register. Fix all three issues by capping max_period at NETC_TMR_DEFAULT_FIPER (0xFFFFFFFF). This ensures that any period_ns passing the range check fits in a u32 without truncation, so the stored value is always valid and non-zero. The accepted range is reduced by integral_period ns (typically only a few nanoseconds), which is negligible in practice.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90101", "url": "https://ubuntu.com/security/CVE-2026-90101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix call to hardware monitoring event handler The first parameter of hwmon_notify_event() is supposed to be the hardware monitoring device. The bnxt driver calls it with the platform device as first parameter instead. This API break results in undefined behavior and may result in a crash. Pass the hardware monitoring device as parameter instead to fix the problem.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90102", "url": "https://ubuntu.com/security/CVE-2026-90102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: key the data server cache on the NFS version nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath address set alone, and struct nfs4_pnfs_ds records no version. That suffices for the files layout driver, which always connects with version 4, but flexfiles takes its version tuple from GETDEVICEINFO per device, and one address can legitimately serve both NFSv3 and NFSv4. Two deviceids on one address with different ds_versions[0].version therefore share a single nfs4_pnfs_ds, and whichever mirror connects first pins ds_clp to its own version. The other one is handed that client anyway, so it selects rpc_call_ops for a version the connection does not speak, and the mismatched sequence-slot handling dereferences NULL. Add the version to the cache key so the two cannot alias, giving each version its own nfs4_pnfs_ds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90103", "url": "https://ubuntu.com/security/CVE-2026-90103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix LAYOUTSTATS send buffer exhaustion encode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that. ff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4, an nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server whose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encode_layoutstats() additionally writes the deviceid4 and the layoutupdate4 lou_type word, neither of which the macro accounts for. The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdr_reserve_space() returns NULL once that happens, and the two ff_layout_encode_io_latency() calls run with dss_info->mirror->lock held, so a NULL return there leaves the lock permanently held. Raise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the reservation.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90107", "url": "https://ubuntu.com/security/CVE-2026-90107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: free pending qentry in smc_llc_flow_stop() before memset smc_llc_flow_stop() resets a flow struct with a blind memset: \tspin_lock_bh(&lgr->llc_flow_lock); \tmemset(flow, 0, sizeof(*flow)); \tflow->type = SMC_LLC_FLOW_NONE; \tspin_unlock_bh(&lgr->llc_flow_lock); If flow->qentry is non-NULL at this point the pointer is overwritten without the allocation being freed, leaking one kmalloc object. A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set flow->qentry after the legitimate message has been consumed by the waiter via smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that window the duplicate is stashed into flow->qentry, and then lost when smc_llc_flow_stop() zeros the struct. Call smc_llc_flow_qentry_del() inside the lock before the memset. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal case where no entry is pending is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90108", "url": "https://ubuntu.com/security/CVE-2026-90108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: free stashed qentry before overwrite in REQ_ADD_LINK to ADD_LINK transition When smc_llc_event_handler() transitions the local LLC flow from SMC_LLC_FLOW_REQ_ADD_LINK to SMC_LLC_FLOW_ADD_LINK on arrival of an ADD_LINK request, it calls smc_llc_flow_qentry_set() unconditionally: \tif (lgr->llc_flow_lcl.type == SMC_LLC_FLOW_REQ_ADD_LINK) { \t\tlgr->llc_flow_lcl.type = SMC_LLC_FLOW_ADD_LINK; \t\tsmc_llc_flow_qentry_set(&lgr->llc_flow_lcl, qentry); \t\t... \t} A CONFIRM_LINK or ADD_LINK_CONT arriving while flow->type is SMC_LLC_FLOW_REQ_ADD_LINK is stashed into flow->qentry via the SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT handler (which stores into flow->qentry for any non-NONE flow type). When the subsequent ADD_LINK arrives, the REQ_ADD_LINK branch overwrites flow->qentry with the new pointer without first freeing the stashed allocation, leaking one kmalloc object. The stashed entry has no consumer: smc_llc_wait() is only called from llc_add_link_work, which is not yet scheduled while the flow type remains REQ_ADD_LINK. No waiter is sleeping on llc_msg_waiter at this point. It is safe to unconditionally free any stashed qentry before the overwrite. Call smc_llc_flow_qentry_del() before smc_llc_flow_qentry_set() in the REQ_ADD_LINK branch. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal path where no entry is stashed is a no-op.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90109", "url": "https://ubuntu.com/security/CVE-2026-90109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue gred_enqueue(), bfifo_enqueue() and plug_enqueue() admit a packet when the current backlog plus the packet length fits within the queue limit: sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (gred default VQ) gred_backlog+qdisc_pkt_len(skb) <= q->limit (gred configured VQ) sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (bfifo) sch->qstats.backlog + skb->len <= q->limit (plug) sch->qstats.backlog and q->backlog are u32, and qdisc_pkt_len()/skb->len are unsigned int, so all sums are computed in 32 bits and wrap at 2^32. Once the true backlog exceeds 4 GiB the wrapped sum becomes small and admission keeps succeeding, so the queue grows without bound and the kernel can be driven to OOM. Promote the sums to u64 so admission stops once the true backlog exceeds the limit. The limit is u32, so the bounded queue stays below 2^32 and the stored u32 backlog never wraps. The bug can only be reproduced as root (albeit with ridiculous setup): attach a gred (or bfifo/plug) qdisc with a limit near 4 GiB, leaving the default VQ unconfigured (for gred), and drive >4 GiB of queued traffic (e.g. via a size table / stab to inflate qdisc_pkt_len, or sustained high-rate traffic). The u32 backlog+len sum wraps at 2^32, admission keeps succeeding, and the queue grows unboundedly to OOM.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90110", "url": "https://ubuntu.com/security/CVE-2026-90110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inetpeer: randomize RB-tree node comparison using SipHash The inetpeer rate limiting system stores peer entries in a Red-Black tree keyed deterministically on the remote IP address. Because tree lookups walk the RB-tree using standard lexicographical comparisons (inetpeer_addr_cmp), an off-path adversary can predict the exact topology of the tree and the sequence of nodes traversed during lookups (the gc_stack candidate list). By combining deterministic tree traversal with aggressive garbage collection (triggered when tree size exceeds inet_peer_threshold), an attacker can selectively force the eviction of targeted inet_peer nodes. When an evicted node is subsequently re-created upon receiving a new packet, its rate-limiting token bucket (rate_tokens, rate_last) is reset to full capacity. This creates a side-channel primitive allowing off-path attackers to bypass IP-keyed ICMP rate limits and infer open UDP ports (similar to SAD DNS style attacks). Mitigate this by randomizing the RB-tree node comparison logic using SipHash with a secret key (inetpeer_hash_key) initialized via net_get_random_once(). Nodes are ordered in the tree by SipHash(addr, key) rather than raw IP addresses. Because the secret key is unknown to external entities, the tree layout and lookup traversal paths are unpredictable to off-path adversaries, breaking the deterministic eviction gadget. Cache the computed 64-bit SipHash (hash) in struct inet_peer and compute the target hash (dhash) once at the beginning of inet_getpeer() to avoid recomputing SipHash at every step of the RB-tree walk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90112", "url": "https://ubuntu.com/security/CVE-2026-90112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlcnic: validate unified ROM sections before loading The unified ROM parser reads directory, product, and data-descriptor fields from the firmware file. Existing validation forms table and data ends with unchecked additions and multiplications. Malformed values can wrap before they are compared with the firmware size. The parser also dereferences typed pointers at firmware-controlled offsets. Valid descriptor extents alone are insufficient for the consumers. The loader reads a fixed-size bootloader regardless of its declared size, the version parser assumes a 17-byte tail, and a partial final firmware word is read as a full u64. A truncated image can therefore make the driver read beyond the firmware allocation during validation or loading. Replace the pointer-returning parser with bounded range helpers. Validate table entry sizes, descriptor indices, section ranges, the fixed bootloader load length, and the version tail before exposing any section. Read all file fields with unaligned little-endian accessors and assemble a partial final word from only the bytes that remain. Apply the same range checks to the legacy image before reading its fixed fields.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89790", "url": "https://ubuntu.com/security/CVE-2026-89790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid divide by zero in rt6_multipath_rebalance rt6_multipath_rebalance() calculates the total eligible nexthop weight in one pass and programs upper bounds in a second pass. Since RTM_NEWROUTE is RTNL-free, a concurrent ignore_routes_with_linkdown update can make the first pass return zero while the second sees an eligible nexthop, causing rt6_upper_bound_set() to divide by zero. UBSAN: division-overflow in net/ipv6/route.c:4845:17 Oops: divide error: 0000 [#1] SMP KASAN NOPTI rt6_upper_bound_set() net/ipv6/route.c:4845 rt6_multipath_rebalance() fib6_add_rt2node() ip6_route_multipath_add() inet6_rtm_newroute() Skip upper-bound calculation when the first pass reports a zero total. This respects the lock-free performance considerations here and solves insecure scenarios.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90113", "url": "https://ubuntu.com/security/CVE-2026-90113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: update queue NAPI association on queue reset In netdevsim, receive queues (struct nsim_rq) embed their own struct napi_struct. When queue reset is performed (e.g. via queue_reset debugfs), nsim_queue_start() swaps in a newly allocated struct nsim_rq, and nsim_queue_mem_free() later deletes and frees the old one. However, nsim_queue_start() failed to update the queue-to-NAPI mapping via netif_queue_set_napi(). As a result, dev->_rx[idx].napi continued to point to the old NAPI struct. After the old queue was freed, a subsequent queue dump via Netlink (NETDEV_CMD_QUEUE_GET) triggered a KASAN slab-use-after-free read in nla_put_napi_id() when accessing rxq->napi->napi_id. Fix this by calling netif_queue_set_napi() in nsim_queue_start() to associate the new NAPI with the RX queue, and clear the association with netif_queue_set_napi(..., NULL) in nsim_del_napi() during teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90114", "url": "https://ubuntu.com/security/CVE-2026-90114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: Reject descending VLAN tunnel ranges A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta. The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable. Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90115", "url": "https://ubuntu.com/security/CVE-2026-90115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: fix NULL pointer dereference in __xsk_rcv() In the __xsk_rcv() multi-buffer path, xsk_buff_alloc() is called in a loop without checking its return value. xsk_buff_can_alloc() only counts fill queue entries without validating their addresses, so it can succeed while xsk_buff_alloc() rejects all remaining entries and returns NULL. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:__xsk_rcv+0x426/0xc20 (net/xdp/xsk.c:350) Call Trace: xsk_generic_rcv+0x26d/0x5f0 xdp_do_generic_redirect+0x3c5/0xcf0 do_xdp_generic+0x92f/0xe70 __netif_receive_skb_core.constprop.0+0xf7e/0x2b30 Fix this with a two-stage transaction. First allocate and stage all buffers required for the packet, recycling all staged buffers with xsk_buff_free() if any allocation fails. Only after this stage succeeds, copy the data, reserve the RX descriptors, and release the buffers in an error-free loop.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90116", "url": "https://ubuntu.com/security/CVE-2026-90116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mtpav: shut down output timer before card teardown snd_mtpav_output_timer() rearms chip->timer while holding chip->spinlock and accesses the card-private mtpav state. snd_mtpav_free() currently takes the same lock and calls timer_delete() when the timer is active. This only removes a pending timer; it does not wait for a callback that is already running and does not prevent the callback from rearming the timer. A callback running on another CPU can therefore continue after snd_mtpav_free() releases the lock and access the card-private state while the card is being torn down. It can also rearm the timer after timer_delete() has returned. Call timer_shutdown_sync() without holding chip->spinlock. This waits for any running callback to finish and prevents further rearming before the card-private mtpav state is released.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90119", "url": "https://ubuntu.com/security/CVE-2026-90119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup snd_ice1712_probe() performs multiple initialization steps after snd_card_new(), but directly returns on failures from later steps without releasing the ALSA card, causing resource leaks when probing fails. Use snd_devm_card_new() together with scope-based cleanup via __free(snd_card_unref), and clear the card pointer after successful registration to keep it alive.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90122", "url": "https://ubuntu.com/security/CVE-2026-90122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: visconti: Make sure clk_init_data is fully initialized The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. visconti_clk_register_gate() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90124", "url": "https://ubuntu.com/security/CVE-2026-90124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/renesas-rzg2l: Fix loss of interrupt rzg2l_clear_irq_int() and rzg2l_clear_tint_int() perform a read-modify-write on the ISCR/TSCR status registers to clear the bit for the interrupt just handled. Since these registers are write-0-to-clear per bit, this is racy: If another interrupt's status bit gets set between the read and the write, that bit is written back as 0 by the software-constructed value, clearing an interrupt that hasn't been serviced yet and losing it. This can be reproduced by triggering multiple interrupts at once, e.g.: gpioset -c gpiochip0 355=0 353=0 328=0 352=0 Fix this by writing back only the bit being cleared, with all other bits set to 1, instead of read-modify-writing the whole register. Since 1-bits are left unchanged by hardware, concurrently-set status bits for other interrupts are preserved.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90125", "url": "https://ubuntu.com/security/CVE-2026-90125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix request buffer leak in smb2_new_read_req() smb2_new_read_req() allocates the request buffer with smb2_plain_req_init() but only publishes it to the caller with *buf = req at the very end of the function. Two error returns sit in between: \trc = smb2_plain_req_init(SMB2_READ, io_parms->tcon, server, \t\t\t\t (void **) &req, total_len); \tif (rc) \t\treturn rc; \tif (server == NULL) \t\treturn -ECONNABORTED; \t[...] \t\trdata->mr = smbd_register_mr(server->smbd_conn, \t\t\t\t\t &rdata->subreq.io_iter, \t\t\t\t\t true, need_invalidate); \t\tif (!rdata->mr) \t\t\treturn -EAGAIN; On either of them the buffer is neither released nor handed back, so it is leaked. The caller cannot clean up after it: smb2_async_readv() does 'goto out' on a non-zero return, which skips the cifs_small_buf_release(buf) at async_readv_out, and buf has not been assigned at that point in any case. The write path has never had this problem. smb2_async_writev() registers the memory region inline and jumps to its release label instead of returning: \twdata->mr = smbd_register_mr(...); \tif (!wdata->mr) { \t\trc = -EAGAIN; \t\tgoto async_writev_out; \t} Commit b7972092199f (\"cifs: smbd: Retry on memory registration failure\") changed both sides from -ENOBUFS to -EAGAIN in a single patch, which puts the two shapes next to each other. Only the -EAGAIN return is reachable in practice, because smb2_plain_req_init() calls smb2_reconnect() first and that already fails with -EIO when server is NULL, before anything is allocated. Both returns are given the same treatment here rather than leaving one of them correct only by accident. Because -EAGAIN is a replayable error, the failure also reaches the retry block at the end of smb2_async_readv(), which marks the subrequest NETFS_SREQ_NEED_RETRY, so a failing registration can be retried rather than ending the I/O, and every attempt that reaches it leaks another buffer. smb2_should_replay() short-circuits on tcon->retry, so on a hard mount the attempt count is not bounded by the retrans setting. Only the asynchronous read path is affected. The synchronous SMB2_read() caller passes rdata == NULL and the memory registration block is guarded on rdata. The memory registration failure path was pointed out by the Sashiko AI reviewer while it was reviewing an unrelated patch to smb2_async_readv().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90126", "url": "https://ubuntu.com/security/CVE-2026-90126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf8563: fix clock provider leak on unbind pcf8563_clkout_register_clk() registers the CLKOUT clock provider with of_clk_add_provider(), but nothing ever unwinds it: there is no of_clk_del_provider() call and the driver has no remove callback. Each of_clk_add_provider() allocates a struct of_clk_provider, takes a reference on the OF node and adds an entry to the global of_clk_providers list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an of_node reference. The clock itself is already device-managed (devm_clk_register()); only the provider registration was not. Use devm_of_clk_add_hw_provider() so the provider is removed automatically on unbind. Tie it to the parent i2c device, whose OF node carries the #clock-cells and clock-output-names properties (the RTC class device has no OF node of its own).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90127", "url": "https://ubuntu.com/security/CVE-2026-90127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio: rtc: time out alarm requests RTC class operations run with rtc_device.ops_lock held. The virtio RTC alarm requests currently wait without a timeout for the device to return their requestq buffers. On surprise removal, virtio-pci marks the virtqueues broken before unregistering the virtio device. If an alarm request is waiting when the device stops responding, viortc_remove() blocks in viortc_class_stop() while trying to acquire ops_lock. The request cannot complete and device removal hangs until the waiting task is signalled. Use the same 60-second timeout as clock read requests for alarm reads, alarm programming, and alarm interrupt enable requests. The existing message reference counting keeps a timed-out request alive until a late response or device teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90128", "url": "https://ubuntu.com/security/CVE-2026-90128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: fix wrong list iterated in add_direct_chain error path In add_direct_chain(), newly allocated direct MR entries are added to the local list 'tmp', which is spliced into mr->head only on success. On the error path, the cleanup loop was incorrectly iterating over mr->head instead of tmp. Fix by iterating over 'tmp' in the err_alloc cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90129", "url": "https://ubuntu.com/security/CVE-2026-90129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_balloon: quiesce balloon work before device shutdown Commit 8bd2fa086a04 (\"virtio: break and reset virtio devices on device_shutdown()\") added a generic virtio bus .shutdown handler that breaks and resets every virtio device during device_shutdown(), i.e. on reboot and kexec. virtio_balloon provides no .shutdown of its own, so that generic path runs while the balloon's asynchronous work is still armed. Once the device has been broken, virtqueue_add_inbuf() in virtballoon_free_page_report() returns -EIO and trips its WARN_ON_ONCE(). On a kernel booted with panic_on_warn that turns an ordinary reboot, for example a kexec based upgrade, into a fatal panic in the middle of device_shutdown(), so the machine never reaches the new kernel. Relaxing that single WARN_ON_ONCE() would only hide the symptom: the inflate/deflate and OOM paths do not warn, they call wait_event(vb->acked, ...) and would instead block forever on a broken queue that can no longer complete. The device has to be quiesced, not just kept quiet. Add a .shutdown handler that quiesces the balloon via the shared virtballoon_quiesce() helper while the device is still alive, and only then breaks and resets it via virtio_device_shutdown(). Unlike virtballoon_remove() the balloon workqueue is not destroyed, as shutdown does not free the device and cancel_work_sync() together with stop_update already prevent any further work from being queued.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90130", "url": "https://ubuntu.com/security/CVE-2026-90130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa_sim: fix cleanup after worker creation failure vdpasim_create() leaves vdpasim->worker as an ERR_PTR when kthread_run_worker() fails. The error path then drops the device reference, which releases the partially initialized simulator. vdpasim_free() unconditionally passes the worker pointer to kthread_destroy_worker(), so the ERR_PTR is dereferenced and can trigger a general protection fault. Store the worker error, clear the pointer, and only clean up the worker when it was successfully initialized. Also make the release path tolerate partially initialized objects by guarding virtqueue and IOTLB cleanup, since the same release path can be reached from other initialization failures. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90135", "url": "https://ubuntu.com/security/CVE-2026-90135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add missing ref_tracker_dir_exit() to alloc_netdev_mqs() sashiko is reporting that trying to read /sys/kernel/debug/ref_tracker/* causes use-afer-free crash when either alloc_percpu() or dev_addr_init() in alloc_netdev_mqs() failed, for commit 4d92b95ff2f9 (\"net: add net device refcount tracker infrastructure\") added ref_tracker_dir_exit() to only free_netdev() path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90136", "url": "https://ubuntu.com/security/CVE-2026-90136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/hsmp: Reject negative power cap writes in hwmon hsmp_hwmon_write() takes the user-supplied hwmon value as a signed long and assigns \"val / MICROWATT_PER_MILLIWATT\" to msg.args[0], which is a __u32. MICROWATT_PER_MILLIWATT is an unsigned long, so a negative write to power1_cap (e.g. \"echo -1 > power1_cap\") is first converted to a huge unsigned value by the division and then stored into the u32 argument. As a result a nonsensical, multi-gigawatt socket power limit is sent to the SMU via HSMP_SET_SOCKET_POWER_LIMIT instead of the write being rejected. Reject negative values with -EINVAL before the conversion. Tested with HSMP enabled: CAP=$(dirname $(grep -l amd_hsmp_hwmon \\ /sys/class/hwmon/hwmon*/name | head -1))/power1_cap # negative write echo -1000000 > $CAP ; echo \"ret=$?\" # valid positive write must still work echo 400000000 > $CAP ; echo \"ret=$?\" Before: # echo -1000000 > $CAP ; echo \"ret=$?\" ret=0 <- accepted; bogus limit sent to SMU # echo 400000000 > $CAP ; echo \"ret=$?\" ret=0 After: # echo -1000000 > $CAP ; echo \"ret=$?\" bash: echo: write error: Invalid argument ret=1 <- rejected with -EINVAL # echo 400000000 > $CAP ; echo \"ret=$?\" ret=0 <- valid write still works", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90137", "url": "https://ubuntu.com/security/CVE-2026-90137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: fix password encoding bounds check The password PSWD_ENCODINGS parser reads password_obj[elem + pos_values] while copying the supported password encodings from the ACPI package. The outer loop only guarantees that elem is within password_obj_count. The encoding count is bounded by MAX_ENCODINGS_SIZE, but that does not guarantee that the ACPI package contains enough entries for all elem + pos_values accesses. A malformed package can therefore declare a non-zero encoding count without providing enough string objects, causing the parser to read past the ACPI package array and pass an out-of-bounds string pointer and length to hp_convert_hexstr_to_str(). Add the same computed-index bounds check used by the other offset-based package parsing loops before reading password_obj[elem + pos_values].", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90138", "url": "https://ubuntu.com/security/CVE-2026-90138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: don't check the listener's sk_err in vsock_accept() Syzbot reported an issue which can be reproduced with these steps: \tr0 = socket(AF_VSOCK, SOCK_STREAM, 0) \tbind(r0, {VMADDR_CID_ANY, PORT}) \tconnect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (self-connect) \tlisten(r0, backlog) -> 0 \tr1 = socket(AF_VSOCK, SOCK_STREAM, 0) \tconnect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0 \taccept(r0) -> -1, EPROTO (stale sk_err) Basically, it creates a socket (r0) and triggers a self-connect after binding it. This self-connect fails with EPROTO because it loops back to r0 while the socket is still in the TCP_SYN_SENT state, causing it to be incorrectly dispatched to the connecting-client path. The unexpected packet type encountered there sets sk_err to EPROTO. After that, it invokes a listen() call on the same socket. This listen() call succeeds because the kernel's listening path never inspects or clears sk_err. Then, a new socket (r1) is created as a normal client and connects to r0. However, vsock_accept() rejects this incoming connection because the listener's sk_err still holds the EPROTO error from the earlier failed self-connect. This rejection causes the child socket created for r1's connection to never be freed on virtio or hyperv transports; only the VMCI transport implements pending_work to revisit and clean up a rejected socket. For a non-blocking connect(), vsock_connect() may return -EINPROGRESS immediately, and vsock_connect_timeout() can later set sk->sk_err asynchronously. Since no vsock transport ever sets sk_err on a socket while it is in TCP_LISTEN state, checking it in vsock_accept() serves no purpose and only carries forward errors left behind by earlier, unrelated connection attempts on the same socket. Remove the checks so accept() no longer rejects valid incoming connections because of a stale error, which also avoids the resource leak described above.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90139", "url": "https://ubuntu.com/security/CVE-2026-90139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: check for NULL root inode in fuse_fill_super_submount fuse_iget() can return NULL when its inode allocation fails, but fuse_fill_super_submount() passed the result straight to get_fuse_inode() and decremented fi->nlookup without checking it: root = fuse_iget(sb, parent_fi->nodeid, ...); fi = get_fuse_inode(root); fi->nlookup--; Inside fuse_iget() the inode allocation can fail and return NULL. The submount root takes the iget5_locked() path, whose alloc_inode() can fail under memory pressure (the auto-submount branch can fail the same way in new_inode() or fuse_alloc_submount_lookup()): inode = iget5_locked(sb, nodeid, fuse_inode_eq, fuse_inode_set, &nodeid); if (!inode) return NULL; A NULL root makes get_fuse_inode() a container_of() on NULL and the nlookup decrement a write to a bogus address, oopsing the mount. With CONFIG_KASAN the following null pointer dereference is reported when the root inode allocation of an auto-submount fails (e.g. under memory pressure): ================================================================== BUG: KASAN: null-ptr-deref in fuse_get_tree_submount+0x656/0x8b0 Read of size 8 at addr 00000000000002b0 by task ls/942 CPU: 0 PID: 942 Comm: ls Tainted: G W 6.6 #15 Call Trace: fuse_get_tree_submount+0x656/0x8b0 vfs_get_tree+0x48/0x140 fc_mount+0x13/0x50 fuse_dentry_automount+0x7a/0xb0 __traverse_mounts+0xca/0x330 step_into+0x339/0xac0 path_lookupat+0xc5/0x2f0 filename_lookup+0x163/0x2a0 vfs_statx+0xd5/0x200 do_statx+0x83/0xd0 __x64_sys_statx+0xa0/0xc0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ================================================================== Return -ENOMEM instead; the caller tears down the partially built superblock on error, matching the other error returns in this function.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89779", "url": "https://ubuntu.com/security/CVE-2026-89779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate ef->size covers the record's name and value When an EA record has a non-zero ef->size, ntfs_read_ea() only checks that the record fits in the remaining buffer (ea_size > bytes), not that ef->size is large enough to hold the record's own name_len + 1 + elength. A crafted image can pass validation with, e.g., ef->size = 24 but elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of the undersized record, reading past the kmalloc(info->size) allocation and leaking heap memory to userspace via getxattr(): BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302) Read of size 65535 at addr ffff888100794550 by task exploit __asan_memcpy (mm/kasan/shadow.c:105) ntfs_get_ea (fs/ntfs3/xattr.c:302) ntfs_getxattr (fs/ntfs3/xattr.c:848) __vfs_getxattr (fs/xattr.c:441) vfs_getxattr (fs/xattr.c:474) do_getxattr (fs/xattr.c:800) path_getxattrat (fs/xattr.c:868) do_syscall_64 (arch/x86/entry/syscall_64.c:94) The buggy address is located 80 bytes inside of allocated 84-byte region in cache kmalloc-96 Compute the size the record needs and require ef->size to cover it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89781", "url": "https://ubuntu.com/security/CVE-2026-89781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read in read_log_rec_buf() read_log_rec_buf() copies a log record into a caller buffer starting at \tu32 off = lsn_to_page_off(log, lsn) + log->record_header_len; log->record_header_len (and log->data_off, used for the following pages) comes verbatim from the on-disk restart area and is only checked for 8-byte alignment in is_rst_area_valid(), so off can exceed log->page_size. \"tail = log->page_size - off\" then underflows and memcpy() reads past the page_size-sized buffer returned by read_log_page(), spilling adjacent slab memory into the replay buffer. This is reachable by mounting a crafted NTFS image: BUG: KASAN: slab-out-of-bounds in read_log_rec_buf+0x216/0x580 Read of size 64 at addr ffff88800a877ff8 by task exploit/127 read_log_rec_buf fs/ntfs3/fslog.c:2299 log_replay fs/ntfs3/fslog.c:4216 ntfs_loadlog_and_replay fs/ntfs3/fsntfs.c:324 ntfs_fill_super fs/ntfs3/super.c:1392 get_tree_bdev_flags fs/super.c:1694 __x64_sys_mount fs/namespace.c:4360 The buggy address is located 4088 bytes to the right of the 4096-byte region [ffff88800a876000, ffff88800a877000) Reject an in-page offset outside the current page before the copy. [almaz.alexandrovich@paragon-software.com: replaced the >= sign with >]", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90140", "url": "https://ubuntu.com/security/CVE-2026-90140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cuse: wait for pending RCU callbacks on module exit Since commit 053fc4f755ad (\"fuse: fix UAF in rcu pathwalks\"), fuse_conn_put() frees the fuse_conn through call_rcu() rather than synchronously. For cuse, fc->release is cuse_fc_release(), which lives in the cuse module. If the module is removed before the RCU grace period ends, the callback jumps into freed module memory: userspace / module unload | RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ close(/dev/cuse) | cuse_channel_release() | fuse_dev_release() | fuse_conn_put(fch->conn) | call_rcu(delayed_release) ------+---> callback queued | rmmod cuse | cuse_exit() | cuse_channel_destroy() | ... | return | | | | rcu_do_batch() | delayed_release() | fc->release() | -> cuse_fc_release() | ^^^ freed text! The freed module text is unmapped by vfree(), so the jump into the stale callback triggers a page-fault Oops. If the virtual address is subsequently reused, the callback could execute unrelated code (undefined behaviour). Fix this by calling rcu_barrier() in cuse_exit() so that any pending fuse_conn release callback completes before the module is removed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89776", "url": "https://ubuntu.com/security/CVE-2026-89776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: vnifilter: enforce exact length of GROUP/GROUP6 attributes The VXLAN VNI filter entry policy declares the GROUP/GROUP6 address attributes as NLA_BINARY with only a maximum length, so validate_nla() accepts a payload shorter than the address. The GROUP consumer reads it with nla_get_in_addr(), an unconditional 4-byte load, so a short attribute over-reads up to 3 bytes of uninitialised slab data, which are stored into remote_ip and echoed back via RTM_GETTUNNEL, disclosing kernel memory. Switch both entries to NLA_POLICY_EXACT_LEN() so the validator rejects any GROUP/GROUP6 that is not exactly 4 / 16 bytes; a valid address is always sent at full width.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90141", "url": "https://ubuntu.com/security/CVE-2026-90141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix integer overflow in ftp helper port/address parsing ip_vs_ftp_get_addrport() accumulates decimal digits into a __u16 (hport) and into unsigned char (p[]) without checking for overflow. A crafted FTP PASV/EPSV response with an over-long port or address octet wraps the value, so the helper configures the data connection with a truncated port/address. The netfilter conntrack FTP helper had the same defect, fixed in commit 2b413fc689ba (\"netfilter: nf_conntrack_ftp: avoid u16 overflows\"). Apply the equivalent fix here: widen the port accumulator to u32 and reject values above 65535, and reject address octets above 255.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90143", "url": "https://ubuntu.com/security/CVE-2026-90143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: kcm: Hold RCU read lock while running BPF parser kcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which prevents CPU migration, but does not establish an RCU read-side critical section. Consequently, BPF map operations can trigger WARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser program. Hold the RCU read lock while running the program.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90145", "url": "https://ubuntu.com/security/CVE-2026-90145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hinic3: Fix skb linearization mismatch and drop skb when skb_checksum_help() failed Previously, hinic3_send_one_skb() cached the skb fragment count before calling hinic3_tx_offload(). If hinic3_tx_csum() falls back to skb_checksum_help() for unsupported tunnel packets, the skb may be linearized. Continuing to build the TX descriptor with the stale fragment count leads to a descriptor mismatch, which can trigger out-of-bounds DMA reads or IOMMU faults. Furthermore, the old code ignored the return value of skb_checksum_help(), transmitting corrupted packets with incomplete checksums upon failure. Fix this by: 1. Moving the hinic3_tx_offload() call before calculating 'num_sge' to ensure the correct fragment count is used if the SKB is linearized. 2. Propagating skb_checksum_help() errors and returning HINIC3_TX_OFFLOAD_INVALID to properly drop the skb.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90146", "url": "https://ubuntu.com/security/CVE-2026-90146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, xdp: move offload check into dev_xdp_install() bpf_xdp_link_update() calls dev_xdp_install() directly and skips dev_xdp_attach(), so the checks in dev_xdp_attach() do not run. A user can make an XDP link with a normal program and then swap in an offloaded or device-bound program with BPF_LINK_UPDATE, which puts it on the software path. dev_xdp_install() is the one place all three paths go through: \"ip link set xdp\" and BPF_LINK_CREATE reach it via dev_xdp_attach(), and BPF_LINK_UPDATE calls it directly. So move the program checks (offloaded, bound to another device, device-bound in generic mode, native vs generic, DEVMAP and CPUMAP) there, and keep only the netlink-flag check (XDP_FLAGS_UPDATE_IF_NOEXIST) in dev_xdp_attach().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90147", "url": "https://ubuntu.com/security/CVE-2026-90147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: devres: fix cleanup in devm_clk_get_optional_enabled_with_rate() devm_clk_get_optional_enabled_with_rate() registers its cleanup action before setting the clock rate. If setting the rate fails, it attempts to disable and unprepare a clock that was never enabled. This issue was spotted while reviewing \"rust: clk: add devres-managed clks\" [1]. Register the cleanup action only after successfully preparing and enabling the clock. [1]: https://lore.kernel.org/rust-for-linux/20260706-clk-type-state-v5-3-67c5f326a16c@collabora.com", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90148", "url": "https://ubuntu.com/security/CVE-2026-90148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Fix incorrect argument passed to nfs4_delete_lease() in nfs4_add_lease() When nfs4_add_lease() races with a delegation return, it calls nfs4_delete_lease() to clean up. Previously, it passed priv, which can legitimately be NULL. Passing a NULL priv eventually leads to a NULL pointer dereference in generic_setlease().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90149", "url": "https://ubuntu.com/security/CVE-2026-90149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/flexfiles: fix NULL dereference for NFSv4.0 data servers flexfiles accepts NFSv4.0 data servers, but two NFSv4 code paths assume the data server client has a session. Unlike NFSv4.1+, an NFSv4.0 client has no session (clp->cl_session is NULL; it uses clp->cl_slot_tbl), so I/O to a v4.0 flexfiles DS oopses: - nfs4_init_ds_session() dereferences clp->cl_session->session_state while seeding the DS lease. It also only seeds cl_lease_time when NFS4_SESSION_INITING is set; without a session that never happens, so cl_lease_time stays 0 and nfs4_renew_state() busy-loops, requeuing every 5 seconds. Seed the lease whenever there is no session and return before touching session state. - ff_layout_async_handle_error_v4() dereferences clp->cl_session->fc_slot_table on every DS I/O error. Fall back to the v4.0 transport slot table (clp->cl_slot_tbl) when there is no session.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90150", "url": "https://ubuntu.com/security/CVE-2026-90150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pnfs/blocklayout: Fix device leaks on parse failure bl_parse_concat() and bl_parse_stripe() allocate a child device array and then parse each child in turn. If parsing a child fails, the failed child is not counted in nr_children and the parent may be left with a children array that bl_free_device() will not release when nr_children is zero. Release the failed child and the already parsed children before returning the error. Also make bl_free_device() release the child array whenever the children pointer is set, so that partially initialised concat or stripe devices are cleaned up correctly. bl_parse_scsi() can also fail after assigning d->bdev_file and dropping the file reference. Clear the pointer after fput() so that an outer cleanup path does not put it again.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90151", "url": "https://ubuntu.com/security/CVE-2026-90151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: remove callback IDR entry on client allocation failure nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfs_client directly with nfs_free_client(). That bypasses nfs_put_client(), which is where the callback IDR entry is removed during normal teardown. A failed allocation can therefore leave cb_ident_idr pointing at a freed nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the stale pointer and take a reference to it. Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client. This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90152", "url": "https://ubuntu.com/security/CVE-2026-90152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix session leak in ksmbd_session_register() See the procedure below: smb2_sess_setup ksmbd_smb2_session_create __session_create atomic_set(&sess->refcnt, 2) hash_add(sessions_table, &sess->hlist, sess->id) ksmbd_session_register xa_store(&conn->sessions, sess->id, sess) // fail ksmbd_user_session_put atomic_dec(&sess->refcnt) // refcnt is 1, session is not freed Remove the session from sessions_table and drop its table reference if xa_store() fails.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90153", "url": "https://ubuntu.com/security/CVE-2026-90153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound smb_check_perm_dacl() ACE walks by DACL size smb_check_perm_dacl() validates that the DACL fits inside the NT security descriptor, but then bounds its two ACE walks by the remaining NTSD length (acl_size) rather than the DACL's declared size (pdacl_size). When pdacl->size is smaller than the trailing NTSD buffer, bytes after the declared DACL boundary - still inside the stored security descriptor - are parsed as ACEs during access checks. A crafted DACL can place an access-granting ACE beyond pdacl->size, and the current code accepts it during SMB2_CREATE access validation, while parse_dacl() and smb_inherit_dacl() stop at pdacl_size. Bound both ACE walks by pdacl_size to match the DACL boundary semantics used elsewhere in the server. Validation: - semantic KUnit harness shows the post-boundary ACE is selected before the fix and rejected (EACCES) after it - linux master (7.2-rc6), x86_64", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90157", "url": "https://ubuntu.com/security/CVE-2026-90157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative optlen in cgroup getsockopt hook A cgroup getsockopt BPF program can shrink ctx->optlen after the kernel getsockopt handler has run. The kernel-buffer variant, used by TCP_ZEROCOPY_RECEIVE, only rejects values larger than the original length. If BPF writes a negative optlen, that value is accepted and propagated back to the TCP getsockopt code. It can then be passed to copy_to_sockptr() as a size_t and trigger the hardened usercopy bytes > INT_MAX warning. Reject negative ctx.optlen in __cgroup_bpf_run_filter_getsockopt_kern(), matching the lower-bound validation already present in the sockptr-based getsockopt hook.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90158", "url": "https://ubuntu.com/security/CVE-2026-90158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: m68k: nfcon: Do not call console_is_registered() in nfcon_device() Since 7c2af0f634f1 (\"tty: tty_io: use console_list_lock for list synchronization\") show_cons_active() calls the .device() method under the console_list_lock, but console_is_registered() tries to acquire console_list_lock as well, causing a deadlock. It should not be necessary to check console_is_registered() here since the function should not be called in the fist place when the console is not registered.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90159", "url": "https://ubuntu.com/security/CVE-2026-90159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disallow bpf_{g,s}etsockopt() in cgroup UNIX getname hooks _bpf_setsockopt() and _bpf_getsockopt() call sock_owned_by_me() for full sockets, so these helpers expect the socket lock to be held. BPF_CGROUP_UNIX_GETPEERNAME and BPF_CGROUP_UNIX_GETSOCKNAME run BPF programs without acquiring the socket lock. A program attached to either hook can therefore trigger the sock_owned_by_me() warning by calling bpf_setsockopt() or bpf_getsockopt(). Disallow bpf_setsockopt() and bpf_getsockopt() for CGROUP_UNIX_GETPEERNAME and CGROUP_UNIX_GETSOCKNAME.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90160", "url": "https://ubuntu.com/security/CVE-2026-90160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lwt_bpf: Restore reserved headroom after xmit program ip_finish_output2() expands an skb to LL_RESERVED_SPACE(dev) before LWT xmit. An LWT_XMIT BPF program can then modify the skb head and still return BPF_OK, so bpf_xmit() rechecks the remaining headroom before the skb continues to neighbour output. That recheck uses dst->dev->hard_header_len. This is not enough for the neighbour cached-header path: neigh_hh_output() copies the cached hardware header using the aligned hh_cache size, HH_DATA_MOD for short headers or HH_DATA_ALIGN(hh_len) otherwise. On Ethernet, hard_header_len is 14 but the cached copy needs 16 bytes. If an LWT_XMIT BPF program calls bpf_skb_change_head(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neigh_hh_output() hits its headroom warning and drops the skb. Use LL_RESERVED_SPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90161", "url": "https://ubuntu.com/security/CVE-2026-90161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix interlaced ztailpacking pclusters On-disk sizes of interlaced pclusters should be block-aligned, and ztailpacking interlaced pclusters should be invalid at all. Currently, mkfs.erofs won't generate any interlaced pcluster with ztailpacking enabled, so this doesn't affect any existing valid filesystems. However, crafted images can contain invalid interlaced ztailpacking pclusters, resulting in an out-of-bounds read from a kmap'd page and copying irrelevant kernel memory into userspace-visible page cache.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90165", "url": "https://ubuntu.com/security/CVE-2026-90165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix invalid pointer dereference in ksmbd_stop_durable_scavenger() See the procedure below: ksmbd_launch_ksmbd_durable_scavenger durable_scavenger_running = true server_conf.dh_task = kthread_run() // fail, dh_task is an ERR_PTR() server_ctrl_handle_reset ksmbd_stop_durable_scavenger kthread_stop(server_conf.dh_task) // invalid pointer", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90166", "url": "https://ubuntu.com/security/CVE-2026-90166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix null-ptr-deref in ksmbd_ipc_tree_connect_request() See the procedure below: ksmbd_tree_conn_connect ksmbd_share_config_get share->name = kstrdup() // fail if (!test_share_config_flag(share, KSMBD_SHARE_FLAG_PIPE)) // false // do not check `share->name` ksmbd_ipc_tree_connect_request strlen(share->name) // null-ptr-deref", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90169", "url": "https://ubuntu.com/security/CVE-2026-90169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: free preauth sessions on connection teardown SMB3.1.1 multichannel binding preserves the preauthentication hash in a preauth_session between the NTLM negotiate and authenticate requests. The binding NTLM negotiate allocates this object and returns STATUS_MORE_PROCESSING_REQUIRED. If the client disconnects before it sends the authenticate request, neither the authenticate nor error cleanup paths free the object. Release any remaining preauthentication sessions when tearing down the connection. Initialize the list when allocating the connection so that this cleanup is safe regardless of the negotiated dialect.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90170", "url": "https://ubuntu.com/security/CVE-2026-90170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ipc response length before dereferencing its fields ipc_validate_msg() computes the expected message size by reading length fields out of the response buffer supplied by the userspace ksmbd daemon (payload_sz, session_key_len, ngroups, ...). Those fields are read before the buffer is verified to be large enough to contain the struct they belong to, so a short response makes the read land past the end of the allocation. handle_response() sizes entry->response purely from the netlink attribute length (nla_len()) and only guards the leading handle read, so the daemon can install a response as small as the kmalloc-8 object seen below. When ipc_msg_send_request() then calls ipc_validate_msg() for a KSMBD_EVENT_RPC_REQUEST, the cast to struct ksmbd_rpc_command reads resp->payload_sz at offset 8 of an 8-byte allocation: [ 3697.841381] ================================================================== [ 3697.844099] BUG: KASAN: slab-out-of-bounds in ipc_msg_send_request+0x763/0x800 [ 3697.846604] Read of size 4 at addr ffff888105f95910 by task kworker/4:3/20682 [ 3697.849061] [ 3697.849801] CPU: 4 UID: 0 PID: 20682 Comm: kworker/4:3 Not tainted 7.2.0-rc3-next-20260717-virtme #117 PREEMPT(lazy) [ 3697.850077] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3697.850303] Workqueue: ksmbd-io handle_ksmbd_work [ 3697.850592] Call Trace: [ 3697.850794] [ 3697.850952] __dump_stack+0x21/0x60 [ 3697.851239] dump_stack_lvl+0xc2/0x100 [ 3697.851528] print_address_description+0x77/0x200 [ 3697.851816] ? ipc_msg_send_request+0x763/0x800 [ 3697.852024] print_report+0x58/0x70 [ 3697.852316] kasan_report+0x117/0x150 [ 3697.852585] ? down_write+0x146/0x1f0 [ 3697.852809] ? ipc_msg_send_request+0x763/0x800 [ 3697.853082] ipc_msg_send_request+0x763/0x800 [ 3697.853385] ? __pfx_ipc_msg_send_request+0x10/0x10 [ 3697.853604] ? kasan_unpoison+0x48/0x70 [ 3697.853936] ? __pfx___up_read+0x10/0x10 [ 3697.854221] ksmbd_rpc_ioctl+0x380/0x520 [ 3697.854542] ? __pfx_ksmbd_rpc_ioctl+0x10/0x10 [ 3697.854757] ? kasan_unpoison+0x48/0x70 [ 3697.854962] ? copy_from_kernel_nofault+0x32c/0x4e0 [ 3697.855166] ? kasan_unpoison+0x48/0x70 [ 3697.855416] fsctl_pipe_transceive+0x139/0x7a0 [ 3697.855705] ? __pfx_copy_from_kernel_nofault+0x10/0x10 [ 3697.855937] ? __pfx_fsctl_pipe_transceive+0x10/0x10 [ 3697.856388] ? __sanitizer_cov_trace_switch+0x7b/0x140 [ 3697.856620] smb2_ioctl+0x1141/0x3420 [ 3697.856994] ? __pfx_smb2_ioctl+0x10/0x10 [ 3697.857182] ? get_smb2_cmd_val+0xe3/0x1c0 [ 3697.857655] handle_ksmbd_work+0x9ad/0x15e0 [ 3697.858034] ? __pfx_handle_ksmbd_work+0x10/0x10 [ 3697.858251] ? lock_release+0xf7/0x360 [ 3697.858466] ? process_scheduled_works+0x954/0x1600 [ 3697.858698] ? process_scheduled_works+0x954/0x1600 [ 3697.858905] process_scheduled_works+0xc22/0x1600 [ 3697.859368] ? __pfx_process_scheduled_works+0x10/0x10 [ 3697.859637] ? __pfx_assign_work+0x10/0x10 [ 3697.859896] ? lock_is_held_type+0x7b/0x110 [ 3697.860146] worker_thread+0x975/0xee0 [ 3697.860524] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 3697.860830] ? __kthread_parkme+0x21e/0x260 [ 3697.861105] kthread+0x3a6/0x490 [ 3697.861423] ? __pfx_worker_thread+0x10/0x10 [ 3697.861643] ? __pfx_kthread+0x10/0x10 [ 3697.861878] ret_from_fork+0x55a/0xa20 [ 3697.862194] ? __pfx_ret_from_fork+0x10/0x10 [ 3697.862480] ? __pfx_kthread+0x10/0x10 [ 3697.862714] ret_from_fork_asm+0x1a/0x30 [ 3697.862965] [ 3697.863039] [ 3697.938882] Allocated by task 20761: [ 3697.940257] kasan_save_track+0x3e/0x80 [ 3697.941782] __kasan_kmalloc+0x72/0x90 [ 3697.943228] __kvmalloc_node_noprof+0x3e9/0x6a0 [ 3697.944948] handle_generic_event+0x59b/0x750 [ 3697.946592] genl_family_rcv_msg_doit+0x3d6/0x560 [ 3697.946977] genl_rcv_msg+0x67c/0x900 [ 3697.947224] netlink_rcv_skb+0x286/0x580 [ 3697.947488] genl_rcv+0x2d/0x80 [ 3 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90175", "url": "https://ubuntu.com/security/CVE-2026-90175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak of ksmbd_ipc_login_request_ext() returned buffer Free it unconditionally after ksmbd_alloc_user() calls. kmemleak splat: unreferenced object 0xffff888103b83540 (size 192): comm \"pool-0\", pid 16970, jiffies 4377290937 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 408ccc66): __kvmalloc_node_noprof+0x730/0x920 handle_generic_event+0xec/0x1a0 [ksmbd] genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x181/0x290 netlink_rcv_skb+0x4f/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x1e6/0x2c0 netlink_sendmsg+0x20a/0x450 ____sys_sendmsg+0x2e8/0x310 ___sys_sendmsg+0x78/0xc0 __sys_sendmsg+0x63/0xc0 do_syscall_64+0xa1/0x670 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90176", "url": "https://ubuntu.com/security/CVE-2026-90176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Do not skip lock checks for single-byte ranges check_lock_range() uses inclusive ranges. Its callers pass the end offset as start + length - 1, so start == end represents a valid single-byte range rather than an empty range. The start == end shortcut therefore skips mandatory byte-range lock checks for one-byte reads, writes, copychunk operations and one-byte truncate ranges. A conflicting lock covering that byte is not checked and the operation is allowed to proceed. Remove the shortcut. The truncate size == inode->i_size case is already handled by only calling check_lock_range() when the new size differs from the current file size.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90178", "url": "https://ubuntu.com/security/CVE-2026-90178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix core_data leak on CPUs without PTS pdata->core_data is allocated in init_temp_data() when the first core temp_data of a package is created, but it is only released from destroy_temp_data(), and only in the branch that handles the package temp_data. Package temp_data is created solely when the CPU supports X86_FEATURE_PTS. On a CPU without it, coretemp_cpu_online() never calls coretemp_add_core() with pkg_flag set, so pdata->pkg_data stays NULL. coretemp_cpu_offline() then skips the removal of the package interface, destroy_temp_data() is never called for package data, and the array is still allocated when coretemp_device_remove() frees the platform data that pointed at it. Release the array in coretemp_device_remove(). destroy_temp_data() sets pdata->core_data to NULL when it frees it, so the added kfree() is a no-op on CPUs that do have PTS. Tested on an Intel Core i5-1135G7. The driver was instrumented to log every allocation and release of pdata->core_data, and the PTS check in coretemp_cpu_online() was patched out to emulate a CPU without package thermal support. Without this change the array was allocated and never released, and coretemp_device_remove() still saw a non-NULL pointer. With it the array is released and the pointer accounting balances. On an unmodified build the release still happens via the package temp_data and the added kfree() sees NULL, with no slab warnings over repeated module load and unload cycles.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90179", "url": "https://ubuntu.com/security/CVE-2026-90179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix deadlock in complain-mode change_hat The use of change_hat when in complain mode can cause a deadlock when the hat doesn't exist and a new learning profile is created for the missing profile. This is because change_hat() has taken the lock to search the hat list and creating the new learning profile needs to take the lock to add it to the list. From the bug report: Originally found in 7.0.0 in LTS ubuntu 26.04 with pam_apparmor + su in complain mode set to change hats. Then verified in newest available vanilla kernel I've compiled to see if still present: 7.2-rc7 vanilla -> affected checked also some other kernels: 6.18.44 vanilla -> affected 6.12.95 with debian patches -> unaffected On systems without bug (for example 6.12.95 debian) it just prints: aa_change_hat rc=0 On systems with bug, the executable always hangs, prints nothing and becomes unkillable. (And once stuck this way, it will cause any further hat changes to also cause the changing process to get stuck) Then in syslog you can find hint about cause: kernel: INFO: task hat:3409 blocked for more than 483 seconds. kernel: Not tainted 7.2.0-rc7 #1 kernel: \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. kernel: task:hat state:D stack:0 pid:3409 tgid:3409 ppid:2605 task_flags:0x400000 flags:0x00080800 kernel: Call Trace: kernel: kernel: __schedule+0x48f/0xfe0 kernel: schedule+0x27/0xa0 kernel: schedule_preempt_disabled+0x15/0x30 kernel: __mutex_lock.constprop.0+0x569/0xa10 kernel: aa_new_learning_profile+0x15f/0x210 kernel: build_change_hat+0x19f/0x3b0 kernel: change_hat.isra.0+0x5dd/0xd60 kernel: aa_change_hat+0x2f3/0x710 kernel: aa_setprocattr_changehat+0x121/0x1f0 kernel: do_setattr+0x28c/0x340 kernel: apparmor_setselfattr+0x20/0x50 kernel: security_setselfattr+0xf6/0x110 kernel: __x64_sys_lsm_set_self_attr+0x53/0x90 kernel: do_syscall_64+0xdd/0x5e0 kernel: ? __mod_memcg_lruvec_state+0xfd/0x260 kernel: ? lruvec_stat_mod_folio+0x8d/0xd0 kernel: ? __folio_mod_stat+0x2d/0x90 kernel: ? map_anon_folio_pte_nopf+0xd1/0x1f0 kernel: ? do_anonymous_page+0x184/0xa10 kernel: ? __handle_mm_fault+0x805/0x870 kernel: ? count_memcg_events+0xef/0x230 kernel: ? handle_mm_fault+0x1f0/0x2f0 kernel: ? do_user_addr_fault+0x2bb/0x7b0 kernel: ? do_syscall_64+0x94/0x5e0 kernel: ? exc_page_fault+0x75/0x160 kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e kernel: RIP: 0033:0x7f815e134c8d kernel: RSP: 002b:00007fff6df94ea8 EFLAGS: 00000246 ORIG_RAX: 00000000000001cc kernel: RAX: ffffffffffffffda RBX: 0000556d8c81d040 RCX: 00007f815e134c8d kernel: RDX: 0000000000000046 RSI: 0000556d8c81d040 RDI: 0000000000000064 kernel: RBP: 00007fff6df94ef0 R08: 00007f815e212ac8 R09: 000000000000000c kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000556d8c81d010 kernel: R13: 0000000000000026 R14: 0000000000000046 R15: 0000000000000064 kernel: kernel: INFO: task hat:3409 is blocked on a mutex likely owned by task hat:3409. To fix the issue, lift the locking out of the core of aa_new_learning_profile(), introduce a wrapper function that takes the lock where needed, and have build_change_hat() call the core function that no longer takes the lock. In addition fix 4 other issues introduced by commit 32e92764d6f8d (\"apparmor: grab ns lock and refresh when looking up changehat child profiles\") - aa_get_profile_rcu() was replaced-by: aa_get_profile without the accompanying rcu_dereference_protected() - an extra aa_get_label(label) was introduced at the start of change_hat() without an accompanying aa_put_label() causing a reference count leak. - a reference count leak was introduced in the label_is_stale(label) case, where the newest profile would be leaked instead of the label passed to the function. - a potential UAF when the lookup walks up the tree with new_ns != ns the new label refere ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90180", "url": "https://ubuntu.com/security/CVE-2026-90180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: mtip32xx: synchronize ioctls with device removal The ioctl handlers only test REMOVE_PENDING before entering mtip_hw_ioctl(). Removal can set that bit immediately afterwards and free dd->port in mtip_hw_exit() while an ioctl still dereferences it. An already open block device can reach the handlers while del_gendisk() is in progress. Serialize both native and compat ioctls with removal. Set REMOVE_PENDING before taking the mutex so new callers fail after an in-flight ioctl has drained, and hold the mutex until the port has been torn down.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90184", "url": "https://ubuntu.com/security/CVE-2026-90184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: serialize configfs attribute updates with device setup The attribute store methods generated with NULLB_DEVICE_ATTR() refuse to change the configuration of a live device by testing NULLB_DEV_FL_CONFIGURED, but that flag is only set by nullb_device_power_store() after null_add_dev() has returned, and the store methods take no lock at all. configfs only serializes writes to the same open file (buffer->mutex), so a write to any attribute can run concurrently with null_add_dev() and change the device configuration while it is being used. null_add_dev() reads the configuration several times, e.g. dev->zoned is read once to set up the queue limits and once to initialize the zone resources: CPU0: echo 1 > nullb0/power CPU1: echo 1 > nullb0/zoned nullb_device_power_store() mutex_lock(&lock) null_add_dev() if (dev->zoned) -> false /* no BLK_FEAT_ZONED */ nullb_device_zoned_store() test_bit(FL_CONFIGURED) -> 0 dev->zoned = true blk_mq_alloc_disk() /* queue is not zoned */ if (nullb->dev->zoned) -> true null_register_zoned_dev() blk_revalidate_disk_zones() blk_revalidate_disk_zones() is then called for a queue that does not have BLK_FEAT_ZONED set, which triggers its WARN_ON_ONCE() and fails the device setup with -EIO: WARNING: CPU: 2 PID: 322 at block/blk-zoned.c:2357 blk_revalidate_disk_zones+0x4c/0x560 Clearing dev->zoned in the same window is worse: the queue is created with BLK_FEAT_ZONED but the zone resources are never initialized, so add_disk() succeeds for a zoned disk that has no zones. And a store that lands after the last dev->zoned test leaves dev->zoned set while dev->zones is still NULL, which null_process_zoned_cmd() dereferences on the first write. Fix this by taking the global lock, which nullb_device_power_store() already holds across null_add_dev() and null_del_dev(), around both the NULLB_DEV_FL_CONFIGURED test and the update of the device configuration. The submit_queues and poll_queues apply callbacks are now called with that lock held, so remove the locking they did themselves. Since the store methods can run as soon as configfs_register_subsystem() returns, that is, before null_init() gets to mutex_init(&lock), also initialize the lock statically with DEFINE_MUTEX().", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90185", "url": "https://ubuntu.com/security/CVE-2026-90185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: serialize configfs attribute stores with the lock The NULLB_DEVICE_ATTR _store takes no lock: apply_fn attributes (submit_queues, poll_queues) get dev->NAME written again after apply_fn returns, outside its lock; APPLY=NULL attributes are entirely lockless. configfs only serializes stores per-open-file, so concurrent stores on separate fds race. For apply_fn attributes, once one store's apply_fn has reconfigured the hardware, a second (losing) store can still overwrite dev->NAME afterwards. This leaves dev->submit_queues out of sync with the live queue count, which is later caught by the WARN_ON_ONCE() in null_map_queues(). For !apply_fn attributes, power_store()'s null_add_dev() validates and builds the device under \"lock\" but only sets CONFIGURED afterwards. A store slipping in during this window can change a field mid-setup -- for example, zone_nr_conv can be pushed above nr_zones after it has already been clamped, leading to an out-of-bounds dev->zones[] access. Take \"lock\" in the macro around the apply_fn call, the CONFIGURED test and the field write, and move it out of nullb_apply_submit_queues()/ nullb_apply_poll_queues() so both paths are covered once. This serializes stores with power_store's setup and with each other.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90186", "url": "https://ubuntu.com/security/CVE-2026-90186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: reject per-device queue resize for shared tag set When shared_tags is enabled, null_setup_tagset() makes the device use the global tag_set, whose driver_data stays NULL. null_map_queues() therefore falls back to the module-wide g_submit_queues/g_poll_queues instead of any per-device value. Resizing submit_queues or poll_queues via configfs on such a device calls blk_mq_update_nr_hw_queues() on the shared set, shrinking set->nr_hw_queues. __blk_mq_realloc_hw_ctxs() only grows the q->queue_hw_ctx[] allocation, so on shrink it merely exits and NULLs the now-excess hctx slots. null_map_queues(), however, keeps mapping CPUs with the unchanged g_submit_queues/g_poll_queues, so mq_map[] ends up pointing at those NULLed hctx slots. blk_mq_map_swqueue() then dereferences the NULL hctx (hctx->cpumask), crashing the kernel: [ 460.218374] KASAN: null-ptr-deref in range [0x0000000000000098-0x000000000000009f] [ 460.219003] CPU: 24 UID: 0 PID: 1492 Comm: sh Not tainted 7.2.0-rc2+ #67 PREEMPT(full) [ 460.219792] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 [ 460.220452] RIP: 0010:blk_mq_map_swqueue+0x4db/0x1430 ...... [ 460.228977] Call Trace: [ 460.229175] [ 460.229354] blk_mq_update_nr_hw_queues+0xd49/0x11c0 [ 460.229779] ? __pfx_blk_mq_update_nr_hw_queues+0x10/0x10 [ 460.230200] nullb_update_nr_hw_queues+0x1a9/0x370 [null_blk] [ 460.230694] nullb_device_submit_queues_store+0xd9/0x170 [null_blk] [ 460.231190] ? __pfx_nullb_device_submit_queues_store+0x10/0x10 [null_blk] [ 460.231776] ? configfs_write_iter+0x35c/0x4e0 [ 460.232122] configfs_write_iter+0x286/0x4e0 [ 460.232460] vfs_write+0x52d/0xd00 [ 460.232779] ? __x64_sys_openat+0x108/0x1d0 [ 460.233106] ? __pfx_vfs_write+0x10/0x10 [ 460.233413] ? fdget_pos+0x1cf/0x4c0 [ 460.233745] ? fput_close+0x133/0x190 [ 460.234038] ? __pfx_expand_files+0x10/0x10 [ 460.234368] ksys_write+0xfc/0x1d0 Reproducer: modprobe null_blk shared_tags=1 submit_queues=64 poll_queues=1 mkdir /sys/kernel/config/nullb/dev echo 1 > /sys/kernel/config/nullb/dev/power echo 1 > /sys/kernel/config/nullb/dev/submit_queues A per-device resize of a shared tag set is meaningless anyway, so reject it with -EINVAL in nullb_update_nr_hw_queues() when the device is bound to the global tag_set.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90187", "url": "https://ubuntu.com/security/CVE-2026-90187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: free zones array on device power-off null_init_zoned_dev() allocates dev->zones when a zoned device is powered on, but null_del_dev() never frees it on power-off; dev->zones is only freed later in null_free_dev(), when the configfs directory is removed. If the device is powered off and then on again, null_init_zoned_dev() allocates a new array and overwrites the dev->zones pointer, leaking the previous allocation each power cycle. Free dev->zones in null_del_dev() via null_free_zoned_dev() to solve it. And calling null_free_zoned_dev() in null_free_dev() is no longer necessary because every caller already invokes null_del_dev() first: via nullb_group_drop_item() before nullb_device_release(), in the null_add_dev() error path of null_create_dev(), and in null_destroy_dev(). Remove the redundant call. And take &lock around zone_cond_store() in the two store wrappers to serialize dev->zones check-and-deref against its alloc/free, which already run under &lock. The reason there was no problem before is that only nullb_device_release() or null_exit() frees the dev->zones, which guarantees that subsequent users won't access the configfs interface.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90188", "url": "https://ubuntu.com/security/CVE-2026-90188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: free global tag_set on init error path If shared_tags is enabled, null_setup_tagset() allocates the global tag_set via null_init_global_tag_set(). If device creation later fails, err_dev destroys the default devices and calls unregister_blkdev(), but never frees the global tag_set. Since module init failed, null_exit() is never invoked, so the global tag_set's tags and maps are permanently leaked. Free the global tag_set in err_dev, matching null_exit() which does if (tag_set.ops) blk_mq_free_tag_set(&tag_set).", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90189", "url": "https://ubuntu.com/security/CVE-2026-90189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: register configfs subsystem after creating default devices In null_init(), configfs_register_subsystem() currently runs before register_blkdev(), so when null_blk is built as a module, a racing mkdir() + poweron from userspace can reach null_add_dev() while null_major is still 0. __add_disk() then hits WARN_ON(disk->minors) (major=0 with minors!=0) and fails: [root@fedora ~]# [ 2366.521436] WARNING: block/genhd.c:476 at __add_disk+0x8a7/0xde0, [ 2366.523552] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib [ 2366.529081] CPU: 26 UID: 0 PID: 1600 Comm: sh Not tainted 7.2.0-rc1+ #66 PREEMPT(full) ...... [ 2366.547251] Call Trace: [ 2366.547575] [ 2366.547831] ? _raw_spin_lock+0x84/0xe0 [ 2366.548260] add_disk_fwnode+0x114/0x560 [ 2366.548739] null_add_dev+0x102d/0x1b80 [null_blk] [ 2366.549310] ? __pfx_null_add_dev+0x10/0x10 [null_blk] [ 2366.549906] ? mutex_lock+0xde/0x1c0 [ 2366.550361] ? __pfx_mutex_lock+0x10/0x10 [ 2366.550827] nullb_device_power_store+0x1e7/0x280 [null_blk] [ 2366.551499] ? __pfx_nullb_device_power_store+0x10/0x10 [null_blk] [ 2366.552177] ? __kmalloc_cache_noprof+0x1f5/0x470 [ 2366.552748] ? configfs_write_iter+0x35c/0x4e0 [ 2366.553242] configfs_write_iter+0x286/0x4e0 [ 2366.553787] vfs_write+0x52d/0xd00 [ 2366.554169] ? __pfx_vfs_write+0x10/0x10 [ 2366.554679] ? __pfx___css_rstat_updated+0x10/0x10 [ 2366.555196] ? fdget_pos+0x1cf/0x4c0 [ 2366.555649] ksys_write+0xfc/0x1d0 ...... Additionally, the err_dev path destroys all devices on nullb_list while configfs is still registered. If a racing mkdir() + poweron puts a user device on the list, null_destroy_dev()->null_free_dev() kfrees the user device's nullb_device but /sys/kernel/config/nullb/ is still reachable. Any userspace access to the item will trigger a UAF. For simplicity, move configfs_register_subsystem() to the end to solve the problems above.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90190", "url": "https://ubuntu.com/security/CVE-2026-90190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: use DEFINE_MUTEX for the file-scope mutex In null_init(), mutex_init(&lock) currently happens after configfs_register_subsystem(), which exposes the nullb subsystem to userspace. A racing mkdir() into /sys/kernel/config/nullb/ can reach null_find_dev_by_name() -> mutex_lock(&lock) before the mutex is initialized, trigger warning: [ 123.137788] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 123.137796] WARNING: kernel/locking/mutex.c:159 at mutex_lock+0x171/0x1c0, CPU#13: mkdir/1301 [ 123.140090] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 ...... [ 123.154926] Call Trace: [ 123.155172] [ 123.155419] ? __pfx_mutex_lock+0x10/0x10 [ 123.156181] ? __pfx__raw_spin_lock+0x10/0x10 [ 123.156571] nullb_group_make_group+0x20/0x100 [null_blk] [ 123.157011] configfs_mkdir+0x47b/0xc70 [ 123.157337] ? __pfx_configfs_mkdir+0x10/0x10 [ 123.157719] ? may_create_dentry+0x242/0x2e0 [ 123.158061] vfs_mkdir+0x2a9/0x6c0 [ 123.158352] filename_mkdirat+0x3dc/0x500 [ 123.158710] ? __pfx_filename_mkdirat+0x10/0x10 [ 123.159070] ? strncpy_from_user+0x3a/0x1d0 [ 123.159413] __x64_sys_mkdir+0x6b/0x90 [ 123.159760] do_syscall_64+0xea/0x600 Replace the runtime mutex_init(&lock) with a static DEFINE_MUTEX(lock) declaration to fix this issue.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90191", "url": "https://ubuntu.com/security/CVE-2026-90191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: riscv-sbi-mpxy: validate RPMI notification lengths The SBI return value controls how many bytes are copied from shared memory into the RPMI notification buffer. It is not validated against the negotiated shared-memory size before that copy. The event walker also uses a reversed loop condition and can inspect a short event record. Validate the complete notification length before copying it, iterate only while a full event header remains, and stop when a declared event payload extends beyond the copied notification data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90192", "url": "https://ubuntu.com/security/CVE-2026-90192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: qcom-cpucp: handle NULL data in send_data callback mailbox_clear_channel() calls mbox_send_message() with NULL data to notify the remote side that the RX channel has been cleared. qcom_cpucp_mbox_send_data() blindly dereferenced the data pointer, causing a NULL pointer dereference kernel panic when invoked from this path under PREEMPT_RT. Add an explicit NULL check and return early without writing to the TX register, which is the correct behaviour for a channel-clear notification.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90193", "url": "https://ubuntu.com/security/CVE-2026-90193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: qcom-cpucp: fix PREEMPT_RT self-deadlock in IRQ handler qcom_cpucp_mbox_irq_fn() calls mbox_chan_received_data() while holding chan->lock. Under PREEMPT_RT, spin_lock_irqsave() is converted to an rt_spinlock (rtmutex-based), which tracks ownership and can sleep. The callback chain triggered by mbox_chan_received_data() eventually reaches mailbox_clear_channel() -> mbox_send_message() -> add_to_rbuf(), which attempts to re-acquire the same chan->lock. Since rtmutex detects the re-entrant lock attempt by the same owner, the thread blocks waiting for a lock it already holds, causing a permanent deadlock. This deadlock manifests as 'irq/N-apss_cpucp_mbox' stuck in D state with the following call trace: rt_spin_lock -> mbox_send_message -> mailbox_clear_channel -> scmi_rx_callback -> mbox_chan_received_data [<- held chan->lock here] Fix by saving chan->cl locally and clearing the HW interrupt register inside the lock, then invoking mbox_chan_received_data() after releasing the lock. This preserves the mutual exclusion for chan->cl access while avoiding the lock re-entrancy that causes the PREEMPT_RT deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90194", "url": "https://ubuntu.com/security/CVE-2026-90194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: scan: fix bus ID cleanup on device_add() failures When device_add() fails after acpi_device_set_name() has allocated an instance ID and a new acpi_device_bus_id has been linked into acpi_bus_id_list, the rollback path only removes wakeup_list and detaches the ACPI handle data. That leaves the bus-ID bookkeeping behind and keeps the allocated instance number consumed. Move the bus-ID cleanup and wakeup-list removal into a single helper. Use it from both the normal device teardown path and the device_add() rollback path. The wakeup list node is initialized before registration, so it can be deleted without checking whether the device is wakeup- capable like in the original teardown path. [ rjw: Rename acpi_device_del_list() to acpi_device_cleanup() ] [ rjw: Subject and changelog edits ]", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90195", "url": "https://ubuntu.com/security/CVE-2026-90195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Fix missing sign-ext for signed 1-byte and 2-byte kfunc args On RV64, the ABI requires sign-extension for signed 1-byte and 2-byte kfunc args. However, the RV64 JIT currently does not perform sign-extension for such kfunc args. Before commit 7ce090afbf72 (\"bpf: Infer zext_dst based on static register liveness analysis\"), state pruning could potentially omit zero-extension of 32-bit subregisters, which inadvertently masked the above issue by making the args appear as if they had been properly sign-extended. After that commit, the problem is exposed, causing the kfunc_call/kfunc_call_test4 selftest to fail. Fix this by extending the existing sign-extension logic to handle signed 1-byte and 2-byte kfunc args as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90196", "url": "https://ubuntu.com/security/CVE-2026-90196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: validate topology volume range before allocation SOF treats the topology mixer min and max values as non-negative indices into its volume table. It stores them in signed fields, allocates max + 1 entries through an int argument, and later indexes the table with the stored range. An inverted range is invalid, while a maximum at or above INT_MAX cannot be represented safely after the increment or in the signed fields. Validate the complete range before storing it or allocating the table.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90197", "url": "https://ubuntu.com/security/CVE-2026-90197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: haptic: don't write an uninitialized value to unhandled usages fill_effect_buf() initializes value only for the four haptic usages handled by its switch, but writes it to field->value[] for every usage. An unhandled usage can therefore receive either an uninitialized value or one left over from the previous usage. hid_output_report() then serializes that value into the effect's report buffer. Skip unhandled usages instead. This also matches switch_mode(), which only updates fields it recognizes. Found with Clang's -Wconditional-uninitialized.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90198", "url": "https://ubuntu.com/security/CVE-2026-90198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix use-after-free in snd_card_do_free() A use-after-free was detected in snd_card_do_free() when a sound card managed by devres is unbound while a user-space application still holds an open file descriptor. For managed cards, the memory is allocated using devres_alloc(), and its release function is set to __snd_card_release(), which calls snd_card_free(). When the device is unbound, the unbind thread calls snd_card_free(), which drops a reference to the card's device. If the user thread still has an open file descriptor, the reference count does not reach zero, and the unbind thread blocks on wait_for_completion(&released). When the user thread closes the file descriptor, it drops the final reference, invoking the device release callback release_card_device(), which calls snd_card_do_free(). snd_card_do_free() performs cleanup and calls complete(card->release_completion). This wakes up the unbind thread, which returns from snd_card_free() and __snd_card_release(). The devres core then immediately frees the memory block containing the snd_card structure. Meanwhile, the user thread continues execution in snd_card_do_free() and evaluates `if (!card->managed)`. It reads the `managed` boolean from the snd_card structure that was just freed by the unbind thread, triggering a KASAN use-after-free. Fix this by caching the value of card->managed in a local variable before calling complete(). This ensures that the card pointer is not dereferenced after the unbind thread has been woken up and potentially freed the card. BUG: KASAN: use-after-free in snd_card_do_free sound/core/init.c:604 [inline] BUG: KASAN: use-after-free in release_card_device+0x1ab/0x1b0 sound/core/init.c:153 Read of size 1 at addr ffff8881912ec909 by task syz-executor130/5857 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description+0x55/0x1e0 mm/kasan/report.c:378 print_report+0x58/0x70 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 snd_card_do_free sound/core/init.c:604 [inline] release_card_device+0x1ab/0x1b0 sound/core/init.c:153 device_release+0xc4/0x1f0 drivers/base/core.c:-1 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x222/0x550 lib/kobject.c:737 snd_card_file_remove+0x331/0x390 sound/core/init.c:1125 snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c:2986 __fput+0x418/0xa50 fs/file_table.c:512 fput_close_sync+0x11f/0x240 fs/file_table.c:617 __do_sys_close fs/open.c:1511 [inline] __se_sys_close fs/open.c:1496 [inline] __x64_sys_close+0x7e/0x110 fs/open.c:1496 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90199", "url": "https://ubuntu.com/security/CVE-2026-90199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject out-of-range evcn in mi_enum_attr() In mi_enum_attr(), the start/end VCN validation for non-resident attributes is: \tif (svcn > evcn + 1) goto out; When evcn is U64_MAX the \"evcn + 1\" expression wraps to 0 and any svcn passes the check. For evcn values close to U64_MAX (but not equal to it) the right-hand side is still a meaningless near-wrap upper bound, so a malformed on-disk attribute with svcn == 0 and evcn near U64_MAX can pass mi_enum_attr() unrejected. VCN (virtual cluster number) is a cluster index, so any valid evcn is bounded by the volume's total cluster count, which ntfs3 holds in sbi->used.bitmap.nbits (set up in ntfs_init_from_boot() before any caller of mi_enum_attr() runs). Reject evcn values that fall outside this range. However, an empty non-resident attribute (no allocated clusters) is legitimately encoded with svcn == 0 and evcn == -1 (U64_MAX), e.g. via attr->nres.evcn = cpu_to_le64((u64)vcn - 1) with vcn == 0. That sentinel must keep passing, so exclude evcn == U64_MAX from the range check. The existing \"svcn > evcn + 1\" test still tolerates the sentinel (\"0 > 0\" is false) and continues to require svcn == 0 for it, while the range check rejects every other out-of-range evcn and thereby also defuses the \"evcn + 1\" wraparound. svcn does not need its own bound: once evcn < nbits, \"svcn > evcn + 1\" implies svcn <= nbits. [almaz.alexandrovich@paragon-software.com: fixed evcn check]", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90200", "url": "https://ubuntu.com/security/CVE-2026-90200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix integer overflow in MFT cluster validation In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are validated against the volume size with: \tif (mlcn * sct_per_clst >= sectors || \t mlcn2 * sct_per_clst >= sectors) \t\tgoto out; mlcn and mlcn2 are u64 fields read directly from the boot sector. sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus the is_power_of_2() check below it), but the multiplication is done in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn near 2^62 with sct_per_clst == 4 wraps to 0, which compares below any non-zero 'sectors', so the check is bypassed and the malformed record is accepted. The accepted mlcn is then used unchanged in \tsbi->mft.lbo = mlcn << cluster_bits; In practice the resulting reads fail at the block layer (sb_bread() returns NULL via grow_buffers()'s check_mul_overflow() guard), so today this manifests as mount failing in odd places rather than as something more dangerous, but the validation step is still wrong and there is no reason for callers to rely on the block layer to catch a value that should never have been accepted in the first place. Use check_mul_overflow() to compute the two sector positions and fail the mount if either multiplication wraps; this preserves the existing semantics (mlcn * sct_per_clst >= sectors) instead of switching to division (mlcn >= sectors / sct_per_clst), which would tighten the check at edge cases where 'sectors' is not a multiple of sct_per_clst. The check_*_overflow() style is the one ntfs3 already uses for similar on-disk arithmetic in fs/ntfs3/run.c.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90201", "url": "https://ubuntu.com/security/CVE-2026-90201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: page_pool: fix UAF in __page_pool_release_netmem_dma on xa_cmpxchg race This bug was discovered while testing the hns3 driver under channel reconfiguration (`ethtool -L` / `ethtool -G`) with iperf3 traffic on arm64. The race is intermittently triggered when page_pool_destroy() runs page_pool_scrub() concurrently with page return via page_pool_put_netmem() on a different CPU. A WARN in page_pool_clear_pp_info() surfaced the dangling DMA index bits left by the cmpxchg loser, which led to the investigation. page_pool_scrub() iterates pool->dma_mapped via xa_for_each() with no page ref held. __page_pool_release_netmem_dma() currently reads and writes netmem fields (dma_addr, DMA index bits in pp_magic) after xa_cmpxchg() returns. The unref path calls put_page() unconditionally regardless of the cmpxchg outcome; when it loses the cmpxchg, it still frees the page before the scrub winner finishes these netmem accesses, so scrub touches a freed page -- a Use-After-Free. Fix this by splitting the DMA release into two functions: 1. __page_pool_unmap_netmem_dma() caches dma_addr before xa_cmpxchg(), does the cmpxchg to remove the DMA mapping, and calls dma_unmap on the cached address. It never touches netmem fields after the cmpxchg, making it safe for the scrub path which holds no page ref. 2. __page_pool_release_netmem_dma() wraps the above and additionally clears dma_addr and DMA index bits in netmem fields. This is safe only when the caller holds a page ref, so it is used by the return path (page_pool_return_netmem). The scrub path calls __page_pool_unmap_netmem_dma() directly; the return path calls __page_pool_release_netmem_dma().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90202", "url": "https://ubuntu.com/security/CVE-2026-90202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers _base_release_memory_pools() unconditionally frees every ioc->pcie_sg_lookup[] entry, including ones the setup loop never allocated after a partial failure, causing a \"bad dma\" warning on debug kernels or a NULL pointer dereference otherwise.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90203", "url": "https://ubuntu.com/security/CVE-2026-90203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check block offset is not negative If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfs_copy_data() to perform an out of bounds access. Fix by checking if offset is negative, and returning 0. This matches existing behaviour where an offset beyond the block returns 0 bytes copied. To trigger this out of bounds access requires a crafted Squashfs filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be able to mount such a filesystem, but once mounted, an unprivileged user can trigger the out of bounds access by reading the crafted file with the negative offset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90204", "url": "https://ubuntu.com/security/CVE-2026-90204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate DIO orphan slot during inode read [BUG] A corrupted append-DIO dinode (high byte at offset 0xa1 corrupted from 0 to 1) can carry an i_dio_orphaned_slot outside the mounted filesystem slot range and trigger a use-after-free error: BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85 Call Trace: ... ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840 ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline] ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295 evict+0x38e/0x8f0 fs/inode.c:810 iput_final fs/inode.c:1914 [inline] iput fs/inode.c:1966 [inline] iput+0x55b/0x8b0 fs/inode.c:1926 ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374 ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373 ... [CAUSE] ocfs2_del_inode_from_orphan() uses i_dio_orphaned_slot to index the slot-local system inode cache. The dinode validator does not check this active slot, so an out-of-range value produces an invalid cache entry pointer that is dereferenced as an inode pointer. [FIX] Reject an active i_dio_orphaned_slot outside the slot range during dinode validation, before DIO orphan recovery can consume it.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90205", "url": "https://ubuntu.com/security/CVE-2026-90205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate orphan slot during inode read Patch series \"ocfs2: validate active orphan slots during inode read\". OCFS2 trusts active ordinary and append-DIO orphan slots read from dinodes. A corrupted slot can therefore index osb_orphan_wipes or the slot-local system-inode cache outside their allocations before the corruption is reported. Patch 1 validates the ordinary orphan slot used by inode wipe processing. Patch 2 validates the append-DIO orphan slot used by DIO completion and orphan recovery. Both checks reject corrupt metadata at the existing inode validation boundary. This patch (of 2): [BUG] A corrupted dinode with OCFS2_ORPHANED_FL can carry an i_orphaned_slot outside the mounted filesystem slot range. ocfs2_wipe_inode() uses it to index osb_orphan_wipes before looking up the orphan directory, causing an out-of-bounds memory access. BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85 Call Trace: ... ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840 ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline] ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295 evict+0x38e/0x8f0 fs/inode.c:810 iput_final fs/inode.c:1914 [inline] iput fs/inode.c:1966 [inline] iput+0x55b/0x8b0 fs/inode.c:1926 ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374 ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373 ... [CAUSE] ocfs2_validate_inode_block() validates i_suballoc_slot but leaves the active ordinary orphan slot unchecked. Downstream consumers assume that the value is smaller than osb->max_slots. [FIX] Reject an active i_orphaned_slot outside the slot range during dinode validation, before the inode reaches orphan wipe processing.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90207", "url": "https://ubuntu.com/security/CVE-2026-90207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: midi: Serialize input teardown with event_input snd_midi_input_event() must not be running while a rawmidi substream is closing, since this can lead to the trigger state becoming out-of-step through this sequence in snd_rawmidi_input_trigger(): \tsnd_rawmidi_input_trigger(up=0) \t\t\t\t\tsnd_midi_input_event() \t\t\t\t\t -> snd_rawmidi_kernel_read() \t\t\t\t\t -> snd_rawmidi_input_trigger(up=1) \t -> cancel_work_sync() which ends with the underlying device being active unexpectedly. When this is called from close_substream(), further input can re-trigger the input event leaving it running after rawmidi_release_priv() has set rfile->rmidi to NULL which leads to: \tUnable to handle kernel NULL pointer dereference at virtual address 00000000000000b0 \tCall trace: \t snd_midi_input_event+0x3c/0x134 [snd_seq_midi] (P) \t snd_rawmidi_input_event_work+0x1c/0x2c \t process_one_work+0x150/0x3a4 \t worker_thread+0x190/0x318 Apply a similar approach to commit ef7607ab1c8ad (\"ALSA: seq: midi: Serialize output teardown with event_input\") which fixed the same issue in the output direction, but updated to use RCU following Takashi Iwai's proposed follow-on patch [1]. With this change in place, midisynth_unsubscribe() clears the input file so snd_midi_input_event() will not re-trigger the stream and will be quiesced by the cancel_work_sync() in snd_rawmidi_input_trigger(). [1] https://lore.kernel.org/linux-sound/20260813144224.753399-1-tiwai@suse.de/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90209", "url": "https://ubuntu.com/security/CVE-2026-90209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/debug: Fix deadlock during unregister Unregistering an s390dbf debug area while one of the associated debugfs files is being written to can cause a deadlock: $ echo >.../vmur/level $ rmmod vmur =================================================== debugfs write debugfs_file_get() debug_unregister() mutex_lock(debug_mutex) debugfs_remove() wait for debugfs_file_put() debug_file_ops.write() debug_input() mutex_lock(debug_mutex) ==> DEADLOCK Fix this by splitting debug_unregister() into an s390dbf and debugfs part, and running only the s390dbf part with debug_mutex locked.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90213", "url": "https://ubuntu.com/security/CVE-2026-90213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: core: fix memory leak in error path of build_tree() In the error path of build_tree(), node instances can remain in the local linked list when the function returns. Whenever an invalid value is detected in the self ID sequence, each allocated node instance is either an entry in the linked list or an entry in the ports array of its parent node. Therefore, the allocate node instances can be safely released by traversing the linked list from its head. Release the remaining node instances with for_each_fw_node() before returning to the caller.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90214", "url": "https://ubuntu.com/security/CVE-2026-90214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: xilinx: formatter_pcm: fix stream_data leak on open error In xlnx_formatter_pcm_open(), stream_data is allocated and adata->play_stream or adata->capture_stream is assigned early. If a later step, such as snd_pcm_hw_constraint_step() or snd_pcm_hw_constraint_integer(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so stream_data is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call snd_pcm_period_elapsed() on the freed substream. Free stream_data and clear the stream pointer on the error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90215", "url": "https://ubuntu.com/security/CVE-2026-90215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: ubi: Release device reference on busy detach ubi_detach_mtd_dev() obtains a device reference through ubi_get_device() before checking whether the UBI device is busy. The busy return path drops ubi->ref_count but leaves the device reference held, so the device object cannot be released after a later detach. Drop the device reference before returning -EBUSY.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90216", "url": "https://ubuntu.com/security/CVE-2026-90216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubi: Fix rollback for explicit UBI device numbers ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90218", "url": "https://ubuntu.com/security/CVE-2026-90218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix WARNING in res_to_rt syzbot reported a WARN_ON(!res->dev) in res_to_rt() triggered via addr_handler() during asynchronous address resolution: \" WARNING: drivers/infiniband/core/restrack.c:138 at res_to_rt+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ib_addr process_one_req RIP: 0010:res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: rdma_restrack_add+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addr_handler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 process_one_req+0x2eb/0x540 drivers/infiniband/core/addr.c:624 process_one_work kernel/workqueue.c:3375 [inline] process_scheduled_works+0xc4e/0x1630 kernel/workqueue.c:3458 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 \" In addr_handler(), cma_acquire_dev_by_src_ip() is called to populate id_priv->cma_dev and bind the associated ib_device to id_priv->id.device. If cma_acquire_dev_by_src_ip() returns an error (non-zero status), the ID remains unassociated with any RDMA device. Previously, rdma_restrack_add(&id_priv->res) was invoked unconditionally even when cma_acquire_dev_by_src_ip() failed, passing a resource with a NULL dev pointer and triggering the WARN_ON assertion in res_to_rt(). Fix this by only adding the resource to restrack when acquiring the device succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90219", "url": "https://ubuntu.com/security/CVE-2026-90219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Free debugfs on registration failure c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via setup_debugfs()), but it is removed only in c4iw_remove(), not in c4iw_dealloc(). When RDMA device registration fails, the registration worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing c4iw_remove(), so the debugfs dentries leak and outlive the freed c4iw_dev. Move debugfs_remove_recursive() into c4iw_dealloc() so every path that frees ctx->dev also removes its debugfs tree.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90220", "url": "https://ubuntu.com/security/CVE-2026-90220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Don't leak the extension cell pointer in the bounce payload The bounce_error_event() embeds the failed event in the bounce payload by pointing data.ext.ptr at it. When that event is a queued variable-length event, its own data.ext.ptr holds the address of its first extension cell, put there by snd_seq_event_dup(). The payload goes out verbatim through snd_seq_expand_var_event(), so the address reaches userspace. That is the same address commit 705dd6dcbc0e (\"ALSA: seq: Clear variable event pointer on read\") removed from the event header. The read path still clears it there, just above the call that expands the payload. Embed a sanitised copy instead, treated exactly as snd_seq_read() treats the header. A stack copy is enough because delivery is synchronous and snd_seq_event_dup() copies before returning. An unprivileged client reaches this by setting SNDRV_SEQ_FILTER_BOUNCE, queueing a variable-length event to a port that does not exist and reading the bounce back. Eight bytes on 64-bit, from its own pool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90221", "url": "https://ubuntu.com/security/CVE-2026-90221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing nci_core_init_rsp_packet_v1() and nci_core_init_rsp_packet_v2() parse the CORE_INIT_RSP packet without validating that the skb contains enough data. A malformed response (e.g. injected via virtual_ncidev) can declare a large num_supported_rf_interfaces while providing insufficient data, causing reads of uninitialized slab memory. This is later used in nci_init_complete_req(), triggering a KMSAN uninit-value warning. Add skb length checks before accessing packet fields: - Validate the skb has at least 1 byte for the status field. - Validate the skb can hold the fixed-size header before parsing. - In v2, bounds-check each variable-length rf_interface entry and its extension parameters within the parsing loop. - In v1, verify the skb is large enough for both the variable-length rf_interfaces array and the trailing rsp_2 structure.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90222", "url": "https://ubuntu.com/security/CVE-2026-90222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: hold a reference to the request skb during send_frame __pn533_send_async() publishes the command and then calls dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame can be matched to this command: the I2C threaded IRQ runs pn533_recv_frame(), which queues cmd_complete_work, and pn533_send_async_complete() frees cmd->req with consume_skb(). On the I2C transport, pn533_i2c_send_frame() still dereferences the same skb after i2c_master_send() returns, so a completion that races the send can free the skb while the transport is still using it. The request skb is owned by the command object and may be freed by command completion at any time after dev->cmd is published, so the transport send path must not assume it stays alive. Hold a temporary reference to the request skb across the send_frame() call so the transport always sees a live skb even if completion races the send. Add a pn533_send_cmd_frame() helper and use it from all three send paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90223", "url": "https://ubuntu.com/security/CVE-2026-90223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound SNL TLV parsing to the skb and add length checks nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed: - For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made \"service_name_len = length - 1\" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3] without a length check. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Walk the TLV list by pointer, bounded by skb_tail_pointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90224", "url": "https://ubuntu.com/security/CVE-2026-90224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix double completion race in nci_data_exchange_complete nci_close_device() and nci_rx_work can both call nci_data_exchange_complete() concurrently. After commit 4527025d440ce8 (\"nfc: nci: fix circular locking dependency in nci_close_device\") moved flush_workqueue(ndev->rx_wq) after mutex_unlock(&ndev->req_lock), rx_work is no longer serialized with the explicit completion call in the close path. Both callers read the non-NULL callback pointer and invoke rawsock_data_exchange_complete(), which calls sock_put() -- but only one sock_hold() was taken, so the second sock_put() underflows the refcount and frees the socket while it is still in use. Replace the bare clear_bit(NCI_DATA_EXCHANGE) with test_and_clear_bit() so that only the first caller proceeds to invoke the callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90225", "url": "https://ubuntu.com/security/CVE-2026-90225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: read llcp_sock->local under the socket lock in getsockopt nfc_llcp_getsockopt() read llcp_sock->local before lock_sock(sk) and then dereferenced the cached pointer inside the locked region. llcp_sock_bind() assigns and clears llcp_sock->local under the same socket lock, dropping the last reference on its error path. A getsockopt() racing an in-flight bind() can observe the pointer, block on lock_sock(), and then dereference a freed nfc_llcp_local once bind() has unwound. Move the llcp_sock->local read and the NULL check inside the lock_sock(sk) region so bind() cannot mutate or free the pointer between the load and the use.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90226", "url": "https://ubuntu.com/security/CVE-2026-90226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: avoid userspace overflow on invalid optlen nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90227", "url": "https://ubuntu.com/security/CVE-2026-90227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme/ioctl: check SUBMIT_IO with nvme_cmd_allowed() Unlike IO_CMD / IO64_CMD, NVME_IOCTL_SUBMIT_IO never calls nvme_cmd_allowed(). Unprivileged callers can thus issue I/O on a partition device or write through a read-only file descriptor. Pass flags and open_for_write through and reject disallowed commands with -EACCES.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90228", "url": "https://ubuntu.com/security/CVE-2026-90228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns() When a host issues an Identify command with CNS 05h (I/O Command Set specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed namespace has no block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The I/O command set is selected by the host-supplied CSI field and the command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled, independent of the namespace backing type, so any file-backed namespace is exposed. Reject the command with Invalid Field when the namespace is not backed by a block device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90229", "url": "https://ubuntu.com/security/CVE-2026-90229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-apple: Destroy the admin queue on removal The admin queue is allocated with blk_mq_alloc_queue() but never destroyed. nvme_free_ctrl() only drops the last reference and blk_mq_exit_queue() and blk_sync_queue() never run: the hctx is never moved to q->unused_hctx_list and the timeout timer and work stay armed on a queue that is about to be freed which will eventually oops inside blk_mq_timeout_work(). This can only be triggered when the controller fails to come up and is then immediately torn down again which is why no one ever ran into this before. Let's just copy what the pcie driver does: unquiesce and destroy the admin queue before nvme_uninit_ctrl(). With this the following WARN followed by a panic no longer happens: WARNING: block/blk-mq.c:4390 at blk_mq_release+0x194/0x238, CPU#4: kworker/u34:4/119 CPU: 4 UID: 0 PID: 119 Comm: kworker/u34:4 Not tainted 7.2.0-rc1-dirty #248 PREEMPT Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: nvme-wq apple_nvme_remove_dead_ctrl_work pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : blk_mq_release+0x194/0x238 lr : blk_mq_release+0x58/0x238 sp : ffffc000833a3b50 x29: ffffc000833a3b50 x28: ffff80001d0450f8 x27: ffff800020c95200 x26: 0000000000000088 x25: 0000000000000000 x24: ffff800020f36805 x23: 0000000000000000 x22: ffffc00081a86878 x21: ffff800020be9c60 x20: 0000000000000000 x19: ffff800022501698 x18: 000000000000000a x17: 7365757165722066 x16: 666f7265776f7020 x15: 0000000000000000 x14: 0000000000000028 x13: 0000000000004def x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000805b4fc8 x8 : ffffc00081915820 x7 : ffffc00081c4f3c8 x6 : 0000000000000001 x5 : 0000000000000004 x4 : ffff800022498d80 x3 : ffffc000833a3b14 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800022501698 Call trace: blk_mq_release+0x194/0x238 (P) blk_put_queue+0x8c/0xf0 nvme_free_ctrl+0x4c/0x260 device_release+0x44/0x128 kobject_put+0xa0/0x120 put_device+0x1c/0x40 nvme_uninit_ctrl+0x48/0x60 apple_nvme_remove+0x54/0xb0 platform_remove+0x28/0x40 device_remove+0x54/0x98 device_release_driver_internal+ device_release_driver+0x20/0x38 apple_nvme_remove_dead_ctrl_wor process_one_work+0x1f4/0x770 worker_thread+0x1b8/0x360 kthread+0x140/0x160 ret_from_fork+0x10/0x20 irq event stamp: 448 hardirqs last enabled at (447):in_unlock_irqrestore+0x74/0x80 hardirqs last disabled at (448): [] el1_brk64+0x20/0x60 softirqs last enabled at (0): [ess+0xb28/0x2698 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 0000000000000000 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagA GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [0000000000000000] user address Internal error: Oops: 0000000096000005 [#1] SMP CPU: 7 UID: 0 PID: 54 Comm: kwor 7.2.0-rc1-dirty #248PREEMPT Tainted: [W]=WARN Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: kblockd blk_mq_timeou pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : percpu_ref_tryget_many.cons lr : percpu_ref_tryget_many.constprop.0+0xc0/0x168 sp : ffffc000829cbce0 x29: ffffc000829cbce0 x28: ffff800020be9f48 x27: ffff800013e503c0 x26: 0000000000000108 x25: 000009c05 x23: 0000000000000000 x22: ffffc000819f5000 x21: ffff800020be9f48 x20: ffff8001deda4808 x19: ffff8000a x17: 00000000580e1fac x16: ffffc00082bbbb7c x15: 0000000000000000 x14: 0000000000000028 x13: 000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000829cbc20 x8 : ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90230", "url": "https://ubuntu.com/security/CVE-2026-90230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix heap out-of-bounds read in nvmet_auth_negotiate() nvmet_execute_auth_send() allocates the DH-HMAC-CHAP message buffer with the host-supplied transfer length (tl) and hands it to nvmet_auth_negotiate() without passing tl along. nvmet_auth_negotiate() then reads the negotiate header and, for each of the halen hash identifiers and dhlen DH group identifiers, indexes into the fixed idlist[60] array (hashes at idlist[0..halen), groups at idlist[30..]). Neither the transfer length nor halen/dhlen is validated. A malicious or non-conformant host can report a tl smaller than the negotiate structure, or a halen/dhlen larger than the array (both are u8, up to 255), making the loops read past the end of the allocated buffer (heap out-of-bounds read). The sibling nvmet_auth_reply() already validates tl against the structure size; the negotiate path did not. Pass tl into nvmet_auth_negotiate(), reject a tl that does not cover the negotiate data plus one full protocol descriptor, and reject halen/dhlen larger than NVME_AUTH_DHCHAP_MAX_DH_IDS.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90232", "url": "https://ubuntu.com/security/CVE-2026-90232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: Don't support cross-netns setup. When a lower device is unregistered, amt_device_event() tries to unregister its upper AMT device, but it has two problems. 1. amt_lookup_upper_dev() looks up an upper device in the lower device's netns only 2. amt_device_event() unregisters a single upper device only If AMT device is created on a lower device in another netns, removing the lower device triggers the splat below and gets stuck until all upper devices are removed. [0] The cross-netns setup seems unintentional considering 1. and the following points: * amt_link_setup() sets dev->netns_immutable to true * skb_scrub_packet() is not called in the fast path * iproute2 binary fails to find cross-netns lower device via link-netns: # ip -n ns1 link add amt0 link-netns ns2 type amt dev veth1 Cannot find device \"veth1\" Instead of supporting it properly and preparing for per-netns netdev unreg, let's forbid cross-netns setup. Note that the problem 2. needs a separate fix. [0]: WARNING: net/core/dev.c:12518 at unregister_netdevice_many_notify+0x1cce/0x2250, CPU#48: ip/2031 Modules linked in: CPU: 48 UID: 0 PID: 2031 Comm: ip Not tainted 7.2.0-rc5+ #27 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:unregister_netdevice_many_notify (net/core/dev.c:12518) Code: 89 ef e8 d5 52 ae fe e9 d0 f4 ff ff 48 8d 3d f9 3b 9c 02 48 c7 c6 c0 0b 63 84 ba ab 1f 00 00 67 48 0f b9 3a e9 65 ff ff ff 90 <0f> 0b 90 eb 81 48 8d 3d f6 3b 9c 02 48 c7 c6 c0 0b 63 84 ba e2 1f RSP: 0018:ffffc90004abf160 EFLAGS: 00010212 RAX: ffff888104d38260 RBX: ffff88800b0911b8 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff85b9f880 RBP: ffffc90004abf2d0 R08: ffffffff85b9f887 R09: 1ffffffff0b73f10 R10: dffffc0000000000 R11: fffffbfff0b73f11 R12: ffff88800b091d08 R13: ffff88800b091178 R14: dffffc0000000000 R15: ffff88800b091000 FS: 00007f555b86c600(0000) GS:ffff8881942a0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562107d489c0 CR3: 0000000109a40002 CR4: 0000000000372ef0 Call Trace: rtnl_dellink (net/core/rtnetlink.c:3632 net/core/rtnetlink.c:3674) rtnetlink_rcv_msg (net/core/rtnetlink.c:7112) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1319) netlink_sendmsg (net/netlink/af_netlink.c:1900) ____sys_sendmsg (net/socket.c:775) __sys_sendmsg (net/socket.c:2738) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... unregister_netdevice: waiting for veth0 to become free. Usage count = 7 ref_tracker: netdev@ffff88800d7496d8 has 3/3 users at __netdev_adjacent_dev_insert (./include/linux/netdevice.h:4525 ./include/linux/netdevice.h:4554 net/core/dev.c:8791) __netdev_upper_dev_link (net/core/dev.c:8879 net/core/dev.c:8963) netdev_upper_dev_link (net/core/dev.c:9009) amt_newlink (drivers/net/amt.c:3321)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90233", "url": "https://ubuntu.com/security/CVE-2026-90233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-pci: release descriptor pools on probe failure The per-NUMA-node descriptor DMA pools are created lazily from nvme_init_hctx_common() once the admin tag set is allocated, but they are only destroyed in nvme_remove() via nvme_release_descriptor_pools(). Any probe failure after the admin tag set has been allocated unwinds through the out_disable label and nvme_pci_free_ctrl(), neither of which releases the pools, leaking the dma_pool objects. Release the descriptor pools in the out_disable error path. It must not be added to nvme_pci_free_ctrl(), as that would double-free against nvme_remove() on the normal teardown path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90235", "url": "https://ubuntu.com/security/CVE-2026-90235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: xprtsock: annotate shared socket callbacks with READ_ONCE/WRITE_ONCE xprtsock replaces and restores sk->sk_data_ready and sk->sk_write_space on live sockets with plain stores, and xs_udp_do_set_buffer_size() invokes sk->sk_write_space via a plain load. These callback pointers are shared with generic socket and protocol paths that may read or invoke them concurrently, so xprtsock needs the same READ_ONCE()/WRITE_ONCE() callback visibility contract that the validated 4022 family applied elsewhere. When SUNRPC takes over an AF_LOCAL, UDP, or TCP socket and later restores the lower-socket callbacks during teardown, another CPU may still hold an earlier callback snapshot. The plain replace/restore pattern leaves the same visibility hole as the validated 4022 family, so a stale snapshot can still invoke xs_data_ready() or xs_udp_write_space() after the live callback fields have already been restored to the lower-socket handlers. Use WRITE_ONCE() for the shared sk_data_ready and sk_write_space stores in xs_local_finish_connecting(), xs_udp_finish_connecting(), xs_tcp_finish_connecting(), and xs_restore_old_callbacks(). Use READ_ONCE() for the direct sk_write_space invocation in xs_udp_do_set_buffer_size(). This matches the required callback visibility contract while leaving adjacent sk_state_change and sk_error_report handling unchanged.", "cve_priority": "negligible", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89784", "url": "https://ubuntu.com/security/CVE-2026-89784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6 rpcb_register_inet4() and rpcb_register_inet6() store the result of rpc_sockaddr2uaddr() into map->r_addr without checking it for NULL. rpc_sockaddr2uaddr() returns NULL when its final kstrdup() fails, and the unchecked NULL is then carried into the synchronous RPCBPROC_SET encode path: rpcb_register_call() -> rpc_call_sync() -> rpcb_enc_getaddr() -> encode_rpcb_string(), whose first statement is strlen(string), dereferencing NULL and oopsing the kernel. The crash reproduces under failslab on v6.12; with KASAN the NULL dereference surfaces as a fault on the shadow of address zero: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 [#1] PREEMPT SMP KASAN RIP: 0010:strlen (lib/string.c:409) Call Trace: encode_rpcb_string (net/sunrpc/rpcb_clnt.c:890) rpcb_enc_getaddr (net/sunrpc/rpcb_clnt.c:910) rpcauth_wrap_req_encode (net/sunrpc/auth.c:745) call_encode (net/sunrpc/clnt.c:1966) __rpc_execute (net/sunrpc/sched.c:952) rpc_run_task (net/sunrpc/clnt.c:1243) rpc_call_sync (net/sunrpc/clnt.c:1272) rpcb_v4_register (net/sunrpc/rpcb_clnt.c:500) svc_generic_rpcbind_set nfsd_rpcbind_set svc_register svc_setup_socket svc_addsock write_ports nfsctl_transaction_write vfs_write The crash is reachable when an in-kernel RPC service (nfsd, lockd, nfs-callback) registers with the local rpcbind under enough memory pressure for the small GFP_KERNEL kstrdup() in rpc_sockaddr2uaddr() to fail. The asynchronous getport path already handles this exact failure mode by returning -ENOMEM; only the two register helpers omit the check. Mirror that handling: bail out with -ENOMEM when rpc_sockaddr2uaddr() returns NULL, before the address is fed into the encoder.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90240", "url": "https://ubuntu.com/security/CVE-2026-90240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush context cache with correct SID when tearing down aliases domain_context_clear_one() and device_pasid_table_teardown() are both invoked once per DMA alias of a device. Each function locates the context entry using the bus/devfn pair provided by the pci_for_each_dma_alias() callback, then calls intel_context_flush_no_pasid(), which constructs a device-selective context-cache invalidation from info->bus and info->devfn (that is, always the requester ID of the device itself). As a result, for every alias other than the device’s own RID, the context entry that was just cleared in memory is never invalidated in the context cache. Hardware may continue using that stale cached entry. In the scalable-mode teardown path, intel_pasid_free_table() can then free the PASID directory still referenced by that stale entry, allowing the IOMMU to walk freed memory. Fix this by passing the source ID of the entry being torn down to intel_context_flush_no_pasid(), instead of deriving it from @info.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90241", "url": "https://ubuntu.com/security/CVE-2026-90241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Tear down scalable-mode context on probe failure intel_pasid_setup_sm_context() walks a PCI device’s DMA aliases via pci_for_each_dma_alias() and programs a scalable-mode context entry for each RID. For a device with a dma_alias_mask, the callback is invoked once for the device’s own RID and once for each alias bit, all with the same pci_dev, so device_pasid_table_setup() runs for multiple RIDs. pci_for_each_dma_alias() stops at the first callback error. Therefore, a failure partway through the walk can leave context entries for already processed RIDs present and still pointing to the device’s PASID table. On this error path, intel_iommu_probe_device() currently jumps directly to intel_pasid_free_table(), which frees the PASID table without first tearing down those context entries. The IOMMU may then walk a present context entry whose PASID table pointer references freed memory. intel_iommu_release_device() already performs teardown before freeing the table. Apply the same ordering on the probe failure path. device_pasid_table_teardown() safely handles RIDs that were never programmed: iommu_context_addr() returns NULL when no context table has been allocated, and clearing the Present bit of an already non-present entry is a no-op. So unwind is safe for both the alias that failed and any aliases not yet reached.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90243", "url": "https://ubuntu.com/security/CVE-2026-90243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down copied context entry copied_context_tear_down() zeroes the 128-bit context entry with context_clear_entry() while the Present bit is still set, and only then issues the context-cache and IOTLB invalidations. This leaves a window in which hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behaviour or spurious faults. While x86 provides strong write ordering, the compiler may reorder the writes to the two 64-bit halves of the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. There is no cacheline flush before the invalidation either, so on an IOMMU without coherent access to the context table the zeroed entry may not be visible to hardware at the point the invalidation is submitted. Apply the same ownership handshake described in the VT-d spec, Section 6.5.3.3 (\"Guidance to Software for Invalidations\"): clear only the Present bit, flush it out to the IOMMU, perform the invalidations, and only then zero the remainder of the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90244", "url": "https://ubuntu.com/security/CVE-2026-90244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Restore locking around msi_page_list Unlike a group's default domain, which is always freshly allocated and privately owned (iommu_group_alloc_default_domain()), VFIO type1's legacy container merges any newly attached group into an existing domain whenever their iommu_ops and cache-coherency enforcement match. iommu_dma_get_msi_page() only asserts the caller's own group mutex is held (iommu_group_mutex_assert()). On an IOMMU that publishes IOMMU_RESV_SW_MSI, e.g. ARM SMMU, a VM with two such devices assigned through the legacy container can have their guest drivers probe and allocate MSIs in parallel; each host-side VFIO_DEVICE_SET_IRQS lands on a different device fd and group mutex, but both devices' domains are the same merged domain, so both can enter iommu_dma_get_msi_page() concurrently and corrupt msi_page_list. commit 288683c92b1a (\"iommu: Make iommu_dma_prepare_msi() into a generic operation\") dropped the prior msi_prepare_lock on the reasoning that \"each iommu_domain is unique to a group,\" which holds for default domains but not this VFIO type1 case. Restore the static lock, since it's only guarding a corner case and will likely never be contended. iommufd avoids the equivalent problem by having its own callers (iommufd_sw_map_msi()) take a ctx-wide sw_msi_lock before ever reaching the shared list. VFIO type1 can't mirror that since it dispatches to iommu_dma_sw_msi() which is outside VFIO's jurisdiction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90245", "url": "https://ubuntu.com/security/CVE-2026-90245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: kyro: Validate overlay viewport coordinates The overlay viewport end coordinates are computed from the viewport origin and dimensions using 32-bit unsigned arithmetic. Large input values can cause these calculations to wrap around before the resulting coordinates are passed to SetOverlayViewPort(). SetOverlayViewPort() packs the viewport coordinates into 16-bit register fields. The X coordinates are additionally adjusted by +2 and +1 before being written. Validate the coordinate calculations for 32-bit wraparound and ensure that the adjusted coordinates fit within their 16-bit register fields before calling SetOverlayViewPort(). Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90247", "url": "https://ubuntu.com/security/CVE-2026-90247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix mmap_lock leak in irq_work path stack_map_get_build_id_offset() introduced a per-CPU irq_work to defer mmap_read_unlock() from NMI context, and bpf_find_vma() later reused the same mmap_unlock_work. Both callers only check whether the work is busy before taking mmap_lock, so a nested caller can reuse the slot before the first caller queues it. Two read locks may then be acquired while only one deferred unlock runs, leaking a read lock and blocking exit_mmap(). Reserve the per-CPU slot before mmap_read_trylock(). Use the same wrapper in stackmap and bpf_find_vma() so both callers release the reservation on trylock failure. Keep rejecting the slot while the irq_work remains busy. Release it after the irq_work callback unlocks the mm.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90248", "url": "https://ubuntu.com/security/CVE-2026-90248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: fix teardown of an adopted proto on insert-race loss In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER. Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly: - TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy) Both errout reactions are single expressions derived from the state. This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race. [1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90249", "url": "https://ubuntu.com/security/CVE-2026-90249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes The IIO core does not filter duplicate writes to the event enable attribute, so writing the same value twice invokes write_event_config() twice. Enabling twice leaks a runtime PM reference, preventing the device from ever suspending again; disabling twice underflows the usage count and triggers a \"Runtime PM usage count underflow\" warning. Bail out early when the requested state matches the current state. While at it, switch to pm_runtime_resume_and_get() so a failed resume is propagated to userspace instead of silently marking the event enabled.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90250", "url": "https://ubuntu.com/security/CVE-2026-90250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, cgroup: Fix storage null-ptr-deref after replacing prog Syzkaller reported a storage null-ptr-deref issue after replacing prog. This occurs in the following scenario: 1. prog A, an empty prog, is attached to a cgrp. 2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the bpf_get_local_storage helper. 3. link_update is called to replace prog A with prog B. The reason is that __cgroup_bpf_replace fails to alloc and assign the required cgrp storage for the incoming replacement prog. Consequently, the new prog inherits an uninit storage, leading to null-ptr-deref panic when kick the new prog. Fix this by rejecting a link update if new_prog's cgroup storage is incompatible with link->prog.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90251", "url": "https://ubuntu.com/security/CVE-2026-90251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MSFT: validate evt_prefix_len against the response length read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: \tif (skb->len < sizeof(*rp)) { \t\tbt_dev_err(hdev, \"MSFT supported features length mismatch\"); \t\tgoto failed; \t} evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so \tmsft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, \t\t\t\t GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes (\"skb->len=11 evt_prefix_len=255\", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with \"MSFT event prefix length mismatch\" and msft->evt_prefix is left unset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90252", "url": "https://ubuntu.com/security/CVE-2026-90252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: free the HCI command when it is cancelled mgmt_hci_cmd_sync() queues the pending command with a NULL destroy callback, so it is only freed if send_hci_cmd_sync() runs. A cancelled entry is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Nothing else reclaims it either: mgmt_pending_new() does not put the command on hdev->mgmt_pending. The leak also pins the socket reference taken by mgmt_pending_new(), so the mgmt socket is never released. Free the command from a destroy callback. The now-empty done label is replaced by a direct return.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90253", "url": "https://ubuntu.com/security/CVE-2026-90253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: free the mesh send cancel command when it is cancelled mesh_send_cancel() queues the pending command with a NULL destroy callback, so it is only freed if send_cancel() runs. A cancelled entry is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Nothing else reclaims it either: mgmt_pending_new() does not put the command on hdev->mgmt_pending. The leak also pins the socket reference taken by mgmt_pending_new(), so the mgmt socket is never released. Free the command from a destroy callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90254", "url": "https://ubuntu.com/security/CVE-2026-90254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: free the advertising instance on the failure and cancel paths adv_timeout_expire() hands a kmalloc()ed instance byte to hci_cmd_sync_queue() with a NULL destroy callback, and only adv_timeout_expire_sync() frees it. That leaks on two paths: - the return value is not checked, and hci_cmd_sync_queue() does not take ownership when it fails (-ENETDOWN, -ENODEV, -ENOMEM); - a cancelled entry is not released, as _hci_cmd_sync_cancel_entry() does not free entry->data when there is no destroy callback. hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Free the buffer from a destroy callback, and in the caller when the entry could not be queued at all.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90255", "url": "https://ubuntu.com/security/CVE-2026-90255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fix the SCO setup context lifetime hci_setup_sync() queues a conn_handle_t with a NULL destroy callback, so the context is only freed if hci_enhanced_setup_sync() actually runs. An entry that is cancelled instead is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. The context also stores a bare hci_conn pointer, so the connection can be freed while the work is queued. The dequeue in hci_conn_del() does not cover it either, as it matches on entry->data == conn and entry->data is the wrapper here. Same problem as commit 2f5d635ad590 (\"Bluetooth: hci_sync: hold conn in hci_connect_acl/le_sync() callbacks\"). Hold the connection and release both from a destroy callback. The submission failure path drops both, since hci_cmd_sync_submit() does not call the destroy callback when it fails to queue.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90257", "url": "https://ubuntu.com/security/CVE-2026-90257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: avoid OOB read of build info string The virtbt_setup_zephyr() sends the Zephyr vendor command 0xfc08 (Read Build Information) and hands the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length. A backend that answers with status only leaves that pointer past the end of the received data, so the walk reads adjacent slab memory until it meets a NUL. Those bytes reach the kernel log and the firmware-info debugfs file. To fix this, print the string with a bounded \"%.*s\" limited to skb->len - 1. A short or unterminated response then prints as much as arrived instead of failing setup. This mirrors commit dd068ef04412 (\"Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()\"), which fixed the identical pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90258", "url": "https://ubuntu.com/security/CVE-2026-90258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: airoha: add missed IRQ resource helpers Without hooking .irq_request_resources, gpiolib cannot set GPIOD_FLAG_USED_AS_IRQ. This breaks pin direction locking and can allow userspace or another driver to reconfigure an active IRQ pin as an output", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90259", "url": "https://ubuntu.com/security/CVE-2026-90259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix a wrong length calculation in qgroup_free_reserved_data() In that function, we round down the start position and round up the ending position. But during the calculation of @len, we use \"round_up(start + len, sectorsize)\", which is the rounded up end position, not the rounded up length. Which results a much larger length, and later we are still using \"start + len\", which is completely incorrect. Fix it by declaring a local @aligned_start and @aligned_len and use them instead.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90260", "url": "https://ubuntu.com/security/CVE-2026-90260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: don't clobber the extent buffer when zeroing it out On a zoned filesystem a freed-but-still-dirty tree block is written out as zeros (EXTENT_BUFFER_ZONED_ZEROOUT) only to keep the zone write pointer advancing. btree_csum_one_bio() implemented this by memzeroing the extent buffer's own folios before submission. That destroys the in-memory buffer while it may still be referenced. In particular btrfs_free_tree_block() can run on it afterwards and reads the header to add a delayed reference; once the header has been zeroed it frees bytenr 0 and corrupts the extent tree (the btrfs_header_bytenr(buf) != 0 ASSERT in btrfs_free_tree_block(), or an \"unable to find ref\" abort). It is flaky and reproduces under fsstress, e.g. generic/461 and generic/013. Write the zeros to disk from the shared zero page instead and leave the extent buffer content untouched, so any later reference - including the delayed reference from btrfs_free_tree_block() - still sees a valid header. end_bbio_meta_write() now clears writeback on the buffer's own folios, as the bio no longer carries them.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90262", "url": "https://ubuntu.com/security/CVE-2026-90262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: retry verity reads for not-uptodate Merkle folios btrfs_read_merkle_tree_page() can find a folio in the mapping that is not uptodate. After taking the folio lock, the current code treats that state as a read error and returns -EIO. That can make a previous transient read failure sticky. If the failed read left a not-uptodate folio in the mapping, later callers find that folio and fail instead of retrying the read. Keep the existing page-cache insertion and locking order, but retry the Merkle item read when a not-uptodate folio is found in the mapping. Also unlock the folio when read_key_bytes() fails so that a later caller can lock it and retry the read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90264", "url": "https://ubuntu.com/security/CVE-2026-90264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: always wait for ordered extents to avoid OE races [BUG] Syzbot reported a bug that there can be conflicting OEs for the same range: BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object alrea[ 179.162726][ T6897] BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object already exists) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ordered-data.c:264! Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026 RIP: 0010:btrfs_alloc_ordered_extent+0x943/0xad0 Call Trace: cow_file_range+0x744/0x12a0 fallback_to_cow+0x5ea/0xa00 run_delalloc_nocow+0x110c/0x17a0 btrfs_run_delalloc_range+0xbe4/0x1c20 writepage_delalloc+0x104d/0x1ba0 btrfs_writepages+0x1667/0x28b0 do_writepages+0x338/0x560 filemap_fdatawrite_range+0x1f2/0x300 btrfs_fdatawrite_range+0x54/0xf0 btrfs_direct_write+0x6a0/0xc30 btrfs_do_write_iter+0x329/0x790 do_iter_readv_writev+0x624/0x8d0 vfs_writev+0x34c/0x990 __se_sys_pwritev2+0x17a/0x2a0 do_syscall_64+0x174/0x580 entry_SYSCALL_64_after_hwframe+0x77/0x7f ---[ end trace 0000000000000000 ]--- [CAUSE] Since commit ff66fe666233 (\"btrfs: fix incorrect buffered IO fallback for append direct writes\"), if the direct IO finished short, we will revert the isize back to the original one, so that append writes can be respected during the buffered fallback. Normally we rely on lock_and_cleanup_extent_if_need() function during buffered writeback to wait for any existing ordered extents. But that ordered extent waiting only happens if the start_pos is inside the isize. Since we have reverted the isize during failed direct IO, we will not wait for any ordered extents. This means we can have a race where the direct IO OE is still in the tree, finished but not yet removed, then we're inserting the OE for the buffered write, causing the above crash. [FIX] Make the OE wait to be unconditional, to handle the reverted isize situation. And since lock_and_cleanup_extent_if_need() now either lock the extents or return -EAGAIN, also remove the branches that handles no-extent-locked cases, and rename it to remove the \"_if_need\" suffix. The following micro benchmark shows the runtime difference for btrfs_buffered_write(), doing `xfs_io -f -c \"pwrite 0 1m\"` workload, all values are the average runtime in nano seconds. function runtime | before | after -----------------------------------+-------------+--------------- lock_and_cleanup_extent_if_need() | 58.2 | 183.0 btrfs_buffered_write() | 2115.6 | 2973.3 The overall runtime of btrfs_buffered_write() is still pretty tiny (still less than 3 micro seconds), I'd say the extra cost is still acceptable. An alternative to fix this problem is to wait ordered extents during iomap_end() where the isize revert is done. But that solution will break nowait requirement, as if a nowait direct IO finished short, we have to wait for the OEs unconditionally or the next append buffered IO can still hit the same problem. So here we have to move the wait cost to buffered write, but at least the code is slightly more streamline.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90265", "url": "https://ubuntu.com/security/CVE-2026-90265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: defrag: fix deadlock between defrag and delalloc space reservation While running fsstress with autodefrag and flushoncommit, hit a deadlock due to the fact that defrag reserves delalloc space while it's holding dirty and locked folios, besides the extent range lock. The stack traces are the following: [958.624] task:kworker/u50:3 state:D stack:0 pid:20365 tgid:20365 ppid:2 task_flags:0x4208060 flags:0x00080000 [958.626] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs] [958.627] Call Trace: [958.628] [958.628] __schedule+0x4be/0x10f0 [958.629] ? preempt_count_add+0x69/0xa0 [958.630] schedule+0x26/0xd0 [958.631] wait_current_trans+0x102/0x160 [btrfs] [958.632] ? __pfx_autoremove_wake_function+0x10/0x10 [958.633] start_transaction+0x374/0x900 [btrfs] [958.634] btrfs_commit_current_transaction+0x1d/0x70 [btrfs] [958.635] flush_space+0xca/0x5e0 [btrfs] [958.636] ? _raw_spin_unlock+0x15/0x30 [958.637] ? btrfs_reduce_alloc_profile+0x8c/0x190 [btrfs] [958.639] ? _raw_spin_unlock+0x15/0x30 [958.640] ? calc_available_free_space.isra.0+0x6f/0x110 [btrfs] [958.641] do_async_reclaim_metadata_space+0x84/0x190 [btrfs] [958.642] btrfs_async_reclaim_metadata_space+0x64/0x80 [btrfs] [958.644] process_one_work+0x19d/0x3a0 [958.644] worker_thread+0x1c4/0x330 [958.645] ? __pfx_worker_thread+0x10/0x10 [958.646] kthread+0xfc/0x130 [958.647] ? __pfx_kthread+0x10/0x10 [958.648] ret_from_fork+0x1f7/0x2c0 [958.648] ? __pfx_kthread+0x10/0x10 [958.649] ret_from_fork_asm+0x1a/0x30 [958.650] [958.651] task:kworker/u49:7 state:D stack:0 pid:52990 tgid:52990 ppid:2 task_flags:0x4208060 flags:0x00080000 [958.653] Workqueue: writeback wb_workfn (flush-btrfs-334) [958.655] Call Trace: [958.655] [958.656] __schedule+0x4be/0x10f0 [958.657] ? __blk_flush_plug+0xe9/0x140 [958.658] schedule+0x26/0xd0 [958.658] io_schedule+0x42/0x70 [958.659] folio_wait_bit_common+0x12b/0x330 [958.660] ? folio_wait_bit_common+0x100/0x330 [958.662] ? __pfx_wake_page_function+0x10/0x10 [958.663] extent_write_cache_pages+0x599/0x830 [btrfs] [958.664] ? acpi_fwnode_get_reference_args+0x1fa/0x270 [958.665] btrfs_writepages+0x77/0x130 [btrfs] [958.666] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] [958.667] do_writepages+0xc6/0x160 [958.668] __writeback_single_inode+0x42/0x310 [958.669] writeback_sb_inodes+0x231/0x570 [958.670] wb_writeback+0x8a/0x340 [958.671] wb_workfn+0xbf/0x450 [958.672] ? finish_task_switch.isra.0+0xc1/0x350 [958.673] process_one_work+0x19d/0x3a0 [958.673] worker_thread+0x1c4/0x330 [958.674] ? __pfx_worker_thread+0x10/0x10 [958.675] kthread+0xfc/0x130 [958.676] ? __pfx_kthread+0x10/0x10 [958.676] ret_from_fork+0x1f7/0x2c0 [958.677] ? __pfx_kthread+0x10/0x10 [958.678] ret_from_fork_asm+0x1a/0x30 [958.679] [958.679] task:btrfs-cleaner state:D stack:0 pid:296750 tgid:296750 ppid:2 task_flags:0x208040 flags:0x00080000 [958.681] Call Trace: [958.682] [958.682] __schedule+0x4be/0x10f0 [958.683] schedule+0x26/0xd0 [958.684] handle_reserve_ticket+0x1b9/0x2c0 [btrfs] [958.685] ? __pfx_autoremove_wake_function+0x10/0x10 [958.686] reserve_bytes+0x283/0x4c0 [btrfs] [958.687] btrfs_reserve_metadata_bytes+0x18/0xb0 [btrfs] [958.688] btrfs_delalloc_reserve_metadata+0x121/0x320 [btrfs] [958.690] btrfs_delalloc_reserve_space+0x46/0xb0 [btrfs] [958.691] btrfs_defrag_file+0x903/0x1110 [btrfs] [958.692] btrfs_run_defrag_inodes+0x334/0x430 [btrfs] [958.694] cleaner_kthread+0x97/0x1c0 [btrfs] [958.694] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] [958.696] kthread+0xfc/0x130 [958.696] ? __pfx_kthread+0x10/0x10 [958.697] ret_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90269", "url": "https://ubuntu.com/security/CVE-2026-90269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject load-acquire from pointers requiring fault protection A BPF_LOAD_ACQ is not rewritten to a BPF_PROBE_MEM load by the verifier, unlike a regular BPF_LDX, so the JIT emits a plain load with no exception table entry and a fault panics the kernel instead of being handled. Reject the source pointer types that a BPF_LDX would have had that fault protection applied to, i.e. the ones bpf_convert_ctx_accesses() turns into BPF_PROBE_MEM: a bare PTR_TO_BTF_ID, PTR_TO_BTF_ID | PTR_UNTRUSTED, PTR_TO_BTF_ID | MEM_ALLOC | PTR_UNTRUSTED and PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED. This is reachable e.g. by loading ->mm out of a trusted task_struct yields an untrusted pointer to mm_struct, and it is NULL for a kernel thread: [...] SEC(\"tp_btf/sched_switch\") int BPF_PROG(demo, bool preempt, struct task_struct *prev, struct task_struct *next) { struct mm_struct *mm = next->mm; /* untrusted */ out_ldx = (__u64)mm->pgd; /* BPF_LDX */ out_acq = load_acquire(&mm->pgd); /* BPF_LOAD_ACQ */ return 0; } [...] Both dereference the same pointer, but only the BPF_LDX is protected (x86-64 JIT, jump targets shown prog-relative): [...] ; out_ldx = (__u64)mm->pgd; 17: movq $-10485760, %r10 1e: movq %rsi, %r11 21: addq $184, %r11 28: subq %r10, %r11 2b: movabsq $140737498841088, %r10 35: cmpq %r10, %r11 38: ja 0x3e <-- kernel addr? 3a: xorl %edi, %edi <-- no: dst = 0, skip the load 3c: jmp 0x45 3e: movq 184(%rsi), %rdi <-- yes: load + extable entry [...] ; load_acquire(&mm->pgd) 53:\tmovq %rsi, %rdi 56:\tmovq 184(%rdi), %rax <-- no check, no extable entry [...] Note that BPF_PROBE_MEM is not visible in a bpftool xlated dump, as bpf_insn_prepare_dump() rewrites it back to BPF_MEM. A PTR_TRUSTED pointer is deliberately not on the list. Such a load is not converted either, but it does not need to be, since the pointer is guaranteed live, so load-acquire from it stays allowed. The check is gated on BPF_LOAD_ACQ so that atomic RMW and store-release error messages are unchanged; writes (RMW / store-release) to such pointers are already rejected elsewhere, so only load-acquire needs this.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90272", "url": "https://ubuntu.com/security/CVE-2026-90272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: arm_pmuv3: Zero initialize hw_id branch stack field PERF_SAMPLE_BRANCH_HW_INDEX is supported by BRBE so hw_id is passed to userspace, but it's never set by the BRBE driver. Zero initialize it as it should be according to the docs: * For the architectures whose raw branch records are * already stored in age order, the hw_idx should be 0. It's probably too risky to remove PERF_SAMPLE_BRANCH_HW_INDEX from BRBE now in case anyone is setting it and reading the value, but zero initializing the whole struct also protects against the same issue with new fields that are added in the future.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90274", "url": "https://ubuntu.com/security/CVE-2026-90274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: etm4x: fix underflow for usage of (nrseqstate - 1) According to IHI006H Embedded Trace Macrocell Architecture Specification[0], TRCSEQEVR is implemented only when TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2; otherwise, TRCIDR5.NUMSEQSTATE is 0b000. IOW, the number of usage in the initialisation or setting TRCSEQEVR with drvdata->nrseqstate - 1 in the loop could make underflow issue when TRCIDR5.NUMSEQSTATE is 0b000. Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate. As part of this introduce ETM_MAX_SEQ_TRANSITIONS macro and apply nr_seq_ctrls and above macro to TRCSEQEVR relevant fields setup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90275", "url": "https://ubuntu.com/security/CVE-2026-90275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid1: don't set array_frozen in raid1_takeover() raid1_takeover() sets conf->array_frozen = 1 on the newly-allocated r1conf and nothing ever clears it, so every I/O to the array stalls permanently once _wait_barrier() sees it stuck at 1. This used to be harmless: level_store() called mddev_resume() right after pers->run(), which called raid1_quiesce(mddev, 0) and cleared array_frozen back to 0 regardless of what raid1_takeover() set. Commit b39f35ebe86d (\"md: don't quiesce in mddev_suspend()\") removed that quiesce(mddev, 0) call, so the pre-set now sticks. setup_conf() already zero-initializes the new r1conf via kzalloc, so just don't set array_frozen here. Same class of bug as commit 892da88d1cd9 (\"md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()\"), also triggered by b39f35ebe86d.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90276", "url": "https://ubuntu.com/security/CVE-2026-90276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: stop daemon timer rearm on destroy llbitmap_destroy() deletes pending_timer before flushing md_llbitmap_io_wq. However, daemon_work can still be queued or running after the timer has been deleted, and the daemon path can arm pending_timer again when it finds dirty chunks that are not ready to flush yet. If that happens during teardown, pending_timer can remain armed after llbitmap is freed and later dereference freed memory. Add a BITMAP_SHUTDOWN bit to llbitmap->flags, set it before deleting the timer, and make the timer and daemon paths stop queueing or rearming work once teardown starts. Cancel daemon_work before flushing the shared workqueue so no already queued daemon instance can race with the free. Use timer_shutdown_sync() so a daemon instance that passed the shutdown check before teardown cannot rearm the timer afterward. BITMAP_SHUTDOWN is a runtime-only state. Mask it out when reading and updating the llbitmap superblock so the shutdown state is never loaded from disk or persisted to disk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90277", "url": "https://ubuntu.com/security/CVE-2026-90277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: prevent create failure bitmap UAF llbitmap_create() publishes mddev->bitmap before reading the bitmap superblock. This is needed because llbitmap_read_sb() can initialize a new bitmap and flush it through helpers that use mddev->bitmap. If llbitmap_read_sb() fails, the old cleanup dropped bitmap_info.mutex and freed llbitmap before clearing mddev->bitmap. Readers such as /proc/mdstat rely on bitmap_info.mutex to keep the bitmap pointer stable while collecting bitmap stats, so they could observe the stale pointer after the failed create path released the mutex. Clear mddev->bitmap while still holding bitmap_info.mutex, then free the failed llbitmap after dropping the mutex. This makes mutex-protected readers see either a live bitmap or no bitmap.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90278", "url": "https://ubuntu.com/security/CVE-2026-90278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: wait for behind writes before destroying bitmap __md_stop() destroyed the bitmap before calling mddev_detach(). That made mddev_detach() skip bitmap_ops->wait_behind_writes(), because the bitmap was already disconnected from mddev. This was still safe for the legacy bitmap because bitmap_destroy() waits for behind writes itself. llbitmap keeps that wait in its ->wait_behind_writes() operation instead, while ->destroy() tears down the llbitmap storage. With the old ordering, RAID1 behind-write completions could still run after llbitmap storage had been freed. Call mddev_detach() before md_bitmap_destroy() so the common detach path can wait for behind writes while the bitmap is still alive. Only destroy the bitmap after those users are gone.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90279", "url": "https://ubuntu.com/security/CVE-2026-90279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: round bitmap stripes with sector division raid5_bitmap_sector_map() aligns the array range to full RAID5 stripe widths before converting it to component sectors. That width is chunk_sectors multiplied by the number of data disks, and it is not always a power of two. Reproduce with a 4-disk RAID5, 1024-sector chunks, and three data disks. The full-stripe width is 3072 sectors. For a one-sector write at array sector 3072, correct rounding gives array range [3072, 6144), which maps to component range [1024, 2048). The old round_down()/round_up() logic instead gives [1024, 4096), which maps to [0, 1024). Use sector_div() based arithmetic so the rounded range is aligned to the actual RAID5 stripe width. The deterministic mapper test now reports the fixed component range as [1024, 2048), while the old mask-based range was [0, 1024).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90280", "url": "https://ubuntu.com/security/CVE-2026-90280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: Fix possible NULL-deref on early runtime suspend There is a small window where the runtime suspend callback may run after pm_runtime_enable() and before pm_runtime_forbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: `if (!qmp->phy->init_count) {` This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized. Similarly to other qcom phy drivers, introduce a qmp->phy_initialized variable that can be used to avoid relying on the possibly uninitialized phy pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90281", "url": "https://ubuntu.com/security/CVE-2026-90281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend Runtime PM must be enabled before creating the PHY, since phy_create() only enables runtime PM on the PHY device if it is already enabled on this parent device. However, the runtime PM callbacks dereference the hsphy instance, which is not yet ready, leaving a window where a suspend callback may trigger a NULL pointer dereference. Take a runtime PM usage reference with pm_runtime_get_noresume() before enabling runtime PM and release it once the PHY has been created, so that no runtime suspend can run before the PHY is ready. This also prevents a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90282", "url": "https://ubuntu.com/security/CVE-2026-90282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend There is a small window where the runtime suspend callback may run after pm_runtime_enable() and before pm_runtime_forbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: `if (!qmp->phy->init_count) {` This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized. Similarly to other qcom phy drivers, introduce a qmp->phy_initialized variable that can be used to avoid relying on the possibly uninitialized phy pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90283", "url": "https://ubuntu.com/security/CVE-2026-90283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: release subpool on fill_super failure hugetlbfs_fill_super() allocates a hugepage subpool when size or min_size mount options are specified. hugepage_new_subpool() may also reserve huge pages for min_size. If root dentry creation fails after the subpool is created, the failure path frees the subpool with kfree(). This bypasses hugepage_put_subpool() and can leave min_size reservations charged. Use hugepage_put_subpool() on the failure path, matching the normal put_super path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90284", "url": "https://ubuntu.com/security/CVE-2026-90284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: do not queue completed sysfs fallback requests fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to pending_fw_head. device_add() publishes the fallback loading interface, so a userspace helper which discovers the device by scanning sysfs can write 0 to the loading attribute and complete the request before it is queued as pending. In that interleaving firmware_loading_store() calls fw_state_done() while pending_list still points to itself, so it cannot remove an entry from pending_fw_head. The subsequent unconditional list_add() then queues an already-completed fw_priv. Once the request is released, pending_fw_head can retain a pointer to freed memory and the next fallback request can fault while validating the list. Only in-flight fallback requests need suspend or reboot abort handling. If the request is already DONE after device_add(), return success from the fallback path without sending another uevent, waiting again, or queueing it as pending. This preserves the invariant that pending_fw_head contains only active fallback requests.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90285", "url": "https://ubuntu.com/security/CVE-2026-90285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path qla2x00_sysfs_read_vpd() called ha->isp_ops->read_optrom() a second time after releasing optrom_mutex. The repeated read is redundant and, unlike the first, runs without optrom_mutex held, exposing flash access to concurrent optrom operations. Drop the duplicate call.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90286", "url": "https://ubuntu.com/security/CVE-2026-90286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx6: Use PFP on the compute queues too On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.) This means that we have to take into consideration that the PFP also exists on compute queues on GFX6: Use PFP for register writes on both graphics and compute queues. In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission. After a VM flush, emit PFP_SYNC_ME on compute queues as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90287", "url": "https://ubuntu.com/security/CVE-2026-90287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: sunplus: fix error handling in sp_uphy_init() Fix the error paths of sp_uphy_init() to undo exactly what each stage did: return directly if clk_prepare_enable() fails, release only the clock if reset_control_deassert() fails, and jump to err_reset if update_disc_vol() fails so the clock and reset are not leaked.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90290", "url": "https://ubuntu.com/security/CVE-2026-90290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Restore DAIF state on error Sashiko AI has reported that if swsusp_mte_save_tags() for some reason fails we return from swsusp_arch_suspend() with DAIF being masked - that is not what we'd expect. Restore the saved DAIF state before returning from the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90291", "url": "https://ubuntu.com/security/CVE-2026-90291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: module/dups: Fix use-after-free in kmod_dup_req lifetime handling The kmod dups code uses RCU to ensure that a kmod_dup_req instance is freed only after it is no longer referenced. When releasing an instance, the kmod_dup_request_delete() function removes the kmod_dup_req from the dup_kmod_reqs list, waits via synchronize_rcu() and finally frees it. However, this doesn't work correctly because parallel users referencing the instance in kmod_dup_request_exists_wait() don't enter an RCU read-side critical section. This can result in a use-after-free. The kmod_dup_request_exists_wait() function may need to hold a valid reference to a kmod_dup_req instance across a blocking wait until the corresponding modprobe command completes. This makes it unsuitable for RCU. Fix the issue by changing the lifecycle management of kmod_dup_req to use reference counting.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90292", "url": "https://ubuntu.com/security/CVE-2026-90292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix use-after-free in siw_accept() siw_accept() looks up the QP supplied by userspace. If that QP is already in RTS, the function jumps to error cleanup before associating the incoming CEP with it. The cleanup tests whether qp->cep is non-NULL and assumes the current call installed the association. However, qp->cep can point to the CEP of an existing connection. The cleanup then drops a reference from the incoming cep, not qp->cep. Once the incoming endpoint loses its remaining references, this can free it before the subsequent cep->qp store, causing a use-after-free. It also clears the existing QP association. Only release the association reference when qp->cep is the incoming CEP. This preserves an existing association and avoids accessing the freed endpoint.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90293", "url": "https://ubuntu.com/security/CVE-2026-90293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: post the full-feature receive buffers after session registration isert_put_login_tx() posts the full-feature receive buffers before __transport_register_session() runs, so an initiator that does not wait for the final Login Response can still have a SCSI command executed against an se_session whose se_tpg is NULL - the same oops as the previous patch, at target_submit+0xbe. Post them from isert_get_rx_pdu(), which the previous patch already uses to send that response, and post them before that send: the receive queue is filled at the moment the initiator is told it may use it. Allocating there keeps the existing property that a memory allocation failure cannot happen once the final Login Response is on the wire. The receive queue is already empty between the final Login Request and isert_post_recvm(); this moves the second point later, from a median of 92 us to 172 us over 1200 logins. Only an initiator that sends before it has been told to can reach that window, and on IB and RoCE its send is retried there until the buffers appear - isert_rdma_accept() asks for rnr_retry_count = 7. iWARP has no RNR flow control, so there the same send terminates the connection instead. Measured over rxe, 400 login cycles per run, with an initiator that does not wait: an instrumented build counted no entries to isert_recv_done() before the buffers are posted in 10 runs, where that initiator oopsed 8 of 10 unpatched runs and 5 of 10 with only the previous patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90294", "url": "https://ubuntu.com/security/CVE-2026-90294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: delay the final Login Response until the session is registered isert_put_login_tx() puts the final Login Response on the wire before __transport_register_session(), which iscsi_post_login_handler() reaches only after iscsi_target_do_login() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses on the NULL dereference. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ib-comp-wq ib_cq_poll_work RIP: 0010:target_submit+0xbe/0x390 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363 RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078 RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52 R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000 R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044 FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? __pfx__raw_spin_lock_bh+0x10/0x10 ? __pfx_target_submit+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ? __pfx_isert_recv_done+0x10/0x10 ? rxe_poll_cq+0x253/0x3d0 ? finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Delay the final Login Response instead. isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn->rx_login_comp, completed by iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP and cxgbit already take PDUs from that thread, isert alone does not. The buffers are still posted first, so the initiator's first command does not meet an empty receive queue and nothing depends on RNR flow control, and the header and payload live in isert_conn, not in the struct iscsi_login that iscsi_target_nego_release() frees first. Over rxe, 400 login cycles per run, the oops appeared in 10 of 20 unpatched runs and in none of 20 runs with this patch. An initiator that never waits is handled by the next patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90295", "url": "https://ubuntu.com/security/CVE-2026-90295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix out-of-bounds write when probed more than once imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: \timx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), \t\t\t\t GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90296", "url": "https://ubuntu.com/security/CVE-2026-90296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix devres accumulation across driver rebind imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev is the CPU device from get_cpu_device(0). That device is never unbound, so its devres list is never released, and imx6q_cpufreq_remove() does not free the array either. Every probe therefore adds an allocation that stays for the lifetime of the system. Allocate against the platform device instead. Its devres is released when the driver is unbound, which is exactly the lifetime the array wants: imx6q_set_target() reads it, and nothing may reach that after cpufreq_unregister_driver(). That makes the array actually go away on unbind, so also clear the file-scope pointer in remove and on the failed-probe path, rather than leave it pointing at memory devres is about to release. Tested by rebinding the driver on qemu's mcimx6ul-evk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90297", "url": "https://ubuntu.com/security/CVE-2026-90297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: crtc: Propagate layer initialization error sun4i_crtc_init() returns plain NULL when layer initialization fails, while all its other error paths return an error pointer. The only caller, sun4i_tcon_bind(), checks the result with IS_ERR() and happily continues with tcon->crtc set to NULL. sun4i_rgb_init() and sun4i_lvds_init() then dereference it in drm_crtc_mask(), which oopses. Return the error pointer instead.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90298", "url": "https://ubuntu.com/security/CVE-2026-90298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: tcon: Drop TCON TOP device reference of_find_device_by_node() takes a device reference. Drop it after mux configuration succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90302", "url": "https://ubuntu.com/security/CVE-2026-90302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: synchronize heartbeat callbacks with o2net teardown Patch series \"ocfs2: harden heartbeat teardown races\". This series fixes two OCFS2 heartbeat/o2net teardown races found by KASAN. This patch (of 2): Heartbeat callbacks stay registered while configfs local-node teardown enters o2net_stop_listening(). A node-down event can still run through o2net_disconnect_node() and o2net_set_nn_state() while teardown is destroying o2net_wq, so the later queue/flush operations can hit a dead workqueue. KASAN has caught this as a slab-use-after-free in __queue_work() with the call chain: KASAN slab-use-after-free in __queue_work+0x56/0xa90 Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __queue_work+0x56/0xa90 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __queue_delayed_work+0x58/0x1e0 queue_delayed_work_on+0xb4/0xc0 o2net_set_nn_state+0x467/0x840 o2net_disconnect_node+0x7b/0xe0 o2net_hb_node_down_cb+0x54/0x60 o2hb_run_event_list+0x236/0x2d0 o2hb_check_slot+0xad4/0xbc0 lock_release+0xc8/0x290 o2hb_check_slot+0x9ea/0xbc0 trace_hardirqs_on+0x18/0x130 o2hb_do_disk_heartbeat+0x646/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) __lock_acquire+0x466/0x2260 lockdep_hardirqs_on_prepare+0xea/0x1a0 ktime_get_with_offset+0xe9/0x230 o2hb_thread+0x14e/0x770 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 __switch_to+0x2e9/0x730 ret_from_fork_asm+0x1a/0x30 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x292/0x760 __alloc_workqueue+0x736/0xc60 alloc_workqueue_noprof+0xb1/0x110 o2net_start_listening+0xe5/0x430 o2nm_node_local_store+0x184/0x310 configfs_write_iter+0x18a/0x210 vfs_write+0x469/0x810 ksys_write+0xd2/0x170 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 rcu_core+0x4f4/0x1320 handle_softirqs+0x156/0x660 queue_delayed_work_on o2net_set_nn_state o2net_disconnect_node o2net_hb_node_down_cb o2hb_run_event_list Keep heartbeat callbacks registered so quorum state still tracks node state, but stop them from driving o2net reconnect/disconnect work once local teardown starts. Mark the transport offline before destroying o2net_wq, wait for any in-flight heartbeat callback to finish, and delay bring-up replay until the new local node is published through o2nm_this_node(). The replay also has to stay serialized with heartbeat callback delivery. Otherwise a live-node snapshot can be copied, a real hb_down callback can install -ENOTCONN for a peer, and the stale replay can call o2net_hb_node_up() for that same peer and queue reconnect work even though heartbeat is already down. The buggy scenario involves two paths, with each column showing the order within that path: local-node teardown: heartbeat node-down callback: 1. configfs local-off enters 1. o2hb_run_event_list() invokes o2net_stop_listening(). o2net_hb_node_down_cb(). 2. teardown heads for 2. the callback reaches destroy_workqueue(o2net_wq). o2net_disconnect_node() and o2net_set_nn_state(). 3. teardown destroys and NULLs 3. the callback flushes or queues o2net_wq. work through o2net_wq.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90303", "url": "https://ubuntu.com/security/CVE-2026-90303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults When CONFIG_DEBUG_USER=y, and cmdline \"user_debug=31\" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte(). If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running. Acquire mmap_write_lock() around show_pte() for user faults to fix the contention. For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr < TASK_SIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications. Keep everything unchanged for kernel faults, because the kernel is already in the \"oops\" state, acquiring a lock may risk a deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90306", "url": "https://ubuntu.com/security/CVE-2026-90306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9481/2: breakpoint: CFI breakpoints only on demand This removes the stub hw_breakpoint_cfi_handler() from ARM, making it not steal breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) unless CFI is actively used in the kernel. When not instrumenting with CFI, or when a breakpoint is issued in userspace, we fall through to return 1 from hw_breakpoint_pending() \"unhandled fault\" so userspace can make use of this breakpoint. Tested with LKDTM and this command line: echo CFI_FORWARD_PROTO > /sys/kernel/debug/provoke-crash/DIRECT still works as expected.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90307", "url": "https://ubuntu.com/security/CVE-2026-90307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes nothing to srp_process_cred_req() and srp_process_aer_req(), which read fixed-size fields from the receive buffer without checking that those fields were received. The buffer size is max_ti_iu_len, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent back, so those bytes reach the target. SRP_AER_REQ behaves the same way and also reads req->lun. The leak is 8 bytes per response. max_ti_iu_len also decides which slab cache the buffer comes from. With 8 the buffer is a kmalloc-8 object and the read is entirely outside it: BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8) Without KASAN the returned bytes are whatever is next in the slab. One run returned \".strtab\". rsp->data[3] in srp_process_rsp() has the same problem: only resp_data_len is checked before it is read. Drop a request that is shorter than the structure being parsed, and check byte_len before the tsk_mgmt read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90308", "url": "https://ubuntu.com/security/CVE-2026-90308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: Hold QP references for AE and CM processing AE QP fatal events and iWARP CM paths load QPs from dev->qp_xa and then use or reference them outside the xarray lock. erdma_destroy_qp() can drop the destroy-path reference and free QP resources while such a lookup is in flight. Add erdma_qp_get_by_qpn() to acquire a kref under the xarray lock with kref_get_unless_zero(). Remove the QP from the xarray before dropping the destroy-path reference so no new lookup can acquire it while destruction waits for existing users.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90309", "url": "https://ubuntu.com/security/CVE-2026-90309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: Hold CQ references when processing EQ events EQ handlers look up CQs from dev->cq_xa and invoke CQ completion or error callbacks outside the xarray lock. erdma_destroy_cq() can erase the CQ from the xarray and free its queue buffer and doorbell record while a previously scheduled EQ handler is still using the CQ. Add a CQ refcount and take a reference under the xarray lock with refcount_inc_not_zero(). Remove the CQ from the xarray before dropping the destroy-path reference, then wait for in-flight EQ users before releasing CQ resources.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90312", "url": "https://ubuntu.com/security/CVE-2026-90312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check load-acquire src ptr type before the load check_atomic_load() calls check_load_mem() before atomic_ptr_type_ok(). For a load-acquire that fetches into its own source register (dst_reg == src_reg), check_load_mem() overwrites src_reg's type with the type of the loaded value, so the subsequent atomic_ptr_type_ok() no longer sees the source pointer and fails to reject the disallowed types (ctx, pkt, flow_keys, sock). Since bpf_convert_ctx_accesses() does not rewrite atomic loads, the raw access to the underlying kernel object is left in place. The destination type is taken from the ctx access itself, so a load-acquire of the sk field of struct __sk_buff for example leaves the register typed as PTR_TO_SOCK_COMMON_OR_NULL, which type_is_sk_pointer() does not match either, while it actually holds unconverted struct sk_buff bytes. Once the NULL check has passed this is a type confusion, not just a leak of kernel data. Validate src_reg with check_reg_arg() and check the source pointer type with atomic_ptr_type_ok() before the load again, mirroring check_atomic_rmw(). Out-of-range register numbers are already rejected earlier by check_and_resolve_insns() (commit 503d21ef8eac (\"bpf: Do register range validation early\")), and the only exemption there, is_stack_arg_ldx(), requires BPF_LDX | BPF_MEM | BPF_DW and thus never matches a BPF_ATOMIC insn. atomic_ptr_type_ok() can therefore not dereference register state out of bounds, that is, the out-of-bounds read addressed by the Fixes commit below does not reappear (as proven also via selftest).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90313", "url": "https://ubuntu.com/security/CVE-2026-90313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed A potential invalid storage access issue can occur after replacing a cgroup bpf prog. This occurs in the following scenario: 1. prog1 with storage is attached to a cgroup in multi-attach mode. 2. prog1 is replaced with prog2 using BPF_F_REPLACE in multi-attach mode, but fails midway (e.g. in bpf_trampoline_link_cgroup_shim or update_effective_progs). 3. A new prog3 is attached to the cgroup in multi-attach mode. The reason is that __cgroup_bpf_attach overwrites pl->storage with the new storage prior to attachment completion. When attachment fails midway, the cleanup path calls bpf_cgroup_storages_free(new_storage) to free the newly allocated storage, but fails to restore pl->storage back to old_storage. Consequently, the still-active prog1 holds invalid or dangling storage pointers, leading to an invalid memory access when prog1 executes and calls bpf_get_local_storage. Additionally, original pl->flags and cgrp->bpf.flags[atype] are left unrestored. Fix this by saving old_pl_flags, old_storage, and old_flags prior to the update, and properly restoring all of them in the cleanup path on error.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90314", "url": "https://ubuntu.com/security/CVE-2026-90314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression \"table_sz - offset - sizeof(*hdr)\", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90316", "url": "https://ubuntu.com/security/CVE-2026-90316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/omap: dsi: Do not copy isr table To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90318", "url": "https://ubuntu.com/security/CVE-2026-90318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: release buffer head after rebuilding parent fat_scan_logstart() leaves the matching directory entry's buffer head in sinfo.bh for the caller to release, just like fat_scan(). fat_rebuild_parent() uses the directory entry to rebuild the parent inode for the nostale_ro NFS export path, but does not release sinfo.bh after a successful scan. Release it once fat_build_inode() has consumed the directory entry data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90319", "url": "https://ubuntu.com/security/CVE-2026-90319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: clear mport->net when rio_add_net() fails rio_alloc_net() stores the newly allocated rio_net in mport->net before rio_scan_alloc_net() registers the device. If rio_add_net() fails, rio_scan_alloc_net() drops the device reference with put_device(), which releases the rio_net through the device release callback. However, mport->net is left pointing at the freed object. A later mport unregister path can then dereference the dangling mport->net pointer and may try to free the same rio_net again. Clear mport->net in the rio_add_net() failure path, matching the cleanup done for the destID table allocation failure path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90322", "url": "https://ubuntu.com/security/CVE-2026-90322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2/cluster: keep heartbeat local node stable o2nm_node_local_store() handles local=0 by stopping o2net and setting cl_local_node to O2NM_INVALID_NODE_NUM, but it leaves cl_has_local set. That stale state makes o2nm_this_node() return 255, blocks a later local=1 attempt with -EBUSY, and can feed 255 to heartbeat users that call o2nm_this_node() dynamically. Clearing cl_has_local is required when the local node is reset. But heartbeat threads can still be running at that point. They pin the local node config item at startup, yet o2hb_do_disk_heartbeat() and thread teardown re-read o2nm_this_node() for the local slot and for o2nm_undepend_this_node(). Once local=0 has cleared the live local-node state, those dynamic reads return O2NM_MAX_NODES, which is also the invalid node number 255. Store the local node number in the heartbeat region when the region starts. Use that stable node for heartbeat slot writes/checks, negotiation messages, and the final configfs undepend. Stop the heartbeat loop when the current local node no longer matches the stored node, and clear cl_has_local together with cl_local_node in the local=0 path so nodemanager state matches node removal. Validation reproduced this kernel report: KASAN slab-out-of-bounds in o2hb_do_disk_heartbeat+0x372/0xb30 RIP: 0010:memset+0xf/0x20 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xd0/0x630 o2hb_do_disk_heartbeat+0x372/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x188/0x2f0 kasan_report+0xe4/0x120 o2hb_do_disk_heartbeat+0x5/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) o2hb_thread+0x14e/0x770 kthread_affine_node+0x139/0x180 lockdep_hardirqs_on_prepare+0xda/0x190 trace_hardirqs_on+0x18/0x130 kthread+0x19d/0x1e0 ret_from_fork+0x37a/0x4d0 __switch_to+0x2d5/0x6f0 ret_from_fork_asm+0x1a/0x30", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90324", "url": "https://ubuntu.com/security/CVE-2026-90324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: check import_ubuf() return value import_ubuf() can fail if the address range (provided by the userspace ublk server) is outside the allowed user address space. Return that 0 bytes were copied if import_ubuf() fails rather than passing an uninitialized struct iov_iter to ublk_copy_user_pages().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90325", "url": "https://ubuntu.com/security/CVE-2026-90325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: skip dying blkg in blkcg_activate_policy() When switching IO schedulers on a block device, blkcg_activate_policy() can race with concurrent blkcg deletion, leading to a use-after-free in rcu_accelerate_cbs. T1: T2: blkg_destroy kill(&blkg->refcnt) // blkg->refcnt=1->0 blkg_release // call_rcu(__blkg_release) ... blkg_free_workfn ->pd_free_fn(pd) elv_iosched_store elevator_switch ... iterate blkg list blkg_get(blkg) // blkg->refcnt=0->1 list_del_init(&blkg->q_node) blkg_put(pinned_blkg) // blkg->refcnt=1->0 blkg_release // call_rcu again rcu_accelerate_cbs // uaf Fix this by checking hlist_unhashed(&blkg->blkcg_node) before getting a reference to the blkg. This is the same check used in blkg_destroy() to detect if a blkg has already been destroyed. If the blkg is already unhashed, skip processing it since it's being destroyed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90326", "url": "https://ubuntu.com/security/CVE-2026-90326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix race between policy activation and blkg destruction When switching an IO scheduler on a block device, blkcg_activate_policy() allocates blkg_policy_data (pd) for all blkgs attached to the queue. However, blkcg_activate_policy() may race with concurrent blkcg deletion, leading to use-after-free and memory leak issues. The use-after-free occurs in the following race: T1 (blkcg_activate_policy): - Successfully allocates pd for blkg1 (loop0->queue, blkcgA) - Fails to allocate pd for blkg2 (loop0->queue, blkcgB) - Enters the enomem rollback path to release blkg1 resources T2 (blkcg deletion): - blkcgA is deleted concurrently - blkg1 is freed via blkg_free_workfn() - blkg1->pd is freed T1 (continued): - Rollback path accesses blkg1->pd->online after pd is freed - Triggers use-after-free In addition, blkg_free_workfn() frees pd before removing the blkg from q->blkg_list. This allows blkcg_activate_policy() to allocate a new pd for a blkg that is being destroyed, leaving the newly allocated pd unreachable when the blkg is finally freed. Fix these races by extending blkcg_mutex coverage to serialize blkcg_activate_policy() rollback and blkg destruction, ensuring pd lifecycle is synchronized with blkg list visibility.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90327", "url": "https://ubuntu.com/security/CVE-2026-90327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: do not write beyond optlen in getsockopt pep_getsockopt() clamps the reported length to the caller's buffer with min_t(), but then stores the value with put_user(val, (int __user *) optval), which always writes sizeof(int) bytes. A getsockopt() call with an optlen smaller than sizeof(int) thus reports the clamped length yet writes a full int, one to three bytes past the user buffer. Write the value with copy_to_user() bounded by len, so at most optlen bytes are copied, matching the length reported back to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90328", "url": "https://ubuntu.com/security/CVE-2026-90328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: steam: Reject short reads Steam Controller FEATURE reports encode the size of the message in the message itself. Previously we were trusting that the size reported matched the size we actually read, leading to a potential issue with short reads. Instead, we should actually verify the length of the read.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90329", "url": "https://ubuntu.com/security/CVE-2026-90329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: synchronize input before cleaning up a failed probe hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90333", "url": "https://ubuntu.com/security/CVE-2026-90333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-integrity: replace forgeable discard filler with a keyed sector marker The discard-block check in dm_integrity_rw_tag() treats a stored tag of all 0xf6 bytes (DISCARD_FILLER) as proof a block was discarded and skips HMAC verification. allow_discards is only accepted in dm-integrity's standalone mode. An attacker with raw write access to the backing device, but without the integrity key, can stamp any block with an all-0xf6 tag and have it served as authentic. Add a new \"allow_discards_keyed\" target argument that marks discarded blocks with a keyed checksum of (salt || sector) instead, computed by integrity_discard_checksum().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90334", "url": "https://ubuntu.com/security/CVE-2026-90334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: clear cdev pointer after cdev_add() failure tty_cdev_add() drops the cdev reference when cdev_add() fails, but leaves driver->cdevs[index] pointing to freed memory. tty_unregister_device() later passes that stale pointer to cdev_del(), causing a use-after-free. Clear the slot after dropping the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90338", "url": "https://ubuntu.com/security/CVE-2026-90338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: amba-pl011: keep console clock enabled for atomic writes pl011_console_write_atomic() runs from nbcon atomic context, where sleeping is not allowed. It calls clk_enable(), which takes the common-clk enable_lock. Under PREEMPT_RT that is a sleeping lock: clk_enable_lock() first tries spin_trylock_irqsave(), but on contention falls back to spin_lock_irqsave(). Therefore, an atomic-context printk on an RT kernel with a clk-backed pl011 can trip: BUG: sleeping function called from invalid context at spinlock_rt.c:48 __might_resched from rt_spin_lock rt_spin_lock from clk_enable_lock clk_enable_lock from clk_enable clk_enable from pl011_console_write_atomic ... from vprintk_emit This was found and reproduced on PREEMPT_RT. Arm32 and arm64 DT SoCs are affected; arm64 SBSA/ACPI has no clk, so clk_enable(NULL) short-circuits before the lock. In addition, write_atomic() may be invoked from NMI context and is documented to avoid locking. Removing clk_enable() from the callback also avoids a potentially unsafe NMI acquisition of the common-clock enable_lock. An nbcon atomic-capable console must be printable from any context, so the clock cannot be gated between writes. Enable the clock while the console is available for output: use clk_prepare_enable() in pl011_console_setup(), release it via clk_disable_unprepare() in the console .exit() callback, and drop the per-write clk_enable()/clk_disable() pairs from write_atomic() and write_thread(). When printk suspends consoles, drop the reference after uart_suspend_port() stops console access and restore it before uart_resume_port() -- but only if suspend actually marked the port suspended (a wake-capable tty stays running and must keep its clock), and keep it when console_suspend_enabled is false so no_console_suspend works. The active power cost of keeping the clock enabled is platform-dependent: none where the UART clock is a fixed always-on oscillator, real where it is a gateable clock branch, which then cannot be gated (nor possibly can its parent clocks) while the console is available for output. When serial core actually suspends the port, the reference is released so the clock provider can gate the clock tree.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90341", "url": "https://ubuntu.com/security/CVE-2026-90341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: coreboot: Validate table bounds The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table. A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header. Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90343", "url": "https://ubuntu.com/security/CVE-2026-90343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: stop PMSR before P2P and NAN teardown PMSR request teardown must abort active measurements while the wireless_dev is still present in the driver. cfg80211_leave_locked() and cfg80211_stop_pd() already do this before invoking the driver's stop callback, but cfg80211_stop_p2p_device() and cfg80211_stop_nan() do not. Those helpers are also called directly by nl80211, rfkill shutdown, and wireless_dev unregister paths. If one of these paths stops a P2P device or NAN interface with a pending request, it removes the mac80211 subinterface from the driver first. Subsequent request cleanup cannot reach the lower driver's abort callback, but cfg80211 frees the request regardless. Driver state can then retain a stale request and use it when it later reports a result. Call cfg80211_pmsr_wdev_down() before stopping the P2P device or NAN interface. This keeps lower-driver request state and cfg80211 request ownership in sync for all of the helpers' callers.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90344", "url": "https://ubuntu.com/security/CVE-2026-90344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: disconnect on CSA to channel 0 The refactor for the CSA parsing erroneously equates channel zero and no information present, leading it to ignore a CSA on an AP that advertises a switch to that (invalid) channel. This leads to not disconnecting, which we should. For Intel devices, this can lead to a firmware crash. Fix this by using an int type for the channel number as well as the opclass, and using a (negative) value that cannot be encoded in the element to indicate it's not present.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90348", "url": "https://ubuntu.com/security/CVE-2026-90348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90349", "url": "https://ubuntu.com/security/CVE-2026-90349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix out-of-bounds link array access in mt7996_tx() When mac80211 leaves the link unspecified, mt7996_tx() substitutes the primary link id of the station or vif. That value is IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added, and it is then used unchecked to index vif->link_conf[], mvif->mt76.link[] and sta->link[], all of which hold IEEE80211_MLD_MAX_NUM_LINKS (15) entries. Clamp the primary link id to the default link before using it, and use the clamped value for the link_sta fallback as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90350", "url": "https://ubuntu.com/security/CVE-2026-90350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: reject out-of-range link ids in mt76_vif_link() mt76_vif_link() indexes mvif->link[] without validating link_id, but callers pass mvif->deflink_id / msta->deflink_id, which hold IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added. Since IEEE80211_MLD_MAX_NUM_LINKS is 15, that reads one element past the end of the array, aliasing mt76_vif_data.offchannel_link. Reachable via mt7996_set_tsf()/mt7996_offset_tsf() and mt7996_net_fill_forward_path(). Bounds check link_id and return NULL, matching mt7996_sta_link() and mt7996_sta_link_protected().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90351", "url": "https://ubuntu.com/security/CVE-2026-90351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: do not attach hif2 WED when the main WED attach failed If the WED attach for the primary PCIe function fails, the probe path still attached wed_hif2 for the secondary function, leaving the device in an inconsistent half-WED configuration that crashes later. The hif2 call also re-enabled hwrro_mode, which the failed primary attach had just turned off. Skip the hif2 WED setup when the primary WED device is not active.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90352", "url": "https://ubuntu.com/security/CVE-2026-90352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: release hif2 reference on probe IRQ failure The hif2 reference obtained by mt7915_pci_init_hif2() is only released on error paths that key off dev->hif2, which is not assigned until after the IRQ setup. If pci_alloc_irq_vectors() or the primary devm_request_irq() fails, the reference leaks. Drop it explicitly on those paths via mt7915_put_hif2().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90353", "url": "https://ubuntu.com/security/CVE-2026-90353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix ext PHY use-after-free on register error path After mt7915_register_ext_phy() succeeded, a failure of the main PHY mt7915_init_debugfs() or mt7915_coredump_register() unwound through free_phy2, which called ieee80211_free_hw() on the ext PHY hw while it was still registered with mac80211, since mt76_unregister_device() only unregisters the main hw. Unregister the ext PHY (thermal + phy + hw) first and skip the redundant free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90354", "url": "https://ubuntu.com/security/CVE-2026-90354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix double hif2 init on the non-WED path mt7915_pci_init_hif2() was called unconditionally and again inside the WED-inactive branch. The helper increments the global hif_idx, writes the PCIe RECOG_ID register and takes a get_device() reference via mt7915_pci_get_hif2(), while removal only drops one reference. On non-WED dual-hif hardware this double-incremented hif_idx, wrote RECOG_ID twice and leaked a device reference. Only the call inside the WED-inactive branch is correct; drop the unconditional one. hif2 is already initialised to NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90356", "url": "https://ubuntu.com/security/CVE-2026-90356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: free vif links after clearing wcid entries on full reset mt7996_mac_reset_vif_iter() queues non-default vif links for kfree_rcu while dev->wcid[] still holds pointers to the wcid embedded in each freed link; mt76_reset_device() then dereferences those entries and runs mt76_wcid_cleanup() on them. If a grace period elapses in between, the cleanup operates on freed memory. Run mt76_reset_device() first, so the wcid entries are cleaned up and cleared while the links are still valid.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90357", "url": "https://ubuntu.com/security/CVE-2026-90357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: unlink TWT flow if the MCU rejects the agreement The flow is added to dev->twt_list before sending the agreement to the firmware, but the error path leaves it linked while flowid_mask is never set. The flow slot can then be reused and memset while still on the list, corrupting twt_list, and station removal leaves a dangling entry behind that mt7915_mac_twt_sched_list_add() later walks.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90358", "url": "https://ubuntu.com/security/CVE-2026-90358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, x86: Fix trampoline stack size for 128-bit arguments btf_distill_func_proto() accepts a function argument up to 16 bytes, so a 128-bit scalar such as __int128 reaches the x86 trampoline with arg_size == 16. But the current implementation assumes an __int128 argument only needs one register, so the register save area is under-allocated and save_args() overwrites adjacent stack slots. Compute the register count from arg_size for all arguments to fix it.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90360", "url": "https://ubuntu.com/security/CVE-2026-90360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: use system_freezable_wq for init complete work schedule_delayed_work() uses system_wq, which is non-freezable, allowing regulator_init_complete_work to run concurrently with system suspend. This work fires ~30s after boot to disable unused regulators via I2C. When it races with PM suspend, the I2C adapter may already be suspended, triggering a -ESHUTDOWN warning in __i2c_transfer(): WARNING: ... at __i2c_transfer+0x36c/0x3c8 Call trace: __i2c_transfer i2c_transfer regmap_i2c_write _regmap_update_bits regulator_disable_regmap _regulator_do_disable regulator_late_cleanup regulator_init_complete_work_function process_one_work Switch to system_freezable_wq so the work is frozen before any device is suspended, eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90361", "url": "https://ubuntu.com/security/CVE-2026-90361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix leak in ath11k_service_ready_ext_event() Currently, during ath11k_service_ready_ext_event() processing, svc_rdy_ext.mac_phy_caps can be allocated during TLV parsing. This is a temporary allocation that is freed on the success path, but not on the error path. If parsing succeeds far enough to allocate mac_phy_caps and then fails on a later TLV, the allocation leaks. So free the allocation on the error path. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90362", "url": "https://ubuntu.com/security/CVE-2026-90362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Drop dev_pm_opp_set_rate(0) dev_pm_opp_set_rate(0) removes the vote specified in required-opps but does not actually park the clock, making it run without the necessary power backing. Drop the explicit call to it. Every call site of ops->link_clk_disable() is followed by pm_runtime_put(), so the power vote will be rescinded if deemed safe. Patchwork: https://patchwork.freedesktop.org/patch/742783/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90363", "url": "https://ubuntu.com/security/CVE-2026-90363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: don't tear down KMS twice when KMS init fails When priv->kms_init() (mdp4_kms_init() / mdp5_kms_init()) fails partway through, both display drivers already tear their KMS state down via mdp4_destroy() / mdp5_kms_destroy() before returning the error. The common error path in msm_drm_init() then runs msm_drm_uninit() -> msm_drm_kms_uninit(), which tries to destroy the very same KMS a second time, which causes a use-after-free crash. Bring MDP4/MDP5 in line with the DPU driver whose dpu_kms_init() doesn't perform error cleanup on the failure. Let the common path own the cleanup, instead of freeing the KMS from their error paths. The crash trace for the reference: __lock_acquire from lock_acquire (kernel/locking/lockdep.c:5906 kernel/locking/lockdep.c:5863) lock_acquire from touch_wq_lockdep_map (kernel/workqueue.c:4094 (discriminator 1)) touch_wq_lockdep_map from __flush_workqueue (kernel/workqueue.c:4136) __flush_workqueue from msm_drm_kms_uninit (drivers/gpu/drm/msm/msm_kms.c:243 (discriminator 33)) msm_drm_kms_uninit from msm_drm_uninit (drivers/gpu/drm/msm/msm_drv.c:93) msm_drm_uninit from msm_drm_init (drivers/gpu/drm/msm/msm_drv.c:184) msm_drm_init from try_to_bring_up_aggregate_device (drivers/base/component.c:249 drivers/base/component.c:227) try_to_bring_up_aggregate_device from __component_add (drivers/base/component.c:269 drivers/base/component.c:748) __component_add from dsi_host_attach (drivers/gpu/drm/msm/dsi/dsi_host.c:1739) dsi_host_attach from mipi_dsi_attach (drivers/gpu/drm/drm_mipi_dsi.c:383) mipi_dsi_attach from sharp_nt_panel_probe (drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c:247) Patchwork: https://patchwork.freedesktop.org/patch/742068/", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90364", "url": "https://ubuntu.com/security/CVE-2026-90364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Unregister cpufreq notifier on init failure acpi_processor_driver_init() registers the cpufreq policy notifier before registering the ACPI processor driver and setting up CPU hotplug state. If driver_register() or cpuhp_setup_state() fails, the error path only unregisters the ACPI processor driver and the idle driver. The cpufreq notifier remains registered even though initialization failed. Mirror the module exit path on the init failure path and unregister the cpufreq notifier when it has been registered.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90366", "url": "https://ubuntu.com/security/CVE-2026-90366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: reserve space for the CSA-abort countdown TLV When a CSA countdown is active, mt7996_mcu_beacon_cntdwn() emits two bss_bcn_cntdwn_tlv entries (the CSA countdown and the CCA-abort BCC), but MT7996_BEACON_UPDATE_SIZE only reserved one. With MBSSID enabled and a near-maximum beacon template the extra 8 bytes could push the offload command past MT7996_MAX_BSS_OFFLOAD_SIZE and trigger skb_over_panic(). Reserve room for both countdown TLVs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90367", "url": "https://ubuntu.com/security/CVE-2026-90367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: hold dev->mt76.mutex while disabling tx worker in SER mt7996_mac_reset_work() parked the tx worker and disabled the RX/TX NAPIs before taking dev->mt76.mutex. mt76_worker_disable()/_enable() are plain kthread park/unpark, not refcounted, and __mt76_set_channel() toggles the same worker and the MT76_RESET bit under the mutex. An L1 SER racing a channel switch could therefore have the worker unparked and MT76_RESET cleared while the reset path resets the DMA rings, corrupting descriptors or tokens. Take the mutex before disabling the worker, as mt7915 does.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90368", "url": "https://ubuntu.com/security/CVE-2026-90368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: unwind state on add_interface failure When mt76_wcid_alloc() fails, mt7915_add_interface() returned without clearing the vif_mask/omac_mask bits it had already set, without removing the firmware dev info added earlier, and without clearing a monitor_vif pointer to the vif mac80211 is about to free. mac80211 does not call remove_interface() for a failed add, so the indices and firmware dev entry leaked permanently and testmode could dereference the stale monitor_vif. Add a proper error unwind.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90370", "url": "https://ubuntu.com/security/CVE-2026-90370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: bound TLV walk in mt7996_mcu_get_chip_config The response TLV loop advanced by tlv->len without a minimum, so a theoretical firmware response containing a zero-length TLV could spin forever, hanging the CPU during device probe. The u32 payload was also read without bounds checking. Reject a short fixed field, stop on a TLV whose length underruns the header or overruns the skb.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90371", "url": "https://ubuntu.com/security/CVE-2026-90371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix RXDMAD_C buffer recycling race The RXDMAD_C buffers come from the RRO data queues' page pools, which are bound to a different NAPI, so the direct page-pool recycle used here could race the owning NAPI; take the non-direct path as is already done for WED RX queues.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90372", "url": "https://ubuntu.com/security/CVE-2026-90372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss If a peer's VHT/HE MCS map has no supported spatial stream (all fields 0x3), the loop exits with nss == 0 and the function returned (u8)-1 (255), which was then written into the firmware sta_rec_bf beamforming fields. Clamp the result to 0.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90373", "url": "https://ubuntu.com/security/CVE-2026-90373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: clear wcid mask under mutex after RCU pointer clear mt7915_remove_interface() cleared the wcid mask bit with no lock held and before clearing the RCU wcid pointer. The mask is a non-atomic RMW shared with the allocators, which all run under dev->mt76.mutex; on DBDC the two wiphys share one mt76_dev, so this raced add_interface/sta_add on the other band and could leak or double-hand-out a wcid. Clearing the bit before the RCU pointer also let a concurrent allocation reuse the index and publish its wcid, which the subsequent NULL assignment then wiped. Move the clear into the existing mutex section, after the RCU pointer is cleared.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90374", "url": "https://ubuntu.com/security/CVE-2026-90374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: validate RX band_idx before dereferencing phys[] band_idx comes from a 2-bit descriptor field (0-3) and was used directly to index dev->mt76.phys[] (size __MT_MAX_BAND == 3) and dereference the result. A corrupt or reserved descriptor value could index out of bounds or hit a NULL phy on parts with fewer bands. Reject invalid band indices, mirroring mt7996_rx_get_wcid().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90375", "url": "https://ubuntu.com/security/CVE-2026-90375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix non-AQL packet accounting for MLO stations __mt76_tx_queue_skb() overrides the wcid passed by the driver with sta->drv_priv, so the wcid might incorrectly be changed after TX, causing wcid->non_aql_packets to be counted on the wrong wcid. For example, on the AP side, if a station's setup link is the 5G link and the station uses 2G to transmit a frame, the value of non_aql_packets is increased on the 5G wcid but decreased on the 2G wcid. Once the inflated counter exceeds MT_MAX_NON_AQL_PKT, the TX scheduler permanently refuses to service the station. Drop the reassignment and account on the wcid used for transmission. This also records the actual wcid in the queue entry.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90376", "url": "https://ubuntu.com/security/CVE-2026-90376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix MLD ID in MAC TXD and HIF TXP Problem: MCU command timeout while the firmware state is normal, and the firmware keeps showing the error log \"ERROR!! NO PAUSE...\". Root cause: If the MLD_ID field in the TXD is neither the primary link id nor the secondary link id, it may lead to a firmware busy loop when the third link is in power saving mode. Remap frames directed to a third link to the primary link wcid. Since TX status events and txfree completions carry the wcid the firmware saw, use the remapped wcid for packet id tracking and non-AQL packet accounting as well, while the frame keeps its original link context for addressing, band and OMAC selection.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90377", "url": "https://ubuntu.com/security/CVE-2026-90377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix RX data queuing of RRO 3.0 For RRO 3.0, RX data released from a RRO data queue should be put to the indicator queue. The frames are processed and completed in the context of the indicator queue NAPI, which only polls skbs queued on the MT_RXQ_RRO_IND list; frames queued under the data queue id are left sitting on that list until the data queue NAPI happens to run, stalling and reordering RX data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90378", "url": "https://ubuntu.com/security/CVE-2026-90378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt792x: Fix memory leak in SDIO TX path When tx_prepare_skb() returns an error in the SDIO TX path, the skb is not freed, leading to a memory leak. This can occur when zero-length frames (such as WNM NULL frames) are dropped to prevent potential hardware TX hangs. Fix this by properly releasing the skb with ieee80211_tx_status_ext() when tx_prepare_skb() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90379", "url": "https://ubuntu.com/security/CVE-2026-90379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash When an AER error occurs and the bus is hung, the register reads return 0xFFFFFFFF, causing the DMA queue state to be corrupted and resulting in an invalid memory access when accessing q->desc[] or q->entry[]. Unable to handle kernel paging request at virtual address ffffffc01099eac0 pc : mt76_dma_add_buf+0x124/0x188 [mt76] lr : mt76_dma_rx_fill+0x11c/0x1d8 [mt76] sp : ffffffc016d9bbf0 x29: ffffffc016d9bc10 x28: 0000000000000000 x27: 0000000000000000 x26: ffffffb7855e50b8 x25: ffffffb80d04f000 x24: 0000000000000000 x23: 0000000000000ec0 x22: ffffffb796803648 x21: ffffffb796801f80 x20: ffffffb7968035f8 x19: 0000000000000ec0 x18: 0000000000000000 x17: 000000004ec00000 x16: 000000000ec00000 x15: ffffffc01099eac0 x14: 000000004ec00000 x13: 00000000ffc5a000 x12: ffffffc016d9bc32 x11: 00000000ffffffff x10: 0000000000000002 x9 : 0000000000000000 x8 : 000000000000b4ac x7 : 0000000000000a20 x6 : ffffffb6c1806400 x5 : 0000000000000000 x4 : ffffffb80d04f000 x3 : 0000000000000000 x2 : 0000000000000001 x1 : 000000000ec04000 x0 : ffffffb7968035f8 Call trace: mt76_dma_add_buf+0x124/0x188 [mt76 (HASH:1029 4)] mt76_dma_rx_reset+0xe8/0xfc [mt76 (HASH:1029 4)] mt7921_wpdma_reset+0x188/0x1b0 [mt7921e (HASH:ee48 5)] mt7921e_mac_reset+0x128/0x418 [mt7921e (HASH:ee48 5)] mt7921_mac_reset_work+0xac/0x1a8 [mt7921_common (HASH:f721 6)] process_one_work+0x188/0x514 worker_thread+0x12c/0x300 kthread+0x140/0x1fc ret_from_fork+0x10/0x30 Fix the invalid memory access by validating the DMA index read from the hardware before it is used as a queue index. An out-of-range value, such as the 0xFFFFFFFF returned while the bus is hung, is now clamped so it can no longer corrupt q->head or q->tail. In addition, check the bus_hung flag in mt7921_mac_reset_work() before attempting the reset sequence, reject MCU messages while the bus is hung, and install no-op bus operations when an unrecoverable AER error is detected, preventing further invalid hardware accesses. Due to hardware limitations - such as the lack of a connected hardware reset pin or the absence of host re-probe functionality - affected Wi-Fi devices may not fully recover to a normal operational state after certain errors, even with AER enabled.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90382", "url": "https://ubuntu.com/security/CVE-2026-90382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARN_ON_ONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when panic_on_warn is set. Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf (\"mt76x2: remove some harmless WARN_ONs in tx status and rx path\") did for the neighboring rx and tx status paths. Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90383", "url": "https://ubuntu.com/security/CVE-2026-90383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: sgi-gru: remove interrupt-context page-table walks The GRU TLB miss handler walks a process's page tables without holding page-table locks or a reference to the mapped page. It also uses a kernel page-table accessor on user page tables and supports only PMD-level large mappings on x86-64. Remove the direct walker. Send interrupt faults directly to user polling mode so the existing call-OS fallback retries them in process context. Remove the mmap-lock failure statistic that can no longer be incremented.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90385", "url": "https://ubuntu.com/security/CVE-2026-90385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid1: create serial pool adding rdev to array with serialize_policy=1 The following bug has been observed with kernel 7.1.3 after adding a new rdev to an existing RAID1 array with serialize_policy enabled: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 19639 Comm: ext4lazyinit Not tainted 7.1.3-1-default RIP: _raw_spin_lock_irqsave+0x27/0x50 CR2: 0000000000004960 Call Trace: wait_for_serialization+0xb9/0x260 [raid1] raid1_make_request+0x762/0xaff [raid1] md_handle_request+0x1c9/0x2e0 [md_mod] The raid1.c code calls wait_for_serialization() if the MD_SERIALIZE_POLICY is set, and wait_for_serialization assumes that rdev->serial is initialized. Normally this will be the case for arrays that have the serialize_policy sysfs attribute set to 1. But when a new rdev is added to an existing array in bind_rdev_to_array(), the condition at mddev_create_serial_pool() causes creation of rdev->serial to be skipped. Fix it.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90386", "url": "https://ubuntu.com/security/CVE-2026-90386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90387", "url": "https://ubuntu.com/security/CVE-2026-90387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: swiotlb: Preserve allocation virtual address for dynamic pools swiotlb_alloc_tlb() can allocate from the DMA atomic pool when a decrypted pool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP, the atomic pool is backed by remapped virtual addresses, which are not the same as the direct-map addresses returned by phys_to_virt(). swiotlb_init_io_tlb_pool() currently reconstructs the pool virtual address from the physical start address. For atomic-pool backed allocations this stores the wrong address in pool->vaddr. Later, swiotlb_free_tlb() passes that address to dma_free_from_pool(), which will fail to recognize the chunk Pass the virtual address returned by the allocation path into swiotlb_init_io_tlb_pool(), and store that address in pool->vaddr. This keeps the pool free path using the same virtual address as the allocator.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90388", "url": "https://ubuntu.com/security/CVE-2026-90388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Check atomic pool allocation result directly The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90389", "url": "https://ubuntu.com/security/CVE-2026-90389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: scope memalloc_noio to allocation critical sections Storing a memalloc_noio_save() token in mddev->noio_flags lets one task save the token and another task restore it. With concurrent suspend sysfs writes, task A can enter PF_MEMALLOC_NOIO, return to userspace still in that scope, and later task B can restore A's saved token. Avoid tying the token lifetime to mddev. Keep mddev_suspend() and mddev_resume() only responsible for array suspension, and enter PF_MEMALLOC_NOIO only in the MD paths that allocate memory after the array has been suspended. Restore the token before resuming the array. A reproducer repeatedly writes suspend_lo and suspend_hi from concurrent workers and checks each worker's /proc/self/stat flags before and after the sysfs write.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90390", "url": "https://ubuntu.com/security/CVE-2026-90390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/bitmap: resume array on backlog_store() error path backlog_store() suspends the array before checking whether a write-mostly device exists. If no such device exists, the error path only unlocks reconfig_mutex and leaves the array suspended, blocking subsequent I/O. Use mddev_unlock_and_resume() to release both states.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90391", "url": "https://ubuntu.com/security/CVE-2026-90391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone dmirror_fault() is called from the dmirror_read() and dmirror_write() retry loops after dmirror_do_read() or dmirror_do_write() finds a missing device page table entry. If the mirrored mm has already exited, mmget_not_zero() fails. The current code returns 0 in that case, which tells the caller that faulting succeeded even though no page was faulted and no device page table entry was installed. The caller then retries the same address, hits -ENOENT again, and can loop forever without making progress. Return -EFAULT instead, so the ioctl fails when the mirrored mm is no longer faultable.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90392", "url": "https://ubuntu.com/security/CVE-2026-90392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF when reading bpf link info In bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is accessed without holding any locks. If the prog is concurrently replaced via bpf_link_update, the old prog can be freed, leading to a potential UAF issue. Fix this by accessing link->prog under RCU protection to safely fetch the pointer and guarantee its lifetime while reading its fields.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90393", "url": "https://ubuntu.com/security/CVE-2026-90393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF in bpf_netns_link_update_prog In bpf_netns_link_update_prog, the checks for old_prog and prog type are currently performed locklessly before acquiring netns_bpf_mutex. This creates a race condition that can lead to a UAF issue. If two threads concurrently execute BPF_LINK_UPDATE on the same netns link, the following execution path can trigger a UAF: CPU0 CPU1 bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) return -EPERM; bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) ... old_prog = xchg(&link->prog, new_prog); bpf_prog_put(old_prog); if (new_prog->type != link->prog->type) <-- trigger UAF Fix this by moving the old_prog and prog->type checks inside the netns_bpf_mutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90394", "url": "https://ubuntu.com/security/CVE-2026-90394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sc2731_charger: cancel work on remove The USB notifier and initial charger detection can schedule info->work. The remove path unregisters the notifier, but does not cancel queued or running work before the devm-allocated driver data is released. Set the platform drvdata used by remove, then cancel the work after unregistering the notifier. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90395", "url": "https://ubuntu.com/security/CVE-2026-90395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: isp1704_charger: cancel work on remove The USB notifier and initial VBUS detection can schedule isp->work. The remove path unregisters the notifier and power supply, but does not wait for queued or running work before tearing down the power supply state. Cancel the work after unregistering the notifier. Do this before unregistering the power supply. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90396", "url": "https://ubuntu.com/security/CVE-2026-90396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix dio leak on metadata mapping error A failed integrity mapping holds a dio reference, so we need to go through the full bio ending in case there were previously submitted bio's in the sequence.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90397", "url": "https://ubuntu.com/security/CVE-2026-90397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published In qcom_scm_probe(), devm_request_threaded_irq() is called before smp_store_release(&__scm, scm). Two paths can dereference __scm before it is published, both causing a NULL pointer dereference. The IRQ handler receives scm via its data argument but passes only wq_ctx to qcom_scm_waitq_wakeup() and qcom_scm_get_completion(), which then dereference __scm directly. Thread scm through both functions so the IRQ handler path never touches __scm. Non-atomic SMC calls made during probe (e.g. from qcom_tzmem_init via qcom_scm_shm_bridge_enable) can return WAITQ_SLEEP, causing qcom_scm_wait_for_wq_completion() to run before __scm is published and dereference it. Add platform_set_drvdata(pdev, scm) early in probe and change qcom_scm_wait_for_wq_completion() to take the device pointer and use dev_get_drvdata() to reach scm, removing any dependency on __scm.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90398", "url": "https://ubuntu.com/security/CVE-2026-90398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix stride mismatch in mac_phy_caps_parse() Currently, in ath11k_wmi_tlv_mac_phy_caps_parse(), kcalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct wmi_mac_phy_capabilities)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation. The reader in ath11k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride. Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides. Compile tested only.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90399", "url": "https://ubuntu.com/security/CVE-2026-90399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix stride mismatch in mac_phy_caps_parse() Currently, in ath12k_wmi_mac_phy_caps_parse(), kzalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct ath12k_wmi_mac_phy_caps_params)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation. The reader in ath12k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride. Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90400", "url": "https://ubuntu.com/security/CVE-2026-90400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: recheck spare changes before starting sync remove_spares() and remove_and_add_spares() modify the array's rdev configuration. These operations are only safe after the array has been suspended. md_start_sync() checks whether spare configuration changes are needed before taking reconfig_mutex. However, the rdev state can change before the mutex is acquired, so the initial check can become stale. In that case, md_choose_sync_action() may remove or replace rdevs while normal I/O is still accessing them. The race can occur as follows: raid10d Worker Normal IO ____________ _______________________ ______________________ raid10_write_request() wait_blocked_dev() set Blocked set Faulty Skip Faulty rdev rrdev->nr_pending++ .repl_bio = bio removeable_rdev = false . array not suspended . lock mddev goto err_handle lock mddev (wait) . update sb . clear Blocked . . unlock mddev . lock mddev (acquires) remove_spares() removeable_rdev = true raid10_remove_disk() rdev = replacement replacement = NULL rdev_dec_pending(NULL) unlock mddev (NULL)->nr_pending-- In this case, rdev_dec_pending() is called with a NULL pointer, resulting in a NULL pointer dereference when attempting to decrement nr_pending. Fix this by suspending the array when spare configuration changes are needed, including for non-read-write arrays, and checking again after taking reconfig_mutex. If the array was not already suspended and a change is now needed, release the mutex, suspend the array, and reacquire the mutex before continuing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90402", "url": "https://ubuntu.com/security/CVE-2026-90402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Fix controller cleanup on EDL sysfs failure mhi_register_controller() adds the controller device before creating the optional trigger_edl sysfs file. If sysfs_create_file() fails, the error path only drops the device reference and leaves the device registered. Hence, call device_del() in the error path before put_device().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90403", "url": "https://ubuntu.com/security/CVE-2026-90403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix error path in rtl_pci_probe() In the last error path in rtl_pci_probe(), the cleanup functions are skipped due to a wrong goto label. Moreover, the successful call to rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to be reverted. Fix this issue by updating the labels and adding the relevant cleanup functions to the last error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90404", "url": "https://ubuntu.com/security/CVE-2026-90404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_debugfs: Unregister panic notifier cros_ec_debugfs_probe() registers notifier_panic with the EC panic notifier chain. The remove path tears down debugfs and the console log, but leaves the notifier registered. A later panic notification can call back into the removed instance and queue work that accesses released data. Unregister the panic notifier before tearing down the debugfs and console log state. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90406", "url": "https://ubuntu.com/security/CVE-2026-90406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: qcom: iris: handle runtime PM resume failure in core deinit Check the return value of pm_runtime_resume_and_get() in iris_core_deinit(). If runtime PM resume fails, skip hardware power-off operations but still perform software teardown and state transition. Also skip the corresponding pm_runtime_put_sync() call to avoid unbalanced runtime PM references.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90407", "url": "https://ubuntu.com/security/CVE-2026-90407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix overreads in ath11k_wmi_process_csa_switch_count_event() There is no policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, so the parse infrastructure does not enforce a minimum length for the event struct. Additionally, the num_vdevs field is taken directly from firmware and used as a loop bound over the vdev_ids array without checking that it fits within the TLV payload. Either condition can cause an out-of-bounds read. Add a TLV policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT so the parse infrastructure enforces a minimum length for the fixed-size event struct. Add a helper ath11k_wmi_tlv_data_len() to recover the payload length of a parsed TLV from the header preceding its data pointer. Use it in ath11k_wmi_process_csa_switch_count_event() to bound num_vdevs before the loop. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90410", "url": "https://ubuntu.com/security/CVE-2026-90410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: davinci: switch to managed controller allocation The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_threaded_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded davinci_spi devdata, which is the IRQ handler's dev_id. The devm_request_threaded_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach davinci_spi_irq() and dereference already-freed memory. Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns. The clock is acquired with devm_clk_get_enabled(), which is registered after the IRQ and thus released before it by the devres LIFO order. Drain the interrupt explicitly with devm_free_irq() before disabling the controller so that a late interrupt cannot access the registers of a clock-gated controller. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90411", "url": "https://ubuntu.com/security/CVE-2026-90411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request __nvme_fc_init_request() maps cmd_iu and then rsp_iu for DMA. If the rsp_iu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmd_iu unmapped and still marked the op as FCPOP_STATE_IDLE before returning. Since blk-mq does not call .exit_request() when .init_request() fails, the cmd_iu mapping is leaked for every op whose rsp_iu mapping fails. Jump to an error path on rsp_iu mapping failure that unmaps cmd_iu and returns the error without marking the op idle, so it stays in the FCPOP_STATE_UNINIT state set by the initial memset().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90413", "url": "https://ubuntu.com/security/CVE-2026-90413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject login PDUs declaring more data than was received isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(), \tpayload_length = ntoh24(login_req->dlength); \ttmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90414", "url": "https://ubuntu.com/security/CVE-2026-90414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject PDUs declaring more data than was received isert_recv_done() hands each received PDU to the opcode handlers without ever looking at wc->byte_len, the number of bytes the HCA actually placed in the receive descriptor. The handlers then copy that many bytes - the data-segment length the initiator declared in the BHS (ntoh24(hdr->dlength), via the derived unsol_data_len / imm_data_len) - out of the fixed-size descriptor: isert_handle_iscsi_dataout(): sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc), unsol_data_len); isert_handle_scsi_cmd(): sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents, isert_get_data(rx_desc), imm_data_len); Because the declared length is never checked against wc->byte_len, an initiator can declare a data segment larger than the bytes it actually sent (and larger than the descriptor) and cause an out-of-bounds read of the receive buffer. Nothing upstream of isert closes this door: - __iscsit_check_dataout_hdr() bounds the inbound payload against conn_ops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter, used here for the inbound check. - iscsi_set_connection_parameters() sets ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in iscsi_check_acceptor_state(), so the value the initiator declares is adopted verbatim (type range 512..16777215). The initiator effectively raises its own ceiling. - isert never clamps the negotiated value to its own fixed receive descriptor (ISER_RX_SIZE, 9216 bytes), so the target core's bound and the descriptor size are unrelated. The imm_data_len == data_len path is more than an over-read: it aliases the receive descriptor via sg_set_buf() and passes it to the backend as the data source for the SCSI WRITE, so an over-declared length causes heap contents past the descriptor to be written through the backend to the backing store. The backend is the victim of the oversized scatterlist isert hands it, not the cause; no read-back of the written bytes was demonstrated. Trigger: after login completes (full feature phase), an initiator that has declared a large TargetRecvDataSegmentLength and a FirstBurstLength that permits unsolicited/immediate data sends a PDU whose declared data-segment length exceeds what was received. With KASAN: BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ib_cq_poll_work Call Trace: sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 isert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout() (ib_isert.c:1160), inlined through isert_rx_opcode(). Validate wc->byte_len against the framing in isert_recv_done() before the PDU reaches any handler, and reinstate the connection if it is short. Because the test compares without subtracting the header length, it also rejects PDUs shorter than the iSER and iSCSI headers, which would otherwise be parsed out of stale descriptor contents. The login handler rejects PDUs shorter than ISER_HEADERS_LEN (commit 29e7b925ae6d (\"IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN\")) but does not bound the declared length either; that is fixed in the next patch. The data handlers had no length check at all. isert reads the data segment from a fixed offset: isert_get_data() returns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for an AHS. The bytes the handlers touch are therefore exactly [ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum against wc->byte_len bounds precisely the region that is read. An AHS term would only make the test stricter without bounding anything furth ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90415", "url": "https://ubuntu.com/security/CVE-2026-90415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: free STAG index when TPT entry write fails write_tpt_entry() allocates a new STAG index with c4iw_get_resource() and bumps stats.stag.cur before programming the entry. When write_adapter_mem() fails, it returns the error without releasing the index or reversing the statistic. No MR is inserted into rhp->mrs, so deregistration never reclaims it, leaking the index until device teardown. Record whether this call allocated the index and, on a failed write, return it to tpt_table and decrement stats.stag.cur. Key the rollback on both the write error and that flag, not the error alone: a non-reset update carries a caller-owned STAG that this call did not allocate and must not free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90416", "url": "https://ubuntu.com/security/CVE-2026-90416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs get_param() reads a congestion parameter as a u32 but formats it with the signed \"%d\" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as \"-2147483648\\n\" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with \"%u\" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90418", "url": "https://ubuntu.com/security/CVE-2026-90418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix BUG in nilfs_copy_dirty_pages() on dirty state mismatch Syzbot reported a kernel BUG triggered within nilfs_copy_dirty_pages(), which copies dirty DAT file folios/pages to its shadow page cache. The BUG occurs when a retrieved dirty folio/page unexpectedly loses its 'dirty' status. This issue arises because, since the commit referenced below, the 'dirty' flag of a folio/page can be cleared asynchronously after the filesystem detects metadata corruption and transitions to read-only mode. Resolve the issue by returning an -EROFS error if the filesystem has transitioned to read-only mode. Also change the behavior to issue a kernel warning only once instead of triggering a kernel BUG when this unexpected 'dirty' state is detected while the filesystem is not in read-only mode.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90419", "url": "https://ubuntu.com/security/CVE-2026-90419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent out-of-bounds read in super root block parsing super-root inode metadata size is trusted before nilfs_read_inode_common(). Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfs_read_inode_common() read past the end of the super-root block. [ryusuke: clarify the commit title]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90420", "url": "https://ubuntu.com/security/CVE-2026-90420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix infinite loop in nilfs_clean_segments() syzbot reported a hung task in nilfs_transaction_begin(). This occurs because the cleaner ioctl falls into an infinite loop if nilfs_segctor_construct() repeatedly returns -EROFS (e.g. the device is remounted as read-only after an I/O error). Currently in nilfs_clean_segments(), if err is non-zero, it logs the error and sleeps but doesn't abort when it encounters a terminal error like -EROFS. This causes the thread to loop forever. Fix this by breaking out of the loop if nilfs_segctor_construct() returns -EROFS. This matches the behaviour in nilfs_segctor_write_out(), which also handles -EROFS.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90422", "url": "https://ubuntu.com/security/CVE-2026-90422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: pllfh: Fix IO remapping leak in register_pllfhs error path When mtk_clk_register_pllfhs function fails to register a PLL, it unregisters all PLLs and cleans up itself in its error path before returning, so the function callers don't need to do it. But contrary to mtk_clk_unregister_pllfhs function, that does almost the same sequence, it does not free the IO memory mapped on fhctl node, leading to a leak. Fix this leak by factorizing the cleanup sequence in a new private function and use it both mtk_clk_register_pllfhs and mtk_clk_unregister_pllfhs functions. Also, change the loop index start value to avoid the -1 operation on index at each loop.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90423", "url": "https://ubuntu.com/security/CVE-2026-90423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix UAF in ODP init error-handling path rxe_odp_mr_init_user() stores &umem_odp->umem in mr->umem before calling rxe_odp_init_pages(). If rxe_odp_init_pages() fails, rxe_odp_mr_init_user() releases umem_odp and returns an error. rxe_reg_user_mr() then unwinds the error through rxe_cleanup(), rxe_mr_cleanup(), ib_umem_release(mr->umem). There is an IS_ERR_OR_NULL(umem) check at the start of ib_umem_release(). But since mr->umem is NOT reset to NULL in the error handling path of rxe_odp_mr_init_user(), the check passes and it reads already-freed fields like umem->is_dmabuf, causing UAF. Fix the UAF by clearing mr->umem after releasing the failed ODP umem so the MR cleanup path does not release it again.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90424", "url": "https://ubuntu.com/security/CVE-2026-90424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Fix VINTF0 leak on the init-failure path tegra241_cmdqv_init_structures() allocates VINTF0 with kzalloc_obj(), inits it, and preallocates its logical VCMDQs. Two of its error paths leak. When tegra241_cmdqv_init_vintf() fails it returns before VINTF0 reaches the cmdqv->vintfs[] array, so the devres unwind on probe failure cannot reach it; free it directly there. A later VCMDQ preallocation failure instead leaves VINTF0 published, and so this time the unwind does reach tegra241_cmdqv_remove_vintf(), which then frees it from vintf->hyp_own. But tegra241_vintf_hw_init() sets that flag only afterward, from a HW read-back, so the still-uninited VINTF0 reads as guest-owned and leaks, with mutex_destroy() and ida_destroy() run on fields it never set up. Decide ownership from vintf->idx instead, the index assigned when its id is allocated: idx 0 is the kernel-owned VINTF0, while idx >= 1 marks a guest VINTF. So the in-kernel free decision in tegra241_cmdqv_remove_vintf() and tegra241_vintf_free_lvcmdq() now keys on idx too, and hyp_own stays a pure HW-readback state.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90425", "url": "https://ubuntu.com/security/CVE-2026-90425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Require exactly one Stream ID for a vSID tegra241_vintf_init_vsid() maps a guest vSID to a single physical Stream ID taken from master->streams[0], and only warns when the device does not have exactly one stream. A device with several streams gets only its first one mapped, so a guest vSID invalidation cannot reach the others' ATC and IOTLB entries; a device with none makes master->streams a ZERO_SIZE_PTR, read out of bounds. Reject the mapping with -EOPNOTSUPP if master->num_streams is not one.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90426", "url": "https://ubuntu.com/security/CVE-2026-90426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Free the error IRQ before tearing down VINTFs tegra241_cmdqv_remove() tears each VINTF down first, then calls free_irq(). Tearing a VINTF down frees vintf0 and clears cmdqv->vintfs[0]. An error in that window makes tegra241_cmdqv_isr() read the stale slot and hand it to tegra241_vintf0_handle_error(), which dereferences a NULL or freed pointer. Free the IRQ before tearing the VINTFs down. free_irq() waits for in-flight handlers to finish and blocks new ones, so no ISR can observe a VINTF as it is torn down. Note: a user-owned VINTF (viommu) could outlive this teardown, which unmaps cmdqv->base and frees cmdqv->vintfs, so a later viommu close then touches freed memory. This is neither introduced nor fixed here: a physical IOMMU is not a pluggable device, so iommufd by design holds no reference on the one behind a viommu, and this teardown is not expected while that viommu is still alive.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90428", "url": "https://ubuntu.com/security/CVE-2026-90428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Don't run the error ISR before probe sets up vintfs __tegra241_cmdqv_probe() requests the error IRQ before it has allocated the cmdqv->vintfs array and set cmdqv->num_vintfs. A CMDQV left enabled with a latched error across a kexec fires the IRQ as soon as it is requested, and tegra241_cmdqv_isr() then walks the uninitialized cmdqv->vintfs array. Request the IRQ only after cmdqv->vintfs is allocated and zeroed, so that a latched interrupt firing early runs the ISR against a valid array of NULL slots that it safely skips.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90429", "url": "https://ubuntu.com/security/CVE-2026-90429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Synchronize the error ISR against VINTF (de)init A user VINTF is torn down by tegra241_cmdqv_deinit_vintf(), which runs from the destroy callback and from the init-failure unwind in the alloc handler. It clears the cmdqv->vintfs[] slot and lets the iommufd core free it, but nothing serializes that against the error interrupt: tegra241_cmdqv_isr() reads cmdqv->vintfs[idx] and dereferences the vintf. A concurrent error can make the ISR read a slot mid-clear (a NULL deref) or use a vintf which is about to be freed (a use-after-free). deinit_vintf() also returns idx to the IDA before clearing the slot, so a concurrent create that reuses idx can publish its new vintf into the slot, only for this teardown to erase it again with the stale NULL store. On the other end, tegra241_cmdqv_init_vintf() publishes a new vintf with a plain store to the cmdqv->vintfs[] slot, and the ISR dereferences fields of a published vintf such as vintf->base. A plain store gives no ordering on a weakly-ordered CPU, and a stale VINTF_ERR_MAP bit on a reused idx can make the ISR pick a vintf the moment it is published, before its fields are set or tegra241_vintf_hw_init() runs. The cmdqv->vintfs[0] slot stays NULL until tegra241_cmdqv_init_structures() first creates VINTF0, so the slot 0 read needs the same NULL check. Publish every slot with an smp_store_release(), and read each slot in the ISR with an smp_load_acquire() under a NULL check, so the ISR always sees a fully built vintf or NULL. Also make deinit_vintf() clear the slot, and synchronize_irq() prior to returning idx to the IDA, so no vintf is freed under a running handler and no reused idx is clobbered.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90430", "url": "https://ubuntu.com/security/CVE-2026-90430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Publish an LVCMDQ only after it is fully initialized tegra241_vintf_init_lvcmdq() stores the freshly allocated vcmdq pointer to the vintf->lvcmdqs[] array, before tegra241_vcmdq_alloc_smmu_cmdq() builds the vcmdq->cmdq. The error ISR dereferences that cmdq, so a latched LVCMDQ error (e.g. one inherited across a kexec) firing in this window would make tegra241_vintf0_handle_error() pass the still-zeroed arm_smmu_cmdq down to __arm_smmu_cmdq_skip_err(), dereferencing NULL queue register pointers. Drop the store from tegra241_vintf_init_lvcmdq() and publish the vcmdq at the end of the allocation instead, with an smp_store_release() that pairs with an smp_load_acquire() in the ISR, which can see a fully built LVCMDQ or NULL. The user-owned LVCMDQ allocation moves accordingly, publishing the vcmdq once tegra241_vcmdq_hw_init_user() succeeds, using a plain store since a user VINTF's lvcmdqs[] has no lockless reader -- the error ISR only walks the VINTF0 array.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89782", "url": "https://ubuntu.com/security/CVE-2026-89782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject restart table growth beyond U16_MAX entries During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index. alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl(): \trt = init_rsttbl(esize, used + add); used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image. BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90431", "url": "https://ubuntu.com/security/CVE-2026-90431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: Prevent crash handling to race with rproc_del() There's no synchronization between rproc_crash_handler_work() and rproc_del(), as such it's possible for a driver to be removed while crash-handler work is scheduled, or even executing - resulting in use-after-free issues. To avoid this the scheduled work need to be cancelled and synchronized against before the removal proceeds. In order to ensure that this doesn't race with the reporting, and thereby scheduling new work, a \"deleting\" flag is introduced. This is similar to the RPROC_DELETE state that was introduced to ensure that \"start\" didn't race with rproc_del(), but the existing mechanism can not be used as it's valid to call rproc_report_crash() in atomic context - and the \"state\" is protected by a mutex. In the event that work is cancelled the pm_stay_awake() is left unbalanced and need to be unrolled. The blocking and cancelling of crash-handler work prior to the actual rproc_shutdown() call does have the explicit side-effect that crashes resulting from the shutdown process will not enter the crash-handling path, and as such will not generate devcoredumps etc. Due to the existing mutual exclusion between these code paths there's no concrete reduction in functionality, but further work would be needed to handle this case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90433", "url": "https://ubuntu.com/security/CVE-2026-90433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: oc-tiny: switch to managed controller allocation The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded driver-private devdata, which is the IRQ handler's dev_id. The devm_request_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach tiny_spi_irq() and dereference already-freed memory (e.g. hw->base). Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90434", "url": "https://ubuntu.com/security/CVE-2026-90434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: release zisofs block pointer buffer head zisofs_fill_pages() reads the compressed block pointer table. The error paths release the current buffer_head, the loop also releases the old buffer_head when it advances. However, the success path leaves the last buffer_head referenced. Release it before returning success.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90435", "url": "https://ubuntu.com/security/CVE-2026-90435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix integer overflow of user QP buffer size set_user_buf_size() computes the QP buffer size by left-shifting the user-supplied rq.wqe_cnt and rq.wqe_shift values as signed integers. A sufficiently large rq.wqe_cnt causes signed integer overflow, which is undefined behavior, and yields a small or negative buf_size, causing ib_umem_get() to map a buffer smaller than the hardware will actually write into. Replace the shifts and addition with check_shl_overflow() and check_add_overflow(), rejecting invalid user inputs. Moreover, guard the identical shift computing qp->sq.offset in _create_user_qp() before set_user_buf_size() is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92476", "url": "https://ubuntu.com/security/CVE-2026-92476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Initialize completion before requesting IRQ kmb_ocs_aes_probe() requests the device IRQ before initializing irq_completion. Once the handler is registered it can run immediately, and ocs_aes_irq_handler() unconditionally calls complete(). An interrupt in this window would therefore use an uninitialized completion. Initialize the completion before requesting the IRQ, as the sibling OCS HCU and ECC drivers already do.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92477", "url": "https://ubuntu.com/security/CVE-2026-92477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: debugfs: Reserve space for a string terminator ufs_saved_err_write() copies user input into a zero-initialized stack buffer and passes it to kstrtoint(). A write that fills the entire buffer overwrites its only terminator. Reject an input whose length leaves no room for the trailing NUL.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92481", "url": "https://ubuntu.com/security/CVE-2026-92481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: free EINT resources on unbind mtk_eint_do_init() creates an IRQ domain, populates it with a mapping for every EINT line and installs a chained handler on the parent interrupt, but none of these are ever released. This was harmless while the drivers were built-in, but now that they can be built as modules and unbound/rmmod'd it leaves behind a dangling IRQ domain, interrupt mappings whose chip data points at freed memory, and a chained handler that keeps firing into that freed data. The plain allocations in mtk_eint_do_init() already use the device-managed devm_*() helpers, so tear the remaining resources down the same way: register a devm action that detaches the chained handler, waits for any in-flight handler to finish, disposes of the per-line mappings and removes the IRQ domain. This mirrors the device-managed lifecycle adopted for the GPIO chip and keeps the whole EINT setup self-cleaning on unbind.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92484", "url": "https://ubuntu.com/security/CVE-2026-92484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fix use-after-free in find_pos_and_ways() error path The error path releases its reference to a switch decoder before logging an error that includes the decoder name. If the released reference is the last one, the decoder can be freed before the error message accesses its name. Drop the reference after the error is reported.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92486", "url": "https://ubuntu.com/security/CVE-2026-92486", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix CFI mismatch in task work callback BPF subprograms use the bpf_callback_t ABI, but task work invokes the callback through a three-argument function pointer. This trips kCFI. Store and invoke the callback as bpf_callback_t.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89785", "url": "https://ubuntu.com/security/CVE-2026-89785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92488", "url": "https://ubuntu.com/security/CVE-2026-92488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: complete object teardown when the destroy command fails erdma_destroy_qp(), erdma_destroy_cq(), erdma_dereg_mr(), and erdma_destroy_ah() returned early when erdma_post_cmd_wait() failed, leaking the queue buffers, MTTs, doorbells and the STAG, QPN, CQN and AHN identifiers. A command timeout clears ERDMA_CMDQ_STATE_OK_BIT and permanently disables the command queue, so no retry can succeed; the RDMA core keeps the object after a failed destructor and forced uverbs cleanup then nulls the pointers, making the resources unreachable. Warn on failure but release every software-owned resource and return success, since during terminal destruction the hardware command result is only diagnostic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92489", "url": "https://ubuntu.com/security/CVE-2026-92489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix skb double-free in xfrm_dev_direct_output() A return value other than 1 from local_out() means that the skb has been consumed or its ownership was transferred. xfrm_dev_direct_output() nevertheless frees the skb on this path, causing a double-free when netfilter drops the packet and invalidating any other owner. Return the local_out() result directly, matching the ownership handling in xfrm_output_resume().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92490", "url": "https://ubuntu.com/security/CVE-2026-92490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unrequest devices if driver registration fails scmi_driver_register() requests protocol devices before registering the driver. If driver_register() fails, those requests remain in the global IDR and retain pointers to the module's ID table. Once the failed module load releases that storage, later request matching or SCMI device creation can dereference the stale pointers. Unrequest the complete protocol table before returning the registration failure. At this point table registration succeeded, so every entry is owned by the current registration attempt.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92491", "url": "https://ubuntu.com/security/CVE-2026-92491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Roll back partial protocol table registration scmi_protocol_table_register() can leave earlier requests registered when a later entry in the same ID table fails. Each request retains a pointer to the driver's ID table, so a failed module load can leave a dangling pointer after the module storage is released. Unrequest only the successfully registered prefix, in reverse order, before returning the failure. Leave the failed entry and the remaining entries untouched because matching requests can be owned by another driver.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92493", "url": "https://ubuntu.com/security/CVE-2026-92493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate-ut: Skip tests when amd-pstate driver is not active The crash issue may occur when modprobe amd_pstate_ut on intel platform. amd_pstate_ut: 1 amd_pstate_ut_acpi_cpc_valid success! amd_pstate_ut: 2 amd_pstate_ut_check_enabled success! BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 20300 Comm: modprobe Kdump: loaded Tainted: G O 6.6.0-0010.rc1.ctl4.x86_64 #1 Hardware name: FiberHome R2200 V5/Xeon Boards, BIOS 3.1a 02/24/2020 RIP: 0010:amd_pstate_ut_check_perf+0x141/0x280 [amd_pstate_ut] Call Trace: amd_pstate_ut_init+0x1b/0xff0 [amd_pstate_ut] ? __pfx_amd_pstate_ut_init+0x10/0x10 [amd_pstate_ut] do_one_initcall+0x42/0x2e0 ? kmalloc_trace+0x26/0x90 do_init_module+0x60/0x240 __se_sys_init_module+0x185/0x1c0 do_syscall_64+0x62/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e Add state detection to amd pstate driver to prevent amd_pstate_ut driver from testing on non-AMD platforms. (ML: adjust title)", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89787", "url": "https://ubuntu.com/security/CVE-2026-89787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check dir entry fits before reading the hash trailer in ext4_search_dir() For casefolded encrypted directories ext4 stores an 8-byte hash trailer after the name (EXT4_DIRENT_HASHES()), at an offset derived from de->name_len. On the sb_no_casefold_compat_fallback() path ext4_match() reads that trailer, but ext4_search_dir()'s by-hand pre-check only tests de->name + de->name_len <= dlimit, which proves the name fits, not the rounded trailer. A crafted entry whose name ends at the block boundary passes the check while EXT4_DIRENT_HASHES(de) lands past the block end, so ext4_match() reads out of bounds on an ordinary lookup. KASAN reports it as a use-after-free when the page after the directory block holds a freed object: BUG: KASAN: use-after-free in ext4_match (fs/ext4/namei.c:1435) Read of size 4 at addr ffff888010458000 by task exploit Call Trace: ext4_match (fs/ext4/namei.c:1435) ext4_search_dir (fs/ext4/namei.c:1470) __ext4_find_entry (fs/ext4/namei.c:1268 fs/ext4/namei.c:1632) ext4_lookup (fs/ext4/namei.c:1703 fs/ext4/namei.c:1769) ... filename_lookup (fs/namei.c:2842) vfs_statx (fs/stat.c:353) __do_sys_newfstatat (fs/stat.c:538) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Require, for hash-in-dirent directories, that the whole entry including the rounded trailer fits before calling ext4_match(). This is the same bound ext4_check_dir_entry() already enforces via ext4_dir_rec_len(), so no well-formed entry is rejected. The other caller, ext4_find_dest_de(), runs ext4_check_dir_entry() first and is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92494", "url": "https://ubuntu.com/security/CVE-2026-92494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix buffer_head leak in ext4_init_orphan_info ext4_init_orphan_info() reads orphan file blocks with ext4_bread() and stores the returned buffer_head in oi->of_binfo[i].ob_bh. If ext4_bread() succeeds but the orphan block magic or checksum validation fails, the function jumps to out_free. However, the old out_free loop starts releasing buffers from i - 1, so the current buffer_head at index i is skipped. This leaks the buffer_head reference obtained by ext4_bread() on the bad magic and bad checksum error paths. Fix this by tracking the number of successfully read buffer_heads and releasing exactly those buffer_heads on the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92495", "url": "https://ubuntu.com/security/CVE-2026-92495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Clear VM_MAYWRITE on DBR/toggle page mmap bnxt_re_mmap() rejects VM_WRITE for the DBR_PAGE and TOGGLE_PAGE mmap flags, but a read-only mapping can still retain VM_MAYWRITE. nd later be upgraded with mprotect(PROT_WRITE). This can bypass the write check that only runs at mmap time. Clear VM_MAYWRITE before vm_insert_page() in the shared DBR/toggle-page branch, matching the existing policy that userspace writes are not expected for these pages.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92496", "url": "https://ubuntu.com/security/CVE-2026-92496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx() Currently, in ath11k_wmi_tlv_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Add an upfront length check before dereferencing skb->data as a wmi_cmd_hdr. The check is placed before the trace_ath11k_wmi_event() call to preserve the existing trace semantics (tracing the full raw WMI event including the header), unlike the analogous ath12k fix which could use skb_pull_data() directly. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92497", "url": "https://ubuntu.com/security/CVE-2026-92497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Avoid buffer overread in ath12k_wmi_op_rx() Currently, in ath12k_wmi_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Update the logic to verify the buffer contains at least enough data to hold a wmi_cmd_hdr before reading from the buffer. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92498", "url": "https://ubuntu.com/security/CVE-2026-92498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: avoid buffer overreads in WMI event handlers The following WMI event handlers currently read from the event buffer without first verifying that the message was large enough to hold the expected event: ath6kl_wmi_scan_complete_rx() ath6kl_wmi_addba_req_event_rx() ath6kl_wmi_delba_req_event_rx() Add length checks to prevent overread.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92499", "url": "https://ubuntu.com/security/CVE-2026-92499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: validate readdir offset before accessing dirent A corrupted directory can trigger the following KASAN report when ext4_readdir() resumes from an invalid position: BUG: KASAN: use-after-free in __ext4_check_dir_entry+0x5ef/0x820 Read of size 2 at addr ffff88810a646000 by task repro_linear/509 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 kasan_report+0xce/0x100 __ext4_check_dir_entry+0x5ef/0x820 ext4_readdir+0xcde/0x2b70 iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x12b/0x220 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f KASAN reports use-after-free because the out-of-bounds access lands in an adjacent freed page. The directory buffer itself is still referenced. ext4_dir_llseek() invalidates the directory cookie so that ext4_readdir() rescans directory entries from the start of the block. The rescan checks only the lower bound of rec_len before advancing. A corrupted rec_len can therefore place the offset where the block has insufficient space for a complete directory entry. The rescan itself may dereference that truncated entry, or the main loop may pass it to __ext4_check_dir_entry(). The latter reads de->rec_len before validating the range. For example: block offset 0 4092 4096 |---- de1.rec_len = 4092 -----|----| de2.inode | de2.rec_len ^ OOB, reported as UAF de2 starts at offset 4092 in this 4 KiB block. Its four-byte inode fits in the block, but its rec_len starts at offset 4096 and crosses the boundary. The minimum safe length is inode-dependent. Encrypted and casefolded directory entries need eight additional hash bytes, while a valid metadata checksum tail is only 12 bytes. Cache the metadata checksum feature state and derive the minimum directory entry length from the on-disk format. Use it to bound both the rescan and the offset passed to the main loop. Report an offset in a truncated block tail and skip the remainder of the block, while continuing to accept an offset exactly at the block boundary.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92500", "url": "https://ubuntu.com/security/CVE-2026-92500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: use fsdata to track inline data write state and fix race Instead of checking the live inode state (ext4_has_inline_data(inode) and ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) in the write_end handlers, use the fsdata parameter of the address space operations to explicitly pass down the state in which write_begin prepared the write. A concurrent thread (such as ext4_page_mkwrite()) can convert the inline data to an extent between write_begin and write_end. If this happens, the write_end handlers would previously miss the inline write_end path and fall through to extent-based write_end logic. However, since block buffers were never allocated in write_begin, this resulted in NULL pointer dereferences or data loss because folio_buffers(folio) was NULL. Define EXT4_WRITE_DATA_INLINE (4) as a bit flag (Bit 2), treating fsdata as bitwise flags rather than mutually exclusive enums to keep states of the write path independent. Communicate this state via fsdata: 1) ext4_write_begin() and ext4_da_write_begin() set the EXT4_WRITE_DATA_INLINE bit in *fsdata via bitwise OR when an inline write is successfully prepared. 2) On entry, ext4_write_begin() clears the EXT4_WRITE_DATA_INLINE bit to safely handle VFS retries (where generic_perform_write() bypasses the fsdata initialization on its retry jump). 3) The write_end handlers perform a bitwise AND to check if the EXT4_WRITE_DATA_INLINE bit is set and invoke the inline write_end helper accordingly. Furthermore, during a buffered write, ext4_write_inline_data_end() acquires the xattr lock after preparing the write. If a concurrent page fault (ext4_page_mkwrite()) converts the inline data to an extent after the write_end handlers check the state but before ext4_write_inline_data_end() acquires the xattr write lock, the subsequent check will trigger a kernel panic via BUG_ON(!ext4_has_inline_data(inode)). To keep git history working and bisectability clean, replace the BUG_ON check in ext4_write_inline_data_end() with a graceful error- handling retry path in this same commit. If the inline data is cleared after locking the xattr, we safely release all resources (releasing iloc.bh, unlocking/putting the folio, stopping the active journal transaction handle) and return 0 (VFS retry) to let the generic write path retry the operation safely.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92501", "url": "https://ubuntu.com/security/CVE-2026-92501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drain in-flight DIO before buffered write fallback generic/746 started failing intermittently on ext3 (no-extent inodes). The test triggers 'Page cache invalidation failure on direct I/O' warnings and subsequent fsync returns -EIO. Adding a 50ms delay between ext4_buffered_write_iter() and filemap_write_and_wait_range() in ext4_dio_write_iter() makes the race almost always reproducible. On no-extent inodes, DIO writes to holes cannot use unwritten extents, so ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0. The iomap layer then returns -ENOTBLK, causing fallback to buffered I/O. The fallback path in ext4_dio_write_iter() calls ext4_buffered_write_iter() which dirties pages, then does flush and invalidate. However, there's an unprotected window between ext4_buffered_write_iter() returning (with inode lock released) and the subsequent flush+invalidate. Concurrent async DIO completions from other threads can run kiocb_invalidate_post_direct_write() during this window. If pages have been re-dirtied, post-invalidation finds dirty pages and triggers the warning, setting -EIO in the error sequence. Consider a file with two 4k extents: [hole][written]. Thread A does DIO to the written extent, while thread B does DIO spanning both: kworker A (4k DIO, allocated block) kworker B (8k DIO, fallback) ----------------------------------- ---------------------------- inode_lock_shared() inode_lock_shared() iomap_dio_rw(): iomap_dio_rw(): kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio (async) dio->size = 0 inode_unlock_shared() inode_unlock_shared() [bio pending in block layer] /* fallback: lock released */ ext4_buffered_write_iter() inode_lock(exclusive) generic_perform_write() -> dirty pages [0, 8k] inode_unlock(exclusive) /* pages dirty, no lock */ [bio completes] filemap_write_and_wait_range() iomap_dio_complete() -> flush dirty pages kiocb_invalidate_post_direct_write() invalidate_mapping_pages() invalidate_inode_pages2_range() -> finds dirty page! -> dio_warn_stale_pagecache() -> errseq_set(-EIO) This issue can be triggered through normal I/O paths, not just intentionally overlapping DIO writes from userspace. For example, generic/746 uses a loop device where multiple kworkers issue concurrent I/O to the backing file. Additionally, when block_size < folio_size, non-overlapping DIO writes that share a large folio can also trigger the race. Add inode_dio_wait() in ext4_buffered_write_iter() before ext4_write_checks() to drain all in-flight DIO. This ensures that all DIO clears existing pages before submitting IO (via kiocb_invalidate_pages()), all BIO waits for all DIO to complete (via inode_dio_wait()), and ext4_write_checks() observes the inode size after all completed DIO so that ext4_block_zero_eof() does not race with in-flight DIO, thus eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92504", "url": "https://ubuntu.com/security/CVE-2026-92504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int3400: clean up ODVP on probe failures evaluate_odvp() creates per-ODVP sysfs files before the thermal zone and later probe resources are registered. The current unwind path only calls cleanup_odvp() from the late sysfs failure path, so failures after evaluate_odvp() but before that label, including thermal_tripless_zone_device_register() failures, leave the ODVP files and storage behind. Move the ODVP cleanup to the common ART/TRT unwind path so every failure after evaluate_odvp() releases the ODVP state. Also clear the cached ODVP pointers in cleanup_odvp(), because evaluate_odvp() can already call it for partial setup failures while probe continues.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92505", "url": "https://ubuntu.com/security/CVE-2026-92505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix undefined behavior in devid_write debugfs function When for_each_pci_segment() loop completes without finding a matching segment, the pci_seg pointer is not NULL but points to an invalid memory location (the list head). Accessing pci_seg->id after the loop causes undefined behavior. Fix this by handling the successful case inside the loop and returning -EINVAL after the loop if no matching segment is found.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92506", "url": "https://ubuntu.com/security/CVE-2026-92506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix requested device removal race scmi_protocol_device_unrequest() drops scmi_requested_devices_mtx while notifying listeners but continues to retain the per-protocol list head. When two SCMI drivers for the same protocol unregister concurrently, one thread can remove the final request and free the list head while the other is running its notifier. The latter then dereferences the freed list head after reacquiring the mutex and can free it a second time. Complete the list and IDR updates, including freeing an empty list head, before dropping the mutex. Keep the blocking notifier outside the critical section and retain only the detached request across the callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92507", "url": "https://ubuntu.com/security/CVE-2026-92507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_dealloc_pd_user() When accessing a PD via the netlink path the only synchronization mechanism for the said PD is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_dealloc_pd_user(), which is too late, since by that point vendor-specific resources associated with the PD might already be freed. This can leave a short window where the PD remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_dealloc_pd_user(), ensuring that the PD is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a PD that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92508", "url": "https://ubuntu.com/security/CVE-2026-92508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_free_cq() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_free_cq(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92509", "url": "https://ubuntu.com/security/CVE-2026-92509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in counter_release() When accessing a counter via the netlink path the only synchronization mechanism for the said counter is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of counter_release(), which is too late, since by that point vendor-specific resources associated with the counter might already be freed. This can leave a short window where the counter remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources, ensuring that the counter is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a counter that is in the process of destruction.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92510", "url": "https://ubuntu.com/security/CVE-2026-92510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_destroy_srq_user() When accessing a SRQ via the netlink path the only synchronization mechanism for the said SRQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_srq_user(), which is too late, since by that point vendor-specific resources associated with the SRQ might already be freed. This can leave a short window where the SRQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_srq_user(), ensuring that the SRQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a SRQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92511", "url": "https://ubuntu.com/security/CVE-2026-92511", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_destroy_cq_user() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_cq_user(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_cq_user(), ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92512", "url": "https://ubuntu.com/security/CVE-2026-92512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix use after free in ib_query_qp() When querying a QP via the netlink flow the only synchronization mechanism for the said QP is rdma_restrack_get(), meanwhile during the QP destroy path rdma_restrack_del() is called at the end of the ib_destroy_qp_user() function which is too late, since by then the vendor specific resources for said QP would already be destroyed, and till the rdma_restrack_del() is called this QP can still be accessed, which could cause the use after free below. Fix this by moving the rdma_restrack_begin_del() to the start of the ib_destroy_qp_user(), which in turn waits for all usages of the QP to be done then removes it from the database to prevent access to it while it is being destroyed. RIP: 0010:ib_query_qp+0x15/0x50 [ib_core] Code: 48 83 05 5d 8e b9 ff 01 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 c7 46 40 00 00 00 00 48 c7 46 78 00 00 00 00 <48> 8b 07 48 8b 80 88 01 00 00 48 85 c0 74 1a 48 83 05 54 91 b9 ff RSP: 0018:ff11000108a8f2f0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ff11000108a8f370 RCX: ff11000108a8f370 RDX: 0000000000000000 RSI: ff11000108a8f3d8 RDI: 0000000000000000 RBP: ff1100010de5a000 R08: 0000000000000e80 R09: 0000000000000004 R10: ff110001057a604c R11: 0000000000000000 R12: ff11000108a8f370 R13: ff110001090e8000 R14: 0000000000000000 R15: ff110001057a602c FS: 00007f2ffd8db6c0(0000) GS:ff110008dc90b000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010b9a7004 CR4: 0000000000373eb0 Call Trace: mlx5_ib_gsi_query_qp+0x21/0x50 [mlx5_ib] mlx5_ib_query_qp+0x689/0x9d0 [mlx5_ib] ib_query_qp+0x35/0x50 [ib_core] fill_res_qp_entry_query.isra.0+0x47/0x280 [ib_core] ? __wake_up+0x40/0x50 ? netlink_broadcast_filtered+0x15a/0x550 ? kobject_uevent_env+0x562/0x710 ? ep_poll_callback+0x242/0x270 ? __nla_put+0xc/0x20 ? nla_put+0x28/0x40 ? nla_put_string+0x2e/0x40 [ib_core] fill_res_qp_entry+0x138/0x190 [ib_core] res_get_common_dumpit+0x4a5/0x800 [ib_core] ? fill_res_qp_entry_query.isra.0+0x280/0x280 [ib_core] nldev_res_get_qp_dumpit+0x1e/0x30 [ib_core] netlink_dump+0x16f/0x450 __netlink_dump_start+0x1ce/0x2e0 rdma_nl_rcv_msg+0x1d3/0x330 [ib_core] ? nldev_res_get_qp_raw_dumpit+0x30/0x30 [ib_core] rdma_nl_rcv_skb.constprop.0.isra.0+0x108/0x180 [ib_core] rdma_nl_rcv+0x12/0x20 [ib_core] netlink_unicast+0x255/0x380 ? __alloc_skb+0xfa/0x1e0 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x230 ? copy_msghdr_from_user+0xea/0x170 ___sys_sendmsg+0x7c/0xb0 ? __futex_wait+0x95/0xf0 ? __futex_wake_mark+0x40/0x40 ? futex_wait+0x67/0x100 ? futex_wake+0xac/0x1b0 __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xb90 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92513", "url": "https://ubuntu.com/security/CVE-2026-92513", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mana_ib: drain QP references after partial table insertion mana_table_store_ud_qp() publishes a QP at its send-queue id before inserting the receive-queue id, dropping the XArray lock between the two xa_insert_irq() calls. A concurrent completion handler can look up the QP and take a transient reference. When the second insertion fails, the rollback erased only the send-queue entry and returned, leaving both the initial table reference and the transient reference outstanding while RDMA core frees the QP, causing a use-after-free. Drain the reference as normal destruction does: drop the initial reference and wait for qp->free, releasing the QP only after every concurrent lookup returns its reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92514", "url": "https://ubuntu.com/security/CVE-2026-92514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: Fix CEQ tasklet use-after-free on removal Each CEQ interrupt handler only schedules eqc->tasklet. The tasklet calls erdma_ceq_completion_handler(), which reads the DMA-coherent EQ ring through get_next_valid_eqe() and updates eq->dbrec through notify_eq(). erdma_ceqs_uninit() frees each CEQ IRQ and then destroys its EQ. free_irq() prevents another hard IRQ and waits for an in-flight handler, but it does not drain a tasklet that the handler already scheduled. The tasklet can therefore access eq->qbuf or eq->dbrec after erdma_eq_destroy() frees them. Clearing ceq_cb->ready does not synchronize with a tasklet that already passed the check at the start of erdma_ceq_completion_handler(). Kill the tasklet after free_irq(), when no handler can schedule it again, and before erdma_ceq_uninit_one() releases the EQ buffers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92515", "url": "https://ubuntu.com/security/CVE-2026-92515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve unique-field state across nested structs btf_find_struct_field() initializes a fresh seen mask for every recursive descent. Unique special fields in different levels of the same aggregate therefore do not see one another. The duplicate fields can reach btf_parse_fields(), where they trigger an invariant WARN_ON_ONCE(). A crafted user BTF can consequently trigger the warning before map creation checks capabilities. Initialize the seen mask once in btf_find_field() and pass the same pointer through struct, datasec, and nested-struct walks. This gives the entire field traversal one shared uniqueness state.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92516", "url": "https://ubuntu.com/security/CVE-2026-92516", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix offset warn check for bpf_res_spin_lock Sashiko pointed out correctly that the case statement for BPF_RES_SPIN_LOCK incorrectly checks offset for BPF_SPIN_LOCK. Fix it by checking res_spin_lock_off instead.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92517", "url": "https://ubuntu.com/security/CVE-2026-92517", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, riscv: Fix extable handling for arena load_acquire emit_atomic_ld_st() returns 1 to have build_body() skip the zext after a sub-word load_acquire. The caller does \"ret = ret ?: add_exception_handler(...)\", which skips add_exception_handler() on any non-zero ret, so the extable entry is missing and a faulting PROBE_ATOMIC load_acquire oopses. REG_DONT_CLEAR_MARKER leaves rd stale on fault, and the verifier still thinks the load overwrote it, so a program can leak it through a map. Check ret >= 0 before calling add_exception_handler(), and pass rd for LOAD_ACQ so the fault zeroes rd like a PROBE_MEM load. Return ret unchanged for the zext skip.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92518", "url": "https://ubuntu.com/security/CVE-2026-92518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Fix kernel stack corruption in tailcall with CFI When CONFIG_CFI_CLANG is enabled, prog->bpf_func already skips the kcfi instruction during setup. Including it again in the tailcall jump offset causes it to jump over an extra 4 bytes, skipping the stack pointer adjustment, which will result in kernel stack corruption.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92519", "url": "https://ubuntu.com/security/CVE-2026-92519", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Fix memory leak in bpf_jit_free When bpf_int_jit_compile() is called for subprograms, it returns early during the first pass (!prog->is_func || extra_pass is false), keeping ctx->offset alive for the subsequent extra pass. If JIT compilation fails for a later subprogram, the BPF core aborts and calls bpf_jit_free() to clean up the first subprogram. However, bpf_jit_free() fails to free jit_data->ctx.offset, which causes a memory leak of the JIT context offsets array. Fix this by adding the missing kfree(jit_data->ctx.offset) in bpf_jit_free().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92520", "url": "https://ubuntu.com/security/CVE-2026-92520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero queue and stack outputs on lock failure Queue and stack pop/peek helpers accept an uninitialized output buffer because the verifier expects the helper to initialize it. The empty-map error path clears the buffer, but a failed lock acquisition returns -EBUSY without writing it. Clear the output before returning -EBUSY so BPF programs cannot observe uninitialized stack contents after a failed helper call.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89786", "url": "https://ubuntu.com/security/CVE-2026-89786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bounds read in ext4_read_inline_dir() ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64(): BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir The dirent payload lives in a buffer of exactly inline_size bytes: \tdir_buf = kmalloc(inline_size, GFP_NOFS); but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic \".\" and \"..\" land at their block-dir offsets. A dirent is formed at \"dir_buf + pos - extra_offset\", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected. Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and main loops, and pass inline_size rather than extra_size to ext4_check_dir_entry() so the length check matches the physical buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92521", "url": "https://ubuntu.com/security/CVE-2026-92521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first. When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer. acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed. Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92522", "url": "https://ubuntu.com/security/CVE-2026-92522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: validate MADT IOAPIC entry bounds The IOAPIC hotplug lookup parses both MADT and _MAT records directly. The MADT walk previously used a subtable's declared length to advance the cursor after only locating a generic header. The _MAT path likewise passed a generic header to the IOAPIC helper. Validate that a current record has a complete generic header, that its declared length is contained in the available record range, and that a typed IOAPIC record contains the full fixed IOAPIC body before reading its fields. Use the same relation for both MADT and _MAT provider paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92523", "url": "https://ubuntu.com/security/CVE-2026-92523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/nldev: validate dynamic counter attribute length RDMA_NLDEV_ATTR_STAT_HWCOUNTERS is a nested attribute whose children are consumed directly with nla_get_u32(). The top-level policy validates only the container, so it does not establish the fixed shape of each child. Require every child payload to be exactly one u32 before reading it.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92524", "url": "https://ubuntu.com/security/CVE-2026-92524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc() When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92525", "url": "https://ubuntu.com/security/CVE-2026-92525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[] For a user QP, qp->sq.queue is a ring the application writes directly, so rxe_post_send() takes the is_user branch and only schedules send_task without validating the WQE. rxe_requester() consumes it in place via req_next_wqe() and calls copy_data(), which indexes &wqe->dma.sge[cur_sge] with the attacker-controlled num_sge/cur_sge. Only the kernel path bounds num_sge (validate_send_wr()); the user WQE is never checked, so a local unprivileged user can post a WQE with an out-of-range cur_sge or oversized num_sge and force an out-of-bounds read of the per-WQE sge array in copy_data() (vmalloc OOB read, local DoS). Bound num_sge to qp->sq.max_sge in rxe_requester() before use, the way get_srq_wqe() already guards SRQ entries, and bound cur_sge only when the WQE carries payload (dma.resid): copy_data() returns early on a zero-length copy before touching dma->sge[], so a zero-payload WQE -- the only kind a max_sge == 0 QP can post -- stays valid. Reproduced under KASAN; the vmalloc-out-of-bounds in copy_data() is gone.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93037", "url": "https://ubuntu.com/security/CVE-2026-93037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Propagate sdma_txinit_ahg() errors set_txreq_header_ahg() ignores the return value of sdma_txinit_ahg(). If sdma_txinit_ahg() fails, it returns before initializing tx->txreq. However, set_txreq_header_ahg() ignores the error and returns the AHG change count, causing the caller to continue processing the request as though initialization had succeeded. Propagate sdma_txinit_ahg() failures to the caller and abort request processing when initialization fails. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93039", "url": "https://ubuntu.com/security/CVE-2026-93039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: Keep link pointers valid on realloc failure meson_card_reallocate_links() grows the DAI link and private data arrays with two consecutive krealloc() calls and updates the owner pointers only after both calls have succeeded. A successful krealloc() may move the data: it frees the old block and returns a new one. When that happens for the link array and the second krealloc() then fails, card->dai_link still points to the block that krealloc() already freed, and the error path frees the new block too. The probe error path then calls meson_card_clean_references(), which dereferences card->dai_link and kfree()s it again, resulting in a use-after-free and a double free. Commit card->dai_link and card->num_links right after the first krealloc() succeeds, so the pointer always refers to a valid allocation that meson_card_clean_references() can walk and free. krealloc() with __GFP_ZERO zero-initializes the added entries, so walking them on the error path is safe. With both failure paths reduced to a plain return, drop the goto labels and the error message.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93040", "url": "https://ubuntu.com/security/CVE-2026-93040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize channel state checks pause() and resume() read and update channel state without holding vc.lock, while the interrupt handlers update the same state under it. Take the same lock around those state checks so that request, status, and configured stay consistent. For example, pause() can observe EDMA_ST_BUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issue_pending() requires EDMA_REQ_NONE, the channel is wedged for good: terminate_all() leaves the stale request behind, so even reconfiguring the channel does not recover it. issue_pending() already runs under vc.lock, but it tests configured before taking it. Move that test under the lock as well, so configured, request, and status are evaluated as one channel-state snapshot.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93041", "url": "https://ubuntu.com/security/CVE-2026-93041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize abort state updates dw_edma_abort_interrupt() drops vc.lock before changing request and status. issue_pending() can acquire the lock in that small window, observe the old busy state, and skip starting queued descriptors. Then the abort handler overwrites the channel status as idle, leaving the new descriptors stranded for good. Keep descriptor completion and the state transition in the same critical section.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93042", "url": "https://ubuntu.com/security/CVE-2026-93042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Terminate all descriptors without callbacks The DMA Engine client documentation says in the \"Terminate APIs\" section of Documentation/driver-api/dmaengine/client.rst: \"No callback functions will be called for any incomplete transfers.\" dw-edma instead calls vchan_cookie_complete() when a deferred STOP reaches the interrupt handler. This schedules a callback for the active descriptor and leaves other issued or submitted descriptors queued. A late callback after dmaengine_terminate_sync() can dereference client state that has already been freed, while leftover descriptors may later restart into reused buffers or leak. Move all issued and submitted descriptors to the terminated list whenever termination completes. For a pending STOP, do this from both the DONE and ABORT paths. Complete their cookies in order without scheduling callbacks. A STOP can remain pending until the running transfer raises an interrupt. Make device_synchronize() wait for such a pending STOP to complete before releasing terminated descriptors. Reuse it from free_chan_resources(), then release the remaining virt-dma resources. Sleep instead of busy-polling while waiting, and warn if the existing timeout expires.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93045", "url": "https://ubuntu.com/security/CVE-2026-93045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject arena frees below the arena base bpf_arena_free_pages() accepts scalar arena addresses. The runtime masks the address to the low 32 bits and reconstructs a full user address from the arena base before returning the range to the arena free tree. When the scalar value is below the low 32 bits of the arena base, full_uaddr falls below user_vm_start. The existing upper-end clipping then turns this into an out-of-range free-tree offset. A later allocation can reuse that offset and return an address below the arena mapping. Reject such frees before computing the clipped range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93046", "url": "https://ubuntu.com/security/CVE-2026-93046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: software node: Fix software_node_get_reference_args() with index -1 The bounds check for the index passed to software_node_get_reference_args() was failing when passed UINT_MAX, this in turn would lead to an out of bound access in the property array. Fix the bound check to also cover the UINT_MAX case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93048", "url": "https://ubuntu.com/security/CVE-2026-93048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition() mtd_add_partition() does not reject the special offset value MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in add_mtd_device() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on cur_offset being the end of the previous partition, but in the dynamic partition path cur_offset equals the offset argument itself, causing undefined behavior. Commit 5daa7b21496a (\"mtd: prepare partition add and del functions for ioctl requests\") introduced mtd_add_partition() and correctly rejected MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2), since those special offsets rely on cur_offset tracking the previous partition's end. However, commit 1a31368bf92e (\"mtd: add a flags for partitions which should just leave smth. after them\") later added MTDPART_OFS_RETAIN (-3) for the static partition table path without updating mtd_add_partition() to also reject this value. With offset=-3 passed via BLKPG, the RETAIN size calculation in allocate_partition() underflows (parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3). If the underflow result does not appear to leave enough space, allocate_partition() jumps to out_register via goto, skipping erasesize initialization. This results in erasesize=0, which triggers: WARN_ON((!mtd->erasesize || !master->_erase) && \t\t!(mtd->flags & MTD_NO_ERASE)) in add_mtd_device(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the \"out of reach\" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error. Fix this by adding MTDPART_OFS_RETAIN to the rejection list in mtd_add_partition(), consistent with the existing handling of APPEND and NXTBLK.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93049", "url": "https://ubuntu.com/security/CVE-2026-93049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdswap: Avoid freeing registered blktrans device twice In mtdswap_add_mtd(), debugfs setup failure after successful blktrans registration can free mbd_dev twice. add_mtd_blktrans_dev() initializes the blktrans device reference and publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the disk down and drops the blktrans reference; when that reference reaches zero, blktrans_dev_release() frees the mtd_blktrans_dev. The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell through the common cleanup label and called kfree(mbd_dev) again. Clear the local pointer after deregistration so the common cleanup can still release the mtdswap state without freeing the blktrans object twice. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89777", "url": "https://ubuntu.com/security/CVE-2026-89777", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: clear vdev->msi_perm after freeing it on init failure vfio_msi_cap_len() lazily allocates the per-device MSI permission table: \tvdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); \tif (!vdev->msi_perm) \t\treturn -ENOMEM; \tret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); \tif (ret) { \t\tkfree(vdev->msi_perm); \t\treturn ret;\t\t/* vdev->msi_perm left dangling */ \t} When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at \"if (vdev->msi_perm) return len;\" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93050", "url": "https://ubuntu.com/security/CVE-2026-93050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipack: ipoctal: fix UAF, null-ptr-deref, and use-after-free in cleanup on remove Three issues arise when the device is removed while a tty session is still active: 1. UAF of struct ipoctal: the remove callback frees ipoctal via kfree() while tty ops may still access it. Fix by introducing kref-based lifetime management — kref is taken in install() when a tty is opened and released in cleanup() when the tty is finally destroyed; remove() uses kref_put() instead of kfree(). 2. NULL dereference in ipoctal_write_tty(): __ipoctal_remove() frees xmit_buf via tty_port_free_xmit_buf() while a userspace process may still hold the tty fd and call write(). Fix by checking for NULL xmit_buf in ipoctal_write_tty(). 3. UAF in ipoctal_cleanup(): ipack_put_carrier(ipoctal->dev) dereferences ipoctal->dev after the ipack_device has been freed by ipack_device_del(). Fix by caching ipoctal->carrier_owner during probe() and calling module_put() on the cached pointer directly in cleanup(), avoiding any access to ipoctal->dev. Also introduce a \"removed\" flag in struct ipoctal, set at the start of __ipoctal_remove(), and checked in every tty op that accesses hardware resources (port_activate, write_tty, set_termios, hangup, shutdown). This prevents page faults when devm_ioremap() regions are unmapped after remove() returns.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93051", "url": "https://ubuntu.com/security/CVE-2026-93051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ad525x_dpot: use driver core groups for sysfs files ad_dpot_probe() creates per-RDAC sysfs files manually and then optionally creates the command sysfs group. This leaves probe responsible for rolling back partial sysfs state and makes remove responsible for matching every file that probe created. Move the device attributes into driver core dev_groups for the I2C and SPI drivers and use an is_visible() callback to expose only the attributes supported by the probed device. With this shape, the driver core creates the sysfs files only after probe succeeds and removes them before the remove callback frees the driver data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93052", "url": "https://ubuntu.com/security/CVE-2026-93052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: bcm-vk: Use acquire/release for msgq_inited bcm_vk_sync_msgq() fills the message queue information and then sets msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the message queues and their cached queue information. atomic_set()/atomic_read() do not order those accesses. A reader can see msgq_inited set while still seeing stale queue information. Use release when publishing the initialized queues and acquire when checking the gate. Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the gate and does not publish queue state to readers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93053", "url": "https://ubuntu.com/security/CVE-2026-93053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: speakup: keyhelp: guard letter_offsets possible out-of-range indexing help_init() builds letter_offsets[] by using the first byte of each function name as an index via `(start & 31) - 1`. If function_names are overridden from sysfs (root) with a name starting outside [a–z], the index underflows or exceeds the array, leading to OOB write. Function names can be overridden with the following commands as root: modprobe speakup_soft echo \"0 _bad\" > /sys/accessibility/speakup/i18n/function_names # then press Insert+2 on /dev/tty This fix checks the first letter in help_init(), and if it is not in the [a–z] range the function returns an error to the caller. Eventually this error is propagated to drivers/accessibility/speakup/main.c:2217, which causes a bleep sound.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93054", "url": "https://ubuntu.com/security/CVE-2026-93054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uio: Fix stale info pointer in failed registration path After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same \"device gone\" state as normal uio_unregister_device().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93055", "url": "https://ubuntu.com/security/CVE-2026-93055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: UDF symlink pathComponent header OOB read udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93056", "url": "https://ubuntu.com/security/CVE-2026-93056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: remove broken string configfs attributes The UAC1_STR_ATTRIBUTE macro defines configfs show/store handlers for the fn_play, fn_cap, and fn_cntl string options. The store function contains an inverted null check on the kstrndup() return value. This means every write attempt returns -ENOMEM on success and dereferences a NULL pointer on allocation failure. The attributes have been broken and unused for many years. Remove the UAC1_STR_ATTRIBUTE macro and the three attributes it generated. The internal defaults (FILE_PCM_PLAYBACK, FILE_PCM_CAPTURE, FILE_CONTROL) set in f_audio_alloc_inst() are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93058", "url": "https://ubuntu.com/security/CVE-2026-93058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Only fini scheduler after successful init msm_ringbuffer_new() destroys a partially initialized ring through msm_ringbuffer_destroy() when an allocation or scheduler setup step fails. If drm_sched_init() fails before it finishes initializing the scheduler, the failure path still calls drm_sched_fini(). That teardown path assumes the scheduler work items, lists, and workqueue state were initialized. Track successful scheduler initialization and call drm_sched_fini() only after drm_sched_init() returned 0. This issue was found by a static analysis checker and confirmed by manual source review. Patchwork: https://patchwork.freedesktop.org/patch/738905/", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93059", "url": "https://ubuntu.com/security/CVE-2026-93059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix task_struct reference leak in recover_worker get_pid_task() increments the task reference count, but the corresponding put_task_struct() was missing in the else branch, leaking a reference on every GPU hang recovery. Patchwork: https://patchwork.freedesktop.org/patch/730662/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93061", "url": "https://ubuntu.com/security/CVE-2026-93061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Avoid stack over-read in debug output helpers host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93062", "url": "https://ubuntu.com/security/CVE-2026-93062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: guard against division by zero in iwl_dbg_tlv_alloc_fragments Make sure we don't end-up with a num_frags = 0 situation. For that, check that the required size is not 0 and put a checker on num_frags as well.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93063", "url": "https://ubuntu.com/security/CVE-2026-93063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mei: check SAP message length before reading it Verify the SAP message size is not larger than the local buffer before reading the message to avoid buffer overflow.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93064", "url": "https://ubuntu.com/security/CVE-2026-93064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix off-by-one in TXF key sanitiser iwl_mvm_frob_txf_key_iter() tracks the last matched byte position in loop variable 'i'. When a full key match is found (match == keylen), 'i' points at the last byte of the matched key. The memset start offset should therefore be i + 1 - keylen, not i - keylen; the current code zeroes one byte before the match and leaves the final key byte un-sanitised.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93065", "url": "https://ubuntu.com/security/CVE-2026-93065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix counter type in iwl_fwrt_dump_error_logs The loop counter 'count' was declared as u8 while num_pc is u32. If firmware advertises more than 255 PC entries the counter wraps back to zero and the loop never terminates potentially causing an infinite loop or reading past the allocated pc_data array. Change the declaration to u32 to match num_pc.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93066", "url": "https://ubuntu.com/security/CVE-2026-93066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: Take cpa_lock around large-page collapse Loading and unloading modules concurrently on several CPUs on a KASAN build, with a short delay injected at the CPA page-table lookup to widen the window, faults within minutes: BUG: KASAN: use-after-free in __change_page_attr+0x7cc/0x7e0 Write of size 8 at addr ffff888181139718 by task modprobe ... The buggy address belongs to the physical page: pfn:0x181139 ... page_type: f2(table) cpa_collapse_large_pages() rebuilds a leaf PMD from its 4K PTEs and frees the old PTE-table pages, while __change_page_attr() fetches a PTE pointer from a lockless lookup_address_in_pgd_attr() and writes it with set_pte_atomic() only later. When module text is served from a shared large ROX mapping the two run on the same PMD: CPU A (module load) CPU B (module finalize) ------------------- ----------------------- execmem_make_temp_rw set_memory_nx __change_page_attr split 2M -> 4K table P kpte = &P[i] (lockless) execmem_restore_rox set_memory_rox (CPA_COLLAPSE) cpa_collapse_large_pages rebuild leaf PMD flush_tlb_all pagetable_free(P) set_pte_atomic(kpte, ...) -> writes into freed P P is a page-table page (page_type: table), reused at once, so the write corrupts whatever got the page next: a bad-pte or bad-page splat, or a fatal fault once P has been turned into read-only text. The flush_tlb_all() before the free does not close this: its IPI only serializes against page-table walkers that run with interrupts off (e.g. GUP-fast); the walk in __change_page_attr() runs with interrupts on, so nothing stops it from holding a stale pointer into P. Serialize the collapse - the PMD rebuild, TLB flush and PTE-table free - under cpa_lock, the same lock __change_page_attr() now takes unconditionally since commit (\"x86/mm/pat: stop gating cpa_lock on debug_pagealloc_enabled()\"), so a concurrent walker can no longer hold a pointer into a table the collapse is about to free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93067", "url": "https://ubuntu.com/security/CVE-2026-93067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: clamp the reported AUX read size to the request tc_aux_transfer() clamps an AUX read to the payload limit: \tsize_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: \tif (size) \t\tsize = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 (\"drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer\").", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93068", "url": "https://ubuntu.com/security/CVE-2026-93068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix DM I2C teardown race DM I2C adapters can remain visible to userspace while DM teardown is already in progress. A concurrent i2c-dev transfer may then enter amdgpu_dm_i2c_xfer() after the backing DM state has been torn down, leading to a NULL pointer dereference. Create a devres group around the DM I2C adapter lifetime and release it at the start of dm_hw_fini(), before HPD, IRQ, and DM state are torn down. This removes the I2C adapters first and waits for in-flight users to drain before the structures used by amdgpu_dm_i2c_xfer() disappear. This fixes a teardown ordering race seen during device removal: BUG: kernel NULL pointer dereference RIP: amdgpu_dm_i2c_xfer+0x122/0x1c0 [amdgpu] Call Trace: __i2c_transfer i2c_transfer i2cdev_ioctl_rdwr", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93070", "url": "https://ubuntu.com/security/CVE-2026-93070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ipu6: Do not free aux device pdata after init ipu6_bus_initialize_device() stores the isys/psys pdata pointer in struct ipu6_bus_device and initializes the auxiliary device. After that point, error unwinding must drop the auxiliary device reference and let ipu6_bus_release() free both the bus device and adev->pdata. The isys and psys init paths already call put_device() when MMU initialization fails, and ipu6_bus_add_device() calls auxiliary_device_uninit() on auxiliary_device_add() failure. Both paths therefore run the bus release callback. The extra kfree(pdata) in the callers can release the same object a second time. Remove the manual pdata frees after the auxiliary device has been initialized. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93071", "url": "https://ubuntu.com/security/CVE-2026-93071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: bcm2835-unicam: Fix asc leaked in error/remove path v4l2_async_nf_add_fwnode_remote() allocates the asc, which is freed when v4l2_async_nf_cleanup() is called. Call v4l2_async_nf_cleanup() properly in the driver paths. Discovered with kmemleak after rmmod: unreferenced object 0xffff000084526b80 (size 64): comm \"modprobe\", pid 185, jiffies 4295013512 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 e8 0d ff bf 00 00 ff ff ................ 40 83 bc 84 00 00 ff ff 60 83 bc 84 00 00 ff ff @.......`....... backtrace (crc ac584083): [<00000000ffb081a7>] kmemleak_alloc+0x38/0x44 [<00000000d2fd9301>] __kmalloc+0x1b0/0x250 [<000000004dd5354d>] __v4l2_async_nf_add_fwnode+0x28/0x9c [<0000000067587657>] __v4l2_async_nf_add_fwnode_remote+0x3c/0x64", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93072", "url": "https://ubuntu.com/security/CVE-2026-93072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/renesas-irqc: Fix generic interrupt chip leak on remove The driver allocates domain generic chips probe. However, on driver removal, the generic chips are not automatically freed when the interrupt domain is removed because the domain flags do not include IRQ_DOMAIN_FLAG_DESTROY_GC. This causes both the domain generic chips structure and the associated generic chips to be leaked. Additionally, the generic chips remain on the global list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. Fix the resource leak by setting IRQ_DOMAIN_FLAG_DESTROY_GC on the interrupt domain; this lets the interrupt domain core automatically release all generic chips when irq_domain_remove() is invoked, removing the need for manual cleanup calls in error paths and remove callback.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93073", "url": "https://ubuntu.com/security/CVE-2026-93073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dax: read holder_ops once in dax_holder_notify_failure() dax_holder_notify_failure() reads dax_dev->holder_ops twice without READ_ONCE() -- once for the NULL check and once for the indirect notify_failure() call. A concurrent fs_put_dax() can clear holder_ops between the two reads, so the check can observe a non-NULL pointer while the call dereferences NULL. (kill_dax() also clears holder_ops, but only after synchronize_srcu(), so it cannot race a reader that is inside dax_read_lock(); fs_put_dax() does no such synchronization.) Fetch holder_ops once into a local with READ_ONCE() so the NULL check and the indirect call observe the same value.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93077", "url": "https://ubuntu.com/security/CVE-2026-93077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/features: Clamp Get Feature output size to the remaining buffer cxl_get_feature() reads a feature in a loop but passes a fixed size_out as the output capacity every iteration. On the last partial iteration the buffer has less room left, so a device that returns more than asked can overflow feat_out. Use the per-iter size data_to_rd_size, which already tracks the remaining room, as the output capacity.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93078", "url": "https://ubuntu.com/security/CVE-2026-93078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/features: Reject Set Features output buffer smaller than the header cxlctl_set_feature() sizes its output buffer from the user's fwctl_rpc.out_len but never checks it is large enough to hold even the fwctl_rpc_cxl_out header. With out_len == 0 , kvzalloc() returns ZERO_SIZE_PTR, which passes the !rpc_out check, the subsequent rpc_out->size = 0 then writes through the poison pointer. Reject requests whose output buffer can't hold the response header, before allocating. The Set Feature reply carries no payload, so the header is all that is required.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93079", "url": "https://ubuntu.com/security/CVE-2026-93079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/features: Reject Get Feature count larger than the output buffer cxlctl_get_feature() sizes its output buffer from the user's fwctl_rpc.out_len, but the device is told to write cxl_mbox_get_feat_in.count bytes into rpc_out->payload, which is a separate user-controlled value. Nothing bounds count against out_len, so a small out_len with a large count overflows the kvzalloc()'d buffer. A heap OOB write reachable from FWCTL_RPC. Reject requests where count exceeds the available payload room, before allocating.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93080", "url": "https://ubuntu.com/security/CVE-2026-93080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix transport device teardown lookup SCMI transport devices are deliberately excluded from normal SCMI bus matching so protocol drivers cannot bind to the internal transport children. However, scmi_device_destroy() uses the same protocol/name lookup to find devices that must be unregistered during channel teardown. Split the match helper so driver matching still skips transport devices, while explicit child lookup can find them for teardown. Use a shared transport-device name prefix macro for both matching and name generation. Since transport-device names are derived from direction and protocol ID, reject duplicate protocol channel setup before creating or finding a transport device. This prevents malformed firmware with duplicate protocol child nodes from reusing an existing transport device and then destroying it when the duplicate IDR insertion fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93082", "url": "https://ubuntu.com/security/CVE-2026-93082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unwind P2A receiver mailbox setup failure mailbox_chan_setup() can request an additional P2A receiver channel after successfully acquiring the primary P2A channel. If that later request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93083", "url": "https://ubuntu.com/security/CVE-2026-93083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unwind TX receiver mailbox setup failure mailbox_chan_setup() can request an additional unidirectional TX receiver channel after successfully acquiring the primary channel. If that second request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93084", "url": "https://ubuntu.com/security/CVE-2026-93084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Drop handle on protocol bind failures The SCMI bus notifier acquires an SCMI handle when the driver core emits BUS_NOTIFY_BIND_DRIVER, before invoking the protocol driver probe callback. The protocol probe path only checks whether sdev->handle is set. If device_link_add() fails after the handle has been acquired, the protocol device can still bind with a valid handle but without the dependency link to the SCMI parent. A concurrent parent unbind can then miss the child and tear down the SCMI instance while the child still holds a handle into it. If the protocol driver probe later fails, for example with -EPROBE_DEFER, the driver core emits BUS_NOTIFY_DRIVER_NOT_BOUND rather than BUS_NOTIFY_UNBOUND_DRIVER. The SCMI notifier only released the handle on BUS_NOTIFY_UNBOUND_DRIVER, so each failed protocol-device bind leaked the SCMI instance users refcount and left sdev->handle set after the failed probe. Make the link helper report failure and drop the acquired handle if the link cannot be created. Also handle BUS_NOTIFY_DRIVER_NOT_BOUND in the same cleanup path used for unbind so failed probes balance the earlier BUS_NOTIFY_BIND_DRIVER acquisition.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93085", "url": "https://ubuntu.com/security/CVE-2026-93085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Reject out of range DT protocol IDs SCMI protocol IDs carried in message headers are limited by MSG_PROTOCOL_ID_MASK. The DT parsing paths noticed protocol IDs outside that range, but only logged an error and then kept processing the invalid value. That lets a malformed 32-bit DT reg value reach helpers which take a u8 protocol ID, where it can be truncated and/or treated as a different protocol. For channel setup, two different out-of-range values can also be used as distinct IDR keys while aliasing the generated SCMI protocol identity. Skip DT protocol nodes whose reg value does not fit the SCMI protocol ID field before setting up channels or creating protocol devices.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93086", "url": "https://ubuntu.com/security/CVE-2026-93086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Avoid IDR updates while cleaning channels scmi_cleanup_channels() walks the TX/RX channel IDRs with idr_for_each() to free transport resources and destroy the dedicated transport devices before calling idr_destroy(). The destroy callback removed each entry from the same IDR being walked. That is not needed for this cleanup path, and it is unsafe because idr_for_each() has not advanced its radix-tree iterator while the callback is running. Removing the current entry from the callback can invalidate the iterator state. The callback also cannot be protected by rcu_read_lock(), because scmi_device_destroy() may sleep. Leave IDR teardown to the following idr_destroy() call and keep the callback limited to device destruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93089", "url": "https://ubuntu.com/security/CVE-2026-93089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Free transport channel on IDR failure If transport channel setup succeeds but the following IDR insertion fails, the error path destroys the transport device and frees the channel info without invoking the transport cleanup callback. Call chan_free() before destroying the device so transport specific resources such as IRQs, mailbox channels and mapped shared memory are released consistently with the normal teardown path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93090", "url": "https://ubuntu.com/security/CVE-2026-93090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Clean up channels on setup failure scmi_channels_setup() can fail after the common BASE channel or earlier protocol channels have already been registered in the TX/RX IDRs. Route this failure through the existing channel cleanup label so the transport channels, transport devices and IDR state created before the failure are released before the probe error path frees the SCMI instance ID.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93091", "url": "https://ubuntu.com/security/CVE-2026-93091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Quiesce notifications before teardown scmi_notification_exit() clears and releases the notification instance, but transport callbacks can still deliver incoming notifications until the TX/RX channels are freed. During remove, an RX interrupt in that window can enter scmi_notify() while notification state is being torn down and then dereference freed memory. The same ordering exists on the probe error path after notification initialization. The notification late-init worker has a separate lifetime issue: protocol event registration queues ni->init_work on the system workqueue, so destroying ni->notify_wq does not drain that work. If the devres group is released while init_work is still pending or running, the late-init worker can dereference the freed notification instance. Quiesce the notification core before TX/RX channels are torn down, then clean up the channels before releasing the notification core resources. Use disable_work_sync() so future late-init queueing is rejected and any already queued or running late-init work has completed before channel teardown starts.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93092", "url": "https://ubuntu.com/security/CVE-2026-93092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unregister device notifier before IDR teardown The requested-devices notifier looks up protocol fwnodes from the active_protocols IDR. During remove, unregister the notifier before releasing and destroying active_protocols so no notifier callback can race with the IDR teardown. Keep the bus notifier registered until after the protocol state is torn down, matching the existing remove ordering for SCMI bus users.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93093", "url": "https://ubuntu.com/security/CVE-2026-93093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Publish channel state before callbacks Transport setup can enable callbacks before the setup routine returns. mailbox_chan_setup() registers the mailbox client with mbox_request_channel(), and the mailbox controller startup path can enable interrupt delivery before SCMI mailbox channel state has been published. Similarly, smc_chan_setup() requests the optional A2P completion IRQ before the SMC transport has made its cinfo pointer visible. If a pending or spurious callback fires in those windows, the transport RX callback can dereference a NULL transport cinfo pointer. Publishing only the transport-private pointer is not sufficient either: an early callback can enter the SCMI core before scmi_chan_setup() has assigned cinfo->handle. The core derives scmi_info from cinfo->handle in the RX path, so a NULL handle can still fault even when the transport-private cinfo is valid. Assign cinfo->handle before invoking the transport setup callback. Publish the mailbox and SMC transport-private channel state before requesting the mailbox channels or IRQ, and clear the early-published pointers again on setup failure. Also unwind mailbox setup devres resources on failure so an optional RX setup error that is ignored by the core does not leave stale transport state behind.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93095", "url": "https://ubuntu.com/security/CVE-2026-93095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: validate thread record before delete key rebuild hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName. That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name. A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation. Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name. Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93097", "url": "https://ubuntu.com/security/CVE-2026-93097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/mbox: Break poison list loop on an empty payload A device that returns count == 0 with CXL_POISON_FLAG_MORE set on every iteration never advances nr_records, so the max_errors guard never trips and the do/while loops forever while holding poison.mutex. That hangs the sysfs-triggered scan thread and blocks all subsequent poison operations on the device. The existing \"Protect against an uncleared _FLAG_MORE\" guard was intended to bound a misbehaving device but does not cover the count == 0 case. Stop the loop on an empty payload so a malfunctioning or malicious device cannot wedge the poison scan.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93098", "url": "https://ubuntu.com/security/CVE-2026-93098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: glink: fix deadlock in endpoint destroy during driver detach During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414  <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0>] invoke_syscall+0x48/0x10c [<0>] el0_svc_common.constprop.0+0xc0/0xe0 [<0>] do_el0_svc+0x1c/0x28 [<0>] el0_svc+0x34/0x108 [<0>] el0t_64_sync_handler+0xa0/0xe4 [<0>] el0t_64_sync+0x198/0x19c The rpmsg device unregistration inside endpoint destroy is redundant. In both contexts where endpoint destruction is triggered: - Driver detach path: the driver core already tears down the rpmsg device. - Channel close path: the rpmsg device is already unregistered before endpoint destruction is reached. Remove the redundant unregistration to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93100", "url": "https://ubuntu.com/security/CVE-2026-93100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Prevent use-after-free in rdtgroup_kn_put() A struct rdtgroup is reference counted via rdtgroup::waitcount. Callers that need the structure to remain valid across a sleep (while waiting on acquiring rdtgroup_mutex) take a reference with rdtgroup_kn_get() and release it with rdtgroup_kn_put(). The release path is intended to serve as the fallback freer: if the count drops to zero and the group has already been marked RDT_DELETED, rdtgroup_kn_put() frees the structure. The bulk teardown paths free_all_child_rdtgrp() and rmdir_all_sub() resulting from a resctrl directory remove or resctrl fs unmount act as the primary freer: they hold rdtgroup_mutex and free each rdtgroup whose waitcount is zero, otherwise they set RDT_DELETED and leave the freeing to the last waiter. These two freers race. rdtgroup_kn_put() commits waitcount == 0 with atomic_dec_and_test() outside rdtgroup_mutex, then reads rdtgroup::flags. Between those two operations a concurrent caller of free_all_child_rdtgrp() or rmdir_all_sub() (which holds the mutex) can observe waitcount == 0 via atomic_read(), call rdtgroup_remove(), and kfree() the structure. The subsequent read of rdtgroup::flags in rdtgroup_kn_put() is then a use-after-free, and the structure may even be freed twice if the freed memory happens to satisfy the RDT_DELETED flag check. Replace the bare atomic_dec_and_test() with atomic_dec_and_mutex_lock() so that the decrement-to-zero takes rdtgroup_mutex before the count becomes globally visible. The inspection of rdtgroup::flags then runs under the same mutex held by the bulk freers, making the two paths mutually exclusive. The common case where the count does not reach zero remains lock-free. Defer kernfs_unbreak_active_protection() until after the mutex is dropped since kernfs active protections functionally wrap rdtgroup_mutex. Remove resource group, which in turn drops its kernfs reference, after kernfs protection is restored. [ bp: Split the commit messsages into smaller, easier-parseable paragraphs. ]", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93101", "url": "https://ubuntu.com/security/CVE-2026-93101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-async: Unregister sub-device if asc_list is empty When my em28xx USB device that uses the i2c tvp5150 driver is disconnected, it crashes. The cause is that the tvp5150 i2c module uses v4l2_async, but the em28xx driver does not since it predates v4l2_async. In that corner case sd->asc_list is empty, so v4l2_async_unregister_subdev() never calls v4l2_device_unregister_subdev(). Modify the code so that, if sd->asc_list is empty, v4l2_device_unregister_subdev() is still called.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89778", "url": "https://ubuntu.com/security/CVE-2026-89778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: fix out-of-bounds page array access on empty zisofs block zisofs_uncompress_block()'s empty-block fast path returns pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the decompression path which returns bytes produced relative to poffset. zisofs_fill_pages() uses that return to advance its page cursor, so when the zisofs block size is below PAGE_SIZE and a sub-page block leaves poffset partway into a page, a following empty block over-counts and advances pages[] one element past its end, after which \"if (poffset && *pages)\" reads pages[1] out of bounds. rock.c only rejects a block-size shift > 17, so a crafted \"ZF\" Rock Ridge record can set it below PAGE_SHIFT; the bug is reached by an ordinary read() of a compressed file on such a mounted ISO9660 image. Return the byte count relative to poffset and zero only [poffset, PAGE_SIZE) of the first page, matching the decompression path. The page-aligned case (poffset == 0) is unaffected. BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290) Read of size 8 at addr ffff88800f5eac48 by task exploit/142 zisofs_read_folio (fs/isofs/compress.c:290) read_pages (mm/readahead.c:184) ... filemap_read (mm/filemap.c:2814) vfs_read (fs/read_write.c:574) __x64_sys_pread64 (fs/read_write.c:769) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address is located 0 bytes to the right of the allocated 8-byte region in the kmalloc-8 cache", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93102", "url": "https://ubuntu.com/security/CVE-2026-93102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Free RX data on late probe failure hfi1_init_dd() allocates the shared AIP/VNIC RX support before returning. If hfi1_init() or hfi1_register_ib_device() later fails, init_one() tears down the device data without calling hfi1_free_rx(). This leaks netdev_rx and its dummy netdev. Free the RX support after IB unregistration and before postinit_cleanup(), as done on normal device removal.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93103", "url": "https://ubuntu.com/security/CVE-2026-93103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89783", "url": "https://ubuntu.com/security/CVE-2026-89783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full The depth check in xfrm6_input_addr() is off by one: if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; ... sp->xvec[sp->len++] = x; xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode receive path re-enters IPv6 input via xfrm_trans_reinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6_input_addr() is called with sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so sp->xvec[sp->len++] writes one slot past the 6-element xvec[]. The write stays within the sec_path allocation (invisible to KASAN); UBSAN_BOUNDS flags it and panics under panic_on_warn. Use \"sp->len >= XFRM_MAX_DEPTH\", matching xfrm_input(). This also restores one chain level the old check rejected at sp->len == 5. UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c:309:10 index 6 is out of range for type 'xfrm_state *[6]'", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93106", "url": "https://ubuntu.com/security/CVE-2026-93106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crash_dump: release keyring reference at the correct time restore_dm_crypt_keys_to_thread_keyring() gets a reference to the user keyring before restoring the saved dm-crypt keys. The same keyring reference is then passed to add_key_to_keyring() for each saved key, but add_key_to_keyring() drops that reference on every call. This is only balanced when exactly one key is restored. With multiple keys, the keyring reference is dropped too many times and may trigger a refcount underflow or use-after-free. When more than five keys are restored, a refcount underflow/use-after-free warning can be triggered. The early error paths after lookup_user_key() also return without dropping the keyring reference. Keep ownership of the keyring reference in restore_dm_crypt_keys_to_thread_keyring(), drop it once on all exit paths, and make add_key_to_keyring() only use the reference without consuming it.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93107", "url": "https://ubuntu.com/security/CVE-2026-93107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Avoid reprocessing the current packet after the QP enters the error state When do_complete() finds the QP in the error state it returns RESPST_CHK_RESOURCE. Before commit 49dc9c1f0c7e (\"RDMA/rxe: Cleanup reset state handling in rxe_resp.c\") this was the flush loop: check_resource() had an error-state branch that fetched each remaining recv WQE and completed it with IB_WC_WR_FLUSH_ERR, without touching the current packet. That commit removed the error-state branch from check_resource() (draining is now done at rxe_receiver() entry) but kept the do_complete() error-state return. As a result, when a QP moves to the error state while a packet is being completed - e.g. an rdma_cm disconnect racing with receive processing - the responder state machine loops back into the request processing chain with the already-completed packet still in hand: check_resource() fetches a fresh recv WQE, execute()/send_data_in() copies the same packet payload again, do_complete() posts another IB_WC_SUCCESS CQE (qp->resp.status is still 0), and control returns to the error-state check. The loop re-executes the same packet once per posted recv WQE (observed: ~1000 duplicate IB_WC_SUCCESS completions of one SEND, one per ~8us, matching the RQ occupancy) until the RQ is exhausted, after which qp->resp.wqe is NULL and send_data_in() dereferences it: BUG: kernel NULL pointer dereference, address: 0000000000000014 Workqueue: rxe_wq do_work RIP: copy_data+0x29/0x1f0 Call Trace: send_data_in+0x25/0x50 rxe_receiver+0xf36/0x1dd0 The duplicate completions are indistinguishable from real receives to the ULP. During an rds stress test, the message was accepted as new and delivered the same datagram to user space hundreds of times, corrupting the stream; any ULP that relies on RC exactly-once delivery is affected. A live packet reaching the error-state check in do_complete() has been executed and completed exactly once and must be consumed, not re-processed. Return RESPST_CLEANUP for it (dequeue and free); keep returning RESPST_CHK_RESOURCE for the pkt == NULL case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93108", "url": "https://ubuntu.com/security/CVE-2026-93108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ipoib: Drain RCU callbacks during module teardown IPoIB reclamation completions can be signaled from inside an RCU callback. Teardown can wake before the callback returns and unload ib_ipoib while its code is still executing. Client registration failure can also remove already-added devices and queue callbacks. Wait after client and workqueue teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93109", "url": "https://ubuntu.com/security/CVE-2026-93109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Drain RCU callbacks during module teardown devx_free_subscription() can remain queued after the last DevX event file drops its module reference or an auxiliary driver detaches its devices. mlx5_ib can then unload before the callback runs. Registration error unwind has the same risk because driver registration can attach existing devices before failing. Wait after all drivers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93110", "url": "https://ubuntu.com/security/CVE-2026-93110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Wait for RCU callbacks before unloading ib_core put_gid_ndev() is queued with call_rcu() and implemented in ib_core. Stopping the workqueues does not drain callbacks already queued, so RCU could invoke it after the module code has been unloaded. synchronize_rcu() does not wait for callbacks. Wait for them after all producers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93112", "url": "https://ubuntu.com/security/CVE-2026-93112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Require a BPF cpumask for bpf_cpumask_populate() bpf_cpumask_populate() writes to its destination with bitmap_copy(), but the destination is typed as struct cpumask *. That allows the verifier to accept borrowed cpumask pointers returned by read-only kfuncs, such as scx_bpf_get_online_cpumask(), as a writable destination. Make the destination a struct bpf_cpumask * so populate follows the same ownership rule as the other mutating cpumask kfuncs. Query kfuncs continue to accept const struct cpumask * inputs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93113", "url": "https://ubuntu.com/security/CVE-2026-93113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: camcc-sc8280xp: unregister CAMCC_GDSC_CLK With the introduction of sync_state support in the clk and pmdomain subsystems, the following warning happens when the unused clocks are shutdown in camcc-sc8280xp: [ 15.408367] titan_top_gdsc status stuck at 'on' [ 15.408429] WARNING: drivers/clk/qcom/gdsc.c:178 at gdsc_toggle_logic+0x14c/0x160, CPU#2: kworker/u32:1/14 [ 15.408462] Modules linked in: bnep vfat fat ath11k_pci(+) ath11k mac80211 cfg80211 mhi libarc4 snd_soc_wcd938x snd_soc_wcd938x_sdw snd_soc_wcd_classh hci_uart snd_soc_wcd_common snd_soc_sc8280xp soundwire_qcom snd_soc_wcd_mbhc snd_soc_qcom_sdw slimbus snd_soc_qcom_common regmap_sdw btqca btrtl qcom_camss soundwire_bus btbcm btintel snd_soc_sdca snd_soc_lpass_wsa_macro bluetooth snd_soc_lpass_tx_macro snd_soc_lpass_va_macro snd_soc_lpass_rx_macro snd_soc_hdmi_codec snd_soc_lpass_macro_common videobuf2_dma_sg ov5675 v4l2_fwnode videobuf2_memops qcom_spmi_adc5 snd_soc_core qcom_spmi_adc_tm5 videobuf2_v4l2 snd_seq snd_seq_device videobuf2_common v4l2_async qcom_vadc_common qcom_spmi_temp_alarm pm8941_pwrkey industrialio videodev snd_compress rfkill ac97_bus snd_pcm_dmaengine qcom_tsens mc qcom_edac snd_pcm pci_pwrctrl_pwrseq qcom_cpufreq_hw snd_timer snd qcomtee soundcore tee leds_gpio joydev binfmt_misc zram lz4hc_compress governor_simpleondemand panel_edp msm xhci_plat_hcd nvme nvme_core dwc3 qcom_pm8008_regulator [ 15.408688] ucsi_glink nvme_keyring nvme_auth pmic_glink_altmode udc_core typec_ucsi aux_hpd_bridge qcom_battmgr ulpi ubwc_config socinfo ocmem drm_gpuvm qcom_q6v5_pas drm_exec qcom_pil_info leds_qcom_lpg gpu_sched led_class_multicolor rtc_pm8xxx qcom_pbs qcom_common drm_display_helper qcom_pon qcom_glink_smem qcom_glink ghash_ce pwrseq_qcom_wcn gpio_sbu_mux qcom_stats phy_qcom_qmp_combo qcom_q6v5 gf128mul cec dispcc_sc8280xp phy_qcom_edp camcc_sc8280xp i2c_qcom_cci qcom_sysmon drm_dp_aux_bus mdt_loader aux_bridge qcom_pm8008 i2c_hid_of_elan dwc3_qcom_legacy llcc_qcom icc_bwmon gpi typec qcom_refgen_regulator phy_qcom_qmp_usb nvmem_qfprom qcom_ipcc phy_qcom_snps_femto_v2 gpucc_sc8280xp pinctrl_sc8280xp_lpass_lpi qcom_hwspinlock pinctrl_lpass_lpi lpasscc_sc8280xp qrtr qcom_aoss pmic_glink pdr_interface phy_qcom_qmp_pcie qcom_smd qcom_pdr_msg icc_osm_l3 qcom_wdt qmi_helpers qcom_rng smp2p rpmsg_core gpio_keys pwm_bl smem hid_multitouch fuse i2c_dev [ 15.408928] CPU: 2 UID: 0 PID: 14 Comm: kworker/u32:1 Not tainted 7.1.0+ #2 PREEMPT(lazy) [ 15.408937] Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET88W (1.60 ) 03/14/2024 [ 15.408942] Workqueue: pm pm_runtime_work [ 15.408959] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 15.408967] pc : gdsc_toggle_logic+0x14c/0x160 [ 15.408978] lr : gdsc_toggle_logic+0x14c/0x160 [ 15.408987] sp : ffff8000800f3b40 [ 15.408991] x29: ffff8000800f3b40 x28: 0000000000000000 x27: 0000000000000000 [ 15.409003] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 15.409014] x23: 0000000000000000 x22: 0000000000000001 x21: ffffa33f298fca88 [ 15.409024] x20: 0000000000000000 x19: ffffa33f298fc5b0 x18: 00cd15db75dacefd [ 15.409035] x17: 000000040044ffff x16: ffffa33f3b1a3d88 x15: 726f776b80000002 [ 15.409045] x14: ffffffffffffffff x13: 0000000000000028 x12: 0101010101010101 [ 15.409056] x11: 7f7f7f7f7f7f7f7f x10: fefeff3039313274 x9 : ffffa33f3a5edafc [ 15.409067] x8 : ffff8000800f3780 x7 : 0000000000000001 x6 : 0000000000000001 [ 15.409078] x5 : ffff000bf3ca1288 x4 : 0000000000000000 x3 : ffff5cccb6a3f000 [ 15.409088] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000080ae0000 [ 15.409098] Call trace: [ 15.409103] gdsc_toggle_logic+0x14c/0x160 (P) [ 15.409115] gdsc_disable+0x4c/0x190 [ 15.409126] _genp ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93114", "url": "https://ubuntu.com/security/CVE-2026-93114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/surface: acpi-notify: Check ACPI companion before use Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION(). Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 (\"ACPI: driver: Check ACPI_COMPANION() against NULL during probe\") does for the core ACPI platform drivers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93115", "url": "https://ubuntu.com/security/CVE-2026-93115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93117", "url": "https://ubuntu.com/security/CVE-2026-93117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: fix UAF when probe runs concurrent to dyn ID removal Dynamic IDs are only guaranteed to be valid when usb_dynids_lock is held, as remove_id_store can free the node. Thus, make a copy in usb_probe_interface. Clarify the documentation that the id parameter is only valid during the probe. USB serial has the same pattern, but it does not need fixing as the IDs cannot be removed via sysfs.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93118", "url": "https://ubuntu.com/security/CVE-2026-93118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed_udc: check endpoint DMA allocation ast_udc_probe() allocates a coherent DMA buffer used as the backing store for endpoint buffers. ast_udc_init_ep() derives per-endpoint buffer pointers from udc->ep0_buf, so a failed allocation is dereferenced during probe. Check the allocation before endpoint setup. The existing probe error path called ast_udc_remove(), which unregisters the gadget unconditionally and is not safe before usb_add_gadget_udc() succeeds. Add a local cleanup helper for probe failures so pre-registration failures only unwind the resources that were actually initialized. This was found by a local static analysis checker for unchecked allocator returns while scanning Linux 6.16. The change was checked by applying it to current mainline and by running checkpatch. I do not have access to Aspeed UDC hardware, so no runtime testing was performed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93119", "url": "https://ubuntu.com/security/CVE-2026-93119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: ljca: bound bank_num in ljca_enumerate_gpio() ljca_enumerate_gpio() reads desc->bank_num from the device and loops valid_pin[i] = get_unaligned_le32(...) for i < bank_num. valid_pin[] holds only LJCA_MAX_GPIO_NUM / 32 = 2 entries. Two checks run before the loop. The reply length must match struct_size(desc, bank_desc, bank_num). The product pins_per_bank * bank_num must not exceed LJCA_MAX_GPIO_NUM. Neither one bounds bank_num against the size of valid_pin[]. The reply is capped at LJCA_MAX_PAYLOAD_SIZE (60) bytes, so the struct_size check limits bank_num to 9. A device that reports bank_num 9 with pins_per_bank 7 still passes both checks. gpio_num is 63 and the reply is 56 bytes. The loop then writes nine u32 into the two entry array and overruns valid_pin[] on the stack. A broken or malicious LJCA device can therefore overflow the stack. Reject a bank_num that does not fit valid_pin[].", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93120", "url": "https://ubuntu.com/security/CVE-2026-93120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: fix out-of-bounds read of qw_sign os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93121", "url": "https://ubuntu.com/security/CVE-2026-93121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix fence cleanup in ffs_dmabuf_transfer() error paths The error paths for endpoint-disabled (ESHUTDOWN) and request-allocation failure (ENOMEM) in ffs_dmabuf_transfer() jump to err_fence_put which calls dma_fence_put() on the fence. However, at that point the fence has only been kmalloc'd — dma_fence_init() has not been called yet, so the refcount and the fence ops are uninitialized. Calling dma_fence_put() on such an object leads to undefined behavior. Use kfree() instead, since the fence is just a plain allocation at this stage, and rename the label to err_fence_free to reflect the actual cleanup action.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93123", "url": "https://ubuntu.com/security/CVE-2026-93123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom-geni: do not advance stale DMA completions The qcom GENI serial DMA TX completion path advances the transmit fifo by the number of bytes recorded in port->tx_remaining. If uart_flush_buffer() runs after the hardware has completed a DMA transfer but before the DMA completion interrupt has been handled, the serial core resets the transmit fifo while port->tx_remaining still describes the old DMA transfer. A previous fix avoided advancing an empty fifo by checking that the fifo length is at least tx_remaining. That still does not distinguish the old DMA payload from new bytes written after the flush. If userspace writes new data before the stale DMA completion interrupt is handled, the fifo can again contain at least tx_remaining bytes and the stale completion can advance and discard those new bytes. Mark an in-flight DMA transfer stale when the transmit fifo is flushed. The later completion still unprepares the original DMA mapping using the saved length, but it no longer advances the transmit fifo.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93126", "url": "https://ubuntu.com/security/CVE-2026-93126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: qcom_q6v5_adsp: Fix reference leak for device node When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In adsp_map_carveout, it does not release the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93128", "url": "https://ubuntu.com/security/CVE-2026-93128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: lg-laptop: Fix LED resource handling The event notification callback might access kbd_backlight even when it was not successfully registered with the LED subsystem. The same happens inside acpi_remove(), where the LED devices are unregistered unconditionally. Fix this by tracking the availability of the kbd_backlight LED device and use devm_led_classdev_register() to let devres take care of unregistering the LED devices during removal. For this the parent device of the LED devices is changed to the native platform device.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93130", "url": "https://ubuntu.com/security/CVE-2026-93130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-base: Fix resource leak on module load failure We need to properly clean up the SMBIOS request and the privacy driver when the module load fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93131", "url": "https://ubuntu.com/security/CVE-2026-93131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-privacy: Fix race condition Accessing priv->features_present needs to happen with the list mutex being held, otherwise priv can be freed at any moment.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93132", "url": "https://ubuntu.com/security/CVE-2026-93132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: RISC-V: Fix riscv_acpi_add_prt_dep() loop handling The loop in riscv_acpi_add_prt_dep() includes error conditions that are handled in a dubious - if not outright wrong - way, by continuining the loop (which skips and misses the entry pointer update to point to the next entry). Rewrite the loop as a for loop (that handles the continuation correctly) and wrap the condition and update statements using helper functions to make it cleaner.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93133", "url": "https://ubuntu.com/security/CVE-2026-93133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: RISC-V: Check acpi_get_handle() status in riscv_acpi_add_prt_dep() In riscv_acpi_add_prt_dep(), the acpi_get_handle() call can fail which would leave link_handle uninitialized. Fix it by checking the acpi_get_handle() return status and skip the entry if it fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93134", "url": "https://ubuntu.com/security/CVE-2026-93134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: printk: Fix possible console use-after-free When emitting a record via legacy printing, it is possible that a handover to another legacy printing context occurs. When a context has performed a handover, the console SRCU read lock is released and the pointer to the console struct might now be invalid. Therefore, after calling nbcon_legacy_emit_next_record() or console_emit_next_record(), it is necessary to check if a handover occurred _before_ further @con usage. Sashiko pointed out that console_flush_one_record() was not doing this. In console_flush_one_record(), after emitting a record, move the further usage of @con after the handover check.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93136", "url": "https://ubuntu.com/security/CVE-2026-93136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: mhi: ep: Fix device refcount leak in the error path of MHI device creation mhi_ep_create_device() takes one device reference for the UL channel and another for the DL channel after allocating the transfer device. These references are normally released by mhi_ep_destroy_device() before the device itself is removed. If dev_set_name() or device_add() fails, the error path currently drops only one reference. The remaining channel references keep the device from being released and leave the channels associated with a device that was never registered. Route both failures through a common unwind path that drops the DL channel reference, the UL channel reference, and the initial reference from device_initialize().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93137", "url": "https://ubuntu.com/security/CVE-2026-93137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free on mm_struct in bpf_find_vma() bpf_find_vma() reads task->mm and calls mmap_read_trylock(mm) without holding a reference on the mm. On a foreign task, a concurrent exit_mm() can free the mm_struct between the lockless read and the trylock, resulting in a use-after-free. mm_struct is not SLAB_TYPESAFE_BY_RCU. For the current task, task->mm is stable. For a foreign task, pin the mm under task->alloc_lock and release it with mmput_async(), mirroring commit d8e27d2d22b6 (\"bpf: fix mm lifecycle in open-coded task_vma iterator\"). Use spin_trylock() instead of get_task_mm() so BPF context does not block on alloc_lock. Reject irqs-disabled contexts and !CONFIG_MMU on the foreign-task path because dropping the mm reference is not safe there. Race: CPU0 (BPF program) CPU1 (exiting task) ============================ ========================== bpf_find_vma(foreign_task): mm = task->mm exit_mm(): task->mm = NULL mmput(mm) -> frees mm_struct mmap_read_trylock(mm) // UAF on mm", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93138", "url": "https://ubuntu.com/security/CVE-2026-93138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the bpf_verifier_lock, but publishes the result through a plain store and re-checks it through a plain lockless load. Nothing orders the stores initializing the struct btf inside btf_parse_vmlinux() against the store publishing the pointer: On a weakly ordered arch, a concurrent first-time caller taking the lockless fast path could in principle observe the pointer before the parsed contents are visible. The mutex_unlock() does not help such a reader given it only synchronizes with a later acquisition of the same lock. Thus, publish the pointer with smp_store_release() and read it on the fast path with smp_load_acquire(). Acquire semantics are needed rather than a dependency-ordered READ_ONCE(): btf_parse_vmlinux() also populates globals outside the returned object (e.g. bpf_ctx_convert.t). An address dependency would only order accesses performed through the pointer and not cover other globals.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93140", "url": "https://ubuntu.com/security/CVE-2026-93140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 (\"udf: Mark LVID buffer as uptodate before marking it dirty\"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 udf_reconfigure+0x336/0x540 fs/udf/super.c:679 reconfigure_super+0x232/0x8f0 fs/super.c:1080 vfs_cmd_reconfigure fs/fsopen.c:268 [inline] vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297 __do_sys_fsconfig fs/fsopen.c:463 [inline] __se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350 do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93141", "url": "https://ubuntu.com/security/CVE-2026-93141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: r8a66597: avoid double free of ep0_req in probe error path If usb_add_gadget_udc() fails, r8a66597_probe() jumps to err_add_udc and frees ep0_req, then falls through to clean_up2 where ep0_req is freed again when it is non-NULL. Remove the redundant free from err_add_udc and keep the cleanup in clean_up2 so the request is released exactly once. Issue found using a prototype static analysis tool and confirmed by code review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93142", "url": "https://ubuntu.com/security/CVE-2026-93142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/rcar: Fix error checking in probe() This code accidentally calls thermal_zone_device_enable() before checking whether thermal_zone_device_register_with_trips() failed. Move the call until later to avoid an error pointer dereference of \"priv->zone\". The driver works differently depending on if we are using OF thermal or not. We use thermal_add_hwmon_sysfs() if we are using OF thermal and call thermal_zone_device_enable() if not. We can share same error check for if either of these fail. Moving the thermal_zone_device_enable() call is a bit cleaner as well. The original code used a three step process to cleanup: 1. Call thermal_zone_device_unregister() to cleanup. 2. Set priv->zone to an error pointer to preserve the error code. 3. Set priv->zone to NULL to avoid a second call to thermal_zone_device_unregister() in the rcar_thermal_remove() function. Now we can just do a direct goto error_unregister and rcar_thermal_remove() handles the cleanup properly.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93143", "url": "https://ubuntu.com/security/CVE-2026-93143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: media: ipu7: fix pm_runtime refcount leak in ipu7_resume() ipu7_resume() calls pm_runtime_get_sync() before resuming the device. If the runtime PM resume fails, the usage count remains incremented, but the error path returns without dropping the reference. Use pm_runtime_resume_and_get() instead, which balances the usage count on failure and avoids the leak. Keep returning 0 on error, as resume callbacks should not propagate failures to the PM core, matching the behaviour of the ipu6 driver.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93145", "url": "https://ubuntu.com/security/CVE-2026-93145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister() gdsc_unregister() removes the OF provider entry and tears down the parent/subdomain wiring, but never calls pm_genpd_remove() on the individual generic_pm_domain structures registered by gdsc_init(): \tvoid gdsc_unregister(struct gdsc_desc *desc) \t{ \t\tstruct device *dev = desc->dev; \t\tsize_t num = desc->num; \t\tgdsc_pm_subdomain_remove(desc, num); \t\tof_genpd_del_provider(dev->of_node); \t} That leaves dangling entries on the global gpd_list. After a provider unbind/rebind cycle (deferred-probe replay during early boot, real module unload of a clk driver that owns GDSCs, or an OF-overlay tear- down) the next gdsc_init() will end up trying to re-register a name that is still in the list and pm_genpd_init() returns -EEXIST. While we are here, flip the order so the consumer-facing OF provider entry is the first thing removed -- otherwise a fresh of_genpd_get_from_provider() call racing with the teardown could attach to a domain that is mid-removal. Iterate the scs[] array and pm_genpd_remove() each registered domain after the subdomain links are torn down. The regulators stay devm- managed (devm_regulator_get_optional() in gdsc_register()), so the release happens automatically when the underlying device is unbound; just the genpd accounting needs to be undone explicitly.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93146", "url": "https://ubuntu.com/security/CVE-2026-93146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: time/namespace: Validate nanosecond field in proc_timens_set_offset() The function validates tv_sec to be within [-KTIME_SEC_MAX, KTIME_SEC_MAX] but never validates that tv_nsec is within the valid range of [0, NSEC_PER_SEC-1] before using it in timespec64_add(). timespec64_add() expects both timespec64 structures to have normalized values with tv_nsec in the range [0, 999999999]. If off->val.tv_nsec contains invalid values (negative or >= NSEC_PER_SEC), it could lead to incorrect calculations or unexpected behavior. Add validation to ensure tv_nsec is within the valid range before performing the addition.", "cve_priority": "negligible", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93149", "url": "https://ubuntu.com/security/CVE-2026-93149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: avoid NULL skb in stop queue drain mac80211_hwsim_stop() drops any frames left in data->pending. The loop currently checks skb_queue_empty() and then dequeues separately. That split is racy with TX status handling, which can remove a pending frame under the queue lock. If the last entry is removed after the empty check, skb_dequeue() returns NULL and the stop path passes that NULL skb to ieee80211_free_txskb(). Use skb_dequeue() as the loop condition instead. The dequeue result is the object that stop owns and frees, and a concurrent status completion that empties the queue simply makes the loop terminate.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93150", "url": "https://ubuntu.com/security/CVE-2026-93150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Make nr_deadline_tasks an atomic_t The nr_deadline_tasks variable in the cpuset structure was introduced by commit 6c24849f5515 (\"sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets\"). It is reported by sashiko [1] that nr_deadline_tasks can currently be modified by inc_dl_tasks_cs() under rq->lock and by cpuset_attach() under cpuset_mutex. So if both updates happen simultaneously, the nr_deadline_tasks variable can be corrupted leading to incorrect operations down the road. Fix that by changing its type to atomic_t so that nr_deadline_tasks are always atomically updated. This fix patch is a low hanging fruit. It can handle some of the races between a concurrent sched_setscheduler() and cpuset_can_attach()/cpuset_attach() calls, but not all of them like the other issue raised by sashiko [2]. This will be handled hopefully in a future follow up patch. [1] https://sashiko.dev/#/patchset/20260626181923.133658-1-longman%40redhat.com [2] https://sashiko.dev/#/patchset/20260630033344.352702-1-longman%40redhat.com", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93151", "url": "https://ubuntu.com/security/CVE-2026-93151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: fix response resource leak on queue teardown When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs. These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows: unreferenced object 0xffff88812bc490c0 (size 32): comm \"kworker/2:1H\", pid 409, jiffies 4307744490 backtrace (crc 89afd339): __kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 unreferenced object 0xffff88814bd05e80 (size 64): comm \"kworker/3:1H\", pid 148, jiffies 4295195428 backtrace (crc e35510cb): __kmalloc_noprof+0x5f9/0x890 rdma_rw_ctx_init+0x333/0x1fa0 [ib_core] nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmet_rdma_free_rsp_resources() that frees up the RDMA read/write context and the request SGLs of such responses.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93152", "url": "https://ubuntu.com/security/CVE-2026-93152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-apple: Use acquire/release for queue enabled state apple_nvme_init_queue() initializes queue state and then marks the queue enabled. The interrupt and request paths check enabled before using that queue state. The old wmb() after WRITE_ONCE(enabled, true) does not publish the earlier initialization before enabled becomes visible. Use a release store when enabling the queue and acquire loads when testing it. Although the shutdown-side enabled accesses are not used for publishing queue initialization, use helpers for them as well for consistency.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93154", "url": "https://ubuntu.com/security/CVE-2026-93154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Add refcounting to user ring MRs Prevent userspace from deregistering the MRs that back QP/CQ/SRQ rings by bumping the MR's refcount upon association.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93155", "url": "https://ubuntu.com/security/CVE-2026-93155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Fix AEAD unregister count in error path register_aes_algs() registers the AEAD algorithms before registering the skcipher algorithms. If skcipher registration fails, the function unwinds the earlier AEAD registration with crypto_engine_unregister_aeads(), but it passes ARRAY_SIZE(algs), which is the skcipher table size. Use ARRAY_SIZE(algs_aead) for the AEAD unwind path so the unregister helper iterates over the same table that was registered. Also clarify the nearby comment: the crypto registration helpers clean up algorithms registered within the same call, while this function must still unwind earlier successful registration steps.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93156", "url": "https://ubuntu.com/security/CVE-2026-93156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: rk3288 - fail ahash requests on HASH idle timeout rk_hash_run() waits for RK_CRYPTO_HASH_STS to become idle after the final DMA transfer, but ignores the poll result. If the hash engine never becomes idle, the driver still reads the digest registers and finalizes the request with the previous success value. Store the poll result and finalize the request with the timeout error before reading the digest registers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93157", "url": "https://ubuntu.com/security/CVE-2026-93157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwrng: xilinx-trng - propagate timeout before any data is read xtrng_readblock32() polls for 16-byte chunks but returns the number of bytes read even when the first poll times out. Its caller then treats a zero return as a short successful read, and partial reads for full 32-byte blocks can make the tail copy use a fixed block offset rather than the amount already produced. Return the poll error when no data has been read, preserve partial positive returns after some data is available, stop the generator on all collection exits, and append tail bytes at the current output count.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93158", "url": "https://ubuntu.com/security/CVE-2026-93158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sa2ul - stop probe if context pool creation fails sa_ul_probe() calls sa_init_mem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool. Stop probing when sa_init_mem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93159", "url": "https://ubuntu.com/security/CVE-2026-93159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure The nonblocking RNG path allocates a work_data structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes. If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated work_data is not usable for producing RNG output and must not remain associated with the hwrng state. Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data. Fix this by freeing the pending work_data. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93160", "url": "https://ubuntu.com/security/CVE-2026-93160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-ecc - reject hardware ECDH without a public key The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the private key stored in the device. However, the public key is cached only after atmel_ecdh_set_secret() successfully generated that private key for the current tfm. atmel_ecdh_generate_public_key() already rejects requests when no public key is cached. Add the same check to atmel_ecdh_compute_shared_secret() to prevent the device from using a private key that was not generated for the current tfm.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93161", "url": "https://ubuntu.com/security/CVE-2026-93161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - clear AES key schedule from stack qat_alg_xts_reverse_key() expands the forward XTS AES key on the stack. That schedule contains key material and can remain in the stack frame. Clear the temporary crypto_aes_ctx with memzero_explicit() after the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93162", "url": "https://ubuntu.com/security/CVE-2026-93162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - cancel work on re-enable SR-IOV timeout The QAT reset worker queues SR-IOV reenable work using a work_struct and completion embedded in an on-stack adf_sriov_dev_data. If the completion wait times out, the reset worker can return while device_sriov_wq still holds or executes the stack-backed work item. Cancel the work on the device_sriov_wq on timeout before the stack frame unwinds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93163", "url": "https://ubuntu.com/security/CVE-2026-93163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwrng: core - fix rng list on registration error hwrng_register(rng) does the following: 1. Checks if rng has name and read methods set 2. Checks if the name already exists 3. Adds rng to global rng_list 4. May try to set rng to current_rng If step 4 fails, it returns an error. However, it does not remove the rng from rng_list, causing a dangling reference which can result in use-after-free if the caller frees rng, since registration failed. Add a list_del_init() cleanup step.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93165", "url": "https://ubuntu.com/security/CVE-2026-93165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Fix memory overread in ring handler `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93167", "url": "https://ubuntu.com/security/CVE-2026-93167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: csky: Fix a4/a5 restoration in syscall trace path The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid. The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments. This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with: mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0) Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0. Fix the trace path by loading a4/a5 from pt_regs before changing sp. Tested on: ck860f, linux-4.19.15, C-SKY abiv2", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93169", "url": "https://ubuntu.com/security/CVE-2026-93169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: zynqmp_dma: fix race between runtime PM and device removal In zynqmp_dma_remove(), runtime PM was disabled only after checking state and doing a manual suspend. This can race with runtime PM in the remove/unbind (rmmod) path. Disable runtime PM first, then suspend only if the device is not already suspended. To prevent any further runtime PM transitions.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93170", "url": "https://ubuntu.com/security/CVE-2026-93170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed. The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinx_dma_complete_descriptor() moves completed descriptors to done_list. 4. Channel is marked idle and start_transfer() is called even though active_list still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions. Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93172", "url": "https://ubuntu.com/security/CVE-2026-93172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug We miss a failed allocation check for pgdat->per_cpu_nodestats, which results in a NULL deref when we offset into the per-cpu area. Propagate -ENOMEM up the stack and leave per_cpu_nodestats pointing at boot_nodestats so a later online can retry the allocation. hotadd_init_pgdat() returns NULL on failure, which __try_online_node() already maps to -ENOMEM. On failure nothing needs to be unwound: - the node is never marked online - per_cpu_nodestats is left pointing at boot_nodestats - __add_memory_resource() cleans up pending memblock resources - later online attempts retry the per_cpu_nodestats allocation", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93173", "url": "https://ubuntu.com/security/CVE-2026-93173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf,lsm: Drop bpf_prog_free from sleepable_lsm_hooks __bpf_prog_put_rcu() is the call_rcu() callback for non-sleepable programs. security_bpf_prog_free() called from there fires bpf_prog_free in softirq; if a sleepable LSM prog is attached to that hook, might_fault() BUGs: BUG: sleeping function called from invalid context in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 5038 preempt_count: 101, expected: 0 Call Trace: __bpf_prog_enter_sleepable+0x1cd/0x320 kernel/bpf/trampoline.c:1255 bpf_trampoline_6442549705+0x53/0xd7 security_bpf_prog_free+0xde/0x130 security/security.c:5465 __bpf_prog_put_rcu+0xab/0xd0 kernel/bpf/syscall.c:2365 rcu_do_batch kernel/rcu/tree.c:2617 [inline] handle_softirqs+0x236/0x800 kernel/softirq.c:622 The call_rcu/call_rcu_tasks_trace split reflects the freed program's sleepability, not that of any attached observer. security_bpf_prog_free() also frees prog->aux->security, which has to stay after the grace period, so drop bpf_prog_free from sleepable_lsm_hooks rather than move the call. Non-sleepable observers still run there.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93174", "url": "https://ubuntu.com/security/CVE-2026-93174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Copy per-CPU map value padding in copy_map_value_long() In kernel, per-CPU map elements are stored with round_up(map->value_size, 8) bytes. On UAPI lookup paths, it copies the rounded size for each CPU into a temporary buffer. However, copy_map_value_long() passes 'map->value_size' to bpf_obj_memcpy(). When the map has special fields, bpf_obj_memcpy() copies around those fields with memcpy(), and does not copy the tail padding between 'map->value_size' and round_up(map->value_size, 8). The temporary UAPI lookup buffers are allocated without __GFP_ZERO. As a result, when the per-CPU map's value size is not equal to round_up(map->value_size, 8), UAPI LOOKUP_ELEM and its variants can return stale heap contents from that padding to user space. The same issue applies to bpf_iter for per-CPU maps. Pass round_up(map->value_size, 8) to bpf_obj_memcpy() from copy_map_value_long(), so per-CPU maps both with and without special fields copy the entire per-CPU slot. Remove the now redundant round_up() from bpf_obj_memcpy()'s long_memcpy path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93177", "url": "https://ubuntu.com/security/CVE-2026-93177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup vddInd, vddciInd and mvddInd from VBIOS-parsed tables index into vddc, vddci and vddmem lookup tables without bounds checks across nine sites. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93178", "url": "https://ubuntu.com/security/CVE-2026-93178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup vddInd and vddcInd fields from VBIOS-parsed tables are used to index into voltage lookup tables without a bounds check. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93182", "url": "https://ubuntu.com/security/CVE-2026-93182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix overflow in update_tg_cfs_runnable() A divide-by-zero crash is observed when running hackbench: [14697.488452] CPU: 112 UID: 0 PID: 124791 Comm: hackbench Not tainted 7.1.0-rc2+ [14697.492627] RIP: 0010:propagate_entity_load_avg+0x35f/0x3e0 [14697.506799] [14697.507411] __dequeue_task+0x2b4/0xc70 [14697.508677] dequeue_task_fair+0x36/0x370 [14697.509047] dequeue_task+0x101/0x2f0 [14697.509426] __schedule+0x1b1/0x1a00 [14697.510868] anon_pipe_read+0x3da/0x450 [14697.511400] vfs_read+0x361/0x390 [14697.512053] __x64_sys_read+0x19/0x30 The divide-by-zero happens here: if (scale_load_down(gcfs_rq->load.weight)) { load_sum = div_u64(gcfs_rq->avg.load_sum, scale_load_down(gcfs_rq->load.weight)); } gcfs_rq->load.weight is an insane large value and is truncated to the lower 32 bits by div_u64, which happen to be 0. Using AI for investigation, the cause is a u32 overflow in update_tg_cfs_runnable(), and flat pickup became a victim when using tg_tasks(): u32 new_sum, divider; ... new_sum = se->avg.runnable_avg * divider; <-- boom The following sequence shows how this triggers the crash: propagate_entity_load_avg() update_tg_cfs_runnable() # u32 overflow corrupts runnable_sum __update_load_avg_cfs_rq() ___update_load_avg() # computes insane runnable_avg update_tg_load_avg() # propagates to tg->runnable_avg update_cfs_group() calc_concur_shares() tg_tasks() # long-to-int truncation, negative nr reweight_entity() # corrupted se->load.weight update_load_add() # corrupted cfs_rq->load.weight propagate_entity_load_avg() update_tg_cfs_load() div_u64() # divide-by-zero Fix by widening new_sum from u32 to u64 (no need to force tg_tasks() to return unsigned long after this fix)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93183", "url": "https://ubuntu.com/security/CVE-2026-93183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/lima: call drm_mm_init() with a valid allocation range lima_vm_create() is currently run before va_start and va_end are set up, meaning they are both 0. lima_vm_create() runs drm_mm_init() with them as arguments for the allocator, and if DRM_DEBUG_MM is enabled the DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on exynos4412-odroid-u2: [ 1.736297] ------------[ cut here ]------------ [ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931! [ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 1.750697] Modules linked in: [ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT [ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree) [ 1.769446] Workqueue: events_unbound deferred_probe_work_func [ 1.775261] PC is at drm_mm_init+0x9c/0xa4 [ 1.779339] LR is at lima_vm_create+0x144/0x17c [ ... ] Fix the issue by moving the lima_vm_create() call after va_start and va_end are set up.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93184", "url": "https://ubuntu.com/security/CVE-2026-93184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl_audmix: rework runtime PM handling in probe After pm_runtime_enable() the AUDMIX block is powered off and stays suspended until the first runtime resume. Register writes issued between probe() and the first resume (e.g. from DAPM or ALSA control paths) target unpowered hardware and cause a system hang. Fix this by calling pm_runtime_resume_and_get() immediately after pm_runtime_enable() to power the hardware up and enable its clocks. Release the reference afterwards with pm_runtime_put() to allow the runtime PM framework to suspend the device and switch the regmap to cache-only mode when idle. When CONFIG_PM is disabled or runtime PM is not enabled, pm_runtime_* calls are stubs that do not power up the hardware. Handle this case explicitly by calling fsl_audmix_runtime_resume() directly so the hardware is always initialised and its clocks are enabled, ensuring register accesses succeed regardless of PM configuration.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93185", "url": "https://ubuntu.com/security/CVE-2026-93185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rt700-sdw: always drain jack work on remove rt700_sdw_remove() drains jack_detect_work and jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status() when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as the remove-time guard for draining these work objects. The delayed works are initialized during rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove path should drain work based on whether the work object exists, not on a runtime hardware state bit that can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED, and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a reachable race on current systems.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93186", "url": "https://ubuntu.com/security/CVE-2026-93186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/mbox: Clamp mailbox output allocation to the payload size CXL_MEM_SEND_COMMAND bounds the user's in.size to the mailbox payload size but leaves out.size unbounded, then cxl_mbox_cmd_ctor() calls kvzalloc(out.size). A large out.size drives a huge allocation, above INT_MAX it WARNs and taints, and with panic_on_warn=1 it panics. The transport __cxl_pci_mbox_send_cmd() already clamps the response copy to min(out.size, payload_size, device len), so the output buffer is never written beyond payload_size. Clamp the allocation to payload_size too, matching the RAW path.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93188", "url": "https://ubuntu.com/security/CVE-2026-93188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: bound device-supplied profile index kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93189", "url": "https://ubuntu.com/security/CVE-2026-93189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: quiesce input in hid_hw_stop() to prevent use-after-free A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver. Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path (\"hwmon: prevent packets from going to driver for probe\", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93190", "url": "https://ubuntu.com/security/CVE-2026-93190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_typec: Reject out-of-bounds PD cap count cros_typec_register_partner_pdos() copies the partner PDOs from the EC TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array. \tmemcpy(caps_desc.pdo, resp->source_cap_pdos, \t sizeof(u32) * resp->source_cap_count); \t... \tmemcpy(caps_desc.pdo, resp->sink_cap_pdos, \t sizeof(u32) * resp->sink_cap_count); PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields from the EC. The only check is that they are not both zero. If either is larger than 7, the memcpy writes past the end of the array on the stack. A count of 255 overflows it by about 1 KB. The EC source arrays are only seven entries wide. A larger count reads past them too. The ChromeOS EC firmware caps these counts today, so a compliant setup does not hit this. The kernel should still validate these values rather than trust them. Validate the counts in cros_typec_register_partner_pdos() next to the memcpy. Skip the PDO registration if either count is above PDO_MAX_OBJECTS. The rest of cros_typec_handle_status() still runs so events are handled and cleared.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93191", "url": "https://ubuntu.com/security/CVE-2026-93191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix incorrect task context in smack_msg_queue_msgrcv The smack_msg_queue_msgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task. In the msgsnd() syscall path, if a receiver is already waiting, the pipelined_send() optimization is used to push the message directly to the receiver task: ipc/msg.c`pipelined_send(): ` smp_store_release(&msr->r_msg, msg) In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->r_tsk, passed as the 'target' parameter): ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, target := msr->r_tsk,,) However, smack_msg_queue_msgrcv() ignores the 'target' and checks 'current': smack_msg_queue_msgrcv(…) ` smk_curacc_msq(isp, MAY_READWRITE); // current task 'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy. Test: 1) create a sysv message queue with label “foo” 2) echo \"bar foo r\" >/smack/load2 3) msgrcv(,,,0,MSG_NOERROR) in \"bar\"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a \"foo\"-labeled task: \"bar\"-labeled task gets the message. This patch fixes the issue by checking permission on the 'target' task instead of 'current'. (2008-02-04, Casey Schaufler)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93192", "url": "https://ubuntu.com/security/CVE-2026-93192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Clear queue->active_job when v3d_fence_create() fails The run_job() callbacks for BIN, RENDER, TFU and CSD assign the incoming job to queue->active_job before calling v3d_fence_create(). If v3d_fence_create() fails, the callback returns NULL without clearing active_job, leaving a dangling pointer. Create a failure path in all run_job() callbacks that clears the active job before returning NULL. The BIN path takes queue->queue_lock around the clear as it races against v3d_overflow_mem_work(); RENDER, TFU and CSD paths have no concurrent reader, so the clear is lock-free.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93193", "url": "https://ubuntu.com/security/CVE-2026-93193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Fix OF node reference leak via auto cleanup Sashiko reported a reference leak in rockchip_dp_drm_encoder_enable(), the of_get_child_by_name() function does not call of_node_put() in a symmetrical way [1]. Fix the device node reference leak by using __free(device_node) to automatically manage of_node_put() for all device nodes.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93194", "url": "https://ubuntu.com/security/CVE-2026-93194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: dw_dp: Release core resources Core resources such as the DisplayPort AUX channel get initialized and registered during dw_dp_bind(), but are never unregistered, which may lead to memory leaks and/or use-after-free: [ 224.661371] BUG: KASAN: slab-use-after-free in device_is_dependent+0xe0/0x2b0 [ 224.662015] Read of size 8 at addr ffff00011aee8550 by task modprobe/658 [ 224.662612] [ 224.662752] CPU: 7 UID: 0 PID: 658 Comm: modprobe Not tainted 7.0.0-rc2-next-20260305 #14 PREEMPT [ 224.662759] Hardware name: Radxa ROCK 5B (DT) [ 224.662762] Call trace: [ 224.662764] show_stack+0x20/0x38 (C) [ 224.662772] dump_stack_lvl+0x6c/0x98 [ 224.662777] print_report+0x160/0x4b8 [ 224.662783] kasan_report+0xb4/0xe0 [ 224.662790] __asan_report_load8_noabort+0x20/0x30 [ 224.662796] device_is_dependent+0xe0/0x2b0 [ 224.662802] device_is_dependent+0x108/0x2b0 [ 224.662808] device_link_add+0x1f8/0x10b0 [ 224.662813] devm_of_phy_get_by_index+0x120/0x200 [ 224.662819] dw_dp_bind+0x34c/0xb10 [dw_dp] [ 224.662830] dw_dp_rockchip_bind+0x194/0x250 [rockchipdrm] [ 224.662864] component_bind_all+0x3a8/0x720 [ 224.662869] rockchip_drm_bind+0x120/0x390 [rockchipdrm] [ 224.662899] try_to_bring_up_aggregate_device+0x76c/0x838 [ 224.662904] component_master_add_with_match+0x1f4/0x230 [ 224.662909] rockchip_drm_platform_probe+0x420/0x538 [rockchipdrm] [ 224.662939] platform_probe+0xe8/0x168 [ 224.662945] really_probe+0x340/0x828 [ 224.662950] __driver_probe_device+0x2e0/0x350 [ 224.662954] driver_probe_device+0x80/0x140 [ 224.662959] __driver_attach+0x398/0x460 [ 224.662964] bus_for_each_dev+0xe0/0x198 [ 224.662968] driver_attach+0x50/0x68 [ 224.662972] bus_add_driver+0x2a0/0x4c0 [ 224.662977] driver_register+0x294/0x360 [ 224.662982] __platform_driver_register+0x7c/0x98 [ 224.662987] rockchip_drm_init+0xc4/0xff8 [rockchipdrm] Since a previous commit exported dw_dp_unbind() function in DW DP core library to take care of the necessary cleanup, use this in the component's unbind() callback, as well as in its bind() error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93195", "url": "https://ubuntu.com/security/CVE-2026-93195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: synopsys: dw-dp: Support unregistering the AUX channel The DisplayPort AUX channel gets initialized and registered during dw_dp_bind(), but it is never unregistered, which may lead to resource leaks and/or use-after-free. Add the missing dw_dp_unbind() function to allow the users of the library to handle the required cleanup, i.e. unregister the AUX adapter.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93198", "url": "https://ubuntu.com/security/CVE-2026-93198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-pcache: validate the persisted dirty_tail chain at load The writeback worker follows the persisted dirty_tail chain, which is decoded from the cache device independently of the key_tail chain that cache_replay() walks and bounds. A crafted image, whose on-media fields are authenticated only by a crc32c with a fixed seed, can aim dirty_tail at a chain of last ksets that never terminates, so cache_writeback_fn() re-arms itself with no delay forever. Walk the dirty_tail chain once at load with the same hop cap cache_replay() uses and fail the table load with -EIO if it does not reach an end within n_segs hops.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93200", "url": "https://ubuntu.com/security/CVE-2026-93200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix use-after-free of master->this sysfs attribute callbacks for the master controller device dereference master->this. However, master->this is freed in i3c_master_detach_free_devs() before the master device itself is released. As a result, sysfs accesses can dereference a freed master->this pointer, leading to a use-after-free. Keep master->this alive until i3c_masterdev_release(), which is called after the master device and its sysfs state are being torn down. Do not free master->this as part of the normal device detach path. On the error path in i3c_master_set_info(), reset master->this and bus.cur_master to NULL before freeing the allocated device.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93199", "url": "https://ubuntu.com/security/CVE-2026-93199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Do not treat master device as a duplicate target i3c_master_search_i3c_dev_duplicate() searches the bus for another I3C device with the same PID as the reference device. The search can match master->this, causing the controller itself to be returned as a duplicate. Since the controller is not a target device, it cannot be a duplicate of one. Exclude master->this from matching so that the function only returns real duplicate target devices.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93196", "url": "https://ubuntu.com/security/CVE-2026-93196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm: virtio_pmem: refcount requests for token lifetime KASAN reports slab-use-after-free in __wake_up_common(): BUG: KASAN: slab-use-after-free in __wake_up_common+0x114/0x160 Read of size 8 at addr ffff88810fdcb710 by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-next-20260220-00006-g1eae5f204ec3 #4 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Call Trace: dump_stack_lvl+0x6d/0xb0 print_report+0x170/0x4e2 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __virt_addr_valid+0x1dc/0x380 kasan_report+0xbc/0xf0 ? __wake_up_common+0x114/0x160 ? __wake_up_common+0x114/0x160 __wake_up_common+0x114/0x160 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 __wake_up+0x36/0x60 virtio_pmem_host_ack+0x11d/0x3b0 ? sched_balance_domains+0x29f/0xb00 ? __pfx_virtio_pmem_host_ack+0x10/0x10 ? _raw_spin_lock_irqsave+0x98/0x100 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 vring_interrupt+0x1c9/0x5e0 ? __pfx_vp_interrupt+0x10/0x10 vp_vring_interrupt+0x87/0x100 ? __pfx_vp_interrupt+0x10/0x10 __handle_irq_event_percpu+0x17f/0x550 ? __pfx__raw_spin_lock+0x10/0x10 handle_irq_event+0xab/0x1c0 handle_fasteoi_irq+0x276/0xae0 __common_interrupt+0x65/0x130 common_interrupt+0x78/0xa0 virtio_pmem_host_ack() wakes a request that has already been freed by the submitter. This happens when the request token is still reachable via the virtqueue, but virtio_pmem_flush() returns and frees it. Fix the token lifetime by refcounting struct virtio_pmem_request. virtio_pmem_flush() holds a submitter reference, and the virtqueue holds an extra reference once the request is queued. The completion path drops the virtqueue reference, and the submitter drops its reference before returning.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93202", "url": "https://ubuntu.com/security/CVE-2026-93202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix recursive locking during device registration i3c_master_register_new_i3c_devs() registers newly discovered devices while holding i3c_bus_normaluse_lock(), a down_read(). device_register() can immediately probe the device, and probe callbacks typically invoke I3C helpers that take i3c_bus_normaluse_lock() again, leading to a recursive acquisition of the same rwsem. rwsems do not support recursive read locking and can deadlock when a writer is waiting. See the \"Recursive read locks\" section of Documentation/locking/lockdep-design.rst. For example, with Intel LPSS I3C, LOCKDEP generates a WARNING like: # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/unbind # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/bind WARNING: possible recursive locking detected kworker/5:1/94 is trying to acquire lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_device_match_id+0x45/0x370 but task is already holding lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_master_reg_work_fn+0x21/0x5f0 Fix this by separating device creation from device registration. Populate desc->dev under the maintenance lock, collect the devices that still need registration into a local list, then release the lock before calling device_register(). Finally retake the lock and clean up any devices that failed to register. Use the maintenance lock rather than the normal-use lock while adding device objects. A write-side maintenance lock prevents readers from observing a partially initialized desc->dev during initial device population, or desc->dev disappearing if registration fails. The local list requires a list node, so add a list node member to struct i3c_device.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93203", "url": "https://ubuntu.com/security/CVE-2026-93203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: avoid CRC corruption due to parallel claim add batadv_bla_add_claim() is used to add claims and modify the backbone of claims for CLAIM frames from remote backbones and local packets. When it handles a claim, it needs to either * add the new claim's CRC to the backbone CRC * remove the already existing claim's CRC from the old backbone and add it to the new backbone But when the \"new\" claim code was running in parallel to the \"change backbone\" code, it can happen that the CRC was invalid because the backbone_gw of the claim was changed twice in the \"new\" claim code path: * CPU0 creates the claim for gateway A and publishes it in the claim hash. The crc16 of the address has not yet been added to A's crc at this point. * CPU1 processes a claim frame of gateway B for the same client, finds the just published claim, and performs the ownership change: it switches the pointer to B, removes the crc16 from A's crc - which never contained it - and adds it to B's crc. * CPU0 continues behind the creation branch, unconditionally switches the pointer back to A without compensating B's crc (its remove_crc is false for the creation path), and finally adds the crc16 to A's crc The CRC is then wrong for both: * claim belongs to A: but CRC is not part of backbone A's CRC * claim doesn't belong to B: CRC is still part of backbone B's CRC This wrong CRC is never recomputated from the stored claims. For local backbone claims, this can also not recovered using syncs. To avoid this, split the functionality in clear separate parts: * new claim which always adds claim CRC to the backbone CRC (but never changes the already set backbone_gw of the claim back) * update of existing claim which automatically changes the backbone_gw entry and only updates both backbone CRCs when there was an actual change", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93204", "url": "https://ubuntu.com/security/CVE-2026-93204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: atomically update mac addresses When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89795", "url": "https://ubuntu.com/security/CVE-2026-89795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: Allow per function PCI slots to fix slot reset on s390 On s390 systems, which use a machine level hypervisor, PCI devices are always accessed through a form of PCI pass-through which fundamentally operates on a per PCI function granularity. This is also reflected in the s390 PCI hotplug driver which creates hotplug slots for individual PCI functions. Its reset_slot() function, which is a wrapper for zpci_hot_reset_device(), thus also resets individual functions. Currently, the pci_create_slot() assigns the same pci_slot object to multifunction devices. This approach worked fine on s390 systems that only exposed virtual functions as individual PCI domains to the operating system. Since commit 44510d6fa0c0 (\"s390/pci: Handling multifunctions\") s390 supports exposing the topology of multifunction PCI devices by grouping them in a shared PCI domain. This creates a problem when resetting a function through the hotplug driver's slot_reset() interface. When attempting to reset a function through the hotplug driver, the shared slot assignment causes the wrong function to be reset instead of the intended one. It also leaks memory as we do create a pci_slot object for the function, but don't correctly free it in pci_slot_release(). Add a flag for struct pci_slot to allow per function PCI slots for functions managed through a hypervisor, which exposes individual PCI functions while retaining the topology. Since we can use all 8 bits for slot 'number' (for ARI devices), change slot 'number' u16 to account for special values PCI_SLOT_PLACEHOLDER and PCI_SLOT_ALL_DEVICES.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89796", "url": "https://ubuntu.com/security/CVE-2026-89796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid infinite kdamond_merge_regions() internal loop Patch series \"mm/damon: unurgent fixes for infinite loop, NULL de-ref and races\", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89804", "url": "https://ubuntu.com/security/CVE-2026-89804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dmem: fix mismatched DMA unmap size for large folios Device-private THP migration maps migration buffers with page_size() and records that length in dma_info->size. For a compound folio page_size() is PAGE_SIZE << order, but two teardown sites still pass a literal PAGE_SIZE to dma_unmap_page(): - nouveau_dmem_migrate_to_ram() on the success path, and - nouveau_dmem_migrate_copy_one() on the copy-error path. For an order > 0 folio this unmaps less than was mapped, leaking the remainder of the IOMMU/IOVA mapping. The other unmap sites, in nouveau_dmem_migrate_chunk() and nouveau_dmem_evict_chunk(), already use the saved size; use it here too.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89809", "url": "https://ubuntu.com/security/CVE-2026-89809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix scope of mqd_mgr dereference in pqm_debugfs_mqds Reading /sys/kernel/debug/kfd/mqds while a process holds an active KFD queue triggers a NULL pointer dereference because the for loop that calls mqd_mgr->debugfs_show_mqd() is incorrectly placed outside the if (pqn->q) block that initializes mqd_mgr. The queue list can contain entries where pqn->q is NULL (kernel queues where only pqn->kq is valid). In the original code: if (pqn->q) { ... mqd_mgr = q->device->dqm->mqd_mgrs[mqd_type]; size = mqd_mgr->mqd_stride(...); } for (xcc = 0; xcc < num_xccs; xcc++) { // WRONG: outside if block mqd = q->mqd + size * xcc; r = mqd_mgr->debugfs_show_mqd(m, mqd); } When iterating over a queue node where pqn->q is NULL: 1. The if (pqn->q) block is skipped 2. mqd_mgr remains uninitialized (NULL from declaration) 3. The for loop executes anyway 4. mqd_mgr->debugfs_show_mqd(m, mqd) dereferences NULL The crash manifests as: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode RIP: 0010:0x0 Call Trace: pqm_debugfs_mqds+0x10c/0x1d0 [amdgpu] kfd_debugfs_mqds_by_process+0x9b/0x110 [amdgpu] seq_read_iter+0x132/0x4b0 ... Fix by moving the for loop inside the if (pqn->q) block, so mqd_mgr and related variables are only used when properly initialized. (cherry picked from commit 8bfe29d5c798940f797aa24135d2734c3ffce9de)", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89812", "url": "https://ubuntu.com/security/CVE-2026-89812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: force complete the MES ring fences on reset The MES scheduler ring has no drm scheduler (no_scheduler = true), so it is skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). It uses a polling fence whose hw value lives in wb (GTT) memory and survives a MODE1 reset, while fence_drv.sync_seq keeps advancing for every packet. When the reset is triggered because MES itself stopped responding, the timed-out packets advance sync_seq past the last hw fence value MES wrote. After resume the first MES submission polls forever on a seq that is never written back, failing the resume and wedging the box on a second reset: amdgpu: MES ring buffer is full. amdgpu: *ERROR* ring gfx_0.0.0 test failed (-110) amdgpu: resume of IP block failed -110 amdgpu: GPU reset end with ret = -110 Force complete the MES scheduler ring fences together with the scheduler rings so their hw fence is realigned to sync_seq. v2: cover all XCCs (one scheduler ring each), not just mes.ring[0].", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89813", "url": "https://ubuntu.com/security/CVE-2026-89813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: force complete the KIQ ring fences on reset Like the MES scheduler ring, the KIQ ring sets no_scheduler = true and uses a polling fence, so it is skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). Its hw fence value lives in wb (GTT) memory and survives a MODE1 reset while fence_drv.sync_seq keeps advancing, so after a reset the first KIQ submission can poll forever on a seq that is never written back. Force complete the KIQ ring fences too so their hw fence is realigned to sync_seq.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89815", "url": "https://ubuntu.com/security/CVE-2026-89815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Drop tt->restore after successful restore ttm_pool_restore_and_alloc() can successfully complete the restore process via ttm_pool_restore_commit(), but tt->restore is not dropped afterward. As a result, subsequent backup/restore flows observe what appears to be a completed restore, while in reality shmem handles are still installed in tt->pages, leading to the stack trace below. Fix this by freeing and dropping tt->restore in ttm_pool_restore_and_alloc() upon successful completion of the restore. 20545 [  309.784531] RIP: 0010:sg_alloc_append_table_from_pages+0x38c/0x490 20547 [  309.809570] RSP: 0018:ffffc9000623b838 EFLAGS: 00010206 20548 [  309.814827] RAX: 0000000000001000 RBX: ffff88816e42a160 RCX: 0000000000000000 20549 [  309.821986] RDX: 0000000000002000 RSI: 0000000000000003 RDI: 0000000000001000 20550 [  309.829147] RBP: ffff88816e42a168 R08: 0000000000000002 R09: 000000007ffff000 20551 [  309.836310] R10: ffffc9000623b928 R11: 0000000000000000 R12: 000000007ffff000 20552 [  309.843471] R13: ffff88815ba5a100 R14: 0000000000000000 R15: 0000000000000001 20553 [  309.850634] FS:  00007f9ff305e700(0000) GS:ffff888276c94000(0000) knlGS:0000000000000000 20554 [  309.858749] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 20555 [  309.864519] CR2: 00007f9fca701000 CR3: 00000001565e2005 CR4: 0000000008f70ef0 20556 [  309.871678] PKRU: 55555558 20557 [  309.874403] Call Trace: 20558 [  309.876866]  20559 [  309.878988]  sg_alloc_table_from_pages_segment+0x60/0x100 20560 [  309.884415]  ? ttm_resource_manager_usage+0x36/0x60 [ttm] 20561 [  309.889845]  ? xe_tt_map_sg+0x7d/0xd0 [xe] 20562 [  309.894045]  xe_tt_map_sg+0x7d/0xd0 [xe] 20563 [  309.898037]  xe_bo_move+0x927/0xaa0 [xe] 20564 [  309.902029]  ttm_bo_handle_move_mem+0xba/0x170 [ttm] 20565 [  309.907022]  ttm_bo_validate+0xbe/0x190 [ttm] 20566 [  309.911405]  xe_bo_validate+0x9a/0x120 [xe] 20567 [  309.915663]  xe_gpuvm_validate+0xd9/0x140 [xe] 20568 [  309.920206]  drm_gpuvm_validate+0x2f0/0x5b0 [drm_gpuvm] 20569 [  309.925459]  ? drm_exec_lock_obj+0x63/0x210 [drm_exec] 20570 [  309.930627]  xe_vm_validate_rebind+0x46/0xb0 [xe] 20571 [  309.935428]  xe_exec_fn+0x20/0x40 [xe] 20572 [  309.939249]  drm_gpuvm_exec_lock+0x78/0xc0 [drm_gpuvm] 20573 [  309.944410]  xe_validation_exec_lock+0x5a/0xa0 [xe] 20574 [  309.949385]  xe_exec_ioctl+0x806/0xc30 [xe] 20575 [  309.953639]  ? ttwu_queue_wakelist+0xd9/0xf0 20576 [  309.957935]  ? __pfx_xe_exec_fn+0x10/0x10 [xe] 20577 [  309.962449]  ? __wake_up_common+0x73/0xa0 20578 [  309.966482]  ? __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20579 [  309.971263]  drm_ioctl_kernel+0xa3/0x100 20580 [  309.975209]  drm_ioctl+0x213/0x440 20581 [  309.978637]  ? __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20582 [  309.983415]  xe_drm_ioctl+0x67/0xd0 [xe] 20583 [  309.987408]  __x64_sys_ioctl+0x7f/0xd0", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89827", "url": "https://ubuntu.com/security/CVE-2026-89827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid force-completing uninitialized UVD rings uvd_v7_0_sw_init() does not initialize the UVD decode ring for an SR-IOV VF. However, amdgpu_uvd_resume() unconditionally force-completes the decode ring when restoring its fence sequence. Skip fence completion when the fence driver is not initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89831", "url": "https://ubuntu.com/security/CVE-2026-89831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: protect critical_task_priority updates with s_umount The sysfs store path already takes s_umount for GC thread control entries, and ckpt_thread_ioprio is covered as well. critical_task_priority also updates checkpoint or GC kthread scheduling state, but it is not covered by that serialization. It can race with remount or teardown paths that are stopping those threads. Protect critical_task_priority sysfs writes with s_umount too.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89836", "url": "https://ubuntu.com/security/CVE-2026-89836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix folio_nr_pages() race after put in large folio invalidate Our v6.18 based Android system is continuely suffering livelock and bad page stat as shown in[1] which related to broken xarray slot status. By investigating big folio operations within f2fs, we find below races and fix it by get the nr_pages before drop the refcount and folio_lock. f2fs_get_read_data_folio() calls f2fs_folio_put() before folio_nr_pages() when invalidating a large folio from the page cache. That unlocks the folio and drops the caller reference, leaving a window where a concurrent truncate or folio split can shrink the compound folio or free it before the invalidate range is computed. An undersized range then leaves split sub-folios in mapping->i_pages, which can later interact badly with truncate and reclaim (stale xarray entries and bad page state when folio->mapping no longer matches the mapping being truncated). [1] PID: 2594 TASK: ffffff8169b81580 CPU: 7 COMMAND: \"Thread-3\" #0 [ffffffc08ef2b8a0] xas_load at ffffffe52d1f42a4 #1 [ffffffc08ef2b900] find_get_entries at ffffffe52c185798 #2 [ffffffc08ef2bb60] truncate_inode_pages_range at ffffffe52c19e83c #3 [ffffffc08ef2bbc0] truncate_inode_pages_final at ffffffe52c19ec2c #4 [ffffffc08ef2bc20] f2fs_evict_inode at ffffffe52c4c8400 #5 [ffffffc08ef2bcc0] evict at ffffffe52c2de9f4 #6 [ffffffc08ef2bd00] iput at ffffffe52c2db1b4 #7 [ffffffc08ef2bd30] dentry_unlink_inode at ffffffe52c2d7204 #8 [ffffffc08ef2bd50] __dentry_kill at ffffffe52c2d3dcc #9 [ffffffc08ef2bd80] dput at ffffffe52c2d3c3c #10 [ffffffc08ef2bda0] __fput at ffffffe52c2b0a7c #11 [ffffffc08ef2bde0] ____fput at ffffffe52c2b1034 #12 [ffffffc08ef2bdf0] task_work_run at ffffffe52beea200 #13 [ffffffc08ef2be20] exit_to_user_mode_loop at ffffffe52bfbc17c #14 [ffffffc08ef2be80] el0_svc at ffffffe52d1f8e54 #15 [ffffffc08ef2beb0] el0t_64_sync_handler at ffffffe52d1f8d10", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89838", "url": "https://ubuntu.com/security/CVE-2026-89838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: limit recovery filename logging to stored length F2FS stores recovery filenames as a length plus a fixed-size i_name buffer. The buffer is not NUL-terminated, but recover_inode() and recover_dentry() print it with %s. For a 255-byte filename, recovery logging can read past i_name into the following raw inode fields. Print the name with a precision bounded by i_namelen and F2FS_NAME_LEN.", "cve_priority": "negligible", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89840", "url": "https://ubuntu.com/security/CVE-2026-89840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate MOVE_RANGE destination size F2FS_IOC_MOVE_RANGE checks the source range, but not the destination end before updating i_size. A source hole can expose this: __clone_blkaddrs() skips NULL_ADDR entries and returns success, so the caller can still extend the destination inode with unchecked pos_out + len. Reject destination overflow and use inode_newsize_ok() before extending the destination inode.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89859", "url": "https://ubuntu.com/security/CVE-2026-89859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero dport diagnostics buffer to avoid info leak qla2x00_do_dport_diagnostics() allocates the qla_dport_diag response buffer with kmalloc_obj() (non-zeroing) and, on success, copies the full sizeof(*dd) back to user space via sg_copy_from_buffer(). The inbound sg_copy_to_buffer() only fills as many bytes as the user request payload provides, and qla26xx_dport_diagnostics() zeroes only dd->buf. The options and unused[] fields are therefore copied out uninitialized, leaking kernel heap contents to user space. Allocate with kzalloc_obj(), matching qla2x00_do_dport_diagnostics_v2().", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89862", "url": "https://ubuntu.com/security/CVE-2026-89862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix BSG job leak on validate flash image error path qla28xx_validate_flash_image() returns QLA_SUCCESS (0) unconditionally, telling the FC BSG transport (fc_bsg_host_dispatch()) that the driver owns and will complete the request. But bsg_job_done() is guarded by \"if (!rval)\", so on the error path (rval == -EINVAL) neither the driver nor the transport completes the job. The request dangles until it times out, leaking block layer resources. Commit c2c68225b145 (\"scsi: qla2xxx: Fix bsg_done() causing double free\") added the \"if (!rval)\" guard to a batch of BSG handlers. That is correct for handlers that also return the error code (the transport then completes the job once via fail_host_msg), but this function returns QLA_SUCCESS unconditionally, so the guard turned a correct single completion into a leak. Always call bsg_job_done(): bsg_reply->result is DID_OK and the error is reported in vendor_rsp[0], and since the function returns 0 the transport will not complete the job a second time.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89866", "url": "https://ubuntu.com/security/CVE-2026-89866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Resume device before setting EOS flag Setting the EOS flag talks to the firmware via send_firmware_command(), which accesses VPU registers. Both the STREAMOFF path (wave5_vpu_dec_job_abort()) and the V4L2_DEC_CMD_STOP path (wave5_vpu_dec_stop()) can run while the device is runtime suspended, so those register accesses hit powered-down hardware and the SoC raises an asynchronous SError, panicking the kernel: SError Interrupt on CPU3, code 0x00000000bf000000 -- SError send_firmware_command+0x2c/0x160 [wave5] wave5_vpu_dec_set_bitstream_flag+0x6c/0x80 [wave5] wave5_vpu_dec_update_bitstream_buffer+0x80/0xec [wave5] wave5_vpu_dec_job_abort+0x44/0xa0 [wave5] v4l2_m2m_cancel_job+0x110/0x19c [v4l2_mem2mem] v4l2_m2m_streamoff+0x24/0x140 [v4l2_mem2mem] Resume the device with pm_runtime_resume_and_get() around the EOS firmware command and release it with pm_runtime_put_autosuspend(), matching the runtime PM handling already done in wave5_vpu_dec_device_run().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89867", "url": "https://ubuntu.com/security/CVE-2026-89867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Defer job_finish() only when a DEC_PIC was queued Decoder instances sharing a VPU also share one v4l2_m2m job slot, released when the running context calls v4l2_m2m_job_finish(). While draining, device_run() defers job_finish() once EOS is sent (sent_eos), expecting a later finish_decode() (from a DEC_PIC completion IRQ) to release the slot. But the m2m core checks job_ready() only when a job is queued, not when it is dispatched. A job queued while draining can run after finish_decode() has already moved the instance to STOP and sent EOS. device_run() then runs in STOP, issues no DEC_PIC, yet still skips job_finish() - so no IRQ, no finish_decode(), and the shared slot is leaked, stalling every instance. With several v4l2h264dec instances in parallel, GStreamer hangs at EOS. Track whether the run actually queued a DEC_PIC (cmd_issued) and defer job_finish() only then. Otherwise finish the job immediately", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89868", "url": "https://ubuntu.com/security/CVE-2026-89868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Add timeout while stop_streaming When stop_streaming is called, an infinite loop may occur in some cases. Add a bounded poll of the queue status: loop until the queues drain, sleeping briefly between polls, and bail out once VPU_DEC_STOP_TIMEOUT elapses.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89873", "url": "https://ubuntu.com/security/CVE-2026-89873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC EXT SPS RPS counts The HEVC SPS control carries the short-term and long-term RPS counts that decoder drivers use to walk the matching EXT SPS dynamic arrays. Reject SPS values that exceed the HEVC limits of 64 short-term sets and 32 long-term references so drivers cannot later index beyond those controls. Also reject EXT SPS ST RPS entries whose negative or positive picture counts exceed the 16-entry arrays, or whose combined delta-POC count exceeds the HEVC DPB maximum.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89875", "url": "https://ubuntu.com/security/CVE-2026-89875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: quiesce overflow recovery before freeing streams The VIP overflow recovery worker is armed from the hardirq handler when a FIFO overflow is detected, and the list-complete path looks the stream up through the VPDMA list private pointer. Both keep touching stream, port and device state; the recovery worker also resets the parser and VPDMA, repopulates the descriptor list, and re-enables the per-list IRQs. vip_stop_streaming() masks and clears the per-list IRQs, but it neither synchronizes the hardirq handler nor disables recovery_work. An overflow IRQ that has already queued recovery_work, or a list-complete IRQ in flight when the stream is torn down, can therefore still dereference the stream after its resources are released: the descriptor list is freed by vip_release_stream() on file release, and the stream itself by free_stream() on unbind/remove. Drain the recovery worker and the IRQ handler at both teardown points through a shared vip_quiesce_stream() helper, before any stream-owned resource is released. disable_work_sync() cancels pending recovery_work, drains a running instance, and raises its disable depth, so a subsequent schedule_work() issued by a racing IRQ handler is rejected at the workqueue scheduler: recovery_work cannot be requeued after disable_work_sync() takes effect. The worker may still re-enable the per-list IRQs before disable_work_sync() returns; disable_irqs() then masks those sources and synchronize_irq() waits for any in-flight handler that still dereferences stream state. In vip_stop_streaming() the helper runs before the parser is stopped, since a worker drained by disable_work_sync() may re-enable the parser before exiting and would otherwise undo the stop. recovery_work is created disabled and enabled in vip_start_streaming() before IRQs, pairing the enable with the teardown disable across the streaming lifecycle. This issue was found by an in-house static analysis tool and confirmed by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89882", "url": "https://ubuntu.com/security/CVE-2026-89882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rkvdec: hevc: guard INTER_REF_PIC_SET_PRED index underflow st_ref_pic_set_prediction() computes the reference RPS index as st_rps_idx - (delta_idx_minus1 + 1) per HEVC spec equation 7-59. Both operands are u8, so when delta_idx_minus1 + 1 exceeds the current index the subtraction wraps and the subsequent array access at calculated_rps_st_sets[ref_rps_idx] reads far out of bounds. A userspace V4L2 client that can open the RKVDEC m2m decoder can submit an EXT_SPS_ST_RPS control with INTER_REF_PIC_SET_PRED set and delta_idx_minus1 crafted to trigger the underflow. Reject the entry early when the reference index would underflow.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89905", "url": "https://ubuntu.com/security/CVE-2026-89905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Move arena register slot below TCC context Currently, the stack layout places the optional arena register slot above the tail call counter context. When arena_vm_start is dynamically enabled, it shifts the relative offset of the tcc_ptr slot within the stack frame, causing hardcoded tracking macros to mismatch and leading to memory misalignment or corruption potentially. To fix this, move the arena register save and restore sequences below the tail call counter context slots in both build_prologue() and the epilogue. Update __build_epilogue() to insert a proper offset decrement to safely skip the unneeded tcc_ptr reading block while accurately aligning with the relocated arena slot at the very bottom. With this patch, the tcc_ptr slot is always positioned at a fixed distance directly underneath the base callee-saved registers that is independent of whether the arena features are on.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89915", "url": "https://ubuntu.com/security/CVE-2026-89915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Remove VM-wide VNCR mapping counter The global VNCR mapping counter is used to decide whether an L1 provided VNCR page is mapped in L0 on any CPU at the point of dealing with a TLB invalidation. It is incremented when a mapping is made in the fixmap, and decremented when unmapped. As it turns out, this tracking has several flaws: - we are trying to invalidate TLBs, and the mapping is only an opportunistic consequence of the TLB. Checking this counter to decide whether a TLB needs to be invalidated may result in missed invalidations. - an L1 vcpu invalidating its own TLB (a very likely case) will not succeed in invalidating the VNCR pseudo TLB because that page is not mapped in L0 at this stage. Given that this tracking fails at delivering the minimum guarantees that are required and is only a performance optimisation, remove it completely.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89917", "url": "https://ubuntu.com/security/CVE-2026-89917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping While VNCR TLB invalidation always occurs under the MMU lock, vcpu_put() doesn't, while it unmaps the VNCR page. The problem is that the invalidation evaluates vncr_tlb::cpu to decide whether an unmapping needs to take place (cpu != -1) before performing it. On the other hand, this_cpu_reset_vncr_fixmap() unconditionally unmaps if L1_VNCR_MAPPED is set. These two obviously can race, with a TOCTOU pattern on the TLBI path, and a BUG_ON() on the vcpu_put() path. And the two can end-up calling vncr_fixmap(-1), with extra lethal effects. Move the reset of vncr_tlb::cpu to -1 to a common function, and make this update atomic so that only a single thread can reset the field and perform the corresponding unmap. The vcpu_put() still need to unconditionally unmap the current VNCR to close another ugly race. Finally, the assignment of vncr_tlb::cpu is moved to be kept in sync with the actual mapping, similar to L1_VNCR_MAPPED being set.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89919", "url": "https://ubuntu.com/security/CVE-2026-89919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: keyop: use mmu_lock to read gmap->asce Every other dat_* consumer in this file (kvm_s390_get_skeys, set_skeys, get_cmma_bits, set_cmma_bits, MEM_CLR_CMMA, kvm_s390_fixup_prefix, kvm_test_age_gfn, kvm_age_gfn) reads kvm->arch.gmap->asce *inside* the mmu_lock read-side. keyop is the only outlier. gmap->asce is mutated under write_lock(mmu_lock) by gmap_set_limit() and keyop might use a stale asce value for walking as KVM_S390_KEYOP and KVM_S390_VM_MEM_LIMIT_SIZE can run concurrently. This can result in memory corruption.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89921", "url": "https://ubuntu.com/security/CVE-2026-89921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Zero initialize data structures for inject_pfault_token __kvm_inject_pfault_token() only sets .type and .u.ext.ext_params2 of the on-stack struct kvm_s390_irq but the full ext substructure is copied into the cpu local variable on inject. ext_params and pad contain stale stack values. Interrupt delivery only uses ext_params2, so nothing leaks to the guest, but a host user can use the migration ioctls to get to the data. Fix by zero-initializing the irq struct. Do the same for the inti data structure.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89935", "url": "https://ubuntu.com/security/CVE-2026-89935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: apds9306: fix PM reference leak in apds9306_read_data() apds9306_read_data() calls pm_runtime_resume_and_get() but several error paths return directly without calling pm_runtime_put_autosuspend(), leaking the runtime PM reference and preventing the device from autosuspending. Use PM_RUNTIME_ACQUIRE_AUTOSUSPEND() and PM_RUNTIME_ACQUIRE_ERR() to automatically handle runtime PM reference release on all return paths.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89966", "url": "https://ubuntu.com/security/CVE-2026-89966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb_cma: fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio alloc_buddy_hugetlb_folio_with_mpol() can pass a NULL nodemask to alloc_fresh_hugetlb_folio() as a fallback to allocate from all nodes. If order is gigantic, alloc_fresh_hugetlb_folio() propagates the NULL nodemask down to hugetlb_cma_alloc_frozen_folio() via alloc_gigantic_frozen_folio(). Additionally, hugetlb_cma_alloc_frozen_folio() previously attempted allocation on hugetlb_cma[nid] without verifying if nid is included in the caller's nodemask. Adding a node_isset(nid, *nodemask) check ensures the initial preferred node allocation honors the memory policy / nodemask. However, hugetlb_cma_alloc_frozen_folio() dereferences the nodemask in node_isset(nid, *nodemask) and for_each_node_mask(node, *nodemask), leading to a null pointer dereference kernel panic when nodemask is NULL. Fix this by checking if nodemask is NULL in hugetlb_cma_alloc_frozen_folio() and defaulting it to cpuset_current_mems_allowed. Enclose the allocation attempts within the cpuset seqcount retry loop so that if the cpuset changes concurrently during allocation, the attempts are retried using the updated nodemask. This ensures that the initial node check and fallback loop safely honor the task's cpuset without violating cpuset constraints or causing NULL pointer dereferences or unexpected allocation failures. From a userspace perspective, this bug allows an unprivileged user to crash the kernel (trigger a panic) by requesting a gigantic hugepage allocation with MPOL_PREFERRED_MANY on a system where CMA is only configured on a subset of NUMA nodes. This can be reproduced by booting a VM with two NUMA nodes, restricting CMA to Node 1 (e.g., hugetlb_cma=1:1G default_hugepagesz=1G hugepagesz=1G hugepages=0), and running a program that allocates a 1GB hugepage area without reserving, restricts allocation to Node 0 using mbind() with MPOL_PREFERRED_MANY, and triggers a page fault: void *ptr = mmap(NULL, 1UL << 30, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB | MAP_HUGE_1GB | MAP_NORESERVE, -1, 0); unsigned long nodemask = 1; /* Node 0 */ mbind(ptr, 1UL << 30, MPOL_PREFERRED_MANY, &nodemask, sizeof(nodemask) * 8, 0); memset(ptr, 0, 1UL << 30); /* Trigger fault */ This results in a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:hugetlb_cma_alloc_frozen_folio+0x75/0x120 Call Trace: only_alloc_fresh_hugetlb_folio.isra.0+0x2c/0x160 alloc_surplus_hugetlb_folio+0x6d/0x100 alloc_hugetlb_folio+0x3c5/0x660 hugetlb_no_page+0x3d9/0x650", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89967", "url": "https://ubuntu.com/security/CVE-2026-89967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/migrate_device: avoid out-of-bounds writes for compound folios migrate_device_range() and migrate_device_pfns() clear the entries following a compound folio so that the PFN arrays retain their page-granular representation. If a compound folio extends beyond the end of the caller-provided range, the loops clear all following folio entries without limiting them to the number of slots remaining in the npages-sized array, causing an out-of-bounds write. Do not proceed with a compound folio if its page-granular representation does not fit entirely in the remaining PFN array. If this happens, drop any reference and lock acquired for the folio, clear the remaining entries, and stop collecting. Observed with a KASAN x86 QEMU kernel using the HMM migrate_anon_huge_zero selftest. Closing /dev/hmm_dmirror0 after migrating an anonymous huge page to device memory exercises: dmirror_fops_release() -> dmirror_device_evict_chunk() -> migrate_device_range()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89971", "url": "https://ubuntu.com/security/CVE-2026-89971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: skip the zoned limits update if the zone info query failed nvme_query_zone_info() returns either a negative errno or a positive NVMe status code, but nvme_update_ns_info_block() only tests for the negative case: \tret = nvme_query_zone_info(ns, lbaf, &zi); \tif (ret < 0) \t\tgoto out; If the device fails the Identify Namespace (I/O Command Set specific) command, or the Identify Controller command issued by nvme_set_max_append(), the positive status falls through and setup continues with the zero-initialized zone info. nvme_update_zone_info() then marks the queue zoned with chunk_sectors and ns->head->zsze set to zero. blk_validate_zoned_limits() does not check chunk_sectors, so the limits commit succeeds. blk_revalidate_disk_zones() does reject the zero zone size, but by then the limits are live and nothing rolls them back, so I/O keeps being submitted to a zoned queue with a zero zone size and disk_zone_no() shifts by ilog2(0): nvme0n1: Invalid non power of two zone size (0) UBSAN: shift-out-of-bounds in include/linux/blkdev.h:747:16 shift exponent -1 is negative disk_zone_no include/linux/blkdev.h:747 [inline] bio_straddles_zones include/linux/blkdev.h:1058 [inline] blk_zone_wplug_handle_write block/blk-zoned.c:1423 [inline] blk_zone_plug_bio.cold+0x25/0x1c8 block/blk-zoned.c:1605 blk_mq_submit_bio+0x18fb/0x2870 block/blk-mq.c:3196 submit_bh_wbc+0x575/0x740 fs/buffer.c:2824 __block_write_full_folio+0x728/0xdd0 fs/buffer.c:1933 Any device, firmware or NVMe-oF target that fails this one command reaches this. Skip the zoned limits update in that case, and log which of the two things happened: during a revalidation the queue keeps the zone geometry it was last validated with, and on a first scan the namespace is registered without zoned limits, so that it is still available as a handle for admin commands. Neither of the paths in nvme_query_zone_info() that return a positive status logs anything, so the failure would otherwise be silent. zi.zone_size is an exact indicator: every path that returns a positive status returns before it is assigned, and after that the only failure left is -ENODEV, which the caller already handles. Found by FuzzNvme.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89976", "url": "https://ubuntu.com/security/CVE-2026-89976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: fix job completion fence cleanup ethosu_ioctl_submit_job() allocates done_fence before validating buffer handles. Errors after allocation call ethosu_job_err_cleanup(), which frees the job but leaks the uninitialized fence. A scheduler dependency error also lets ethosu_job_run() return before dma_fence_init(). Normal cleanup then passes a zeroed refcount to dma_fence_put(). Release done_fence in the common cleanup path and use dma_fence_was_initialized() to distinguish initialized fences from raw allocations. [robh: also fix goto]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89977", "url": "https://ubuntu.com/security/CVE-2026-89977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: check MMIO mapping errors in probe devm_platform_ioremap_resource() returns an error pointer when the register resource cannot be mapped. ethosu_probe() stores it and continues until initialization dereferences it through MMIO accessors. Return the mapping error before initializing the device.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89978", "url": "https://ubuntu.com/security/CVE-2026-89978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: return early from a zero-length flush SYNC_BO does not constrain its size, so a request for zero bytes reaches drm_clflush_virt_range(), which ends with an unconditional clflushopt(end - 1). For an empty range that is the byte before the mapping, and abo->mem.kva comes from vmap(), so the access lands in the guard page below the vmalloc area and faults: BUG: unable to handle page fault for address: ffffd16fbbc70fff #PF: supervisor read access in kernel mode Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 1000 Comm: sync_bo_probe RIP: 0010:drm_clflush_virt_range+0x3c/0x70 Call Trace: amdxdna_drm_sync_bo_ioctl+0x124/0x430 [amdxdna] drm_ioctl+0x301/0x4c0 __x64_sys_ioctl+0x115/0x2f0 do_syscall_64+0xa6/0x3d0 Any process that can open the render node can do this. Reproduced 3 of 3 times on a Strix Point NPU (1022:17f0), by calling SYNC_BO with size 0 on an AMDXDNA_BO_SHARE object. The import arm takes the same request but flushes the whole scatterlist, so it survives it. Nothing needs flushing for an empty range, so answer before choosing a path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89981", "url": "https://ubuntu.com/security/CVE-2026-89981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Don't read GMID_EL1 when MTE is disabled __cpuinfo_store_cpu() gates the GMID_EL1 read on the raw ID_AA64PFR1_EL1, so it reads the register even when the kernel has disabled MTE (CONFIG_ARM64_MTE=n or arm64.nomte). KVM sets HCR_EL2.TID5 in that case, and pKVM injects an UNDEF the host cannot handle: Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP pc : __cpuinfo_store_cpu+0xf4/0x264 Kernel panic - not syncing: Attempted to kill the idle task! Only pKVM reaches it, and only after a CPU is offlined and brought back online: its CPU_ON relay sets the host HCR before the CPU enters EL1, while plain nVHE sets it at CPUHP_AP_KVM_ONLINE. Gate the read on the CPU's own ID_AA64PFR1_EL1 with the command-line override applied, and on CONFIG_ARM64_MTE, which no register reflects. The boot CPU stores its registers before init_cpu_features() strips an unsafe override, so clamp against the hardware value here too.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89791", "url": "https://ubuntu.com/security/CVE-2026-89791", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: Fix use-after-free when perf mmap() revival races with the last munmap() perf_mmap_close() drops rb->mmap_count *without* holding event->mmap_mutex (the refcount_dec_and_test() right before the refcount_dec_and_mutex_lock() of event->mmap_count). A concurrent perf_mmap_rb() can slot its entire \"revival\" path into that window (perf_mmap holds event->mmap_mutex for its whole duration, including rb_alloc): munmap side (perf_mmap_close) mmap side (perf_mmap_rb) ----------------------------------- -------------------------------- rb->mmap_count 1 -> 0 (no lock) (holds event->mmap_mutex) inc_not_zero(rb->mmap_count) fails ring_buffer_attach(event, NULL) rb_alloc() + attach new rb refcount_set(&event->mmap_count, 1) lock; event->mmap_count 1 -> 0 ring_buffer_attach(event, NULL) ring_buffer_put() -> frees the *new* rb The revival's refcount_set(&event->mmap_count, 1) is an invisible 1 -> 1 write: the close frees the just-revived buffer although the other process still has it mapped -- a page-level use-after-free allowing local privilege escalation to root by any unprivileged user (default kernel.perf_event_paranoid=2). Swap the order of the two counter updates: event->mmap_count is dropped first via refcount_dec_and_mutex_lock(), so its 1 -> 0 transition and the ring_buffer_attach() stay serialized with perf_mmap(). rb->mmap_count == 0 then implies every event using the buffer is detached already, so the result of the rb->mmap_count drop can gate the remaining teardown directly and detach_rest is no longer needed. An earlier fix for this race from Kyle Zeng and David Lee takes event->mmap_mutex around both counter updates [0]; here the not-last close stays lockless.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89987", "url": "https://ubuntu.com/security/CVE-2026-89987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: transfer the pmd dirty bit to the folio on zap zap_huge_pmd_folio() propagates the pmd young bit to the folio for the file case, but not the dirty bit. The pte path does propagate it, in zap_present_folio_ptes() and so does the pmd split path, in __split_huge_pmd_locked(). For most file mappings the omission is harmless, because writing to a shared file mapping goes through page_mkwrite(), which dirties the folio. tmpfs is different: it has no page_mkwrite(), and vma_wants_writenotify() is false for it, so a *read* fault on a MAP_SHARED tmpfs mapping installs a writable pmd via do_read_fault(). do_read_fault() does not call fault_dirty_shared_page(), so subsequent stores through that mapping set only the hardware dirty bit in the pmd and never call folio_mark_dirty(). A shmem folio allocated by a fault is marked uptodate but not dirty (see the clear: block in shmem_get_folio_gfp()), so PG_dirty is never set at all. Unmapping such a folio - munmap(), or exit_mmap() when the process dies - then loses the only record that it was written, because zap_huge_pmd() drops the pmd without transferring the dirty bit. Reclaim afterwards sees a clean shmem folio: the whole swap-out block in shrink_folio_list() is inside \"if (folio_test_dirty(folio))\", so pageout() is skipped and the folio falls into __remove_mapping(). There, folio_is_file_lru() is false for a swapbacked folio, so no shadow entry is created and __filemap_remove_folio(folio, NULL) simply empties the i_pages slot. The data is freed without ever being written to swap, and the next fault on that index returns a freshly zeroed folio. This is silent data loss for any process that keeps state in a MAP_SHARED tmpfs segment across an unmap - for example a cache handed from one process generation to the next through /dev/shm. It requires the folio to be PMD-mapped, so it only shows up once shmem THP is enabled (which is what we did in Meta fleet and started noticing crashes); with THP off the pte path transfers the dirty bit correctly. It also only becomes visible when swap is enabled, because with no swap device shmem folios (which are on the anon LRU) are not scanned by reclaim at all, so the clean folio is never dropped. Reproduced on x86_64 with a tmpfs mounted huge=within_size: read-fault a 2MB-backed region, write a known pattern through the resulting mapping, munmap, force reclaim of the cgroup, then re-map and read back. Without this patch the region reads back as zeros and vmstat shows zswpout 0 - the data was discarded rather than swapped. With this patch the region reads back correctly and the pages are swapped out as expected. With huge=never, or when the first touch is a write, the test passes either way.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89996", "url": "https://ubuntu.com/security/CVE-2026-89996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious \"close it on the failure path\" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/ remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90002", "url": "https://ubuntu.com/security/CVE-2026-90002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Take trace_array reference before accessing its ftrace_ops The trace instance files set_ftrace_filter and set_ftrace_notrace was updated to work with specific trace instances (trace_arrays). The issue is that when these files are opened, there is a small race window where it will use the ftrace_ops from the inode->private pointer to get a reference to the trace_array and then take its reference. The problem is that the ftrace_ops itself could be freed. If the rmdir on the instance happens at the same time the set_ftrace_filter file is opened, the rmdir could have also freed the ftrace_ops and referencing it will cause a use-after-free bug and crash the kernel. Instead, pass in the trace_array as the file private data (NULL for the top level instance), and then pass both the trace_array and the ftrace_ops to the ftrace_regex_open() function. If the trace_array is NULL, then it just uses the ftrace_ops without the need to take its reference (like normal). If the ftrace_ops is NULL, that is only the case for the top level instance and the global_ops can be used. This allows the trace_array to have its reference incremented before touching the ftrace_ops that could also be freed when the instance is.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90013", "url": "https://ubuntu.com/security/CVE-2026-90013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Take trace_array reference when opening options file The options files do not take the trace_array reference for the options they represent. This could cause a use-after-free kernel crash if one of these files is opened by one task and another task removes the instance that the option is for. Because it doesn't take a reference upon opening, it will not stop the removal which will free the options descriptor that is being used. As the options are somewhat dynamic in their creation at boot up, each file represents a flag in the trace_array. The trace_array has an array of indexes to represent each of these flags that is stored in the trace_flags_index array. The address of the index array element is used to pass to the inode->i_private pointer. Then that element is read which holds the index (which represents the flag) and then the index is used to calculate the trace_array descriptor from its trace_flags_index array. One issue is that the index element can not be referenced until the trace_array's reference is taken. To handle this, create a new helper function called: trace_array_options_get() that will iterate all the existing trace_arrays in the ftrace_trace_arrays list (under the trace_types_lock), and compare the passed in address of the index element with the entire array of the trace_array's trace_flags_index array. If it matches, then up the corresponding trace_array's reference and return.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90014", "url": "https://ubuntu.com/security/CVE-2026-90014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Have show_event_filters/triggers files take trace array ref The newly added files show_event_filters and show_event_triggers that show all filters or triggers that are set within the trace array do not take a reference for the trace array it is showing. Without taking a reference, the trace_array may be freed via \"rmdir\" while a task is reading one of theses files. Those files iterate all the events within an instance (trace_array) and nothing prevents that instance from being freed while its data is being read. This causes a use-after-free crash. Have the open of both those files take the trace_array reference via the trace_array_get() that prevents the trace_array from being freed while the files are opened.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90016", "url": "https://ubuntu.com/security/CVE-2026-90016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie() rtw_restruct_wmm_ie() scans in_ie for a WMM IE with: \twhile (i < in_len) { \t\t... \t\tif (i + 5 < in_len && in_ie[i] == 0xDD && ...) { \t\t\t... \t\t\tbreak; \t\t} \t\ti += (in_ie[i + 1] + 2); /* to the next IE element */ \t} When the \"i + 5 < in_len\" match check fails simply because i is within 5 bytes of the end of the buffer (i.e. no WMM IE was found near the tail of in_ie), execution falls through to \"i += (in_ie[i + 1] + 2)\", which reads in_ie[i + 1]. If i == in_len - 1 at that point, this is a 1-byte out-of-bounds read of an attacker-influenced IE buffer built from association/scan data. Commit a75281626fc8f (\"staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie\") added the \"i + 5 < in_len\" guard to the match condition itself, but did not add an equivalent guard before the fallthrough advance, so the same class of OOB read remained reachable through the non-matching path. Add an explicit bounds check before advancing to the next IE.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90023", "url": "https://ubuntu.com/security/CVE-2026-90023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_mass_storage: fix null pointer dereference in fsg_common_set_num_buffers() Previously fsg_num_buffers_validate() was removed as it was not necessary due to Kconfig setting the limits for n from 2 to 256 with default as 2. However, setting the page content in such a way that kstrtou8() reflects n value as either 0 or 1 bypasses these restrictions leading to a null pointer dereference if n is 0. Fix this by adding a check for n < 2 and returning -EINVAL if n is either 0 or 1 consistent with Kconfig logic.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90028", "url": "https://ubuntu.com/security/CVE-2026-90028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: hd3ss3220: track VBUS enable state per consumer regulator_is_enabled() reports the aggregate regulator state, not whether this consumer holds an enable reference. If another consumer enables VBUS first, the driver can skip its own regulator_enable() call and later attempt to drop a reference it never acquired, triggering an unbalanced regulator disable warning. Track successful enable and disable calls locally. Keep the state unchanged when an operation fails so a later role or ID notification retries the operation while this consumer keeps balanced references.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90040", "url": "https://ubuntu.com/security/CVE-2026-90040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped Wire up a gmem_invalidate_range() call for SNP VMs, and use it to force vCPUs to reload/recheck their guest-provided VMSA if the backing gmem page is being invalidated, e.g. is being PUNCH_HOLE'd. Use the same core logic to handle invalidations as VMX does for the APIC-access page, as the two concepts are nearly identical: shove the physical address of a page into the vCPU's control structure: 1. Snapshot the invalidation sequence counter 2. Grab the pfn (from guest_memfd in this case) 3. Acquire mmu_lock for read 4. Re-request reload if retry is needed, otherwise commit the change. Note, the re-request action in #4 is necessary as KVM's retry logic is fuzzy, i.e. can get false positives. If the guest_memfd page has been dropped, at some point a subsequent reload will fail to get a PFN from guest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false positive, KVM will retry until there are no relevant MMU notifier events (and will retry in the \"outer\" loop, i.e. will drop locks and resched as needed). Note #2! Take care to invalidate the VMSA when a relevant memslot is DELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated on memslot bindings (KVM doesn't know what GFN range(s) to invalidate without a binding). And more importantly, the VMSA mapping requires a memslot, i.e. must be invalidated if its memslots disappears, regardless of the state of the underlying guest_memfd inode. Failure to invalidate the vCPU's control.vmsa_pa (which is checked by pre_sev_run()) can prevent KVM from properly freeing the page as firmware will reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU is actively running, i.e. if VMSA page is in-use. That in turn leads to an RMP #PF on the next use, as the page will still be assigned to the SNP VM. SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3 SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f] CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 Call Trace: dump_stack_lvl+0x54/0x70 rmpupdate+0x12c/0x140 rmp_make_shared+0x3b/0x60 sev_gmem_invalidate+0xe0/0x170 [kvm_amd] delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e ------------[ cut here ]------------ SEV: Failed to update RMP entry for PFN 0x78d198 error -14 WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345 CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd] Call Trace: delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e irq event stamp: 20689 hardirqs last enabled at (20699): [] __console_unlock+0x5c/0x60 hardirqs last disabled at (20708): [] __console_unlock+0x41/0x60 softirqs last enabled at (20722): [] __irq_exit_rcu+0x7e/0x140 softirqs last disabled at (20717): [] __irq_exit_rcu+0x7e/0x140 ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: ffff99 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90043", "url": "https://ubuntu.com/security/CVE-2026-90043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix slot lock bit position on big-endian 64-bit The slot lock is a bit operation on the whole __lock word, which flags and ac_time alias as two u32s. On little-endian the lock bit lands in the position ZRAM_ENTRY_LOCK reserves in flags, so the aliasing works out. On 64-bit big-endian it lands in ac_time instead: with ZRAM_TRACK_ENTRY_ACTIME enabled, storing the access time from mark_slot_accessed() or slot_free() wipes out the held lock bit, letting another CPU take the same slot lock; an access time value with that bit set makes the slot look locked forever. Shift the lock bit into the flags half of the word on big-endian 64-bit.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89794", "url": "https://ubuntu.com/security/CVE-2026-89794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: zero pipe read compound padding Compound response handling extends the last response iov to an eight-byte boundary. smb2_read_pipe() allocates only the payload size, so the alignment padding can expose up to seven bytes of uninitialized kernel heap memory. Allocate the aligned size and clear the unused tail before pinning the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89797", "url": "https://ubuntu.com/security/CVE-2026-89797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500_fg: fix use-after-free on remove ab8500_fg_remove() destroys the driver workqueue while the threaded interrupt handlers are still armed; they are devm-managed and freed only after ->remove() returns, so a handler that fires in that window queues work on the freed workqueue. Tear the workqueue down through devm instead, registering its cleanup after the power supply and before the interrupt requests. devm then frees the interrupts first, so the handlers can no longer queue work, before disabling the delayed and plain work items and destroying the workqueue. Disabling the items, rather than cancelling them, keeps them disabled so no producer (including the power-supply external_power_changed callback) can requeue them. Found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-90037", "url": "https://ubuntu.com/security/CVE-2026-90037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during close_lru reaping An nfs4_openowner left on nn->close_lru after its final CLOSE keeps its last closed stateid in oo_last_closed_stid, holding only a raw pointer to its nfs4_client. The laundromat reaps timed-out entries, drops nn->client_lock, and calls nfs4_put_stid(), which dereferences the client through cl_lock. Nothing pins the client across that window, so a concurrent force_expire_client() can free it and nfs4_put_stid() reads freed memory. __destroy_client() hits the same race, walking clp->cl_openowners without cl_lock. Pin the client with cl_rpc_users before dropping client_lock, and skip clients already expiring. __destroy_client() then cleans up its own close_lru entries through release_last_closed_stateid(), so teardown no longer races the laundromat.", "cve_priority": "critical", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90036", "url": "https://ubuntu.com/security/CVE-2026-90036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during blocked-lock reaping A bare lock owner -- its only remaining reference a blocked lock on nn->blocked_locks_lru -- holds a raw pointer to its nfs4_client but no reference keeping the client alive. When the per-net laundromat reaps such a lock, freeing the nbl drops the owner reference held through flc_owner, and the final nfs4_put_stateowner() takes the client's cl_lock. Because the laundromat detaches the nbl first, __destroy_client() no longer finds it, so a concurrent force_expire_client() can free the client before nfs4_put_stateowner() runs, dereferencing cl_lock in freed memory. Pin the client with cl_rpc_users before dropping nn->blocked_locks_lock, and skip clients already expiring, whose blocked locks __destroy_client() frees while holding an owner reference. Take nn->client_lock outside nn->blocked_locks_lock. Every other site holds nn->blocked_locks_lock as a leaf, acquiring no further lock, so placing nn->client_lock outside it cannot form a lock-order cycle.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89520", "url": "https://ubuntu.com/security/CVE-2026-89520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/core: Make core-sched flips wait for in-flight selections Core scheduling's pick_next_task() operates on all sibling rqs under one acquisition of the shared core-wide lock. A ->pick_task() that releases the rq lock leaves every sibling __lock momentarily free, letting __sched_core_flip(false) complete mid-selection and rebind rq_lockp() under it. The selection resumes on the split locks, touching sibling state it no longer protects, and __schedule() finally releases a lock that was never taken while leaking the one that was. Count in-flight core-wide selections in the leader's rq->core_pick_in_flight and make __sched_core_flip() wait for the count to drain. The count only changes under the shared lock, which the flip holds while sampling, so no other ordering is needed. The wait can repeat while selections overlap, but the flip backs off between samples and flips are rare cookie-lifetime events. sched_core_cpu_deactivate() moves the count to the new leader - a stale copy left behind would bias it forever if that CPU later returns as its own leader.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89798", "url": "https://ubuntu.com/security/CVE-2026-89798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: arm rn_done before publishing the notification rpcrdma_rn_register() inserts @rn into rd_xa with xa_alloc() before storing the caller's callback in rn->rn_done. The xarray makes @rn reachable to rpcrdma_remove_one(), which walks rd_xa and invokes rn->rn_done(rn) for every registered notification. A device removal that races a fresh registration can therefore observe @rn with rn_done still NULL, because the notification objects are zero allocated by their owners, and call through a NULL function pointer. Store rn->rn_done before xa_alloc() publishes @rn. The xarray's store-side and load-side ordering then guarantees that any CPU which finds @rn in rd_xa also observes the armed callback. rpcrdma_rn_unregister() treats a non-NULL rn_done as the sentinel for a completed registration, so the early store must not survive a failed registration. Clear rn_done again when xa_alloc() fails. Were it left set, the failed-accept cleanup path would call rpcrdma_rn_unregister() on an @rn that was never inserted, erasing an unrelated rd_xa slot and underflowing rd_kref.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89799", "url": "https://ubuntu.com/security/CVE-2026-89799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disable preemption in bpf_get_stackid The get_perf_callchain call needs disabled preemption plus we need it disabled as long as we access its returned trace entries buffer. Note the bpf_get_stackid_pe function is executed already with preemption disabled.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-90041", "url": "https://ubuntu.com/security/CVE-2026-90041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sony: clean up device list on probe failure sony_input_configured() adds some controllers to sony_device_list before HID core registers their input devices. input_register_device() can fail after the callback returns successfully. sony_probe() then observes that HID_CLAIMED_INPUT is clear and unwinds, but only stops the HID hardware. The devres-managed sony_sc is freed while its list node remains linked, so the next matching controller traverses freed memory. Initialize the list node and device ID to inactive states. Make list removal idempotent and run the driver-private cleanup on every probe failure path. This also makes a second cleanup safe when sony_input_configured() already unwound a partial initialization before sony_probe() handles the missing input claim. Found by 0sec (https://0sec.ai) using automated source analysis; verified against the HID input registration and probe unwind paths.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90042", "url": "https://ubuntu.com/security/CVE-2026-90042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: properly decrypt filenames in vmalloc() buffers The fscrypt subsystem uses the scatterlist crypto API, inheriting its requirement that any buffers are in the linear mapping region. However, the messenger client uses kvmalloc() to create buffers for messages, which will occasionally place those buffers in the vmalloc() region when physical memory fragmentation doesn't permit a large enough kmalloc(). The various callers of ceph_fname_to_usr() directly pass (slices of) raw messages from the MDS without considering that the messages may be in vmalloc() buffers, resulting in oopses especially on non-x86 platforms (see 'Closes:' for more details and a reproducer). Make ceph_fname_to_usr() explicitly tolerant of vmalloc()-allocated fname->ctext, fname->name, and/or oname->name buffers, using `tname` (which, when non-null, must be a linear address; when null, is briefly allocated as necessary) as a bounce buffer to avoid passing any inappropriate addresses to fscrypt_fname_disk_to_usr(). Additionally change parse_reply_info_readdir() -- the only function to supply its own `tname` -- to follow the new \"tname must never come from vmalloc()\" rule by passing NULL when the message is not in the linear region. Though this causes a per-dentry kmalloc()+kfree(), this overhead exists only when processing the minority of messages that spill into vmalloc(). My (crude) testing puts this at only about 1 in 8,000 readdir messages. Still, if the overhead proves unreasonable in the future, it is easy enough to mitigate: a future change could allocate a bounce buffer in parse_reply_info_readdir() and use that as `tname` instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90039", "url": "https://ubuntu.com/security/CVE-2026-90039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Guard admin state-revocation walks with NFSD_NET_UP Writing to /proc/fs/nfsd/unlock_filesystem, or sending the NFSD_CMD_UNLOCK_FILESYSTEM or NFSD_CMD_UNLOCK_EXPORT netlink command, walks the NFSv4 client hash tables to revoke open state and cancel async COPY operations. All three handlers gate that walk on nn->nfsd_serv, but a listener added via portlist or netlink listener_set sets nn->nfsd_serv before any nfsd thread starts. nfsd_startup_net() has not yet allocated nn->conf_id_hashtbl, so the walkers dereference a NULL table. A local administrator with CAP_SYS_ADMIN can crash the kernel this way without ever starting the server. nn->nfsd_serv is set when the service is created, which precedes table allocation. NFSD_NET_UP instead brackets the window where the tables are live: set at the end of nfsd_startup_net() and cleared in nfsd_shutdown_net() after they are freed, both under nfsd_mutex. Gating the three unlock paths on NFSD_NET_UP fixes the startup-time NULL dereference while preserving the earlier post-shutdown use-after-free fix.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90044", "url": "https://ubuntu.com/security/CVE-2026-90044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix Use-After-Free in AIO error path In ffs_epfile_write_iter() and ffs_epfile_read_iter(), when ffs_epfile_io() fails with an error other than -EIOCBQUEUED, the io_data structure (`p`) is freed. However, for AIO operations, the kiocb cancel function was already armed and kiocb->private was set to `p`. If a concurrent cancel operation (such as sys_io_cancel()) executes after ffs_epfile_io() fails but before the function frees `p`, a Use-After-Free can occur when the cancellation handler accesses the freed pointer. To securely fix this race condition, we must properly un-arm the cancellation. Invoking `kiocb->ki_complete()` does exactly this by acquiring `ctx->ctx_lock` and safely removing the kiocb from the active sequence. In doing so, it ensures that a parallel io_cancel can no longer discover the kiocb, effectively closing the race window. We then return -EIOCBQUEUED to notify the VFS layer that the kiocb has been consumed and it should avoid attempting to complete the request again or triggering subsequent completion handlers.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90045", "url": "https://ubuntu.com/security/CVE-2026-90045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: ffs: fix mm lifetime handling io_data stores a pointer to the submitting task's mm_struct, but does not currently hold a reference to it while async requests are pending. This can result in a use-after-free if the task exits before completion handling finishes. Take a reference with mmgrab() when queuing the read request and release it with mmdrop() on request completion.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90046", "url": "https://ubuntu.com/security/CVE-2026-90046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: don't spin_trylock() in NMI on UP Patch series \"mm/page_alloc: fixes for free_pages_nolock() on RT/UP\". Pre-existing bugs found by Sashiko during review of this other series: https://lore.kernel.org/all/20260703-alloc-trylock-v5-0-c87b714e19d3@google.com/ I have not reproduced these bugs, and I suspect there is no real-world user that is affected by them. This patch (of 2): As noted in can_spin_trylock(), using this is unsafe in this context. commit 620b46ed6ae17 (\"mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP\") fixed this on the alloc side but missed the free side. Impact: If BPF programs using these features in NMI (probably tracing) are present on non-SMP builds this might crash the kernel and is probably exploitable by local attackers for privilege escalation.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80926", "url": "https://ubuntu.com/security/CVE-2026-80926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in oplock break notification smb2_oplock_break_noti() reads opinfo->conn without any lock and dereferences it after two allocations which may sleep. When the durable handle owning the oplock is disconnected, session_fd_check() clears opinfo->conn and drops its conn reference under ci->m_lock, and the last ksmbd_conn_put() frees the connection. A break triggered by another connection that races with the teardown can then resurrect the freed connection: ksmbd_conn_get() is a plain atomic_inc, and the queued break work later dereferences the stale conn via ksmbd_conn_write(), a use-after-free reachable by any authenticated client holding a durable batch oplock. Thread the caller's inode into the notification path instead of taking a new reference on it. Every caller of oplock_break() already holds a live ksmbd_file (or an explicit ksmbd_inode_lookup_lock() reference, in the parent lease break paths) on the inode that owns the break target's oplock list, so ci cannot be freed during the call, and its lock can be taken without dereferencing opinfo->o_fp, which a concurrent close may free. Select and pin the connection under ci->m_lock, the same lock session_fd_check() and ksmbd_reopen_durable_fd() use to update opinfo->conn, so a concurrent detach either loses the race to the clear or keeps the connection alive until the notification work releases it. Transfer the reference to the work item and release it on allocation failures.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-89800", "url": "https://ubuntu.com/security/CVE-2026-89800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSE A successful OP_UNMAP_SPARSE marks its region dirty with nouveau_uvma_region_dirty() and defers the teardown to nouveau_uvmm_bind_job_cleanup(); it does not remove the region from uvmm->region_mt. If a later op in the job fails, the unwind path never clears reg->dirty (set in one place, cleared nowhere) and sets op->reg = NULL, so cleanup skips the teardown. The region is left in the tree with dirty set and its completion never signalled. Later binds over that range then fail permanently -- -ENOENT or -EINVAL from the dirty checks, or an unkillable wait_for_completion() in bind_validate_region() -- for the lifetime of the uvmm. Clear reg->dirty when the unwind reverts the sparse unmap, restoring the region to the state it was found in.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89801", "url": "https://ubuntu.com/security/CVE-2026-89801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: fix premature region free on failed OP_UNMAP_SPARSE In nouveau_uvmm_bind_job_submit()'s OP_UNMAP_SPARSE arm, op->reg is set from nouveau_uvma_region_find(), which only looks the region up and takes no reference; a region's sole reference is its membership in uvmm->region_mt. Two failure paths leave op->reg set: the -ENOENT check when the region is busy, and the drm_gpuvm_sm_unmap_ops_create() failure. The sibling nouveau_uvmm_sm_unmap_prepare() failure just below clears op->reg; these two do not. unwind_continue steps back one op, so the failing op is skipped by the unwind loop and its op->reg stays set. nouveau_uvmm_bind_job_cleanup() then enters its if (op->reg) branch and calls nouveau_uvma_region_remove() and nouveau_uvma_region_put() on it, dropping the tree's sole reference and freeing a region this job never created. The comment above the cleanup loop documents the broken invariant: op->reg must be NULL on submit failure. This frees a live region on an unrelated failure, reachable single-job when drm_gpuvm_sm_unmap_ops_create() returns -ENOMEM; if another job owns the same region, its cleanup then removes and puts the freed region, a use-after-free. Clear op->reg on both failure paths.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89802", "url": "https://ubuntu.com/security/CVE-2026-89802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: fix NULL deref unwinding an OP_MAP_SPARSE op Each bind_job_op is zeroed by kzalloc_obj() in bind_job_op_from_uop(), and the OP_MAP_SPARSE case in nouveau_uvmm_bind_job_submit() only creates a region, so op->ops stays NULL for a successfully processed sparse map. If a later op in the same job fails, the reverse unwind loop revisits that op and calls drm_gpuva_ops_free(&uvmm->base, op->ops) unconditionally. drm_gpuva_ops_free() dereferences its argument right away (list_for_each_entry_safe on &ops->list), so a NULL op->ops oopses. The path is reachable by any render-node fd holder, since NOUVEAU_VM_BIND is DRM_RENDER_ALLOW. Guard the free with IS_ERR_OR_NULL(), as nouveau_uvmm_bind_job_cleanup() already does for the identical free.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89803", "url": "https://ubuntu.com/security/CVE-2026-89803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: unsubscribe the channel-kill event before the fence context nouveau_channel_del() tears the fence context down first and only drops the channel-kill subscription later, in the middle of the nvif object teardown: \tif (chan->fence) \t\tnouveau_fence(chan->cli->drm)->context_del(chan); \t... \tnvif_object_dtor(&chan->vram); \tnvif_event_dtor(&chan->kill); The subscribed handler is nouveau_channel_killed(), which calls nouveau_channel_kill() and from there nouveau_fence_context_kill() on chan->fence. A kill event delivered in that window takes fctx->lock and walks fctx->pending on a fence context that context_del() has already freed. Nothing reaches this below Fermi today, because the subscription is gated on FERMI_CHANNEL_GPFIFO and nothing kills a channel there. On Fermi and newer the window is real but narrow, since a kill has to land exactly while the channel is being destroyed. That is reason enough on its own, which is why this carries a Fixes: tag. The last patch in this series subscribes Tesla channels as well; nothing kills those today, so it does not widen the exposure now, but it is the groundwork for a recovery path that would, and the ordering is better fixed before that lands than alongside it. Drop the subscription before anything it depends on is torn down.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89806", "url": "https://ubuntu.com/security/CVE-2026-89806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: ofdrm: Fix integer overflow in fb_size calculation The framebuffer size calculation `fb_size = linebytes * height` can overflow when both values are large (e.g., 46341 * 46341 > INT_MAX). Since linebytes and height are both int types, the multiplication is performed as int * int, which results in undefined behavior on overflow. Use check_mul_overflow() to detect and prevent this overflow, consistent with the approach used in simpledrm.c and corebootdrm.c.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89807", "url": "https://ubuntu.com/security/CVE-2026-89807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: guard against NULL restore_mqd in CRIU queue restore Both create_queue_cpsch() and create_queue_nocpsch() unconditionally call mqd_mgr->restore_mqd() when a CRIU restore is in progress (qd != NULL), with no NULL guard. On any system where restore_mqd is not implemented for the given queue type, a user holding CAP_CHECKPOINT_RESTORE can trigger a kernel NULL pointer dereference and panic the machine by issuing KFD_IOC_CRIU_OP_RESTORE with a crafted queue restore object. Note that checkpoint_mqd is likewise unimplemented on GFX12, so no legitimate CRIU image can reach this path — only a hand-crafted restore payload. Add a NULL guard for restore_mqd immediately after mqd_mgr is resolved, unwinding via the existing error labels and returning -EOPNOTSUPP if the callback is not implemented. This mirrors the existing checkpoint_mqd guard in checkpoint_mqd().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89808", "url": "https://ubuntu.com/security/CVE-2026-89808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vram When migration vm range is hole at cpu side(MIGRATE_PFN_MIGRATE set + MIGRATE_PFN_VALID unset) driver still allocates device pages. There is no dma map of src pages and migration. j is 0 and svm_migrate_copy_memory_gart() will return an uninitialized r. That can trigger out_free_vram_pages to drop all VRAM just set up. Initialize r and only call the last svm_migrate_copy_memory_gart if j > 0. Current code postponed the last page to the final copy. This patch flushes on the last page when reach to the end of current drm_buddy_block; avoids another svm_migrate_copy_memory_gart.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89810", "url": "https://ubuntu.com/security/CVE-2026-89810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix error path at svm_migrate_copy_to_ram If page migration from device to sys ram fails for some reasons driver needs release and unlock allocated system pages. To do that driver should use page physical address, or pfn, then get struct page*. Current driver uses dma address(for adev) that is not correct with IOMMU enabled, or even in general. The patch releases and unlocks allocated system pages based on where migration failed by struct page* of sys ram pages. Also dma_unmap correspodent system ram pages at error path.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89811", "url": "https://ubuntu.com/security/CVE-2026-89811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Add TLB flush after MES queue eviction/suspension MES (Micro Engine Scheduler) does not perform heavy-weight TLB invalidation after unmapping queues, unlike HWS which does this automatically. This causes a race condition where in-flight DMA descriptors can access memory that has been unmapped, leading to page faults and GPU queue hangs during SVM page migration. The issue manifests as KFDSVMRangeTest.MultiThreadMigrationTest failures on gfx1151 (Strix Point) with XNACK mode 1 enabled - the GPU compute queue hangs with packets submitted but never consumed. Add kfd_flush_tlb() calls after MES queue removal in two locations: - evict_process_queues_cpsch(): after all queues removed during eviction - suspend_queues(): after debug/criu queue suspension (with mem_fence barrier) This ensures all in-flight memory accesses from unmapped queues are flushed before memory is freed or migrated. (cherry picked from commit f5c4f88e0f9c45a8fb9dfac0c1df726c95e41b77)", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89814", "url": "https://ubuntu.com/security/CVE-2026-89814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: clamp the isolation index for rings outside a partition adev->isolation[] has one slot per partition, but a ring that is not assigned to one keeps AMDGPU_XCP_NO_PARTITION, which is ~0, so indexing the array with it is out of bounds. SDMA submissions hit this on both the isolation enforcement and the VM flush path and trip UBSAN. Fall back to the first slot the way the cleaner shader path already does, and stop taking the address before the ring type check that makes it relevant.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89816", "url": "https://ubuntu.com/security/CVE-2026-89816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used Commit 1c6ceeee6ebb (\"drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits\") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89817", "url": "https://ubuntu.com/security/CVE-2026-89817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: NUL-terminate TV mode names read from the device gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89818", "url": "https://ubuntu.com/security/CVE-2026-89818", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn: fix integer overflow in dec_msg buffer count check If the supplied msg[2] (num_buffers) is 0x3FFFFFFF, the expression 6 + num_buffers * 4 wraps to 2 and the bounds check passes, letting the parser loop far past the end of the message BO. Triggering it additionally requires a ~4GiB mapping so that msg[1] survives the earlier \"header does not fit in BO\" check. Rewrite the test in division form, which is overflow-free by construction. Also update the message to reflect that msg is invalid.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89819", "url": "https://ubuntu.com/security/CVE-2026-89819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: validate plane degamma LUT size for private color prop Unlike the CRTC degamma path, which is guarded by amdgpu_dm_verify_lut_sizes(), the per-plane degamma LUT size was never validated before use. __set_dm_plane_degamma() passed the user-supplied size straight into __is_lut_linear() and, for a non-linear LUT, into __set_input_tf() -> __drm_lut_to_dc_gamma(), the latter always iterating MAX_COLOR_LUT_ENTRIES entries regardless of the actual LUT size. A malformed AMD_PLANE_DEGAMMA_LUT blob (e.g. a single entry) could thus trigger a divide-by-zero in __is_lut_linear() or an out-of-bounds read in __drm_lut_to_dc_gamma(). Reject any plane degamma LUT whose size does not match MAX_COLOR_LUT_ENTRIES, mirroring the invariant the code already asserts a few lines below (and which the CRTC path enforces). The AMD_PLANE_DEGAMMA_LUT property is only exposed on builds with AMD_PRIVATE_COLOR defined.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89820", "url": "https://ubuntu.com/security/CVE-2026-89820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix dc_lock leak on GPU reset error paths On GPU reset, dm_suspend() takes dc_lock and leaves it for dm_resume() to drop. If amdgpu_dm_commit_zero_streams() or dm_dmub_hw_init() fails, the function returns with the lock still held. The matching resume path is then skipped, so every later dc_lock take hangs. Release the cached DC state and unlock before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89821", "url": "https://ubuntu.com/security/CVE-2026-89821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid divide-by-zero in __is_lut_linear() __is_lut_linear() computes the expected value of each entry with \texpected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89822", "url": "https://ubuntu.com/security/CVE-2026-89822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Guard against NULL driver_data in i915_pci_probe() pci_match_device() can return the dummy pci_device_id_any entry when a device is force-bound via sysfs driver_override, in which case ->driver_data is unset (NULL). i915_pci_probe() casts it to struct intel_device_info * unconditionally and dereferences intel_info->require_force_probe, causing a NULL-ptr-deref. (cherry picked from commit 2727922084672cc274ecea726ea00363c2893731)", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89823", "url": "https://ubuntu.com/security/CVE-2026-89823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: fix race between partial drm_dev_register() failure and ioctl If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89824", "url": "https://ubuntu.com/security/CVE-2026-89824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel-edp: fix i2c adapter leak on probe failure Make sure to drop the i2c adapter reference on probe failure (e.g. probe deferral) and on driver unbind also if a devicetree redundantly uses the 'ddc-i2c-bus' property to point to the aux ddc bus.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89825", "url": "https://ubuntu.com/security/CVE-2026-89825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: fix firmware control interface bounds checks panthor_init_cs_iface() and panthor_init_csg_iface() validate firmware control interface offsets with 32-bit arithmetic and the size of the host wrapper structures. The offsets are derived from firmware-provided strides, so the arithmetic can wrap before the bounds check, and the host wrapper size is not the size of the firmware control interface being mapped. Use 64-bit arithmetic for the computed offsets and validate against the actual firmware control interface structure sizes with subtraction-based bounds checks. Also validate that the shared section is large enough for the global control interface before using it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89826", "url": "https://ubuntu.com/security/CVE-2026-89826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: harden firmware build-info bounds checks panthor_fw_read_build_info() checks whether the metadata range fits in the firmware image with hdr.meta_start + hdr.meta_size. Both fields are u32, so the addition can wrap and let an out-of-bounds range pass validation. The function also reads the \"git_sha: \" prefix without first checking that the metadata is long enough, and meta_size == 0 can underflow the NULL terminator index. Use subtraction-based bounds checking and reject metadata that is too short to contain the expected prefix and trailing NULL byte.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89828", "url": "https://ubuntu.com/security/CVE-2026-89828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init() drmm_cgroup_register_region() is called before INIT_LIST_HEAD() and gpu_buddy_init() in amdgpu_vram_mgr_init(). If it fails, the function returns early and bypasses those initializations. Since adev->mman.initialized is set to true before amdgpu_vram_mgr_init() is called, a failure triggers amdgpu_ttm_fini(), which calls amdgpu_vram_mgr_fini(), which then: - Calls list_for_each_entry_safe() on reservations_pending and reserved_pages, whose list_head::next pointers are zero-initialized (NULL). The loop does not recognize them as empty and dereferences NULL. - Calls gpu_buddy_fini(), which iterates free_trees[] unconditionally via for_each_free_tree(). Since mm->free_trees is NULL (never allocated), this dereferences NULL. Both result in a kernel panic on the module load error path. Fix by moving drmm_cgroup_register_region() to after the list and buddy allocator are fully initialized, so the teardown path is safe to run.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89829", "url": "https://ubuntu.com/security/CVE-2026-89829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to pass folio->index to f2fs_sanity_check_node_footer() Otherwise in f2fs_sanity_check_node_footer(), it will check the same nid incorrectly.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89830", "url": "https://ubuntu.com/security/CVE-2026-89830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix valid block count leak on data block allocation failure In __allocate_data_block(), when allocating a new data block (dn->data_blkaddr == NULL_ADDR), inc_valid_block_count() is called first to increment total_valid_block_count and i_blocks. If the subsequent f2fs_allocate_data_block() fails, the function returns the error directly without rolling back the already-incremented block counts, causing a permanent leak. Fix this by calling dec_valid_block_count() to undo the increment before returning the error. The condition old_blkaddr == NULL_ADDR precisely identifies the case where inc_valid_block_count() was called.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89832", "url": "https://ubuntu.com/security/CVE-2026-89832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to clear dirty flag on folio in error path If node block is corrupted due to chksum mismatch or inconsistent footer info, it needs to drop clear flag of node folio, in order to persist inconsistent node data to storage.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89833", "url": "https://ubuntu.com/security/CVE-2026-89833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid potential deadloop in f2fs_fsync_node_pages() There is potential deadloop in race condition: Thread A\t\t\t\tThread B - fsync - f2fs_do_sync_file - f2fs_fsync_node_pages - last_fsync_dnode - folio_get(last_folio) \t\t\t\t\t- f2fs_setattr \t\t\t\t\t - f2fs_truncate \t\t\t\t\t - f2fs_truncate_blocks \t\t\t\t\t - f2fs_do_truncate_blocks \t\t\t\t\t - f2fs_truncate_inode_blocks \t\t\t\t\t - truncate_dnode \t\t\t\t\t - truncate_node \t\t\t\t\t - invalidate_mapping_pages \t\t\t\t\t - folio->mapping = NULL - is_node_folio alwasy return false - atomic && !marked is always true, then goto retry", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89834", "url": "https://ubuntu.com/security/CVE-2026-89834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to migrate all curseg types during free_segment_range In free_segment_range(), the curseg evacuation loop only iterates up to NR_CURSEG_PERSIST_TYPE (0..5), missing non-persistent in-memory curseg types such as CURSEG_COLD_DATA_PINNED and CURSEG_ALL_DATA_ATGC. Even though these in-memory curseg types are not saved in the on-disk checkpoint header, they still occupy active physical segments at runtime. If an active in-memory curseg happens to be allocated within the segment range being truncated during filesystem shrink, failing to evacuate it will cause subsequent writes to the curseg attempting out-of-bounds I/O on the truncated storage range. Fix this by expanding the curseg evacuation loop upper bound to NR_CURSEG_TYPE to ensure all active curseg types are safely migrated out of the target range.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89835", "url": "https://ubuntu.com/security/CVE-2026-89835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: avoid NULL checkpoint thread access in sysfs checkpoint_merge can be enabled even when no checkpoint merge thread is running. A read-only mount is one case: f2fs does not start f2fs_issue_ckpt there, but ckpt_thread_ioprio is still writable through sysfs. The ckpt_thread_ioprio store path updates the saved ioprio value and, when checkpoint_merge is enabled, calls set_task_ioprio() for the checkpoint thread. If cprc->f2fs_issue_ckpt is NULL, that dereferences a NULL task pointer. Protect ckpt_thread_ioprio sysfs writes with s_umount as well, so the checkpoint thread cannot disappear under the store path while updating its ioprio.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89837", "url": "https://ubuntu.com/security/CVE-2026-89837", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix dentry folio leak in find_in_level find_in_level() gets a dentry folio with f2fs_find_data_folio() before calling find_in_block(). If find_in_block() returns an error, the function stores the error in res_folio and breaks out of the loop without dropping the dentry folio. This leaks the folio reference on the find_in_block() error path. Drop the dentry folio before returning the error to the caller.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89839", "url": "https://ubuntu.com/security/CVE-2026-89839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: use the mount idmap for the owner check in f2fs_xattr_advise_set() f2fs_xattr_advise_set() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing the \"system.advise\" xattr to be set, instead of the idmap that the VFS passes to the ->set() handler. f2fs supports idmapped mounts, so on such a mount this checks the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EPERM and an unrelated caller wrongly allowed. Pass the handler's idmap instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89841", "url": "https://ubuntu.com/security/CVE-2026-89841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: only redirty pinned folios in redirty_blocks redirty_blocks() pins folios with read_cache_folio() and then walks the same range again with filemap_lock_folio() to redirty them and drop the references it took. Commit 5951fee46bef (\"f2fs: Use a folio in redirty_blocks()\") changed the second pass to a do/while loop. If read_cache_folio() fails before anything is pinned, page_idx does not advance but the cleanup loop still runs once. If readahead has already populated the failed folio in page cache, that extra iteration finds it and folio_put_refs(folio, 2) drops one reference too many. Later drop_caches or reclaim can then report \"BUG: Bad page state\". Only redirty the range that was pinned successfully.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89842", "url": "https://ubuntu.com/security/CVE-2026-89842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Skip NVMe LS reject IOCB when FW not started qla_nvme_xmt_ls_rsp() bails out to the out: label when firmware is not started (!ha->flags.fw_started), but the out: path unconditionally calls qla_nvme_ls_reject_iocb(), which ends in qla2x00_start_iocbs() and an unconditional doorbell write to the request queue in-pointer register. This rings the firmware doorbell and queues an IOCB that stopped or resetting firmware cannot consume, and touches MMIO during the reset/EEH window where fw_started is also clear. Only emit the LS reject IOCB (and ring the doorbell) when fw_started is set; otherwise just clean up and return. The post-allocation failure cases (SRB alloc / qla2x00_start_sp() failure) run with firmware started and still send the reject. Apply the same guard to the reject emission in qla2xxx_process_purls_pkt().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89843", "url": "https://ubuntu.com/security/CVE-2026-89843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89844", "url": "https://ubuntu.com/security/CVE-2026-89844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold vport_slock for host map update in report ID acquisition qla24xx_report_id_acquisition() format-1 handling drops vport_slock after taking the vport reference and then calls qla_update_host_map() without the lock. That reaches qla_update_vp_map(), which mutates the ha->host_map btree via btree_insert32()/btree_update32()/btree_remove32() and is documented to require vport_slock to be held by the caller. Running it unlocked can race concurrent host_map updates and corrupt the btree. The format-2 path in the same function already wraps its host_map update (SET_AL_PA) in vport_slock; the format-1 path is the lone outlier. Hold vport_slock across the format-1 qla_update_host_map() call to honor the documented locking contract. The vref_count taken in the loop keeps the vport valid, so this only adds the missing host_map serialization.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89845", "url": "https://ubuntu.com/security/CVE-2026-89845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89846", "url": "https://ubuntu.com/security/CVE-2026-89846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: \tif (IS_FWI2_CAPABLE(ha)) { \t\tsense_data += rsp_info_len; \t\tpar_sense_len -= rsp_info_len; \t} rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): \tif (sense_len > par_sense_len) \t\tsense_len = par_sense_len; \tmemcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89847", "url": "https://ubuntu.com/security/CVE-2026-89847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid double completion in async IOCB timeout qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates \"if (sp->comp) complete(sp->comp)\"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89848", "url": "https://ubuntu.com/security/CVE-2026-89848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Quiesce response IRQ before freeing request queue qla2xxx_delete_qpair() deletes the request queue before the response queue. qla25xx_delete_req_que() frees the request queue memory (kfree(req) in qla25xx_free_req_que()), but the response-queue MSI-X is only released later, in qla25xx_free_rsp_que(). In that window the response interrupt can still fire, qla2xxx_msix_rsp_q() queues qpair->q_work, and qla_do_work() -> qla24xx_process_response_queue() dereferences the now-freed rsp->req (LOGINOUT/CT/ELS entries and the status path), a use-after-free. The cancel_work_sync() added for the qpair teardown lives in the response free path, which runs after the request queue is already freed, so it does not protect rsp->req. Release the response-queue interrupt and flush qpair->q_work before deleting the request queue, so no late completion can reach the freed request queue. Clearing have_irq makes the subsequent qla25xx_free_rsp_que() skip its free_irq(), and the firmware queue-delete order (request then response) is preserved; the request-delete mailbox completes on the default vector and is unaffected by dropping the qpair response interrupt early.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89849", "url": "https://ubuntu.com/security/CVE-2026-89849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path qla2x00_status_entry() filters out non-TYPE_SRB entries and the SRB_NVME_CMD, SRB_BIDI_CMD and SRB_TM_CMD types, then falls through to a SCSI fast path that assumes the command is an SRB_SCSI_CMD. The first thing on that path, qla_chk_edif_rx_sa_delete_pending(), and the subsequent handling both evaluate GET_CMD_SP(sp), i.e. sp->u.scmd.cmd. The srb u union overlays the SCSI command pointer with other command layouts (bsg_job, iocb_cmd). If firmware delivers an unexpected STATUS_TYPE IOCB for a non-SCSI handle, sp->u.scmd.cmd can read as a non-NULL garbage pointer, bypassing the NULL checks in qla_chk_edif_rx_sa_delete_pending() and at the cp == NULL test, and leading to a wild pointer dereference. Reject any SRB whose type is not SRB_SCSI_CMD before entering the fast path. The outstanding_cmds slot is left untouched so a genuinely non-SCSI command still completes through its proper handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89850", "url": "https://ubuntu.com/security/CVE-2026-89850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Don't query firmware state while chip is down qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89851", "url": "https://ubuntu.com/security/CVE-2026-89851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace enable parsing in debugfs qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as \"disable\" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89852", "url": "https://ubuntu.com/security/CVE-2026-89852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89853", "url": "https://ubuntu.com/security/CVE-2026-89853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89854", "url": "https://ubuntu.com/security/CVE-2026-89854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix cs84xx use-after-free on host teardown qla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via __qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran before scsi_remove_host(), which is what removes the 84xx_fw_version host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx_84xx_fw_version_show(), which dereferences the freed ha->cs84xx, resulting in a use-after-free. Move qla84xx_put_chip() to after scsi_remove_host() in both qla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once scsi_remove_host() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89855", "url": "https://ubuntu.com/security/CVE-2026-89855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize flash version read in reset handler The \"update cache versions without reset\" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89856", "url": "https://ubuntu.com/security/CVE-2026-89856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as \"ha->max_req_queues = ha->msix_count - 1\" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent \"ha->max_req_queues--\" then underflows 0 to 255. When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following \"ha->req_q_map[0] = req\" dereferences ZERO_SIZE_PTR, corrupting memory or crashing the kernel. Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89857", "url": "https://ubuntu.com/security/CVE-2026-89857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject qla_nvme_ls_reject_iocb() allocates from and advances the request ring through __qla2x00_alloc_iocbs() (which assumes the hardware_lock is held) and qla2x00_start_iocbs() (which advances the ring and rings the request-in doorbell), but takes no lock itself. Two of its callers invoke it without the producer lock held: - qla_nvme_xmt_ls_rsp(), the NVMe-FC .xmt_ls_rsp transport callback, on its error path, and - qla2xxx_process_purls_pkt(), run from the purex work/DPC context. Both use ha->base_qpair, whose qp_lock_ptr is hardware_lock, so they can run concurrently with normal I/O submission on the base ring and corrupt the ring producer state, leading to duplicated or dropped commands. The third caller, qla2xxx_process_purls_iocb(), runs inside qla24xx_process_response_queue() with the qpair lock already held and is safe; that is also why the lock cannot be taken inside the helper itself (it would recursively re-acquire hardware_lock on the response path). Take qp_lock_ptr around the two unlocked callers and document the helper as caller-locked. Both run in process context, so spin_lock_irqsave() is used and nothing in the locked region sleeps.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89858", "url": "https://ubuntu.com/security/CVE-2026-89858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89860", "url": "https://ubuntu.com/security/CVE-2026-89860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Initialize NVMe abort_work once at submission qla_nvme_fcp_abort() and qla_nvme_ls_abort() ran INIT_WORK() on priv->abort_work immediately before schedule_work(). INIT_WORK() reinitializes the work_struct, resetting its list head and clearing the pending bit. If an abort is issued more than once for the same command (for example, concurrent transport teardown and a timeout-driven abort), the second INIT_WORK() reinitializes a work item that is already queued, which can corrupt the workqueue list and lead to crashes or a looping worker. Initialize priv->abort_work once at command submission, next to the existing per-command spin_lock_init(&priv->cmd_lock), and leave only schedule_work() in the abort paths. schedule_work() already does nothing when the work item is still pending, so a repeated abort no longer disturbs an in-flight work item. The command is not returned to the transport until the final kref_put()/release callback runs after abort_work has completed, so the work item is idle before priv is reused and the single submission-time INIT_WORK() is safe.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89861", "url": "https://ubuntu.com/security/CVE-2026-89861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition() In the format 1 path, the virtual port is located on ha->vp_list while holding vport_slock, but the lock is dropped before vp is used: qla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED are set on vp. No reference is taken across that window, so a concurrent qla24xx_deallocate_vp_id() can tear the vport down and free it, leading to a use-after-free. Take a vport reference (vref_count) under vport_slock when the matching vp is found, and drop it after the last use of vp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before unlinking and freeing the vport, so the pointer stays valid. This matches the reference idiom already used by the other ha->vp_list traversals.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89863", "url": "https://ubuntu.com/security/CVE-2026-89863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check qla_chk_edif_rx_sa_delete_pending() obtains the SCSI command via GET_CMD_SP(sp) and immediately dereferences cmd->sc_data_direction. That command pointer can be NULL: the firmware may post a status completion for a command that has already been returned or aborted. The caller qla2x00_status_entry() acknowledges this on the very same status path, re-fetching GET_CMD_SP(sp) and bailing out with the \"Command already returned\" message when it is NULL -- but that check runs only after qla_chk_edif_rx_sa_delete_pending() has already dereferenced the pointer, so a NULL cmd crashes the kernel in interrupt context. Return early when cmd is NULL, before touching cmd->sc_data_direction.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89864", "url": "https://ubuntu.com/security/CVE-2026-89864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound i2c->length in I2C bsg handlers struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: \tstruct qla_i2c_access { \t\tuint16_t device, offset, option, length; \t\tuint8_t buffer[0x40]; \t} __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89865", "url": "https://ubuntu.com/security/CVE-2026-89865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: \tif (len == 1) \t\topt |= BIT_0; \tif (opt & BIT_0) \t\tlen = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89869", "url": "https://ubuntu.com/security/CVE-2026-89869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: qcom: iris: use disable_irq() during power-off The IRQ is registered as a threaded IRQ. Using disable_irq_nosync() in iris_vpu_power_off() does not wait for an already queued threaded IRQ handler to complete before returning. As a result, a threaded IRQ handler may still run after the VPU has been powered down and access hardware registers after power-off. Replace disable_irq_nosync() with disable_irq() so the power-off path waits for any in-flight threaded IRQ handler to complete before returning.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89870", "url": "https://ubuntu.com/security/CVE-2026-89870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: zoran: Avoid freeing a registered video_device twice zoran_init_video_device() installs zoran_vdev_release() as the video_device release callback through zoran_template. After video_register_device() succeeds, video_unregister_device() drops the registered video_device reference and the V4L2 core eventually invokes that release callback, which kfree()s the video_device. zoran_exit_video_devices() called video_unregister_device() and then kfree(zr->video_dev), so device teardown could free the same video_device twice. Remove the direct kfree() and clear the cached pointer after unregistering. The pre-registration failure path keeps its manual free because the video_device was not registered there. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89871", "url": "https://ubuntu.com/security/CVE-2026-89871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure kthread_run() returns an ERR_PTR on failure, not NULL. When start_streaming() fails, data->kthread_vid_cap is left holding this error pointer instead of being cleared. This causes two subsequent bugs: 1. A future call to start_streaming() sees a non-NULL kthread_vid_cap and returns 0 (success) immediately, without actually starting the capture thread. 2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which is false for an error pointer, and proceeds to call kthread_stop() on the error pointer, leading to a kernel crash. Fix this by resetting kthread_vid_cap to NULL on failure before jumping to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89872", "url": "https://ubuntu.com/security/CVE-2026-89872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. [Sakari Ailus: Fix subject prefix and coding style a little.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89874", "url": "https://ubuntu.com/security/CVE-2026-89874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-async: avoid deleting unlinked ASC entry on link error v4l2_async_match_notify() creates ancillary media links before adding asc->asc_subdev_entry to sd->asc_list. If ancillary link creation fails, the function jumps to err_call_unbind while asc_subdev_entry has not been linked yet. Async connections are zero-allocated, so the list entry still has NULL next and prev pointers on this path. Calling list_del() on it can therefore dereference NULL instead of returning the original link creation error. Do not delete asc_subdev_entry from err_call_unbind. There is no list insertion to undo on this path; the bound callback and sub-device registration are the operations that need to be rolled back.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89876", "url": "https://ubuntu.com/security/CVE-2026-89876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: tda18250: fix possible integer overflow Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89877", "url": "https://ubuntu.com/security/CVE-2026-89877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7164: fix cleanup on resource allocation failure saa7164_dev_setup() adds the device to the global saa7164_devlist before requesting the PCI BAR memory regions. If get_resources() fails, saa7164_dev_setup() decrements the device count and returns an error, but leaves the device on saa7164_devlist. The probe error path then frees the device, leaving a dangling entry on the global list. Reuse the existing MMIO mapping error path to remove the device from saa7164_devlist and decrement the device count before returning. Also release BAR0 if it was successfully requested but the BAR2 request fails.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89878", "url": "https://ubuntu.com/security/CVE-2026-89878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: check firmware size before reading trailing marker s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89879", "url": "https://ubuntu.com/security/CVE-2026-89879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: bound JPEG frame size before copying into the buffer s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: \tpayload = le32_to_cpu(pdword[3]); \tif (payload > vc->req_image_size)\t/* payload is checked ... */ \t\treturn -EINVAL; \tvc->pkt_size = payload; \tvc->jpg_size = le32_to_cpu(pdword[4]);\t/* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89880", "url": "https://ubuntu.com/security/CVE-2026-89880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89881", "url": "https://ubuntu.com/security/CVE-2026-89881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89883", "url": "https://ubuntu.com/security/CVE-2026-89883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: sunxi-cir: Unregister rc device on probe failure After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89884", "url": "https://ubuntu.com/security/CVE-2026-89884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: platform: mtk-mdp3: fix NULL deref on failed SCP lookup Add the missing sanity check after looking up the SCP to avoid dereferencing a NULL-pointer in case its driver has not yet been bound.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89885", "url": "https://ubuntu.com/security/CVE-2026-89885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: platform: mtk-mdp3: Fix SCP device refcounting mdp_probe() first tries to get the SCP handle with scp_get(). When that fails, it falls back to looking up the SCP platform device with __get_pdev_by_id() and then reads its driver data. The fallback lookup returns the platform device with a reference, just like scp_get() does. However, the fallback path currently drops that reference immediately after platform_get_drvdata(). The driver later still calls scp_put(mdp->scp) unconditionally from the probe error path and from mdp_video_device_release(), which drops the SCP device reference again. Keep the fallback reference until the existing scp_put() call, so that the fallback path follows the same ownership rules as the scp_get() path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89886", "url": "https://ubuntu.com/security/CVE-2026-89886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: intel/ipu6: fix async notifier cleanup leak on parse error isys_notifier_init() calls v4l2_async_nf_init() and then adds fwnode remote subdevs in a loop with v4l2_async_nf_add_fwnode_remote(). If an endpoint parse or add fails partway through the loop, it jumps to err_parse and returns without calling v4l2_async_nf_cleanup(), leaking every v4l2_async_connection already added to the notifier's waiting list. The register-failure path just below already cleans up correctly, and the caller only tears the notifier down (isys_notifier_cleanup()) once isys_notifier_init() has returned success. Clean up the notifier on the parse error path too.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89887", "url": "https://ubuntu.com/security/CVE-2026-89887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov7740: fix use-after-destroy in remove The ov7740_remove() function had a severe teardown order bug where it destroyed the driver's mutex before freeing the V4L2 control handler which relies on that mutex, leading to a use-after-destroy kernel panic. Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and mutex_destroy() sequentially, but then called ov7740_free_controls() which invokes both of them a second time, resulting in a double-free. This patch fixes the issue by unregistering the subdevice first, and relying exclusively on ov7740_free_controls() to safely tear down the mutex and control handler in the correct order.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89888", "url": "https://ubuntu.com/security/CVE-2026-89888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov02a10: fix endpoint parsing use-after-free The ov02a10_check_hwcfg() function calls fwnode_handle_put(ep) immediately after allocating and parsing the endpoint. However, it subsequently calls fwnode_property_read_u32() using the same 'ep' handle, leading to a potential use-after-free. Additionally, reading the optional 'ovti,mipi-clock-voltage' property used to overwrite the 'ret' variable. If the property was missing, 'ret' would become negative, and this failure code would be incorrectly returned at the end of the function, causing probe to fail entirely. Fix the use-after-free by moving fwnode_property_read_u32() before the endpoint is parsed and freed. Avoid the error leak by not assigning the result of fwnode_property_read_u32() to 'ret'.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89889", "url": "https://ubuntu.com/security/CVE-2026-89889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: imx415: Release runtime PM reference on VBLANK error The VBLANK path returned immediately when programming VMAX failed after pm_runtime_get_if_in_use() had taken a runtime PM reference. Break out of the switch instead so the common pm_runtime_put() path is used.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89890", "url": "https://ubuntu.com/security/CVE-2026-89890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: go7007: defer the ALSA v4l2 put until card release go7007_snd_init() already takes a v4l2_device reference for the ALSA side, but go7007_snd_remove() drops it immediately after calling snd_card_free_when_closed(). That is too early when a userspace process still has the capture PCM open. The ALSA card and its PCM callbacks remain alive until the last file is closed, so the release path can still reach struct go7007 through pcm->private_data and call go7007_snd_hw_free() after the V4L2 release path has freed the object. Move the matching v4l2_device_put() to the ALSA card private_free callback so the existing ALSA reference covers the whole deferred card lifetime.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89891", "url": "https://ubuntu.com/security/CVE-2026-89891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free of dev_next->devlist on disconnect When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 (\"USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89892", "url": "https://ubuntu.com/security/CVE-2026-89892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: defer audio-only extension registration The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89893", "url": "https://ubuntu.com/security/CVE-2026-89893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: cancel NetUP CI work before teardown netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state. netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state. Call cancel_work_sync() before dvb_ca_en50221_release() and kfree(). This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89894", "url": "https://ubuntu.com/security/CVE-2026-89894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: reject geometry changes while the VBI queue is busy vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: \toffset = lines_completed * (dev->width << 1) + ...; \tif (dma_q->current_field == 2) \t\toffset += dev->width * 2 * dma_q->lines_per_field; \tmemcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89895", "url": "https://ubuntu.com/security/CVE-2026-89895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cobalt: Avoid freeing ALSA private data twice snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89896", "url": "https://ubuntu.com/security/CVE-2026-89896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: fix memory leak in cedrus_init_ctrls() In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89897", "url": "https://ubuntu.com/security/CVE-2026-89897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: Serialize exclusive follower delivery cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89898", "url": "https://ubuntu.com/security/CVE-2026-89898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: extron-da-hd-4k-plus: add sanity check Add check to prevent overflowing msg.msg[] in case the incoming data is malformed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89899", "url": "https://ubuntu.com/security/CVE-2026-89899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: disable delayed work before freeing an interrupted transmit cec_transmit_msg_fh() drops adap->lock to wait for a blocking transmit in wait_for_completion_killable(). If that wait is interrupted by a signal, cancel_delayed_work_sync() can run before the CEC kthread arms the reply timeout via schedule_delayed_work(&data->work) in cec_transmit_done_ts(). The work is then armed after the cancel, and the data is freed with its delayed_work still pending: ODEBUG: free active (active state 0) object: ... hint: cec_wait_timeout Use disable_delayed_work_sync(): it cancels the work and disables it, so the later schedule_delayed_work() becomes a no-op and the work cannot be re-armed. The data is freed right after, so it need not be re-enabled.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89901", "url": "https://ubuntu.com/security/CVE-2026-89901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89902", "url": "https://ubuntu.com/security/CVE-2026-89902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: Avoid preempt count underflow without probe LoongArch uses break 11 for the breakpoint placed after an instruction that Kprobes executes out of line. Since userspace can issue the same break instruction, do_bp() can reach kprobe_singlestep_handler() when there is no current probe. The handler actually returns false in this case, but it first calls preempt_enable_no_resched(). The corresponding preempt_disable() is done by kprobe_breakpoint_handler() on a real Kprobe hit, so it has not run here. As a result, an ordinary userspace breakpoint (code 11) underflows the current task's preempt count. This also makes in_interrupt() return true until the task schedules. One visible consequence is the socket cgroup attribution: cgroup_sk_alloc() treats the allocation as interrupt context and assigns the socket to the root cgroup. A socket opened from the SIGTRAP handler can then avoid a BPF_CGROUP_INET_SOCK_CREATE policy attached to the task's own cgroup. Return as soon as kprobe_running() reports no active probe. The same check has appeared in [PATCH v10 2/4] of the original LoongArch Kprobes series, but was dropped before the feature reached mainline.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89903", "url": "https://ubuntu.com/security/CVE-2026-89903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: Do not save/restore percpu base register in rethook trampoline The rethook trampoline saves $r21 ($u0), the percpu base, into its frame at entry and restores it at exit. Inbetween rethook_trampoline_handler() may schedule via preempt_enable_notrace(). If the task migrates to another CPU, the frame's $r21 holds the old CPU's percpu base, and restoring it poisons $r21 on the new CPU. Until the next user->kernel transition heals $r21, all this_cpu_*() accesses (runqueues, RCU per-CPU data, timer tick programming, FPU ownership) hit the wrong CPU's percpu area. Under kretprobe-heavy preemptible load this can corrupt scheduler and timer state: scheduling-while-atomic splats, wrong-CPU RCU warnings, WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), and CPUs parking in the idle loop with the constant timer never re-armed (hard lockup). Reproduces on a Loongson-3A6000 with kretprobes on VFS paths plus heavy file churn (OS install / unsquashfs). By convention $r21 always holds the current CPU's percpu base in kernel mode: SAVE_SOME() at exception entry reloads it only when coming from user mode, and RESTORE_SOME() restores it only when returning to user mode; the context-switch path never writes it. Therefore the live $r21 at trampoline exit is already correct, and nothing inbetween can change it legitimately (kernel C code cannot write a global register variable). The same flaw existed even in the pre-rethook kretprobe trampoline since v6.3; it was carried over when rethook replaced it. Drop both the save and the restore here. Drop the restore is enough to solve the issue, and drop the save is to keep the code tidy and no need to clear it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89904", "url": "https://ubuntu.com/security/CVE-2026-89904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: Fix acpi_package_ids[] array overflow With LoongArch virt machine, a typical setting is one core per socket, there will max 256 sockets (packages) on one VM. With PPTT acpi table, array acpi_package_ids[] will be overflowed. Here change the array size of acpi_package_ids[] with the max value of MAX_PACKAGES and KVM_MAX_VCPUS.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89906", "url": "https://ubuntu.com/security/CVE-2026-89906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Refactor jump offset calculation in tail call The old macro-based jmp_offset calculation derives the jump distance from a stale prior-pass code stride, which can lead to wrong branch offsets and soft lockups under extra JIT passes. Fix this by calculating the offset directly on the absolute target: \"ctx->offset[insn + 1] - ctx->idx\". To avoid a false 16-bit range check abort during size estimation, add a \"ctx->image == NULL\" guard to inject a safe dummy offset.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89908", "url": "https://ubuntu.com/security/CVE-2026-89908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY kvm_arch_prepare_memory_region() computes new->arch.flags, i.e. whether a memslot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE, only for KVM_MR_CREATE and KVM_MR_MOVE, and returns early for every other change. But the generic code allocates a zeroed memslot for every change and never copies old->arch, so after a KVM_MR_FLAGS_ONLY update, e.g. toggling KVM_MEM_LOG_DIRTY_PAGES for live migration, the active memslot has arch.flags == 0. With both flags clear, fault_supports_huge_mapping() falls through to the alignment check on the HVA range alone, which no longer verifies that the GPA and HVA have the same offset within a PMD. A memslot that was marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can then be mapped with PMD entries on read faults, and since kvm_map_page() aligns the gfn and the pfn independently, the guest ends up accessing the wrong host pages, exactly the \"d -> f, e -> g\" case described in the comment above the check. Carry the arch flags over from the old memslot for KVM_MR_FLAGS_ONLY, as the GPA, HVA and size are guaranteed to be unchanged for that case.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89909", "url": "https://ubuntu.com/security/CVE-2026-89909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Free init resources if kvm_init() fails kvm_loongarch_init() calls kvm_loongarch_env_init() to allocate the per-CPU kvm_context (vmcs) and kvm_loongarch_ops and to register the perf callbacks, and then calls kvm_init(). If kvm_init() fails its result is returned directly, but since module_init() does not run the module_exit() stuff on failure, so kvm_loongarch_env_exit() is never called and those resources are leaked. So call kvm_loongarch_env_exit() when kvm_init() fails, matching the teardown-on-failure pattern used by riscv_kvm_init().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89911", "url": "https://ubuntu.com/security/CVE-2026-89911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Correctly cap TLBI Range to the architural limit TLB Invalidation by Range has a fairly powerful way of encoding pretty large ranges in a small number of bits. This range can be based on an arbitrary VA, which means it is pretty easy for a guest to generate an overflow should the hypervisor be naive enough to add the range to the base... Make sure the range is capped to the limit dictated by the address bit that determines the VA range. For an IPA invalidation, this is further corrected down the line to ignore the upper range.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89912", "url": "https://ubuntu.com/security/CVE-2026-89912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save MAPC with V=0 drops ite->collection but leaves the ITE on the device's ITT list, and vgic_its_save_ite() dereferences it unconditionally. A guest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the host when the VMM issues KVM_DEV_ARM_ITS_SAVE_TABLES to migrate it. That sequence is UNPREDICTABLE per the architecture, but KVM already handles the resulting state in the translate, MOVI and DISCARD paths. Save a zeroed entry, which vgic_its_restore_ite() reads back as invalid. Skipping the ITE instead would leave the ITT slot holding whatever is in guest memory, and restore rejects an entry naming a collection the restored collection table does not have.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89913", "url": "https://ubuntu.com/security/CVE-2026-89913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-v3: take an LPI reference in vgic_v3_save_pending_tables vgic_v3_save_pending_tables() iterates dist->lpi_xa using xa_for_each() and dereferences the returned struct vgic_irq in the loop body without holding a reference on the LPI. The xarray iterator only provides temporary RCU coverage while looking up the current entry. That is not sufficient for this loop body, which reads fields from struct vgic_irq and performs guest memory accesses before the iteration completes. A concurrent path can trigger this race: the irqfd cached injection path (vgic_its_inject_cached_translation) obtains a transient LPI reference via vgic_its_check_cache() without holding kvm->lock, vcpu->mutex, config_lock, or its_lock. If guest ITS DISCARD then drops the cache and ITE references under its_lock, the transient inject reference may become the final one. When vgic_put_irq() drops it, the LPI is erased from lpi_xa and freed via kfree_rcu(). Meanwhile, vgic_v3_save_pending_tables() may still hold a stale pointer obtained from the xarray iterator and dereference it after the RCU grace period completes. Fix this by re-fetching each iterated LPI via vgic_get_irq(), which takes a stable reference, and dropping it with vgic_put_irq() on all paths. This matches the pattern already used by other lpi_xa iterators in the vgic ITS code.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89914", "url": "https://ubuntu.com/security/CVE-2026-89914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Sign-extend VA for range-based TLBI invalidation When the decode_range_tlbi() helper was moved to be used for S1 TLBIs, the required sign extension was omitted. Add it. As a result, special care must be taken to not overflow PA bits when this is used for S2 invalidation.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89916", "url": "https://ubuntu.com/security/CVE-2026-89916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry A VNCR TLB invalidation can occur on one vcpu while another vcpu is faulting in this same page. Without correctly handling this, we can end up with the following scenario: - vcpu A walks the PTs to translate VNCR - before vcpu A is able to grab the MMU lock to insert the TLB, vcpu B updates the S1 PTs with an invalid entry, and issues a TLBI S1E2 for this VA - vcpu A inserts the TLB for something that is now invalid This isn't a new problem, and we manage S2 by having the MMU notifier to bump up mmu_invalidate_seq on invalidation so that the fault can be replayed. We can perform something similar here, and extend invalidate_vncr_va() to update the same counter, clearly indicating that the context has changed under our feet. This is safe as the invalidation always happen while holding the MMU lock for write, and that we sample the sequence number before walking S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89918", "url": "https://ubuntu.com/security/CVE-2026-89918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Correctly handle end of VA space TLBI invalidation Our TLB invalidation by VA code is based on comparing two ranges, one defined by the TLB, and one defined by the TLBI instruction. Each range is defined by a start and a size. However, the way the comparison is done doesn't account for address rollover, as it compares an address with (base + size). This works nicely until this expression represent the last page/block in the TTBR1 VA space, as the result is a big fat 0. And a failed TLB invalidation. Rewrite the comparison in a way that is immune to the address rollover (making the end address inclusive instead of exclusive), and move this into a common helper that is used by both VA and IPA invalidations, as suggested by Hyunwoo Kim (although the IPA version didn't suffer from this particular problem, obviously).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89775", "url": "https://ubuntu.com/security/CVE-2026-89775", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation Computing the effects of a TLB invalidation involves looking at the size of the mapping cached by the TLB. For S1 mappings such as VNCR, this is deducted from the combination of the base granule size and the mapping level. However, this implies that the S1 MMU is *on*. When the MMU is off, we indicate this with the level being set to a \"creative\" value of -127 (S1_MMU_DISABLED). This ends-up being misinterpreted by pgshift_level_to_ttl() as it doesn't handle negative levels at all (the level is immediately cast to a u8 and only the bottom two bits considered), leading to an invalidation size of 0. Not helpful. Tidy-up pgshift_level_to_ttl() to handle these negative levels, and ttl_to_size() to always return SZ_1G when no valid TTL is present. This allows the removal of open-coded checks for similar situations. Note that the check for a negative value not explicitely checking for S1_MMU_DISABLED is deliberate, so that actual negative levels introduced with LVA2 and D128 can take the same path if we ever support them.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89920", "url": "https://ubuntu.com/security/CVE-2026-89920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory corruption by not reinjecting CK machine checks Channel-subsystem damage machine checks are for the host channel subsystem. The guest channel subsystem is emulated in the userspace VMM. There is no point in forwarding such machine checks into the guest. This also simplifies the machine check reinjection and avoids kfree of a stack variable as reported by sashiko. There might be still machine checks that have the ck bit set with another bit (like instruction damage), mask out the CK bit in s390_backup_mcck_info(), like the CP and ED bits already are.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89922", "url": "https://ubuntu.com/security/CVE-2026-89922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Take srcu when importing watchpoint data __import_wp_info() backs up the original guest memory contents of a watchpoint with read_guest_abs(), which is kvm_read_guest() and therefore resolves the memslot via __kvm_memslots(). That requires kvm->srcu (or kvm->slots_lock) to be held, otherwise a concurrent memslot update can free the memslots array under us once its SRCU grace period has elapsed. As this is not fast path, following lock ordering (mutex first, then srcu) take the big hammer and hold the srcu for the full import.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89923", "url": "https://ubuntu.com/security/CVE-2026-89923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Free guest debug data on vcpu destroy kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89924", "url": "https://ubuntu.com/security/CVE-2026-89924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix old_data leak in guest debug error path __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89925", "url": "https://ubuntu.com/security/CVE-2026-89925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory leak in guest debug handling bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89926", "url": "https://ubuntu.com/security/CVE-2026-89926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix length check __import_wp_info() struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: \twp_info->len = bp_data->len; \t[...] \tif (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) \t\treturn -EINVAL; \twp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89927", "url": "https://ubuntu.com/security/CVE-2026-89927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89928", "url": "https://ubuntu.com/security/CVE-2026-89928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Consume the locked rmap value in the lockless rmap walk __kvm_rmap_lock() deliberately elides the rmap lock when it observes an empty rmap. In that case kvm_rmap_lock_readonly() also re-enables preemption and returns zero, so the caller holds neither the rmap lock nor a preemption reference. The elision documents the invariant it relies on: \t * Elide the lock if the rmap is empty, as lockless walkers (read-only \t * mode) don't need to (and can't) walk an empty rmap, nor can they add \t * entries to the rmap. I.e. the only paths that process empty rmaps \t * do so while holding mmu_lock for write, and are mutually exclusive. kvm_rmap_age_gfn_range() ignores the returned value and unconditionally enters for_each_rmap_spte_lockless(). The iterator started with rmap_get_first(), which re-reads rmap_head->val rather than using the value returned by the lock. If a writer populates the rmap between the lock's read and the iterator's re-read, the aging path walks the newly installed rmap without holding its lock. For a KVM_RMAP_MANY rmap this leaves the walker following a pte_list_desc chain that it never locked. A writer holding mmu_lock for write may free that chain (e.g. kvm_zap_all_rmap_sptes() on the recycle path, or any rmap zap) via kmem_cache_free() while the walk is in progress, giving a slab use-after-free. Nothing serialises the two: the aging path runs without mmu_lock when CONFIG_KVM_MMU_LOCKLESS_AGING=y, and the rmap lock that would otherwise exclude the writer was elided. Because the empty path re-enables preemption, the interval between the two reads can span an arbitrary scheduling delay. Fix the class of bug by having the lockless walk consume the value returned by the lock instead of re-reading the rmap. Split rmap_get_first() into __rmap_get_first(), which starts an iterator from an already-read rmap value, and make for_each_rmap_spte_lockless() take that value and call __rmap_get_first() directly. kvm_rmap_age_gfn_range() passes the value returned by kvm_rmap_lock_readonly(): when the lock was elided the value is zero, __rmap_get_first() returns NULL, and the walk is skipped. No lockless walker re-reads the rmap, so the lock-elision invariant cannot be violated, and no lock()-without-paired-unlock() path is added to the aging code.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89929", "url": "https://ubuntu.com/security/CVE-2026-89929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU When emulating INVVPID, KVM executes INVVPID on the physical CPU using vpid02 (instead of the L1 assigned VPID), after doing some validations on the operands. However, it is possible that the physical CPU KVM executes INVVPID on is different from the CPU L2 is running on. For example, in the following scenario: - L2 runs on CPU #1 and exits to L1 (vmx->nested.vmcs02.cpu=1) - L1 migrates to CPU #2 and executes INVVPID - KVM executes INVVPID on CPU #2 - L1 migrates back to CPU #1 and runs L2 (vmx->nested.vmcs02.cpu=1) The TLB entries on CPU #1 are never invalidated, because INVVPID was executed on CPU #2, and vmcs02 never ran on a different pCPU (i.e. vmx_vcpu_load_vmcs() will *not* request KVM_REQ_TLB_FLUSH). Ensure that INVVPID is being executed on the same pCPU that L2 last ran on, and if not, fallback to clearing last_vpid=0 to trigger a full VPID flush on the next nested VM-Enter (as KVM will detect L1 using a different VPID for L2). If L2 ends up running on a different pCPU, KVM will flush the TLB anyway through vmx_vcpu_load_vmcs().", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89930", "url": "https://ubuntu.com/security/CVE-2026-89930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Service local TLB flushes on failed nested VM-Enter KVM services local TLB flushes on \"full\" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition. The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case. More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89931", "url": "https://ubuntu.com/security/CVE-2026-89931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit Always check and clear KVM_REQ_GET_NESTED_STATE_PAGES when emulating a nested VM-Exit to ensure the request is cleared, even when KVM was built with CONFIG_KVM_HYPERV=n, as KVM subtly relies on the \"check\" to clear the flag and thus avoid double-mapping the vmcs12 pages, e.g. if KVM manages to bail from VM-Enter without processing the request, and then emulates VMLAUNCH or VMRESUME.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89932", "url": "https://ubuntu.com/security/CVE-2026-89932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always flush vpid02 on first use Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID. This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM). Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM happens to reuse a VPID that has TLB entries on the physical CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89933", "url": "https://ubuntu.com/security/CVE-2026-89933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: pressure: dps310: fix NULL pointer dereference on ACPI probe When the device is enumerated through its ACPI HID (IFX3100), i2c_client_get_device_id() returns NULL: the ACPI-derived client name does not match the driver's i2c_device_id table. dps310_probe() then dereferences that NULL pointer in \"iio->name = id->name\" and crashes the kernel during probe. The IIO device name is always \"dps310\", so set it directly and drop the now-unused device-id lookup.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89934", "url": "https://ubuntu.com/security/CVE-2026-89934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: ltrf216a: fix runtime PM reference leak in error path ltrf216a_get_lux() acquires a runtime PM reference by calling ltrf216a_set_power_state(data, true). However, if ltrf216a_read_data() fails, the function returns immediately without dropping the reference. This leaves the runtime PM usage count unbalanced, preventing the device from autosuspending after a failed read. Fix this by releasing the runtime PM reference before returning from the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89936", "url": "https://ubuntu.com/security/CVE-2026-89936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: dac: m62332: Fix regulator reference count imbalance m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89937", "url": "https://ubuntu.com/security/CVE-2026-89937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sgp30: Handle IAQ thread creation failure kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89938", "url": "https://ubuntu.com/security/CVE-2026-89938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF The atlas driver requests its hardware data-ready IRQ with devm_request_threaded_irq(); its threaded handler queues an irq_work, atlas_work_handler(), that calls iio_trigger_poll(data->trig). The IRQ is devm-managed, so free_irq() runs from the devres unwind after atlas_remove() returns without flushing that irq_work. Once a buffer is enabled, conversion-complete IRQs keep firing and queueing it; a pending irq_work can therefore run after the unwind has freed atlas_data/indio_dev and the trigger, when atlas_work_handler() derives the atlas_data pointer via container_of() and dereferences data->trig, a use-after-free. Call iio_trigger_poll_nested() directly from the threaded handler instead of bouncing through irq_work. free_irq() then drains the threaded handler, closing the window; other iio drivers with a threaded data-ready IRQ do the same (e.g. bmi270). This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89939", "url": "https://ubuntu.com/security/CVE-2026-89939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89940", "url": "https://ubuntu.com/security/CVE-2026-89940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: buffer: Tie IIO dma fence lock lifetime to the fence The `iio_dma_fence` implementation currently uses a lock embedded in the `iio_dmabuf_priv`. But the `iio_dma_fence` can outlive the `iio_dmabuf_priv`, which can cause a use-after-free. Tie the lifetime of the lock to the lifetime of the fence by embedding them in the same struct. We can't just hold a reference to the `iio_dmabuf_priv` from the `iio_dma_fence` since `iio_buffer_dmabuf_release()` might sleep and the fence release callback is not allowed to sleep. Note that the `dma_fence` framework now has an internal lock that gets used when the passing `NULL` for `lock` in `dma_fence_init()`, but in order to allow this patch to be backportable use an external lock.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89941", "url": "https://ubuntu.com/security/CVE-2026-89941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: buffer: Make IIO DMA fence release RCU-safe The `dma_fence` documentation states that if a custom release implementation is provided, the `dma_fence` object must be freed in an RCU-safe way. The current `iio_dma_fence` implementation uses `kfree()`, which might result in a use-after-free. Remove the custom `release` implementation. This makes the DMA fence core fall back to `dma_fence_free()`, which calls `kfree_rcu()` on the fence. This requires that the fence be the first member of `struct iio_dma_fence`. Using the default release method for extended DMA fence structures is a common pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89942", "url": "https://ubuntu.com/security/CVE-2026-89942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: buffer: Fix potential use-after-free in anonymous buffer release An anonymous buffer handle holds a reference to the underlying IIO device. The reference is dropped in the buffer handle's release function. If the device has been removed, either through unbind or hot-unplug, the buffer handle might hold the last reference. The release function takes the mutex for the buffer using a guard, which means the unlock happens after all the code in the function, including `iio_device_put()`. If the anonymous buffer holds the last reference this might free both the IIO device and the buffer, which contains the mutex, leading to use-after-free when the mutex is unlocked. Fix this by using a scoped guard just around the buffer dmabuf list access, making sure the mutex is unlocked before releasing the IIO device. Version 10 of the patch that introduced this issue used this exact scheme of first unlocking and then dropping the reference [1]. During review it was suggested to use a guard instead, and version 11 made that change [2].", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89943", "url": "https://ubuntu.com/security/CVE-2026-89943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: loongson: Fix error handling in ACPI property parsing In loongson_card_parse_acpi(), the return value of device_property_read_string() for the `codec-dai-name` property was ignored. If the property is missing or invalid, an uninitialized pointer would be used later, potentially leading to undefined behavior. Fix this by checking the return value and propagating the error appropriately.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89944", "url": "https://ubuntu.com/security/CVE-2026-89944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: hdac_hda: Fix hlink refcount leak on component registration failure hdac_hda_dev_probe() gets the HDA link with snd_hdac_ext_bus_link_get() before registering the ASoC component. If component registration fails, the function returns without dropping the link reference. Always call snd_hdac_ext_bus_link_put() after the registration attempt so the reference taken during probe is balanced on both success and failure.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89945", "url": "https://ubuntu.com/security/CVE-2026-89945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l34: drain threaded IRQ before runtime suspend cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89946", "url": "https://ubuntu.com/security/CVE-2026-89946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l33: drain threaded IRQ before runtime suspend cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89947", "url": "https://ubuntu.com/security/CVE-2026-89947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: meson: align gxbb_32k_clk_sel number of parents with actual count The following out-of-bounds read has been observed by Christian on a GXBB WeTek Hub: ================================================================== BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418 Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT Hardware name: WeTek Hub (DT) Call trace: show_stack+0x14/0x20 (C) dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8 __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188 __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 The buggy address belongs to the variable: gxbb_32k_clk_parents+0x60/0x400 The buggy address belongs to a vmalloc virtual mapping The buggy address belongs to the physical page: Memory state around the buggy address: ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 ================================================================== Commit 7915d7d5407c (\"clk: amlogic: gxbb: drop non existing 32k clock parent\") dropped a non-existing clock parent from the gxbb_32k_clk_sel mux but didn't adjust the hard-coded num_parents field. Fix the actual number of parents of that mux by using ARRAY_SIZE instead (avoiding similar problems in future).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89948", "url": "https://ubuntu.com/security/CVE-2026-89948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix freeing of claims on meshif deletion When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89949", "url": "https://ubuntu.com/security/CVE-2026-89949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: avoid unaligned fault in IP extraction Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89950", "url": "https://ubuntu.com/security/CVE-2026-89950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: mcast: linearize skbuff for packet generation batadv_mcast_forw_packet() and batadv_mcast_forw_scrape() is not only called (indirectly) by the unsharing+linearizing batadv_recv_mcast_packet() handler. When it is called (indirectly) by batadv_mcast_forw_mcsend() then it will be unshared but not linearized. The SKB_LINEAR_ASSERT() can therefore cause a fatal BUG(). The linearization should happen during the expansion of the head because the scrape function can be hit already during the initial batadv_mcast_forw_mode() selection code: * batadv_interface_tx * batadv_mcast_forw_mode * batadv_mcast_forw_mode_by_count() * batadv_mcast_forw_push() -> calls batadv_mcast_forw_expand_head() before everything else * batadv_mcast_forw_push_tvlvs() * batadv_mcast_forw_push_dests() * batadv_mcast_forw_push_adjust_padding() * batadv_mcast_forw_scrape()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89951", "url": "https://ubuntu.com/security/CVE-2026-89951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix stale receive device on merged fragments Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches the local mesh interface. Refresh the receive device metadata from the current receive device before running the packet handlers. This keeps internally reinjected merged fragments consistent with the normal receive path after hard interface teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89952", "url": "https://ubuntu.com/security/CVE-2026-89952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: validate ONFI extended parameter page sections nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89953", "url": "https://ubuntu.com/security/CVE-2026-89953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89954", "url": "https://ubuntu.com/security/CVE-2026-89954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: afs: validate v2 image info bounds The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use. Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89955", "url": "https://ubuntu.com/security/CVE-2026-89955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix NULL deref in status_show() during queue probe When vfio_ap_mdev_probe_queue() creates the sysfs attribute group, the queue's driver data has not yet been set. A concurrent read of the 'status' attribute can therefore call dev_get_drvdata() and get NULL, which is then passed directly to vfio_ap_mdev_for_queue() where q->apqn is unconditionally dereferenced, causing a NULL pointer dereference. Fix this by acquiring the update locks before calling sysfs_create_group(). The status_show() function acquires guests_lock before reading the driver data, so any concurrent read will block until after dev_set_drvdata() has been called and the update locks are released. As a bonus, the APQN no longer needs to be read from the queue struct after allocation — it can be read directly from apdev before allocation and stored in a local variable, which is then assigned to q->apqn once the allocation succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89956", "url": "https://ubuntu.com/security/CVE-2026-89956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects In order to traverse or add/remove ap_matrix_mdev objects in the matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held. There are two functions that access the list without holding the mutex: vfio_ap_mdev_probe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock mutex to guard the add of a newly created ap_matrix_mdev object to the matrix_dev->mdev_list. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an ap_matrix_mdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently. The adding of an ap_matrix_mdev object to matrix_dev->mdev_list is now guarded by the matrix_dev->guests_lock which is the correct way to protect against concurrent mdev_list access. Also removed the following two lines of code because the matrix_mdev is allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger and cfg_chg_trigger are already zero-initialised when the struct is allocated before the call to vfio_register_emulated_iommu_dev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace. matrix_mdev->req_trigger = NULL; matrix_mdev->cfg_chg_trigger = NULL; vfio_ap_mdev_for_queue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The status_show function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue function which iterates the matrix_dev->mdev_list to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrix_dev->guests_lock mutex must be held. To fix this, the guests_lock mutex is taken prior to taking the matrix_dev->mdevs_lock mutex in the status_show function. It is taken there rather than the vfio_ap_mdev_for_queue function - where it is needed - because it must be taken prior to the mdevs_lock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevs_lock is needed there to access fields within the matrix_mdev object in that function. See the vfio-ap-locking.rst in the linux kernel tree.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89957", "url": "https://ubuntu.com/security/CVE-2026-89957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removed The vfio_ap_mdev_hot_unplug_cfg() function uses the return value of bitmap_andnot() to determine whether the guest APCB needs to be updated. However, bitmap_andnot() returns false when the resulting destination bitmap is empty. This means that if the only adapter, domain or control domain assigned to an mdev is removed from the host's AP configuration, the bit is correctly cleared from the shadow APCB, but bitmap_andnot() returns false because the result is an empty bitmap. Consequently, do_hotplug remains 0 and vfio_ap_mdev_update_guest_apcb() is never called, leaving the KVM guest with stale hardware access to the unplugged AP devices. Fix this by replacing the bitmap_andnot() return value check with bitmap_intersects() to determine whether the shadow APCB actually overlaps with the removal mask. If there is an intersection, call bitmap_andnot() solely for its side effect of clearing the bits, then unconditionally set do_hotplug to trigger the guest APCB update.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89958", "url": "https://ubuntu.com/security/CVE-2026-89958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL The ap_driver structure has two fields which are function pointers to callbacks: * .on_config_changed: called at the start of the AP bus scan function to notify the device driver that the host AP configuration has changed and the associated AP devices will be added or removed accordingly. This gives the implementor a chance to evaluate the configuration changes and respond to them before the associated devices are added or removed. * .on_scan_complete: Called at the end of the AP bus scan function to notify the device driver that the host AP configuration has changed and the AP devices have been added or removed accordingly. This gives the implementor the opportunity to respond to the changes after the associated devices are added or removed. These two callbacks are implemented in the vfio_ap device driver via the vfio_ap_on_cfg_changed and vfio_ap_on_scan_complete functions respectively. Within the call stack of these two callback functions the matrix_mdev->kvm->lock mutex is taken without checking whether matrix_mdev->kvm is NULL or not. If matrix_mdev->kvm has never been set, trying to take the lock will trigger a NULL pointer dereference. This patch adds checks for matrix_mdev->kvm == NULL before taking the matrix_mdev->kvm->lock mutex. Note that the matrix_mdev->kvm->lock mutex taken in the vfio_ap_mdev_hot_plug_config function is moved to the calling function along with the matrix_dev->mdevs_lock which is needed there to access the fields of the matrix_mdev. It makes little sense to make the change the check for matrix_mdev->kvm there before taking the kvm->lock mutex only to have to move it out via another patch, so it is done in this patch. It is important to make note of the following: 1. The matrix_dev->guests_lock is acquired at the start of both callback functions. This ensures that matrix_mdev will not be removed via the vfio_ap_mdev_remove function because it too takes matrix_dev_guests_lock before removing the object; so, matrix_mdev will be available for the duration of the callback functions. 2. The matrix_dev->mdevs_lock mutex must be taken in order to access fields within the matrix_mdev structure 3. matrix_mdev->kvm->lock mutex must be taken before the matrix_dev->mdevs_lock to prevent a lockdep splat. 4: The kvm->lock must be held while plugging the guest's AP configuration into its SIE state description via the vfio_ap_mdev_update_guest_apcb function. 5. The vfio_ap_mdev_update_guest_apcb checks matrix_mdev->kvm to verify it is not NULL before doing the hot plug of the guest's AP configuration.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89959", "url": "https://ubuntu.com/security/CVE-2026-89959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove The vfio_ap_config_remove function uses the bitmap_andnot function to clear bits from the matrix_mdev->matrix.adm bitmap (specifies the control domains assigned to the mdev). This prevents the explicitly unplugged control domains from being removed the KVM guest. The bitmap_and function is used instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89960", "url": "https://ubuntu.com/security/CVE-2026-89960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm() In vfio_ap_mdev_set_kvm(), kvm->arch.crypto.pqap_hook is set to &matrix_mdev->pqap_hook before the update locks are acquired and the mdev list is checked for a conflicting assignment. If another mdev is already attached to the same KVM instance, the function returns -EPERM without restoring the hook pointer, leaving kvm->arch.crypto.pqap_hook pointing at the failing matrix_mdev instead of the mdev that legitimately owns the KVM. Since matrix_mdev->kvm is never set on this error path, vfio_ap_mdev_unset_kvm() will not clean up the hook when matrix_mdev is later closed. If matrix_mdev is subsequently freed, any PQAP instruction executed by the guest will dereference the stale pointer through pqap_hook_rwsem, resulting in a use-after-free. Since kvm->arch.crypto.pqap_hook is only set in the vfio_ap_mdev_set_kvm() function and is cleared in the vfio_ap_mdev_unset_kvm() function, a check for 'kvm->arch.crypto.pqap_hook != NULL' is all that is needed to determine whether it belongs to another mdev. This will alleviate the need to iterate the matrix_dev->mdev_list list to see if the kvm object is assigned to another mdev.This was introduced in v3 to alleviate the need to take the mdevs_lock while iterating the list; however, this did not prevent a potential race condition. The pqap_hook_rwsem(write) is now performed inside get_update_locks_for_kvm(), which is updated to acquire pqap_hook_rwsem(write) between kvm->lock and mdevs_lock. This ordering is consistent with the PQAP intercept path, which acquires pqap_hook_rwsem in read mode while srcu is held under vcpu->mutex, establishing the dependency: kvm->lock -> vcpu->mutex -> srcu -> pqap_hook_rwsem(read). The pqap_hook_rwsem is now released inside the release_update_locks_for_kvm(), which is updated to release pqap_hook_rwsem(write) between mdevs_lock and kvm->lock. Additionally, kvm_put_kvm() in vfio_ap_mdev_unset_kvm() is moved after release_update_locks_for_kvm(). Previously it was called while kvm->lock was held; if it were ever the last reference, kvm_destroy_vm() would run under kvm->lock, which would deadlock.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89961", "url": "https://ubuntu.com/security/CVE-2026-89961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population vmemmap_populate_compound_pages() uses addr_pfn to determine the PFN offset within a compound page and to decide whether the current vmemmap slot should be populated as a head page mapping or should reuse a tail page mapping. However, addr_pfn is advanced manually in parallel with addr. The loop itself progresses in vmemmap address space, so each PAGE_SIZE step in addr covers PAGE_SIZE / sizeof(struct page) struct page slots. Since addr_pfn is compared against nr_pages in data-PFN units, it should advance by the same number of PFNs. The existing manual increments do not match that and therefore do not reliably track the PFN corresponding to the current addr. As a result, pfn_offset can be computed from the wrong PFN and the code can make the head/tail decision for the wrong compound-page position. Fix this by deriving addr_pfn directly from the current vmemmap address instead of carrying it as loop state.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89962", "url": "https://ubuntu.com/security/CVE-2026-89962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/kexec_file: Prevent kexec range truncation Sashiko AI review pointed out the following issue. The __merge_memory_ranges() function incorrectly handles overlapping memory ranges when merging them. Although sort_memory_ranges() sorts all ranges by their start address in ascending order beforehand, the merge logic remains defective in two ways: 1. It compares the current range's start against the previous element (i-1) instead of the running target index (idx) 2. It unconditionally overwrites 'ranges[idx].end' with 'ranges[i].end'. This logic flaw leads to critical memory truncation when a larger memory range completely subsumes subsequent smaller ranges. For example, consider a sorted input array with three ranges: Range A (idx=0): [0x1000 - 0x9000] Range B (i=1): [0x2000 - 0x5000] (completely inside Range A) Range C (i=2): [0x6000 - 0x8000] (completely inside Range A) 1. When i=1 (Range B): ranges[1].start (0x2000) <= ranges[0].end + 1 (0x9001) is TRUE. The code executes: ranges[0].end = ranges[1].end, which erroneously shrinks Range A's end from 0x9000 down to 0x5000. 2. When i=2 (Range C): ranges[2].start (0x6000) <= ranges[1].end + 1 (0x5001) is FALSE. The code falls into the else block, creating a broken new range. As a result, valid memory fragments [0x5001 - 0x5fff] and [0x8001 - 0x9000] are completely lost from the kexec exclude lists, potentially allowing the crash kernel to overwrite active memory, causing data corruption or crashes. Fix this by ensuring the start of the current range is compared against the end of the active merged range (idx), and use max() to safely prevent the outer boundary from being truncated.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89963", "url": "https://ubuntu.com/security/CVE-2026-89963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/kexec_file: Fix null-ptr-def in extra size calculation A static Sashiko AI review identified a potential NULL pointer dereference in kexec_extra_fdt_size_ppc64(). On platforms without any reserved memory regions, get_reserved_memory_ranges() can return 0 while leaving 'rmem' unallocated as NULL. Passing it directly leads to a kernel panic when evaluating 'rmem->nr_ranges'. Add a NULL check for 'rmem' to prevent this crash.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89964", "url": "https://ubuntu.com/security/CVE-2026-89964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: eisa: Fix infinite loop when parsing invalid IRQ value When an invalid value is passed via the \"eisa_irq_edge=\" kernel command line parameter (e.g. \"eisa_irq_edge=16,5\"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89965", "url": "https://ubuntu.com/security/CVE-2026-89965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: reject an arena whose nfree is below the lane count The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89968", "url": "https://ubuntu.com/security/CVE-2026-89968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: reject unsolicited H2CData PDUs nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the \"list_add double add\" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89969", "url": "https://ubuntu.com/security/CVE-2026-89969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as \tqueue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89970", "url": "https://ubuntu.com/security/CVE-2026-89970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: Synchronize timeout work during SQ teardown nvmet_auth_sq_free() cancels auth_expired_work with cancel_delayed_work(). If the work has already started, cancellation does not wait for the callback. Transport teardown can consequently free or reuse the queue containing struct nvmet_sq while nvmet_auth_expired_work() still accesses that SQ. Add a teardown-specific helper that synchronously drains the delayed work before freeing authentication state, and use it from nvmet_sq_destroy(). Keep the non-synchronous helper for in-band authentication state cleanup, where the SQ owner remains alive.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89972", "url": "https://ubuntu.com/security/CVE-2026-89972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: add missing SRCU grace period in error path nvme_alloc_ns() error path at out_unlink_ns removes ns from the namespace head siblings list with list_del_rcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs. The normal removal path in nvme_ns_remove() correctly calls synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for in-progress readers. Add the same grace period in the error path.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89973", "url": "https://ubuntu.com/security/CVE-2026-89973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: check the data direction of a C2HData PDU nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89974", "url": "https://ubuntu.com/security/CVE-2026-89974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails nvmf_create_ctrl() owns the fabrics options and frees them whenever ->create_ctrl() returns an error, so a transport must not free them on its own error paths. nvme-fc tracks this by testing ctrl->ctrl.opts in nvme_fc_ctrl_free(), which requires nvme_fc_init_ctrl() to clear that pointer on every error exit. The coupling is implicit, and commit 1a9e218195a5 (\"nvme: split device add from initialization\") broke it by adding a second error exit. When nvme_add_ctrl() fails, nvme_fc_init_ctrl() jumps to out_put_ctrl:, past the \"ctrl->ctrl.opts = NULL\" that only sits on the fail_ctrl: path, so nvme_fc_ctrl_free() frees the options and nvmf_create_ctrl() frees them a second time: BUG: KASAN: slab-use-after-free in nvmf_free_options+0x30/0x190 nvmf_free_options+0x30/0x190 drivers/nvme/host/fabrics.c:1284 nvmf_create_ctrl drivers/nvme/host/fabrics.c:1374 [inline] Freed by task 5534: nvme_fc_ctrl_free drivers/nvme/host/fc.c:2374 [inline] nvme_fc_init_ctrl+0xe17/0x1450 drivers/nvme/host/fc.c:3605 nvme_add_ctrl() fails when dev_set_name() cannot allocate, so this is reachable under memory pressure or fault injection. Without KASAN the options are freed twice. Rather than clear the pointer on the second exit as well, derive ownership the way nvme-tcp, nvme-rdma and nvme-loop do, from list membership: their free_ctrl leaves the options alone unless the controller made it onto the transport list. The list cannot simply be populated on the success path as it is there. nvme-fc runs the initial connect synchronously via flush_delayed_work(), and the controller has to be reachable on rport->ctrl_list for the whole of it: nvme_fc_unregister_remoteport() needs to find it to signal connectivity loss, nvme_fc_match_disconn_ls() matches an incoming Disconnect Association LS against ctrl->association_id, which is only assigned during that window, nvme_fc_resume_controller() needs it on remoteport re-registration, and nvme_fc_existing_controller() uses it to reject a duplicate connect racing the one in flight. Keep the insertion where it is and add a fail_unlist: label, falling into fail_ctrl:, for the error paths that run after it. The earlier error paths never reach the insertion and keep using fail_ctrl: directly, so the list is only touched where the controller is actually on it. nvme_fc_ctrl_free() cannot use the plain \"goto free_ctrl\" the other transports use, because it still has to put_device(), release the rport reference and free the ida entry for resources taken before the insertion. Sample list_empty() under rport->lock instead. ctrl->ctrl.opts also stays valid for the whole teardown now. That is not the bug being fixed, but it removes some fragility around the old idiom: nvme_free_ctrl() calls nvme_auth_free() before ->free_ctrl(), and ctrl_max_dhchaps() dereferences ctrl->opts without a NULL check when ctrl->dhchap_ctxs is set, which nvme-fc permits since NVMF_ALLOWED_OPTS allows the dhchap options. The nvme sysfs attributes that dereference ctrl->opts, such as hostnqn and address, evaluate their is_visible() test once at device_add() time and stay readable until cdev_device_del().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89975", "url": "https://ubuntu.com/security/CVE-2026-89975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fabrics: fix DHCHAP secret leak on parse failure nvmf_parse_options() duplicates dhchap_secret and dhchap_ctrl_secret with match_strdup() before validating the DHHC-1: representation. If validation fails, the parser returns -EINVAL before the temporary string in p is assigned to opts->dhchap_secret or opts->dhchap_ctrl_secret. nvmf_create_ctrl() subsequently frees opts, but nvmf_free_options() cannot release the unassigned temporary string. Each rejected option therefore leaks one allocation. This is easy to miss because valid secrets transfer ownership to opts and are freed normally, while the malformed-secret path still returns the expected -EINVAL to userspace. With CONFIG_NVME_HOST_AUTH enabled, the leak is reachable before the required-option checks and transport lookup. No NVMe-oF target or working transport connection is required; for example, repeatedly writing \tdhchap_secret=BAD or \tdhchap_ctrl_secret=BAD to /dev/nvme-fabrics deterministically takes the leaking parse path. Free the temporary string before leaving both validation error paths. Use kfree_sensitive() because the copied option may contain secret material even when its representation is rejected, matching the sensitive cleanup used for stored DHCHAP secrets.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89979", "url": "https://ubuntu.com/security/CVE-2026-89979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race between non-atomic ops and trigger-start We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89980", "url": "https://ubuntu.com/security/CVE-2026-89980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: harmony: initialize locks before requesting IRQ snd_harmony_create() registers the IRQ before initializing h->lock and h->mixer_lock. A pending interrupt can invoke the handler while these locks are uninitialized. Initialize both locks before requesting the IRQ so the handler always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89982", "url": "https://ubuntu.com/security/CVE-2026-89982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89983", "url": "https://ubuntu.com/security/CVE-2026-89983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89984", "url": "https://ubuntu.com/security/CVE-2026-89984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \\ \t./perf bench syscall basic --loop 1000 | \\ \t./perf script -i - --fields brstack|tr ' ' '\\n'| \\ \tgrep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90048", "url": "https://ubuntu.com/security/CVE-2026-90048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list() ni_create_attr_list() allocates a fixed buffer of al_aligned(record_size) (== record_size) bytes and then walks every attribute of the primary MFT record, writing one ATTR_LIST_ENTRY per attribute and advancing the cursor by le_size(name_len), with no check against the end of the buffer; the total size is only computed after the loop. A minimum-size resident attribute occupies SIZEOF_RESIDENT (0x18 = 24) bytes on disk, but an unnamed attribute expands to le_size(0) (0x20 = 32) bytes in the list. Because the number of attributes in a record is not bounded (mi_enum_attr() accepts arbitrarily many equal-type, nameless minimum-size attributes), a crafted record packed with such attributes produces a list larger than record_size and overflows the heap buffer. This is reachable from a crafted, loop-mounted NTFS image: opening the file and adding an attribute (e.g. via setxattr) drives ntfs_set_ea() -> ni_insert_resident() -> ni_insert_attr() -> ni_ins_attr_ext() -> ni_create_attr_list(). BUG: KASAN: slab-out-of-bounds in ni_create_attr_list+0xc48/0x1058 Write of size 4 at addr ffff000008984c00 by task setfattr/345 ni_create_attr_list+0xc48/0x1058 ni_ins_attr_ext+0x510/0x7c0 ni_insert_attr+0x3f8/0x70c ni_insert_resident+0xc8/0x3b0 ntfs_set_ea+0x66c/0xd28 ntfs_setxattr+0x4d8/0x5b0 __arm64_sys_setxattr+0xa4/0x124 Allocated by task 345: ni_create_attr_list+0x188/0x1058 The buggy address belongs to the cache kmalloc-1k of size 1024 (the write lands at object+1024). Size the buffer from the actual attributes instead of assuming a single record_size is always enough.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89986", "url": "https://ubuntu.com/security/CVE-2026-89986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix sleeping allocation in alloc_pages_bulk_weighted_interleave() syzbot reported a sleeping function called from invalid context splat in bucket_table_alloc(). When rhashtable_insert_slow() rehashes the table under rcu_read_lock(), it calls bucket_table_alloc(..., GFP_ATOMIC | __GFP_NOWARN). If the bucket table allocation uses vmalloc, __vmalloc_node_range_noprof() invokes vm_area_alloc_pages() -> alloc_pages_bulk_mempolicy_noprof() with the passed GFP_ATOMIC flags. If the current task has an MPOL_WEIGHTED_INTERLEAVE mempolicy, alloc_pages_bulk_weighted_interleave() is called and currently hardcodes GFP_KERNEL when allocating the temporary weights array, triggering a might_alloc() splat in atomic/RCU contexts. Pass the gfp flags (masked with GFP_RECLAIM_MASK to strip page-allocator zone modifiers like __GFP_HIGHMEM) received by alloc_pages_bulk_weighted_interleave() to kmalloc() instead of hardcoding GFP_KERNEL. Since the weights buffer is immediately initialized in full, kmalloc() is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89988", "url": "https://ubuntu.com/security/CVE-2026-89988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kprobes: Protect kprobe_blacklist with RCU __within_kprobe_blacklist() traverses kprobe_blacklist without holding kprobe_mutex. When a module is unloaded, kprobe_remove_area_blacklist() removes blacklist entries and immediately frees them with kfree(). A concurrent call to within_kprobe_blacklist() can therefore dereference freed memory. Furthermore, within_kprobe_blacklist() can be called in atomic or non-preemptible contexts where the sleeping kprobe_mutex cannot be taken. Protect kprobe_blacklist with RCU. Use guard(rcu)() and list_for_each_entry_rcu() for traversal, list_add_tail_rcu() for insertions, list_del_rcu() for deletions, and kfree_rcu() to reclaim entries safely after a grace period.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89989", "url": "https://ubuntu.com/security/CVE-2026-89989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89990", "url": "https://ubuntu.com/security/CVE-2026-89990", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: lock mutex in ceph_mds_check_access() MDS session OPEN handling replaces mdsc->s_cap_auths under mdsc->mutex, freeing the previous array and its strings. ceph_mds_check_access() traverses this array without holding the mutex. A concurrent session reopen can therefore free the array while it is being inspected, resulting in a use-after-free like this: Unable to handle kernel paging request at virtual address 003aaad64b2c8bb9 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 56 UID: 2953037534 PID: 1253231 Comm: php-cgi8.4 Not tainted 6.18.45-i2-ampere #1146 NONE [..] pc : ceph_mds_check_access+0xd4/0x550 lr : ceph_mds_check_access+0xc8/0x550 [...] Call trace: ceph_mds_check_access+0xd4/0x550 (P) ceph_atomic_open+0x138/0xbe8 path_openat+0xa24/0xfa8 do_filp_open+0x94/0x158 do_sys_openat2+0x88/0xf8", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89991", "url": "https://ubuntu.com/security/CVE-2026-89991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix infinite loop in pcpu_freelist push with one possible CPU __pcpu_freelist_push() can loop forever when only one CPU is possible and an NMI re-enters pcpu_freelist_push() while the interrupted context holds that CPU's freelist lock. After the current-CPU fast path fails, the fallback loop walks cpu_possible_mask while skipping the current CPU. With CONFIG_SMP=n, or when an SMP kernel is limited to one possible CPU with nr_cpus=1 or possible_cpus=1, there are no other possible CPUs to examine. The loop therefore makes no lock acquisition attempt and can never make progress. The following stack was observed on a UP system: NMI context: pcpu_freelist_push free_htab_elem htab_map_delete_elem [perf-event BPF program] __perf_event_overflow perf_event_nmi_handler exc_nmi Interrupted context: __pcpu_freelist_push pcpu_freelist_push free_htab_elem htab_map_delete_elem [raw_tp/sys_enter BPF program] __bpf_trace_sys_enter do_syscall_64 raw_res_spin_lock() detects the same-CPU recursive acquisition and returns -EDEADLK, but the subsequent fallback loop has no candidate head on a system with one possible CPU. Restore the extra fallback head that existed before the rqspinlock conversion. Keep the current-CPU fast path, then try the other possible CPUs and finally the extra head. The additional head lets a push, which cannot fail without losing a preallocated element, make progress when the only per-CPU head is held by the interrupted context. Also check the extra head from the pop path so that nodes placed there can be reused.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89992", "url": "https://ubuntu.com/security/CVE-2026-89992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuidle: dt_idle_genpd: kfree() the original name allocation dt_idle_pd_alloc() kasprintf()s the full node path, then points pd->name at kbasename() of that string. dt_idle_pd_free() kfree()s pd->name, which is no longer the start of the allocation. Copy the basename instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89993", "url": "https://ubuntu.com/security/CVE-2026-89993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Initialize IRQ data before requesting IRQs dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89994", "url": "https://ubuntu.com/security/CVE-2026-89994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-edma: tracing: no ptr dereference during log output The fsl edma events store a pointer to a struct fsl_edma_engine in the ringbuffer and dereference it when a log entry is printed. At this time, the pointer may no longer be valid. Event injection can be used to trigger a crash: $ cd /sys/kernel/tracing $ echo 'value = 0' > events/fsl_edma/edma_writeb/inject $ cat trace The log output needs only edma->membase. Add a membase field at the end of the event and use the new field for log output. Keep the existing fields for backward compatibility.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89995", "url": "https://ubuntu.com/security/CVE-2026-89995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dma-direct: return struct page from dma_direct_alloc_from_pool() Commit 5b138c534fda (\"dma-direct: factor out a dma_direct_alloc_from_pool helper\") changed dma_direct_alloc_from_pool() to return the CPU address from dma_alloc_from_pool(). That fits dma_direct_alloc(), but dma_direct_alloc_pages() also uses the helper and expects a struct page *. Fix this by making dma_direct_alloc_from_pool() return the struct page * again, and pass the CPU address back through an out-parameter for the dma_direct_alloc() caller.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89997", "url": "https://ubuntu.com/security/CVE-2026-89997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix resume-vs-remove race If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method. Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free. Fix this bug by refusing to resume if the device is being destroyed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89998", "url": "https://ubuntu.com/security/CVE-2026-89998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix race when loading and unloading a table If the userspace calls two concurrent table load ioctls and one of them succeeds and the other fails, there is a race condition because dm_setup_md_queue walks &md->table_devices without any lock. If the walk races with dm_table_destroy -> free_devices -> dm_put_table_device, there is access to invalid memory. Fix this race by extending the lock over the list walk.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89999", "url": "https://ubuntu.com/security/CVE-2026-89999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: validate report length in wacom_intuos_pro2_bt_irq wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: \twacom_intuos_pro2_bt_pen(wacom); \tif (type == INTUOSP2_BT || type == INTUOSP2S_BT) { \t\twacom_intuos_pro2_bt_touch(wacom); \t\twacom_intuos_pro2_bt_pad(wacom); \t\twacom_intuos_pro2_bt_battery(wacom); \t} else { \t\twacom_intuos_gen3_bt_pad(wacom); \t\twacom_intuos_gen3_bt_battery(wacom); \t} Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] \t(the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT (\"gen3\"): wacom_intuos_gen3_bt_battery() reads data[45], \tso the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 (\"HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq\") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90000", "url": "https://ubuntu.com/security/CVE-2026-90000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: rmi: fix OOB access with undersized RMI reports The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: \tdata->input_report_size = hid_report_len(input_report); \tdata->output_report_size = hid_report_len(output_report); \talloc_size = data->output_report_size + data->input_report_size; \tdata->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); \tdata->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly \"this probe validated the reports\"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90001", "url": "https://ubuntu.com/security/CVE-2026-90001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: bpf: serialize device reference release in struct_ops destroy path __hid_bpf_ops_destroy_device() and hid_bpf_unreg() can race on the same registration reference, double-putting struct hid_device and freeing it while hid_destroy_device() still uses it. Serialize the remove/NULL decision under hdev->bpf.prog_list_lock so exactly one path releases each registration reference: unreg re-checks ops->hdev under the lock and returns without putting when the destroy path already cleared it; all put_device() calls happen after the lock is dropped, which is safe because a concurrent unreg then observes ops->hdev == NULL under the lock. Background: each successful attach (hid_bpf_ops_reg) acquires one device reference (hid_get_device()). Two paths can release it: - device destruction: hid_destroy_device() -> hid_bpf_destroy_device() -> __hid_bpf_ops_destroy_device(), which walks hdev->bpf.prog_list under rcu_read_lock() and drops one reference per attached program; - BPF link release: bpf map delete (no BPF_F_LINK) synchronously calls st_ops->unreg() -> hid_bpf_unreg(), which drops the reference for its own registration. The coordination handshake (e->hdev = NULL on the destroy side vs \"if (!hdev) return\" on the unreg side) is a TOCTOU check: the two paths run under different lock domains (rcu_read_lock vs prog_list_lock), so a concurrent unreg can read ops->hdev as non-NULL, block on prog_list_lock, and then proceed while the destroy traversal executes - both paths then drop the same reference. The refcount reaches zero legitimately (each decrement is individually valid), so no refcount_t saturation fires: the device is simply freed while the transport is still inside hid_destroy_device(), and subsequent teardown touches freed memory. The fix serializes the remove/NULL decision under prog_list_lock on both sides and moves the destroy-side puts outside the lock. With the lock held, plain reads/writes of ops->hdev are sufficient; no READ_ONCE/WRITE_ONCE are added, keeping the patch minimal. Unlocked-read safety: the unlocked read of ops->hdev at the top of hid_bpf_unreg() cannot touch a freed device, because the unreg path itself still holds this registration's reference (released only by its own hid_put_device() after the lock is dropped), and a destroy traversal that already cleared ops->hdev makes the lock-internal re-check return early without any put. At most one of the two paths releases each registration reference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90003", "url": "https://ubuntu.com/security/CVE-2026-90003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent rcuwait use-after-free during requeue PI On PREEMPT_RT, FUTEX_CMP_REQUEUE_PI can trigger a KASAN report (slab-out-of-bounds) in futex_requeue_pi_complete() invocation of rcuwait_wake_up(). The futex_q used by futex_wait_requeue_pi() is allocated on the waiter's stack. An early wakeup can race with a PI requeue as follows: waiter requeue task ------ ------------ futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_NONE -> Q_REQUEUE_PI_IN_PROGRESS * timeout/ signal wakes waiter * futex_requeue_pi_wakeup_sync() Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_WAIT requeue_pi_wake_futex futex_requeue_pi_complete() cmpxchg Q_REQUEUE_PI_WAIT -> Q_REQUEUE_PI_LOCKED rcuwait_wait_event() if (atomic_read(&q->requeue_state) != Q_REQUEUE_PI_WAIT) break /* no schedule() */ /* q.pi_state->owner == current */ futex_private_hash_put() /* return from syscall */ rcuwait_wake_up(&q->requeue_wait) /* q is gone */ futex_requeue_pi_complete() publishes Q_REQUEUE_PI_LOCKED before calling rcuwait_wake_up(). The waiter observes this state in rcuwait_wait_event() before invoking schedule() in rcuwait_wait_event(). Here, the waiter is free leave the syscall before requeue task can complete the wake. To address this race skip rcuwait_wake_up() in the Q_REQUEUE_PI_LOCKED case. This state is only published by requeue_pi_wake_futex(), which saves q->task before futex_requeue_pi_complete() and wakes the waiter via wake_up_state(). This wake is intended to wake the waiter from its futex_do_wait() sleep. If the waiter is still sleeping there, it can not get into the Q_REQUEUE_PI_WAIT state (and require this removed wake). Should the waiter be woken up from futex_do_wait() by other means (as in this example) and sleep in futex_requeue_pi_wakeup_sync() then the wake_up_state() from requeue_pi_wake_futex() will wake it, too. Should the waiter task terminate before wake_up_state() had a chance to wake the task then the task pointer does not become invalid because the futex_hash_bucket::lock is held and the task pointer is RCU protected. [bigeasy: Updated comment and commit message]", "cve_priority": "high", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90005", "url": "https://ubuntu.com/security/CVE-2026-90005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: samples/damon/wsse: handle damon_start() failure Patch series \"samples/damon: handle damon_{start,stop}() failures\". All DAMON sample modules are not correctly handling failures from damon_start(). Among those, mtier also has an additional problem for handling of damon_stop() failures. wsse and prcl also have a problem in their damon_call() failure handling. As a result, memory leaks, next DAMON operation disruptions, and use-after-free can happen. Fix those. Note that only the damon_start() failure caused issues can reliably be reproduced. Reproducing those issues require the admin permission, though. This patch (of 6): damon_sample_wsse_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it leaks the memory for DAMON context. Free the context in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo $$ | sudo tee /sys/module/damon_sample_wsse/parameters/target_pid $ echo Y | sudo tee /sys/module/damon_sample_wsse/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the third command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the third and the fourth commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90006", "url": "https://ubuntu.com/security/CVE-2026-90006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: samples/damon/mtier: handle damon_stop() failure damon_sample_mtier_stop() assumes its damon_stop() call will always successfully stops the two DAMON contexts. Hence it deallocates the two DAMON contexts after the damon_stop() call. However, if a given context is already stopped, damon_stop() fails and returns an error while letting the DAMON contexts that have not yet stopped keep running. This kind of unexpected early DAMON context stops could happen due to memory allocation failures in kdamond_fn(). Because damon_sample_mtier_stop() just deallocates all DAMON contexts with damon_target and damon_region objects that are linked to the contexts, the execution of the unstopped DAMON context (kdamond) ends up using the memory that freed (use-after-free). Fix the issue by separating the damon_stop() to be invoked per context. Note that DAMON_SYSFS also allows multiple DAMON contexts execution. But, it calls damon_stop() for each context one by one. Hence this issue is only in mtier. For the long term, it would be better to refactor damon_stop() to always ensure stopping all contexts regardless of the failures in the middle. Make this fix in the current way, though, to keep it simple and easy to backport. I will do the refactoring later. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90007", "url": "https://ubuntu.com/security/CVE-2026-90007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Use rollback index when freeing MSI-X vectors pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90011", "url": "https://ubuntu.com/security/CVE-2026-90011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where \tpadding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90012", "url": "https://ubuntu.com/security/CVE-2026-90012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: Fix DMA mapping ownership on partial map failure If RX mapping fails after TX mapping succeeds, __spi_map_msg() unmaps TX but leaves tx_sg_mapped set. If TX mapping fails on a later transfer, mappings created for earlier transfers remain active. In both cases, cur_{tx,rx}_dma_dev have not yet been updated because they are assigned only after every transfer has been mapped. The subsequent spi_unmap_msg() may therefore unmap the TX mapping again or release earlier mappings using a NULL or stale device. Using a NULL device can trigger an oops. An empty SG table does not prevent the NULL dereference because dma_unmap_sg_attrs() accesses the device before checking the entry count. Publish both mapping devices before mapping starts and unwind all failures through __spi_unmap_msg(). This clears the mapping flags and releases each mapping once with the device that created it. Publishing the devices before the loop also refreshes them when no transfer needs mapping. No mapping flag is set in that case, so current users do not use the pointers as mapping owners.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89793", "url": "https://ubuntu.com/security/CVE-2026-89793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: clear VM_MAYWRITE on read-only ublk char device mmap ublk_ch_mmap() rejects mmap requests with VM_WRITE set, but never clears VM_MAYWRITE on the resulting read-only mapping. This allows a userspace daemon to mmap the per-queue command buffer PROT_READ, then upgrade it to PROT_WRITE via mprotect(), since VM_MAYWRITE was never cleared. The command buffer holds struct ublksrv_io_desc entries that are kernel-written ABI; a writable mapping lets an unprivileged daemon process corrupt fields such as addr, op_flags, nr_sectors, and start_sector. Same bug class as the drm/panthor and drm/vc4 VM_MAYWRITE fixes, and the 2026-08-13 ptp/vmclock fix (a5edadbae57e). Verified via mprotect() PoC: before the fix, a PROT_READ mapping can be upgraded to PROT_READ|PROT_WRITE and a write into the command buffer corrupts io_desc fields (confirmed under KASAN). After the fix, mprotect() returns -EACCES.", "cve_priority": "medium", "cve_public_date": "2026-09-16 10:16:00 UTC" }, { "cve": "CVE-2026-90015", "url": "https://ubuntu.com/security/CVE-2026-90015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90017", "url": "https://ubuntu.com/security/CVE-2026-90017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: \tconst u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); \t... \tc = frame_body[0]; \t... \ta = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90018", "url": "https://ubuntu.com/security/CVE-2026-90018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: \tif (attr_ptr + 4 > wps_ie + wps_ielen) \t\tbreak; \tu16 attr_id = get_unaligned_be16(attr_ptr); \tu16 attr_data_len = get_unaligned_be16(attr_ptr + 2); \tu16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: \tmemcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack \"u8 sr\"/\"u8 selected_registrar\" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The \"attr_ptr + 4 > wps_ie + wps_ielen\" header check above was added by commit 1463ca3ec6601 (\"staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()\"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90019", "url": "https://ubuntu.com/security/CVE-2026-90019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: fix null pointer dereference in usb_put_function_instance() usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90020", "url": "https://ubuntu.com/security/CVE-2026-90020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90021", "url": "https://ubuntu.com/security/CVE-2026-90021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: initialize work in f_midi_alloc() f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc().", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90022", "url": "https://ubuntu.com/security/CVE-2026-90022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi2: fix use-after-free in string attribute show path f_midi2_opts_str_show() takes the string lock internally, but its callers dereference the opts->info. pointer before calling it, outside the lock. This races with f_midi2_opts_str_store(), which frees the old string under opts->lock when the attribute is written concurrently, the show path can read a pointer that gets freed before the lock inside str_show() is even taken. Change f_midi2_opts_str_show() to take a pointer to the string field, matching the existing pattern in f_midi2_opts_str_store(), and dereference it only after the lock is held. Update all three callers (iface_name, block name, and the EP string option macro) accordingly.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90024", "url": "https://ubuntu.com/security/CVE-2026-90024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: midi2: Fix null-pointer dereference in f_midi2_free_ep_reqs A null-pointer dereference occurs in f_midi2_free_ep_reqs() when attempting to clean up an endpoint that was never initialized. When configuring the MIDI 2.0 gadget via configfs and setting the block direction to SNDRV_UMP_DIR_INPUT, the initialization of the midi1_ep_out endpoint is explicitly skipped during the gadget bind phase (f_midi2_bind()). As a result, the usb_ep->card field remains NULL. Later, when the host sets the alternate setting, f_midi2_set_alt() unconditionally stops both the IN and OUT endpoints by calling f_midi2_stop_eps(), which in turn calls f_midi2_free_ep_reqs() for both endpoints. When f_midi2_free_ep_reqs() is called for the uninitialized midi1_ep_out, it attempts to dereference usb_ep->card to determine the number of requests to free, leading to a crash. Fix this by using usb_ep->num_reqs instead of usb_ep->card->info.num_reqs in f_midi2_free_ep_reqs(). usb_ep->num_reqs is correctly set during f_midi2_init_ep() and remains 0 if the endpoint was never initialized, safely avoiding the loop. For consistency, apply the same change to f_midi2_alloc_ep_reqs(). Oops: general protection fault, probably for non-canonical address 0xdffffc00000000ee: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000770-0x0000000000000777] ... RIP: 0010:f_midi2_free_ep_reqs drivers/usb/gadget/function/f_midi2.c:1166 [inline] RIP: 0010:f_midi2_stop_eps+0x28e/0x4d0 drivers/usb/gadget/function/f_midi2.c:1246 ... Call Trace: f_midi2_set_alt+0x11c/0xf00 drivers/usb/gadget/function/f_midi2.c:1296 composite_setup+0x1ffd/0x3480 drivers/usb/gadget/composite.c:1933 configfs_composite_setup+0xbd/0x100 drivers/usb/gadget/configfs.c:1877", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90025", "url": "https://ubuntu.com/security/CVE-2026-90025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix OOB altmode array index The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90026", "url": "https://ubuntu.com/security/CVE-2026-90026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: cancel reset_work on stop pdphy_stop() disables IRQs but leaves reset_work pending. If the IRQ handler schedules it just before disable_irq(), the work runs after remove() frees the struct via devm. Call cancel_work_sync() after disabling IRQs to close the window. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90027", "url": "https://ubuntu.com/security/CVE-2026-90027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic-typec: disable cc_debounce_dwork on stop cc_debounce_dwork is queued from the set_cc() and start_toggling() callbacks, which run from TCPM's kthread worker. port_stop() returns before tcpm_unregister_port() destroys that worker. Flushing the worker during unregister may therefore run a callback which queues the delayed work after port_stop() has returned. The delayed work can then run after devres has freed pmic_typec_port. Use disable_delayed_work_sync() in port_stop() to cancel a pending instance and prevent the TCPM callbacks from queueing another one. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90029", "url": "https://ubuntu.com/security/CVE-2026-90029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: realtek_cr: fix use-after-free on disconnect realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free. Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed. Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90030", "url": "https://ubuntu.com/security/CVE-2026-90030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: clear forceRM when issuing EndTransfer The forceRM bit of the DEPCMD register controls the behavior of the EndTransfer command used to stop an active transfer. Older DWC3 programming guide revisions recommended setting forceRM=1 when issuing EndTransfer. Newer programming guide revisions recommend issuing EndTransfer with forceRM cleared. With forceRM=1 on DWC_usb31 v2.00a and v2.10a controllers, a transfer aborted through the ep_dequeue path was observed to remain active after EndTransfer completion. A subsequent StartTransfer issued on the same endpoint triggered writes associated with the aborted transfer. This resulted in an SMMU fault because the transfer buffer had already been unmapped during EndTransfer command-completion cleanup. Using forceRM=0 eliminates the issue. Although older DWC3 programming guide revisions recommended setting forceRM=1, no issues are known from using forceRM=0. Clear forceRM when issuing EndTransfer to provide consistent EndTransfer behavior and align with newer programming guide recommendations.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90031", "url": "https://ubuntu.com/security/CVE-2026-90031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90032", "url": "https://ubuntu.com/security/CVE-2026-90032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: usbtv: keep device alive while ALSA card exists The ALSA PCM callbacks store the driver state in pcm->private_data. An open PCM file can outlive USB disconnect because usbtv_audio_free() uses snd_card_free_when_closed(). The disconnect path can then drop the V4L2 device reference and free struct usbtv before ALSA releases the substream, so a later close dereferences freed memory in snd_usbtv_pcm_close(). Take a V4L2 device reference for the ALSA card and drop it from the card private_free callback. This keeps struct usbtv valid until ALSA has closed the remaining files and freed the card.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90033", "url": "https://ubuntu.com/security/CVE-2026-90033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90034", "url": "https://ubuntu.com/security/CVE-2026-90034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90035", "url": "https://ubuntu.com/security/CVE-2026-90035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix division by zero in get_estimated_bw() get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3)", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90047", "url": "https://ubuntu.com/security/CVE-2026-90047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Don't hand out the flat CCS storage as usable VRAM get_flat_ccs_offset() reads the base of the flat CCS storage from the hardware, scales it by the number of enabled L3 nodes, and rounds the result up to 128K. Everything below that offset is then handed to the VRAM allocator as usable memory. Rounding a limit that means \"usable memory ends here\" upwards publishes whatever lies between the real base and the rounded one as free memory, and that memory belongs to the compression hardware. The scaled value has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it is not: \tflat CCS base: raw 0x3fafff800, rounded 0x3fb000000 so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator's pool. Whatever is allocated there gets that tail overwritten by the compression hardware, which needs no page-table entry, no buffer object and no GPU submission to do it, and does it before userspace exists. On this machine a Mesa VM's level-3 page table landed on that page on every cold boot. It lost the entry covering the compositor's batch-buffer heap, so the compositor's first submission faulted fetching its batch and gdm restarted it forever: a black screen on an otherwise working machine. Restarting gdm cleared it because the next VM's page tables were allocated somewhere else. Round down instead, to the page size the allocator works in. On this machine that excludes exactly one page. Reading the reserved page afterwards shows what had been writing it: \t[369] 0xcccc000000000000 \t[371] 0xcc77000000000000 \t[373] 0xcccc000000000000 \t[375] 0xcc77000000000000 compression metadata, two bytes per sixteen, sitting where the driver used to hand out memory. The assertion that should have caught this compares the offset against GSMBASE - ccs_size for equality. That value is 128K aligned, so it agrees with the rounded-up offset precisely when the base is not aligned - the check cannot fail in the case it exists to catch, and is compiled out unless CONFIG_DRM_XE_DEBUG is set. Replace it with one that can fail: CCS storage must not run into GSM. [ And this was a debug session from hell, enormously helped by an AI doing much of the grunt-work. I'd like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it. I suspect those things have been trained by people who may not be quite as stubborn as I am. But while the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed. So credit where credit is due and I let the AI write the commit message above. This is basically a one-liner fixing a bogus \"round_up()\" to a \"round_down()\", but there were 24 patches adding more and more debug information to this, and 18 kernel boot to finally narrow it down to this. - Linus ]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90049", "url": "https://ubuntu.com/security/CVE-2026-90049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80724", "url": "https://ubuntu.com/security/CVE-2026-80724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: vmclock: prevent read-only mappings from becoming writable vmclock_miscdev_mmap() rejects writable mappings of the shared vmclock ABI page with -EROFS, but leaves VM_MAYWRITE set. Userspace can map the page read-only and then upgrade it to writable with mprotect(), after which the guest can corrupt the host-written timekeeping data (sequence counter, UTC time, TSC offset) that the vmclock ABI defines as read-only. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 does for its read-only objects and as fixed in drm/vc4 (CVE-2026-68445) and drm/panthor (CVE-2024-53071).", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80914", "url": "https://ubuntu.com/security/CVE-2026-80914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready iso_conn_ready() looks up the BIS listener socket with iso_get_sock(), which takes a reference, and then, without re-checking its state, creates a child socket from it: parent = iso_get_sock(hdev, ...); if (!parent) return; lock_sock(parent); sk = iso_sock_alloc(sock_net(parent), NULL, BTPROTO_ISO, ...); ... iso_chan_add(conn, sk, parent); ... release_sock(parent); sock_put(parent); If the listener socket is closed concurrently, between iso_get_sock() and lock_sock(), the reference taken by iso_get_sock() may be the last one: the close path drops the link-list reference, and once iso_conn_ready() drops its own reference at the end of the function the socket is freed. The child socket, however, is already linked to the freed parent, and a later disconnect of the child runs iso_chan_del() -> bt_accept_unlink(), which dereferences the dangling parent pointer into the freed accept queue (a use-after-free). The same dangling pointer is also dereferenced through parent->***() in iso_chan_del(). Fix it the same way the connected (non-BIS) path was fixed in commit 0d255e63fcf3 (\"Bluetooth: ISO: hold sk properly in iso_conn_ready\"): after taking the socket lock, re-check that the parent is still a listening, alive socket, and bail out otherwise.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80833", "url": "https://ubuntu.com/security/CVE-2026-80833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ss support which is one of the only remaining ones. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. Also, it had a buffer overread bug in the line 'memcpy(ctx->seed, d + dlen, ctx->slen);'. There's no point in fixing these bugs separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80834", "url": "https://ubuntu.com/security/CVE-2026-80834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ce support which is one of the only remaining ones. Note that the sun8i-ce support for hwrng remains in place. That is the interface that actually matters. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. There's no point in fixing this separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80925", "url": "https://ubuntu.com/security/CVE-2026-80925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vlan: fix skb_under_panic and races when toggling HW VLAN offload Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(), which dynamically changed vlandev->hard_header_len. This causes two issues: 1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2) read dev->hard_header_len without holding RTNL lock. Mutating hard_header_len dynamically under RTNL creates a data race where upper layers reserve insufficient headroom based on a stale hard_header_len, resulting in skb_under_panic when vlan_dev_hard_header() is called. 2. In addition, vlan_transfer_features() updated hard_header_len without updating header_ops, causing a mismatch between allocated headroom and header creation. Always setting dev->hard_header_len = real_dev->hard_header_len and dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN unconditionally ensures: - dev->hard_header_len remains 100% static and immutable at real_dev->hard_header_len, eliminating all dynamic runtime updates and data races on hard_header_len. - Upper layers allocating skbs via LL_RESERVED_SPACE() will always reserve sufficient headroom for software VLAN tag insertion (real_dev->hard_header_len + real_dev->needed_headroom + VLAN_HLEN). - vlandev inherits real_dev->needed_tailroom so underlying trailer/padding/ICV requirements are honored. - AF_PACKET SOCK_RAW network header offsets remain correctly aligned at real_dev->hard_header_len. - vlan_header_ops is used unconditionally. Note to stable teams: Make sure to backport these commits: e16e960d55a4 (\"ipvlan: inherit needed_headroom and needed_tailroom from phy_dev\") cef51860becd (\"macvlan: inherit needed_headroom and needed_tailroom from lowerdev\")", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80857", "url": "https://ubuntu.com/security/CVE-2026-80857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: wait for FR_FINISHED on abort_on_kill to prevent use-after-free The abort_on_kill path in request_wait_answer() calls fuse_abort_conn() and returns without waiting for FR_FINISHED. If fuse_dev_do_write() is concurrently processing the same request (FR_LOCKED set), the caller frees req->args while it is still being accessed, causing a use-after-free. Fix this by jumping to the existing wait_event(FR_FINISHED) instead of returning early. The wait will not hang because fuse_abort_conn() ensures all requests are ended.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80858", "url": "https://ubuntu.com/security/CVE-2026-80858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: publish io-uring queues with release semantics fuse_uring_create_queue() initializes a fuse_ring_queue and then publishes the pointer into ring->queues[qid] with WRITE_ONCE() under the fch->lock. There are several readers that may concurrently be fetching that pointer locklessly and then deferencing it. WRITE_ONCE() doesn't ensure ordering of the queue's field initialization before the ring->queues[qid] pointer assignment. The queue must be published with smp_store_release() so the field initialization is guaranteed to happen before. Readers in paths where the read may happen concurrently with the store need to use READ_ONCE() because any race involving a plain access is undefined.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80859", "url": "https://ubuntu.com/security/CVE-2026-80859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix missing barrier when checking io-uring readiness fuse_block_alloc() reads fch->initialized and then fch->io_uring. fch->io_uring is set before fch->initialized, ordered by the smp_wmb() in fuse_chan_set_intialized(), but fuse_block_alloc() has no matching read barrier between the two loads. This may lead a CPU to observe fch->initialized=1 but fch->io_uring=0, and skip the check that blocks request allocation until the io-uring queues are ready. This can reintroduce the lock-order inversion deadlock that commit 3393ff964e0f prevents. Add an smp_rmb() barrier to pair with the smp_wmb() in fuse_chan_set_initialized() to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80860", "url": "https://ubuntu.com/security/CVE-2026-80860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix race between interrupt and resend After commit f8fce75fedf7 (\"fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req\") the WARN_ON(!list_empty(&req->intr_entry)) in fuse_request_free() still triggers due to the following race: In request_wait_answer() if (test_bit(FR_SENT, &req->flags)) -> returns true In fuse_chan_resend() clear_bit(FR_SENT, &req->flags) In request_wait_answer() queue_interrupt(req) Fix by: - move clearing FR_SENT inside fpq->lock - move setting FR_PENDING inside fiq->lock - recheck FR_SENT after acquiring fiq->lock in fuse_dev_queue_interrupt()", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80590", "url": "https://ubuntu.com/security/CVE-2026-80590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 (\"net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list\") and by commit 9e4b7a99a03a (\"net: gso: fix panic on frag_list with mixed head alloc types\") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 (\"tun: Allow GSO using virtio_net_hdr\"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74735", "url": "https://ubuntu.com/security/CVE-2026-74735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: fix tunnel and session refcount leak on seq_file release In pppol2tp_proc_open() and l2tp_dfs_seq_open(), iteration state (pd->tunnel and pd->session) is kept in seq_file private data to allow iteration across multiple read() system calls. However, if userspace closes /proc/net/pppol2tp or /sys/kernel/debug/l2tp/tunnels before reading to end-of-file (EOF), any tunnel or session reference stored in pd->tunnel / pd->session is left un-dropped when seq_file private data is freed. Fix this by dropping any remaining pd->tunnel and pd->session references in pppol2tp_proc_release() and l2tp_dfs_seq_release() when closing the file.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74745", "url": "https://ubuntu.com/security/CVE-2026-74745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: avoid deadlock when canceling IRQ affinity notifier Unregistering IRQ affinity notifiers waits for the callback synchronously. bnxt takes the netdev instance lock in the notifier (to restart the queue) and cancels the work under the same lock. This may obviously deadlock. Move the restart to the async service task. The queue restart isn't super time sensitive. Store the new TPH tag, schedule the task. Safely canceling the service task is already ironed out. In bnxt_request_irq() the order of registering notifier, affinity and initial TPH programming has to be inverted. I think it was racy previously since user may trigger an update as soon as notifier is installed. There's a small known gap - if pcie_tph_get_cpu_st() fails at init and the target tag is 0 we may miss programming the entry. This does not seem worth fixing, the code has skip-on-failure all over the place, anyway.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74747", "url": "https://ubuntu.com/security/CVE-2026-74747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: revalidate ihl to prevent out-of-bounds access While the outer IP header is already pulled into the skb head, we must be careful and revalidate the embedded headers after reading them from the skb frags to prevent out-of-bounds access. One such place reported by Sashiko is ip_vs_nat_icmp() where local process can change the ihl field and after skb_ensure_writable() we can see larger value which is a problem for the ip_send_check(cih) calls. Add check to drop the packet if the ihl field is changed.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74750", "url": "https://ubuntu.com/security/CVE-2026-74750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: defer key slot crypto freeing to workqueue Key slots are released through a kref and the existing release path frees the AEAD transforms from an RCU callback. That is not safe for all crypto implementations: crypto_free_aead can sleep, for example when an async or hardware implementation has teardown work to complete. Use queue_rcu_work for key-slot release. This keeps the RCU grace period needed by lockless key-slot readers, but runs the actual crypto teardown from workqueue context where sleeping is allowed. Once the rcu_work callback runs, pre-existing RCU readers are gone, and the final kref put already proves that no transform user remains, so the worker can release the AEAD transforms and free the slot directly. The previous patch drains ovpn_wq during module exit, so queued key-slot teardown work cannot outlive module text.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74752", "url": "https://ubuntu.com/security/CVE-2026-74752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate cookie AUTH state before use When cookie authentication is disabled, COOKIE_ECHO restores fixed-size AUTH fields directly from peer-controlled cookie bytes. A forged RANDOM length, HMAC list, or CHUNKS list can then reach association consumers with lengths or identifiers that were never validated against the local backing arrays. A forged RANDOM length can cause out-of-bounds reads during key-vector construction. A forged HMAC identifier also caused a 32-byte write past a zero-length AUTH chunk, providing a primitive for a local privilege escalation chain. Validate the cookie's RANDOM, HMACS, and CHUNKS parameters at the cookie trust boundary before copying them into the association. Reject invalid types, malformed lengths, unsupported HMAC identifiers, HMAC lists without SHA1, and forbidden chunk ids.", "cve_priority": "high", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74754", "url": "https://ubuntu.com/security/CVE-2026-74754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: pair EH runtime PM get and put shost->eh_noresume is currently consulted twice in one error handling iteration: once before scsi_autopm_get_host() and once again before scsi_autopm_put_host(). That is racy when a PM-triggered error path flips shost->eh_noresume while the SCSI EH thread is still running. The problem flow looks like this: PM path ufshcd_set_dev_pwr_mode() shost->eh_noresume = 1 ufshcd_execute_start_stop <-- trigger EH ... shost->eh_noresume = 0 EH path scsi_error_handler() if (!shost->eh_noresume) scsi_autopm_get_host() <-- skipped ... if (!shost->eh_noresume) scsi_autopm_put_host() <-- executed later In that case one EH iteration can skip autoresume on entry and still drop a runtime PM reference on exit. That leaves an unmatched runtime PM put and can trigger a runtime PM usage count underflow. Fix this by making eh_noresume a regular bool so it can be accessed with READ_ONCE() and WRITE_ONCE(). Snapshot it once per EH iteration and use that snapshot for both runtime PM get and put decisions.", "cve_priority": "low", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-80521", "url": "https://ubuntu.com/security/CVE-2026-80521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Unlink scc_entry in unix_del_edge(). Kyle Zeng reported that GC could free a dead SCC partially. The scenario is as follows: 1) Create two SCCs: X -. A <-> B ^--' 2) Run the following concurrently: 2-1) send() sk-B to sk-B from sk-X 2-2) close() both A and B At 2-1), there is a small window where unix_add_edges() publishes a new edge (B <-> B) to GC but its skb is not queued by skb_queue_tail(). If 2-2) completes before skb_queue_tail() and GC is triggered, it judges A <-> B as dead, but B is not freed because GC cannot collect the not-yet-queued skb holding the B <-> B edge. X -. A <-> B -. This edge is visible ^--' ^..' but skb is not This itself is not a problem since the next GC run will judge B as dead as well and free it finally. X -. A <.> B -. ^--' ^--' However, X's SCC forces the next GC to call unix_walk_scc_fast(), and it iterates over A through B's scc_entry. Let's unlink scc_entry before freeing the vertex in unix_del_edge().", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80523", "url": "https://ubuntu.com/security/CVE-2026-80523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: spacemit: k3: set hdma clock as critical HDMA clock is responsible for the internal TCM access path of X100 RISC-V core, so set the clock flag as critical to prevent it from being shut off, otherwise the Linux system will hang, for example in the case of a vector instruction access generates a page fault.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80524", "url": "https://ubuntu.com/security/CVE-2026-80524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: optee: ffa: Add NULL check in optee_ffa_lend_protmem Sashiko (locally) reports a possible null dereference under memory pressure due to the lack of validation of the allocated pointer. Fix that by adding the missing check.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80557", "url": "https://ubuntu.com/security/CVE-2026-80557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix OOB read in decode_watchers() via missing bounds check ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80579", "url": "https://ubuntu.com/security/CVE-2026-80579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: clear fb_info->mode before deleting a videomode fb_set_var() can delete a mode from info->modelist when userspace passes FB_ACTIVATE_INV_MODE through FBIOPUT_VSCREENINFO. The code checks that the mode being deleted is not the current info->var and that fbcon is not using it, but it does not check fb_info->mode. fb_info->mode may still point into the modelist entry being deleted. If the entry is freed, later mode sysfs reads through show_mode() can dereference a stale pointer. Clear fb_info->mode before calling fb_delete_videomode() when it matches the mode being removed.", "cve_priority": "low", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80580", "url": "https://ubuntu.com/security/CVE-2026-80580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: bound mode sysfs output to the sysfs buffer mode_string() uses snprintf() which can return a value larger than the remaining buffer space. show_modes() accumulates the return value into i without checking whether i has reached PAGE_SIZE, causing the offset to advance past the sysfs buffer if the modelist is long enough. Add a size parameter to mode_string() and use scnprintf() to return only the bytes actually written. Add an early return when offset already exceeds the buffer. In show_modes(), stop accumulating once the buffer is full.", "cve_priority": "low", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80582", "url": "https://ubuntu.com/security/CVE-2026-80582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/shmem_helper: Check VMA boundaries for PMD mappings In the ->huge_fault handler do not install a PMD huge page mapping if the huge page exceeds the boundaries of the VMA. All other ->huge_fault handlers have similar checks and the resulting mapping will trigger a VM_BUG_ON_VMA() if it ever reaches copy_pmd_range().", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80583", "url": "https://ubuntu.com/security/CVE-2026-80583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses The \"DEC0 MODE\" to \"DEC7 MODE\" controls are enumerated, but tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 (\"ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type\") and commit 0ea5eff7c606 (\"ASoC: codecs: va-macro: fix accessing array out of bounds for enum type\"), but tx-macro was missed. On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value sanity check catches the 4 bytes written past the enumerated item and every read of these controls fails with -EINVAL: snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74734", "url": "https://ubuntu.com/security/CVE-2026-74734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: ohci: fix NULL pointer dereference in ar_context_release During the error handling path of the driver's probe function, a NULL pointer dereference can occur in ar_context_release(). When pci_probe() fails early (e.g., if pcim_enable_device() or MMIO mapping fails), the devres cleanup mechanism invokes release_ohci(). This function unconditionally calls ar_context_release() to clean up the asynchronous receive contexts. However, if ar_context_init() was not yet called, ctx->ohci remains NULL (as the fw_ohci structure is zero-initialized by devres_alloc()). ar_context_release() immediately dereferences ctx->ohci to get the dev pointer before checking if the context was actually initialized, leading to a crash: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:ar_context_release+0x3f/0x380 drivers/firewire/ohci.c:543 Call Trace: release_ohci+0x3f/0x60 drivers/firewire/ohci.c:3567 release_nodes drivers/base/devres.c:546 [inline] devres_release_all+0x1a8/0x260 drivers/base/devres.c:576 device_unbind_cleanup drivers/base/dd.c:597 [inline] really_probe+0x451/0xae0 drivers/base/dd.c:772 To fix this, move the assignment of the dev pointer after the !ctx->buffer check. If ctx->buffer is NULL, it indicates that the context was never successfully initialized and there is nothing to release, safely avoiding the dereference of the uninitialized ctx->ohci pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74736", "url": "https://ubuntu.com/security/CVE-2026-74736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: reject dev-bound programs bound to a different device cls_bpf_prog_from_efd() obtained a SCHED_CLS program via bpf_prog_get_type_dev() but never verified that a device-bound (offloaded) program's bound netdev matches the TC netdev the classifier is being attached to. This let a program loaded with prog_ifindex for device A be attached via cls_bpf + skip_sw to device B; deleting device A then destroyed the program's offload state while it was still attached to device B, triggering a netdevsim WARN (panic with panic_on_warn=1). Mirror the XDP attach path (net/core/dev.c) and reject the attach with -EINVAL when a dev-bound program's bound device does not match the target device.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74737", "url": "https://ubuntu.com/security/CVE-2026-74737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG On the packet reception path, the ID of the MAC Port on which the packet was received, is embedded in the RX DMA Descriptor's metadata. The ID is extracted using the helper function cppi5_desc_get_tags_ids() which fills in the 16-bit Source Tag into the 'port_id' variable. However, it is only the lower 8-bits of the 16-bit Source Tag that represent the MAC Port ID, while the upper 8-bits are Hardware-Reserved and carry an arbitrary value. With the existing logic, sporadic kernel crash is observed due to the subsequent driver code accessing out-of-bound memory because of an invalid port_id. Hence, fix the port_id extraction logic to use only the lower 8-bits of the Source Tag as the MAC Port ID.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74738", "url": "https://ubuntu.com/security/CVE-2026-74738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: sdw-mbq: don't call an unset readable_reg callback regmap_sdw_mbq_poll_busy() decides whether to poll the Function Busy bit by calling ctx->readable_reg(), which is a straight copy of config->readable_reg. That callback is optional: regmap_readable() treats a NULL ->readable_reg as \"every register is readable\", and drivers rely on that. es9356 and tac5xx2-sdw both build an MBQ regmap without one. Since commit ca1b11b36d82 (\"regmap: sdw-mbq: Allow defers on undeferrable controls\") the poll runs on every -ENODATA, not only for Controls the driver marked deferrable, so any of those devices answering COMMAND_IGNORED takes the kernel through a NULL function pointer. Treat a missing callback the way the rest of regmap does and poll.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74739", "url": "https://ubuntu.com/security/CVE-2026-74739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: skip hash tables in u32_bind_class() u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode through the walker callback. u32_bind_class() unconditionally casts the passed fh to tc_u_knode and accesses &n->res, so when fh is actually a tc_u_hnode, which has no tcf_result member, this results in a slab-out-of-bounds read of res->classid in tc_cls_bind_class(). The issue can be reproduced with the following commands: tc qdisc add dev lo root handle 1: hfsc tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit Fix this by skipping hash tables via the TC_U32_KEY(handle) check.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74740", "url": "https://ubuntu.com/security/CVE-2026-74740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain tcf_action_exec() handles TC_ACT_GOTO_CHAIN by first checking rcu_access_pointer(a->goto_chain) and then calling tcf_action_goto_chain_exec(), which does a second, independent rcu_dereference_bh(a->goto_chain) read and immediately dereferences chain->filter_chain. A concurrent tcf_action_set_ctrlact() (e.g. the gact replace path) can clear a->goto_chain between the two reads, so the second read returns NULL and tcf_action_goto_chain_exec() dereferences NULL. Fix the race by doing a single rcu_dereference_bh() read of a->goto_chain in tcf_action_exec(), checking it once for NULL, and passing the resulting chain pointer into tcf_action_goto_chain_exec(). This turns the split check/use into a single check/use on one value.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74741", "url": "https://ubuntu.com/security/CVE-2026-74741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling In non-MSI-X mode (such as legacy INTx or single MSI), wx->msix_entry is not allocated or initialized. Calling NGBE_INTR_MISC(wx) dereferences wx->msix_entry->entry, leading to a NULL pointer dereference crash. This issue was introduced by fixing the IRQ vector when the number of VFs is 7. Fix the issue by explicitly checking `pdev->msix_enabled` to determine the correct vector index. Additionally, as a side fix, set the interrupt mask to BIT(0) for the non-MSI-X fallback. In MSI/INTx mode, the MISC and queue interrupts share vector 0, and the WX_PX_MISC_IVAR register is only valid in the MSI-X case. Thus, BIT(0) is the correct mask for the miscellaneous cause when MSI-X is disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74742", "url": "https://ubuntu.com/security/CVE-2026-74742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: fix queue index used to wake the peer txq in veth_poll veth_poll() derives the index of the peer TX queue to wake from rq->xdp_rxq.queue_index. That field is only initialized by xdp_rxq_info_reg() in veth_enable_xdp_range(), which runs only when an XDP program is attached. On the plain GRO/NAPI path (veth_napi_enable_range()) xdp_rxq_info_reg() is never called, so queue_index stays 0 for every queue, as priv->rq is zero-allocated. So in a multi-queue setup with GRO enabled and no XDP program attached, every NAPI instance looks at the peer's TX queue 0. If veth_xmit() stops peer TX queue 1 because the ptr_ring is full (NETDEV_TX_BUSY), nothing ever wakes it again: the poller draining queue 1 wakes queue 0 instead. veth implements no ndo_tx_timeout, so the netdev watchdog does not kick in either, and the queue stays stopped indefinitely. Derive the index from the position of the rq within priv->rq instead, which is correct regardless of whether XDP was ever enabled. Scripts to reproduce the stall are available at https://github.com/netoptimizer/veth-backpressure-performance-testing", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74743", "url": "https://ubuntu.com/security/CVE-2026-74743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: inherit needed_headroom and needed_tailroom from lowerdev macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74744", "url": "https://ubuntu.com/security/CVE-2026-74744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvlan: inherit needed_headroom and needed_tailroom from phy_dev ipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying phy_dev (or stacked lower device) requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.", "cve_priority": "high", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74746", "url": "https://ubuntu.com/security/CVE-2026-74746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: publish GC-visible tuple last nf_flow_table_iterate() only treats original-direction tuple nodes as owning entries. Publishing the original node first lets GC observe and free a flow while flow_offload_add() is still inserting the reply node. Publish the reply node first and the original node last so GC never sees a partially installed flow. KASAN can trigger slab-use-after-free read and write reports in the flowtable/rhashtable path (rht_deferred_worker, jhash, flow_offload_del, flow_offload_lookup, etc.).", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74748", "url": "https://ubuntu.com/security/CVE-2026-74748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix refcount race between list:set GC and swap __ip_set_put_byindex() resolved the index to a set pointer under RCU, then took ip_set_ref_lock in __ip_set_put() to decrement set->ref. ip_set_swap() holds that same lock while swapping both the ip_set_list slots and the two sets' ref counters, so it can interleave between the dereference and the lock acquisition, leaving the caller to decrement a set whose reference already moved to the other index and hit BUG_ON(set->ref == 0). list_set_gc() reaches this from timer softirq, which the nfnl mutex does not serialize against swap: an expiring list:set member calls list_set_del() -> ip_set_put_byindex() while IPSET_CMD_SWAP runs on the referenced sets. Resolve the index and decrement under ip_set_ref_lock, as ip_set_swap() already does, keeping the refcount tied to the index rather than to a stale set pointer. kernel BUG at net/netfilter/ipset/ip_set_core.c:685! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ip_set_put_byindex (net/netfilter/ipset/ip_set_core.c:870) Call Trace: list_set_del (net/netfilter/ipset/ip_set_list_set.c:159) set_cleanup_entries (net/netfilter/ipset/ip_set_list_set.c:181) list_set_gc (net/netfilter/ipset/ip_set_list_set.c:578) call_timer_fn (kernel/time/timer.c:1748) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2374) run_timer_softirq (kernel/time/timer.c:2405) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74753", "url": "https://ubuntu.com/security/CVE-2026-74753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: Reject exited events as group leaders perf_event_remove_on_exec() sets remove-on-exec events to the EXIT state and detaches their group relationships. The event's file descriptor can remain open, however, and perf_event_open() currently accepts that event as a group leader because its early validation rejects only REVOKED and DEAD events. A new sibling can consequently be linked to the detached leader. When the leader is closed, perf_group_detach() observes that its PERF_ATTACH_GROUP bit is already clear and skips the new sibling. The sibling then retains a group_leader pointer to the freed event. Reject group leaders in the EXIT state. Perform the check while holding the shared context mutex so that an exec in the target task cannot detach the leader between validation and group attachment. [peterz: make the earlier test fully consistent]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-80519", "url": "https://ubuntu.com/security/CVE-2026-80519", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: finish crypto callback cleanup before peer release Crypto completion callbacks hold both key-slot and peer references. The peer reference pins the netdev, and dropping the last peer reference can let netdev unregistration and module removal make progress. Do not release that peer reference before the callback has finished its own cleanup. If ovpn_crypto_key_slot_put runs after ovpn_peer_put, it can schedule an RCU callback backed by module text after ovpn_cleanup rcu_barrier has already run. The TX error path also freed the remaining skb after ovpn_peer_put, leaving callback cleanup outside the peer/netdev lifetime window. Release the key slot and free any remaining skb first, then drop the peer reference as the last callback action.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80520", "url": "https://ubuntu.com/security/CVE-2026-80520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix NULL dereference when killing missing key ovpn_crypto_kill_key assumes both crypto slots are populated and dereferences each slot before checking it. That is not guaranteed: a peer can have only one installed key, and the kill path may be asked to remove a key that is not present. Read each slot once while holding the crypto state lock, check for NULL before looking at key_id, and only replace the slot that actually matches.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80522", "url": "https://ubuntu.com/security/CVE-2026-80522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: tegra - fix rctx->cryptlen calculation in tegra_gcm_do_one_req() Perform rctx->cryptlen calculation in tegra_gcm_do_one_req() the same way it is done in tegra_ccm_crypt_init(). The current formulae may lead to a crash if a caller does not call tegra_gcm_setauthsize() and so ctx->authsize remains zero. Then a decrypt operation with incorrect rctx->cryptlen will lead to a write beyound rctx->dst_sg buffer. As a follow-up cleanup delete struct tegra_aead_ctx->authsize field since it appears to be completely unused. Also simplify tegra_ccm_setauthsize() and tegra_gcm_setauthsize() functions respectively.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80525", "url": "https://ubuntu.com/security/CVE-2026-80525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-topology: Refresh copier IPC payload before widget setup The ipc_config_data buffer for copier widgets is built once during ipc_prepare (called from sof_pcm_setup_connected_widgets) and cached for reuse. For host copiers this buffer contains the copier_data with gtw_cfg.node_id (host DMA ID). For DAI copiers it additionally includes a dma_config_tlv trailer with stream_id and dma_channel_id for HDA link DMA. On suspend/resume, both host and link DMA streams are released and re-allocated with potentially different stream tags. The underlying copier_data and dma_config_tlv structures are correctly updated by host_config and sdw_hda_dai_hw_params respectively. However, since the widget list (spcm->stream[].list) persists across suspend, sof_pcm_hw_params skips sof_pcm_setup_connected_widgets and ipc_prepare never runs again to rebuild ipc_config_data. The stale cached payload is then sent to firmware with boot-time DMA channel assignments, causing DMA channel conflicts that lead to firmware errors and crashes. Fix this by refreshing copier_data and dma_config_tlv portions of ipc_config_data in sof_ipc4_widget_setup right before the IPC message is sent. This ensures the payload always reflects the current DMA state regardless of whether ipc_prepare ran. For DAI copiers, the gtw_cfg.config_length in copier_data is temporarily inflated to include the TLV size (matching the ipc_config_data layout) before copying, then restored, mirroring what sof_ipc4_prepare_copier_module does when first building the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80526", "url": "https://ubuntu.com/security/CVE-2026-80526", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2562: Validate values for volume writes tas2562_volume_control_put() does not do any validation of the control value written by userspace, it uses it to look up a value in a fixed size array which can easily be overflowed and then writes whatever value it gets back to the device. Add validation that we are loading a value we have in the array.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80527", "url": "https://ubuntu.com/security/CVE-2026-80527", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix hanging __ceph_get_caps() with stale mds_wanted A reader can hang forever in __ceph_get_caps() when the client no longer holds `FILE_RD`, but local cap state still says that the capability is already wanted (via `mds_wanted`). One way to trigger this is through MDS cap revocation. If another client performs a conflicting operation, the MDS can revoke `FILE_RD` from the reader; the next read then has to reacquire `FILE_RD`. If the cap update that should request `FILE_RD` never reaches the MDS after `cap->mds_wanted` was raised, the reader is left holding only non-file caps while local `mds_wanted` still includes the file read caps. In that state, try_get_cap_refs() sees `need <= mds_wanted` and returns 0, so __ceph_get_caps() just waits on `i_cap_wq`. If the cap update that was supposed to request `FILE_RD never reaches the MDS after `cap->mds_wanted was` raised, no further request is sent and the waiter can sleep indefinitely until unrelated cap traffic happens to wake it up. The ordering issue is that `cap->mds_wanted` is updated in __prep_cap() before the `CEPH_MSG_CLIENT_CAPS message` is actually queued for send. That makes one field serve two different meanings at once: what this client wants, and what the client believes the MDS already knows it wants. A proper fix would be to split those states and track whether a cap update is actually in flight or has been observed by the MDS. However, simply moving the `cap->mds_wanted assignment` later would not be sufficient: queueing the message in the messenger does not guarantee that the MDS processed that specific wanted set, and reconnect or message loss can still invalidate that assumption. Fixing that properly would require a larger rework of the cap state machine. To allow simpler backports to stable kernels, this patch implements a simpler workaround: - stop waiting forever in __ceph_get_caps(); after a bounded wait, fall back to the renew path - make ceph_renew_caps() issue a synchronous `OPEN` request whenever the inode still does not actually hold the wanted caps, instead of only calling ceph_check_caps() The extra issued-vs-wanted check in ceph_renew_caps() is necessary because the previous test only checked whether the inode still had any real caps at all. That is not enough after revocation: the client can still hold something like `pLs` and yet be missing `FILE_RD` completely. In that case, falling back to ceph_check_caps() is not sufficient, because it still trusts `cap->mds_wanted` and may resend nothing. By requiring `(issued & wanted) == wanted` before taking the asynchronous path, the code only uses ceph_check_caps() when the `wanted caps` are already actually issued. Otherwise, it sends the synchronous `OPEN` renew. This preserves the existing asynchronous fast path when the wanted caps are already issued, avoids changing cap-state semantics, and fixes the hang by guaranteeing that a stalled waiter eventually retries through a path that does not rely on the stale `mds_wanted` state. [ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to mds_client.h, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80528", "url": "https://ubuntu.com/security/CVE-2026-80528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: avoid fs reclaim while using current->journal_info handle_reply() stores a `ceph_mds_request` pointer in `current->journal_info` while filling the inode and dentry cache from an MDS reply. An allocation in this section can enter direct reclaim and prune dentries from another filesystem. If this dirties an ext4 inode, ext4 starts a JBD2 transaction. JBD2 interprets the Ceph request in `current->journal_info` as a journal handle and dereferences the request's `r_tid` as `h_transaction`, causing a kernel crash, e.g.: Unable to handle kernel paging request at virtual address 00000000077b4818 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 6 UID: 0 PID: 2699135 Comm: kworker/6:3 Tainted: G W 6.18.38-i3 #1113 NONE [...] Workqueue: ceph-msgr ceph_con_workfn pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : jbd2__journal_start+0x2c/0x208 lr : __ext4_journal_start_sb+0x100/0x178 [...] Call trace: jbd2__journal_start+0x2c/0x208 (P) __ext4_journal_start_sb+0x100/0x178 ext4_dirty_inode+0x3c/0x90 __mark_inode_dirty+0x58/0x400 iput.part.0+0x2b0/0x370 iput+0x18/0x30 dentry_unlink_inode+0xc0/0x158 __dentry_kill+0x80/0x250 shrink_dentry_list+0x90/0x130 prune_dcache_sb+0x60/0x98 super_cache_scan+0xe8/0x190 do_shrink_slab+0x174/0x388 shrink_slab+0xd8/0x4c0 shrink_node+0x31c/0x908 do_try_to_free_pages+0xd0/0x508 try_to_free_pages+0x11c/0x238 __alloc_frozen_pages_noprof+0x4d0/0xdd0 __folio_alloc_noprof+0x18/0x70 __filemap_get_folio+0x248/0x440 ceph_readdir_prepopulate+0x570/0x9e8 mds_dispatch+0x1424/0x1ba0 ceph_con_process_message+0x74/0xa0 ceph_con_v1_try_read+0x3a0/0x1510 ceph_con_workfn+0x260/0x460 Enter a scoped NOFS allocation context and leave it after clearing `journal_info`. This prevents filesystem reclaim from recursing into another filesystem while the field contains Ceph-private data.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80529", "url": "https://ubuntu.com/security/CVE-2026-80529", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: don't swallow dquot recovery verification errors xlog_recover_dquot_commit_pass2() validates the recovered dquot with xfs_dqblk_verify() and, on failure, sets error = -EFSCORRUPTED and jumps to out_release. But out_release unconditionally returns 0, so the corruption error is discarded: the caller xlog_recover_items_pass2() sees success, log recovery proceeds as if the dquot were valid, and the corrupt quota buffer can be written back to disk.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80530", "url": "https://ubuntu.com/security/CVE-2026-80530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN When exchanging two full-file ranges, xmi_can_exchange_reflink_flags() can move the reflink inode flag from the file that currently has it to the other file, as long as exactly one side is marked. This assumes that the file contents, and therefore all shared extents, are exchanged. That assumption is not true when XFS_EXCHMAPS_INO1_WRITTEN is set. xfs_exchmaps_can_skip_mapping() can skip hole and unwritten mappings from file1, so an exchange can complete without moving every mapping that the earlier flag-swap decision accounted for. In that case the post-operation cleanup can clear the reflink flag from an inode that still owns shared written extents. Later writes then take the non-reflink write path and may update blocks that should still have been protected by CoW, which shows up as data corruption between reflink-related files. Fix this by disabling the reflink flag exchange whenever XFS_EXCHMAPS_INO1_WRITTEN is requested. The contents exchange can still proceed; the conservative outcome is that both inodes keep the reflink flag. The regular reflink flag cleanup path can drop the extra flag later once the inode no longer has shared extents.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80531", "url": "https://ubuntu.com/security/CVE-2026-80531", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: avoid UAF on sc->tempip in xrep_tempfile_create LOLLM noticed a potential UAF if the tempfile creation code fails after it set sc->tempip. Fix that.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80532", "url": "https://ubuntu.com/security/CVE-2026-80532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix another iunlink infinite loop bug in online fsck xrep_iunlink_resolve_bucket is supposed to reconstruct as much of the incore prev and next unlinked list pointers based on what it finds on disk and in memory before we move on to relinking the truly lost inodes back into the unlinked list. However, it's still vulnerable to infinite loops that come in via the next_unlinked pointers. Fix this problem by remembering which inodes we've already seen and checking new agino pointers against that. If a bit is already set, either this is a loop or the inode has nonzero link count. We'll deal with the second case in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80533", "url": "https://ubuntu.com/security/CVE-2026-80533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: don't walk off the end of a null sc->sa.agi_bp in AGI repair LOLLM noticed a longstanding bug where xrep_iunlink_walk_ondisk_bucket tries to walk ragi->sc->sa.agi_bp to rebuild the unlinked inode lists. Unfortunately, it's possible for agi_bp to be null if the buffer verifier fails, so we have to use ragi->agi_bp (which skips verifier checks) instead.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80534", "url": "https://ubuntu.com/security/CVE-2026-80534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix ilock leak on error in xfs_dq_get_next_id xfs_dq_get_next_id() takes the quota inode ILOCK before calling xfs_iread_extents(). If xfs_iread_extents() fails, the function returns immediately without releasing the lock, leaking the quota inode ILOCK. This can leave the quota inode locked and cause subsequent quota operations to hang. Fix this by jumping to a common unlock path on error instead of returning directly.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80535", "url": "https://ubuntu.com/security/CVE-2026-80535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: don't double-lock when deleting a self-referential directory LOLLM notices that the dirtree scrubber can detect a directory that refers to itself. In this case, it's not correct for the directory tree repair code to try to iolock/ilock both sc->ip and dp, because they're the same inode. Fix this by detecting that corner case and handling it appropriately.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80536", "url": "https://ubuntu.com/security/CVE-2026-80536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: bounds-check buffer log item's dirty bitmap xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: \tmemcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), \t\titem->ri_buf[i].iov_base, \t\tnbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error. Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80537", "url": "https://ubuntu.com/security/CVE-2026-80537", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix off-by-one in rtrefcount btree root level validation xfs_rtrefcountbt_compute_maxlevels() sets \tmp->m_rtrefc_maxlevels = min(d_maxlevels, r_maxlevels) + 1; where the trailing \"+ 1\" already accounts for the inode-root level, so the deepest valid on-disk root level is m_rtrefc_maxlevels - 1 and a cursor must satisfy bc_nlevels <= bc_maxlevels (= m_rtrefc_maxlevels). The two on-disk validation paths, xfs_rtrefcountbt_verify() and xfs_iformat_rtrefcount(), check the root level with \">\" instead of \">=\", so a crafted rtreflink (metadir + realtime + reflink) image whose /rtgroups/N.refcount inode has bb_level == m_rtrefc_maxlevels is accepted on mount. xfs_rtrefcountbt_init_cursor() then sets bc_nlevels = bb_level + 1, exceeding bc_maxlevels by one. Since the xfs_rtrefcountbt_cur slab object is sized for exactly bc_maxlevels entries, the first btree op on such a cursor indexes bc_levels[m_rtrefc_maxlevels] past the end of the object. This is reached by the first rtrefcount cursor built after mount, via log/CoW recovery (xfs_reflink_recover_cow() during xfs_mountfs()) or an FS_IOC_GETFSMAP over the realtime device. Reject a root level equal to m_rtrefc_maxlevels, matching the \">=\" form already used by the sibling data-device refcount/rmap verifiers and the in-memory rtrmap verifier. BUG: KASAN: slab-out-of-bounds in xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101) Write of size 2 at addr ffff888018391658 by task exploit/144 xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101) xfs_btree_query_range (fs/xfs/libxfs/xfs_btree.c:5308) xfs_refcount_recover_cow_leftovers (fs/xfs/libxfs/xfs_refcount.c:2113) xfs_reflink_recover_cow (fs/xfs/xfs_reflink.c:1085) xlog_recover_finish (fs/xfs/xfs_log_recover.c:3551) xfs_mountfs (fs/xfs/xfs_mount.c:1158) xfs_fs_fill_super (fs/xfs/xfs_super.c:1940) get_tree_bdev_flags (fs/super.c:1634) vfs_get_tree (fs/super.c:1694) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address belongs to the cache xfs_rtrefcountbt_cur of size 216 The buggy address is located 8 bytes to the right of allocated 216-byte region [ffff888018391578, ffff888018391650) Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80538", "url": "https://ubuntu.com/security/CVE-2026-80538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: propagate errors from xfs_rtginode_load xfs_rtginode_ensure() treats every xfs_rtginode_load() error other than -ENOENT as success. This can leave the realtime group inode unset after an I/O, allocation, or corruption error. Growfs then continues as though the inode had been loaded. Only -ENOENT means that the inode needs to be created. Return all other errors to the growfs caller.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80539", "url": "https://ubuntu.com/security/CVE-2026-80539", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: disallow multiple FENCE chunks in one submit amdgpu_cs_pass1() dispatches on chunk_id once per chunk without rejecting repeated ids. p->uf_bo is a single-slot field, so a submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs amdgpu_cs_p1_user_fence() twice, and the second run overwrites p->uf_bo with a freshly referenced BO without dropping the reference taken by the first. amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE chunk but the last leaks a BO reference. The leaked BO outlives handle close and process exit. Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc (\"drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit\") did for p->bo_list. (cherry picked from commit 665b1fc2a1845206408f9a2c6da67101789edb82)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80540", "url": "https://ubuntu.com/security/CVE-2026-80540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix UVD decode image min size calculation This needs to use pitch instead of width. Also reject pitch over 4096 to avoid overflow. (cherry picked from commit b41c8cb12e202b220353332ab87dc01a11f69304)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80541", "url": "https://ubuntu.com/security/CVE-2026-80541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate GEM_CREATE domain combinations AMDGPU_GEM_CREATE checked domain bits against AMDGPU_GEM_DOMAIN_MASK, but did not validate domain combinations. Userspace could combine CPU|GTT|VRAM with DOORBELL, GDS, GWS, or OA, making amdgpu_bo_placement_from_domain() exceed AMDGPU_BO_MAX_PLACEMENTS and hit BUG_ON(). Allow combinations only within CPU/GTT/VRAM, and require non-CPU/GTT/ VRAM domains to be specified one at a time. Return -EINVAL for invalid combinations in amdgpu_gem_create_ioctl(). v2: Rename helper from amdgpu_gem_domain_valid() to amdgpu_gem_are_domains_valid() (Christian) (cherry picked from commit db39852d0c39843cb02048dfb47e4b8c703e9080)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80542", "url": "https://ubuntu.com/security/CVE-2026-80542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL pointer dereference in amdgpu_dm_crtc_set_vblank() amdgpu_dm_crtc_set_vblank() dereferences acrtc_state->stream when vblank is enabled/queried from DRM_IOCTL_MODE_CRTC_GET_SEQUENCE before a stream is attached to it. BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: amdgpu_dm_crtc_set_vblank+0x6b/0x4d0 [amdgpu] Call Trace: drm_vblank_enable drm_vblank_get drm_crtc_get_sequence_ioctl drm_ioctl_kernel drm_ioctl Reproduced by running VKCTS with WSI tests enabled on RADV. Guard the enable path on acrtc_state->stream being non-NULL, matching the existing checks in this function. (cherry picked from commit 7b1b31bf6942e6f43509b48da23f8e27269aac39)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80547", "url": "https://ubuntu.com/security/CVE-2026-80547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Implement a crw lock Unlike the channel_program struct, which covers synchronous I/O submissions and asynchronous interrupts, the CRW region relies exclusively on asynchronous events coming from hardware. Implement a lock to manage the list of those payloads, to ensure they are read cohesively.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80548", "url": "https://ubuntu.com/security/CVE-2026-80548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Selectively expand io_mutex The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share. With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80549", "url": "https://ubuntu.com/security/CVE-2026-80549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Move cp cleanup out of not operational The fsm_notoper() routine is called when the device has been lost, and is (by definition) no longer operational. Since this can happen asynchronously from the normal behavior of the driver, the cleanup may happen when holding other locks in the calling sequence (notably, the cio subchannel lock). Push the cleanup of the private->cp resources to a workqueue, where it can be done out from under that lock sequence and a future patch can safely manage the locking requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80550", "url": "https://ubuntu.com/security/CVE-2026-80550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Fix out of bounds check on CCW array The routine ccwchain_calc_length() counts the number of channel command words (CCWs) that are chained together in a single channel program, and rejects anything larger than CCWCHAIN_LEN_MAX (256) CCWs. The loop itself is \"do..while (count < 257)\", and while the logic in is_cpa_within_range() correctly adjusts between the 0-index array of CCWs and the count of CCWs starting at 1, this means it would look at a possible 257th CCW before ending the loop and (correctly) returning an error. Fix this by restructuring the loop to break as soon as 256 CCWs (thus indexes 0-255) are examined, without looking at memory outside the range.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80551", "url": "https://ubuntu.com/security/CVE-2026-80551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure first IDAW remains constant The first IDAW in a list does not need to be on a 2K/4K boundary like all others, and so is read separately to accurately calculate the size of the buffer needed to read the full IDAL. Verify that the address found in the first IDAW is unchanged between reads, to ensure a consistent set of IDAWs being worked with.", "cve_priority": "high", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80552", "url": "https://ubuntu.com/security/CVE-2026-80552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure index for read/write regions are within range The introduction of the capability chain rightly clamped the region indexes to the range of the capabilities itself, but neglected to do so for the existing read/write regions which should also be enforced.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80553", "url": "https://ubuntu.com/security/CVE-2026-80553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Cancel existing workqueues The initialization of the io_work and crw_work workqueues begs the question of whether they should be un-initialized. Add the corresponding cleanup tags in _release_dev to ensure work isn't dispatched after the private struct is free'd.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80554", "url": "https://ubuntu.com/security/CVE-2026-80554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Limit the number of channel program segments The processing of channel programs, and the CCWs within them, is done recursively. As such, there is an arbitrary (but not architectural) limit to the number of CCWs that can exist in a single channel program. The vfio-ccw logic breaks these channel programs into segments whenever it encounters a Transfer-In-Channel (TIC) CCW, and the combined number of segments count towards the global limit. Impose an equivalent limit to the number of segments until such logic can be made non-recursive.", "cve_priority": "high", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80555", "url": "https://ubuntu.com/security/CVE-2026-80555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Free all memory if cp_init() fails The routine cp_free() is called to unpin/free any memory once an I/O is completed successfully, or if cp_prefetch() fails. But if cp_init() fails, and cp->initialized is not enabled, the same routine cannot be used to free all the memory. An attempt to address this exists in ccwchain_handle_ccw(), where a single call to ccwchain_free() is made for the currently-processed CCW segment. But this will leak other segments (created as a result of a Transfer in Channel) that had been allocated as part of the same channel program. Address this by performing the cleanup outside of the recursive ccwchain_handle_ccw()/ccwchain_loop_tic() logic.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80556", "url": "https://ubuntu.com/security/CVE-2026-80556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: atmel-mci: Fix use-after-free in atmci_remove due to race condition In atmci_probe, &host->bh_work is bound with atmci_work_func, and atmci_interrupt, atmci_timeout_timer and atmci_dma_complete can all queue this work on system_bh_wq. If we remove the module, atmci_remove makes cleanup and the memory allocated for host with devm_kzalloc() is released after the remove callback returns, while the work mentioned above may still be pending or running. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | atmci_interrupt | queue_work(system_bh_wq, | &host->bh_work) atmci_remove | atmci_cleanup_slot(...) | atmci_writel(host, ATMCI_IDR, ~0UL) | timer_delete_sync(&host->timer) | dma_release_channel(host->dma.chan) | free_irq(platform_get_irq(pdev, 0), host) | | atmci_work_func | // use host // devm resources released after | // remove returns, host is freed | | // use host (use-after-free) Fix it by canceling the work after all the sources that can schedule it (IRQ handler, timeout timer and DMA completion callback) have been stopped, and before proceeding with the remaining cleanup in atmci_remove.", "cve_priority": "low", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80558", "url": "https://ubuntu.com/security/CVE-2026-80558", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Avoid using invalid osd indices from primary_temp A corrupted osdmap received from a Ceph monitor or OSD may contain osd indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts that don't exist, i.e., that are greater than max_osd or smaller than CEPH_HOMELESS_OSD (-1). These indices are used to create the up and acting set in ceph_pg_to_up_acting_osds(), called from calc_target(). While most of these osd indices are checked, the one from primary_temp is not. Subsequently, this may lead to calc_target() returning this (potentially invalid) index as target osd for a (linger) request. Because the osd_state, osd_weight, and osd_addr arrays only contain max_osd entries (with indices 0 to max_osd -1), this leads to out-of-bounds accesses when trying to read values from these arrays. This patch fixes the issue by adding a check to get_temp_osds(), so that only valid osd indices from primary_temp are used, and it falls back to using the primary from pg_temp or the up set if it is invalid. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80559", "url": "https://ubuntu.com/security/CVE-2026-80559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: sur40 - fix input device registration ordering In sur40_probe(), input_register_device() was previously called early before the V4L2 video device and vb2_queue components were fully initialized. If userspace opened the input device immediately upon registration, sur40_open() would trigger and start the sur40_poll() worker thread. This worker thread invokes sur40_process_video() and accesses the uninitialized vb2_queue structure, leading to a data race and potential system crash. Furthermore, if V4L2 or video registration failed after input_register_device() succeeded, the error path fell through to calling input_free_device() on a successfully registered device instead of input_unregister_device(), corrupting input core state. Move input_register_device() to the very end of sur40_probe(). This ensures the V4L2 and video queue structures are fully initialized before polling can start, and naturally resolves the error path bug since input_free_device() is now only called when input registration has not yet occurred. To maintain strict LIFO (Last-In, First-Out) teardown ordering, also move input_unregister_device() to the very beginning of sur40_disconnect(). This guarantees that the input polling worker thread is stopped before V4L2 video components or control handlers are unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80560", "url": "https://ubuntu.com/security/CVE-2026-80560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openrisc: signal: do not restore privileged SR bits on sigreturn restore_sigcontext() copies the whole supervision register (SR) from the signal frame and only clears SPR_SR_SM before the value is reloaded into the hardware SR (through ESR and l.rfe) on the return to user space. All other SR bits are left under user control. An unprivileged task can thus return from a signal handler through a crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the CPU performs no translation or protection on data accesses, so the task gains read and write access to arbitrary physical memory, a local privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH and the cache-enable bits are exposed the same way. The ptrace GPR regset already refuses any change to SR for exactly this reason. Restore only the arithmetic flag bits (F, CY, OV) from the signal frame and take every privileged control bit from the SR the kernel saved on signal entry. Verified with qemu-system-or1k -M or1k-sim: before this change an unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to physical address 0x03000000 (beyond the kernel's mem=32M); afterwards the same PoC receives SIGSEGV and physical memory is unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80561", "url": "https://ubuntu.com/security/CVE-2026-80561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix multiple unsafe decodes in decode_locker() decode_locker() in cls_lock_client.c contains three unsafe decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_copy() at the locker_id_t name field has no preceding bounds check. With p == end after ceph_start_decoding() accepts struct_len=0, this reads sizeof(ceph_entity_name) = 9 bytes past the validated buffer boundary. 2. *p += sizeof(struct ceph_timespec) after the locker_info_t header is an unchecked pointer advance. A malicious OSD can position p past end, causing all subsequent _safe checks to pass against a bogus boundary. 3. len = ceph_decode_32(p) has no preceding bounds check, and the immediately following *p += len is uncapped. A malicious OSD can send len=0xffffffff, advancing p gigabytes past end and escaping the decode window entirely. Fix all three by replacing bare operations with their safe variants: ceph_decode_copy -> ceph_decode_copy_safe *p += sizeof(...) -> ceph_decode_skip_n ceph_decode_32(p) -> ceph_decode_32_safe *p += len -> ceph_decode_skip_n A new label is added to return -EINVAL on any bounds violation. -EINVAL is appropriate here: the data received from the OSD is structurally malformed, which is an invalid argument to the decode contract regardless of whether the caller or the wire is at fault. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition) without any further privileges beyond OSD session establishment. [ idryomov: use ceph_decode_skip_string() to skip description, trim changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80562", "url": "https://ubuntu.com/security/CVE-2026-80562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: ml-ioh: use raw_spinlock_t for the register lock ioh_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. ioh_irq_enable() and ioh_irq_disable() take the same lock from the .irq_enable/.irq_disable callbacks, which are likewise invoked with desc->lock held. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, and those critical sections only perform short sequences of MMIO register accesses (ioread32()/iowrite32()); the .irq_set_type callback additionally emits a dev_warn() on an unsupported type. None of these are sleepable operations, so keeping this register lock non-sleeping is appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same fix as commit a02b8950d619 (\"gpio: pch: use raw_spinlock_t for the register lock\"); this driver shares the same structure as gpio-pch.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80563", "url": "https://ubuntu.com/security/CVE-2026-80563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: sloppy-logic-analyzer: fix use-after-free via debugfs trigger on unbind The \"trigger\" debugfs file has a hand-rolled ->write handler (trigger_write()) that dereferences the per-device gpio_la_poll_priv. The file is created with debugfs_create_file_unsafe(), and the handler never takes a debugfs reference. Nothing keeps the object alive while the handler runs. priv is allocated with devm_kzalloc(). devres frees it when the platform device is unbound. debugfs_create_file_unsafe() installs no full_proxy wrapper, so debugfs_remove_recursive() in gpio_la_poll_remove() does not wait for an in-flight trigger_write(). The blob_lock taken there does not help, because trigger_write() never takes it. A write that races an unbind therefore writes into freed memory: trigger_write() gpio_la_poll_remove() priv = m->private buf = memdup_user() [may sleep] mutex_lock(&priv->blob_lock) debugfs_remove_recursive() [no wait] mutex_unlock(&priv->blob_lock) (remove returns; devres frees priv) priv->trig_data = buf <-- use-after-free write priv->trig_len = count The race is reachable by root via /sys/bus/platform/drivers/gpio-sloppy-logic-analyzer/unbind. Create \"trigger\" with debugfs_create_file() instead. Its full_proxy wrapper makes debugfs_remove_recursive() drain any in-flight ->write before it returns. The use-after-free is confirmed under KASAN with a minimal reproducer of the same debugfs_create_file_unsafe() plus devm_kzalloc() pattern (available on request); it produces a slab-use-after-free write in the handler.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80564", "url": "https://ubuntu.com/security/CVE-2026-80564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix NULL dereference due to missing ptp adjfine Fix NULL dereference due to missing implementation of adjfine, which can be triggered from usermode as follows: sudo ./testptp -d /dev/ptp0 -f 0 [ 551.943697] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] [ 552.061946] Call Trace: [ 552.064487] [ 552.066681] ptp_clock_adjtime+0x1c0/0x2c0 [ 552.070874] ? get_clock_desc+0x6b/0xb0 [ 552.074825] pc_clock_adjtime+0x78/0xc0 [ 552.078755] __do_sys_clock_adjtime+0x85/0x110 [ 552.083293] do_syscall_64+0xea/0x610", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80565", "url": "https://ubuntu.com/security/CVE-2026-80565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qce - fix error path in devm_qce_register_algs If ops->register_algs() fails, the error path repeatedly calls the same ops->unregister_algs() from the failed registration. Use the loop index to unregister the previously registered algorithms instead.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80566", "url": "https://ubuntu.com/security/CVE-2026-80566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: hynitron_cstxxx - validate touch count and finger IDs The driver allocates max_touch_num input slots, which are indexed from zero through max_touch_num - 1. The current check allows a finger ID equal to max_touch_num to reach cst3xx_report_contact(). While the input core ignores out-of-range slot indices, reporting touch data without a valid slot change corrupts the touch state of the previously active slot. The touch count is read from the controller's report and is used to index the fixed-size report buffer without first checking its range. Reject counts larger than the supported number of touch slots before checking the trailing byte or parsing touch data. Reject finger IDs equal to or greater than max_touch_num, and return immediately when an invalid finger ID is encountered so that corrupt touch frames are discarded instead of reporting partial contact state. The V821 Avaota F1 board configures the vendor driver with one touch slot, so finger ID 1 is already invalid on that device.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80567", "url": "https://ubuntu.com/security/CVE-2026-80567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue Previously, rmi_f54_buffer_queue() waited for the worker thread to finish but ignored whether it succeeded. If the worker failed (e.g., due to a timeout or register read failure), the queue thread would silently return success, delivering stale or uninitialized memory to userspace. Add a 'report_error' field to struct f54_data to store the worker's exit status. Check this field in rmi_f54_buffer_queue() after the worker finishes, and mark the buffer as VB2_BUF_STATE_ERROR if an error occurred.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80568", "url": "https://ubuntu.com/security/CVE-2026-80568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - block s_input when F54 queue is busy Changing the input (diagnostic report type) mid-stream changes the report size. Since V4L2 buffers are allocated based on the size at stream start, changing the input while streaming could lead to a heap buffer overflow if the new size is larger than the allocated buffers. Prevent this by blocking VIDIOC_S_INPUT with -EBUSY if the V4L2 queue is busy (streaming).", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80569", "url": "https://ubuntu.com/security/CVE-2026-80569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer rmi_f54_work() reads a diagnostics report from the device into f54->report_data, sizing the transfer with rmi_f54_get_report_size(): \treport_size = rmi_f54_get_report_size(f54); \t... \tfor (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) { \t\tint size = min(F54_REPORT_DATA_SIZE, report_size - i); \t\t... \t\trmi_read_block(.., f54->report_data + i, size); \t} report_data is allocated once at probe from F54's own electrode counts (array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))), but rmi_f54_get_report_size() computes the size from drv_data->num_*_electrodes when those are set, i.e. from the F55 function's electrode counts. Both counts come straight from device queries (F54 and F55 each report up to 255 electrodes) and nothing constrains the F55 counts to the F54 ones. A malicious or malfunctioning RMI4 device that reports larger F55 electrode counts than its F54 counts makes report_size exceed the allocation, so the read loop writes past report_data (and the V4L2 dequeue memcpy() then reads past it). On conforming hardware the F55 configured electrodes are a subset of the F54 physical electrodes, so report_size never exceeds the buffer and well-behaved devices are unaffected. Record the allocation size and reject a report that does not fit, mirroring the existing zero-size check.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80570", "url": "https://ubuntu.com/security/CVE-2026-80570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - zero report size on F54 work error In rmi_f54_work(), if an error occurs during report request or command verification, the code jumped directly to the 'error' label, bypassing the 'abort' label where f54->report_size was normally zeroed out. This left f54->report_size containing its previous successful payload size. If a user then altered the V4L2 format to a smaller size, and a subsequent run failed, rmi_f54_buffer_queue() would copy the stale, larger payload size into the shrunken V4L2 buffer, causing a heap buffer overflow. Fix this by merging the 'abort' and 'error' labels into a single 'out' exit path, and ensuring that f54->report_size is always set to 0 on failure by checking for error and zeroing the local report_size first.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80571", "url": "https://ubuntu.com/security/CVE-2026-80571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: papr-phy-attest - validate cmd.length, plug mem leak In papr_phy_attest_create_handle(), the params->cmd.length is not validated before use, which can result in a buffer overlow. Check it and return -EINVAL if it is either 0 or exceeds sizeof(params->cmd). Also, params is freed on the success path but not error. Free it on errors after memory allocation. And free it on negative fd.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80572", "url": "https://ubuntu.com/security/CVE-2026-80572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: byd - synchronize timer deletion before freeing private data byd_disconnect() uses timer_delete() before freeing the driver's private data. This does not wait for a running byd_clear_touch() callback, which dereferences the private data and its psmouse pointer. A callback racing with disconnect can therefore access the private data after it has been freed. The timer can also still be re-armed by byd_process_byte() while the disconnect is in progress. Use timer_shutdown_sync() before freeing the private data: it waits for a running callback and turns any later re-arm attempt into a no-op.", "cve_priority": "low", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80573", "url": "https://ubuntu.com/security/CVE-2026-80573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: iforce - validate input packet lengths iforce_process_packet() reads fixed fields from joystick, wheel and status packets without first checking their lengths. In particular, the shared hats-and-buttons helper unconditionally reads data[6]. The status tail is a sequence of 16-bit effect addresses, but an incomplete final address is also consumed. A successful zero-length USB URB additionally reads the packet ID before the common parser is called. Reject the zero-length USB transfer, require the seven-byte joystick and wheel prefixes and the two-byte status prefix, and consume only complete status-tail addresses.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80574", "url": "https://ubuntu.com/security/CVE-2026-80574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: focaltech - fix array out-of-bounds in focaltech_process_rel_packet Make finger2 (and also finger1) unsigned, so that if the finger index in the packet is 0 then subtracting 1 creates an array index which overflows above the existing check for FOC_MAX_FINGERS, as the existing comment says it should, instead of writing to state->fingers[-1].", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80575", "url": "https://ubuntu.com/security/CVE-2026-80575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cs40l50-vibra - validate custom data from user space cs40l50_add() copies the custom data of an FF_PERIODIC/FF_CUSTOM effect straight from the ff_effect the user passed to EVIOCSFF, without requiring it to hold anything: work_data.custom_data = memdup_array_user(periodic->custom_data, periodic->custom_len, sizeof(s16)); work_data.custom_len = periodic->custom_len; The driver then reads two words out of that buffer: custom_data[0] as the waveform bank in cs40l50_effect_bank_set(), and custom_data[1] as the index within the bank in cs40l50_effect_index_set(). Neither read is covered by a length check, and custom_len is fully user controlled: - custom_len == 0 makes memdup_array_user() call memdup_user() with a length of zero, which returns ZERO_SIZE_PTR rather than an error, so custom_data[0] dereferences it. - custom_len == 1 allocates two bytes. A bank of ROM or RAM keeps effect->type out of the OWT case, and custom_data[1] is then read one word past the allocation. The bank value itself is also mishandled. It is masked with CS40L50_CUSTOM_DATA_MASK (0xffff) but stored in an s16, so a custom_data[0] of 0x8000 or above wraps to a negative value that passes the \"bank_type >= CS40L50_WVFRM_BANK_NUM\" test. cs40l50_effect_index_set() indexes vib->dsp.banks[] with it before the switch statement's default case gets a chance to reject it: base_index = vib->dsp.banks[effect->type].base_index; max_index = vib->dsp.banks[effect->type].max_index; Require the two words the driver reads to be present, and hold the masked bank in a u32 so the existing upper-bound test covers the whole range. The da7280 haptic driver already range checks custom_len this way.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80576", "url": "https://ubuntu.com/security/CVE-2026-80576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: reject oversized IBs with per-ring packet limits On GFX rings, amdgpu_cs_p2_ib() passed user-supplied ib_bytes through to ib->length_dw without a limit, while ring_emit_ib() encodes length into packet fields. Oversized values can corrupt adjacent control bits and destabilize command submission. Add a per-ring IB packet size limit helper and reject command submissions exceeding the corresponding dword limit before IB allocation. Use the documented 20-bit limit for GFX/compute/SDMA/VPE, and apply the MM fallback limit for other ring types. (cherry picked from commit 7f48fa2cf62e3fa6c9c3870aa74988f773247e52)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80577", "url": "https://ubuntu.com/security/CVE-2026-80577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: skip zero-sized firmware sections panthor_fw_load_section_entry() skips BO creation when the firmware section VA range is empty. If such a section is added to the firmware section list, section->mem is left as NULL. Later reload and unplug paths iterate over all firmware sections and dereference section->mem, which can lead to a NULL pointer dereference. Zero-sized firmware sections are valid, so accept them as no-op entries but skip adding them to the section list.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80578", "url": "https://ubuntu.com/security/CVE-2026-80578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: core: Fix pointer desynchronization in fb_io_read() In fb_io_read(), if copy_to_user() performs a partial copy (e.g., due to a faulty user buffer), the loop adjusts the chunk size 'c' and updates the remaining 'count'. However, the hardware 'src' pointer has already been eagerly advanced by the original chunk size. If the loop is allowed to continue, the read will resume from an incorrect, over-advanced offset. Since the remaining 'count' was only decremented by the successful bytes, this desynchronization causes the next iterations to execute more hardware reads than originally bounded, eventually leading to out-of-bounds I/O reads. Fix this by breaking out of the loop immediately upon a partial copy_to_user(). A partial copy indicates a faulty user buffer, making subsequent read attempts futile. Breaking out ensures we return the number of successfully read bytes without risking out-of-bounds hardware accesses in subsequent mismatched iterations.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80581", "url": "https://ubuntu.com/security/CVE-2026-80581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout Ignore IPC errors for pipeline state change if the firmware state is crashed or the IPC has timed out. If the firmware has crashed the kernel still needs to go through the state changes to reset its internal to be able to correctly work the next time the DSP is booted up. The case with IPC timeout is a bit more problematic, but it has been rootcaused to be the result of system scheduling blockage and the firmware did actually received and handled the message, but the reply handling got blocked by issues outside of the SOF stack. So far the best way to handle this is to continue with setting the state.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80584", "url": "https://ubuntu.com/security/CVE-2026-80584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/qeth: validate user buffer length in SNMP and ARP query ioctls qeth_snmp_command() and qeth_l3_arp_query() allocate a buffer sized by a user-supplied length (udata_len) without checking a lower bound, then set udata_offset to a fixed non-zero value and pass both to a reply callback. The callback bounds-checks the copy with if ((udata_len - udata_offset) < len) Both fields are u32, so a udata_len smaller than udata_offset makes the subtraction wrap and the check pass, and the following memcpy() writes past the allocation. A udata_len of 0 also yields ZERO_SIZE_PTR from kzalloc(), which the existing NULL check does not catch. Reject buffers smaller than udata_offset before allocating, so the callback subtraction can no longer underflow.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80585", "url": "https://ubuntu.com/security/CVE-2026-80585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fastopen: only mark MPTFO subflows with SYN data Passive TCP Fast Open accepts a valid-cookie SYN even when it carries no data. In that case the child socket's receive queue is intentionally left empty. mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking for queued SYN data. That made data-less TFO SYNs hit a WARN and, if the warning was non-fatal, left stale MPTFO state behind. The stale flag could later trigger a state-confusion bug in check_fully_established(). Only mark the subflow as MPTFO after confirming that an SKB was queued. Return quietly when the receive queue is empty. Note that mptcp_subflow_context's is_mptfo field is now not just about subflows where the TFO was present, but about MPTFO subflow that consumed SYN data. Only having a valid cookie but not carrying data is not really \"doing TFO\".", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80586", "url": "https://ubuntu.com/security/CVE-2026-80586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: options: reset DSS fields in case of unexpected size A remote peer could send a malformed DSS with a wrong size, followed by another DSS or MPC + Data. In this case, the first suboption will be ignored, but leaving some fields written, which could lead to inconsistency or access uninitialized data. Explicitly reset the fields that could have been modified in case of unexpected size.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80587", "url": "https://ubuntu.com/security/CVE-2026-80587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid combining some incoming suboptions Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A few points of attention: - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch. - In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption. - In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80588", "url": "https://ubuntu.com/security/CVE-2026-80588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: reclaim forward-allocated memory on RX path errors After commit 9db5b3cec4ec (\"mptcp: borrow forward memory from subflow\"), errors in the receive path prior to queueing skbs into the receive queue do not trigger forward-allocated memory reclaiming. Prevent forward memory from growing unboundedly in pathological drop scenarios by explicitly reclaiming memory when skbs are dropped.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80589", "url": "https://ubuntu.com/security/CVE-2026-80589", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: stop the timeout timer when releasing a never added disk disk_release() undoes blk_mq_init_allocated_queue() for a disk whose probe failed before add_disk(), but it only calls blk_mq_exit_queue(). Nothing there stops q->timeout, and that timer rolls forward: it stays pending until it next expires, not until the last request completes. So if the driver issued any I/O before adding the disk, the request_queue is freed while still linked into a timer wheel bucket. Commit 6f8191fdf41d (\"block: simplify disk shutdown\") dropped the blk_cleanup_queue() call that used to stop it. __del_gendisk() and blk_mq_destroy_queue() still do; only the probe failure path lost it. nvme gets there because nvme_update_ns_info() submits Report Zones or FDP io-mgmt-recv on ns->queue before the disk is added, so a later failure - a concurrent reset setting NVME_CTRL_FROZEN, or device_add_disk() failing - lands in put_disk() with the timer armed: BUG: KASAN: slab-use-after-free in detach_if_pending+0x30c/0x340 Write of size 8 at addr ffff888004d71310 by task kworker/u8:2/37 __timer_delete_sync+0x156/0x240 kernel/time/timer.c:1621 blk_sync_queue+0x22/0x40 block/blk-core.c:222 nvme_sync_queues+0x100/0x150 drivers/nvme/host/core.c:5362 nvme_reset_work+0x138/0x930 drivers/nvme/host/pci.c:3264 Allocated by task 34: __blk_mq_alloc_disk+0x33/0x100 block/blk-mq.c:4462 nvme_alloc_ns+0x290/0x3870 drivers/nvme/host/core.c:4146 Freed by task 0: blk_free_queue_rcu+0x3a/0x50 block/blk-core.c:254 rcu_core+0xc10/0x1730 kernel/rcu/tree.c:2857 The queue being synced there is ctrl->admin_q, only a victim sharing a timer wheel bucket with the freed queue's dangling entry; other runs tripped in enqueue_timer(), __run_timers() or blk_mq_timeout_work(). Failing nvme_alloc_ns() with a debug patch makes it deterministic: one leaked timer trips KASAN within seconds, while 1987 patched releases produced no splat. Stop the timer and the queue work items before blk_mq_exit_queue(), like blk_mq_destroy_queue() does. Found by FuzzNvme.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74593", "url": "https://ubuntu.com/security/CVE-2026-74593", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Take cgroup_lock() first in scx_cgroup_lock() scx_cgroup_lock() write-locks scx_cgroup_ops_rwsem and then takes cgroup_lock(), which can deadlock through kernfs: scx enable/disable cgroup rmdir cpu.weight write ------------------ ------------ ---------------- cgroup_lock() percpu_down_write(rwsem) cgroup_lock() kernfs_get_active() percpu_down_read(rwsem) kernfs_drain() The enable path waits for the rmdir to release cgroup_mutex. The rmdir, deactivating the cpu controller's files, waits in kernfs_drain() for the write's active reference. The write, in scx_group_set_weight(), waits for the rwsem behind the pending writer. Take cgroup_lock() first. The set_* paths take no cgroup locks inside the read side, so a pending write-lock then only waits for read sections that always run to completion, and no dependency from the rwsem back to cgroup_mutex remains.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74596", "url": "https://ubuntu.com/security/CVE-2026-74596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs,fsverity: remove check for fsverity being enabled in setattr_prepare() The check that fs-verity is available in the kernel is not necessary here. Filesystems could have fsverity files even without fs-verity enabled. In that case, truncate on fsverity file will succeed, what this check is trying to prevent.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74600", "url": "https://ubuntu.com/security/CVE-2026-74600", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_table_check: skip special zero mappings page_table_check_set() and page_table_check_clear() account mappings based on PageAnon(). Shared zero-page PTEs and huge zero PMDs are special mappings, but page_table_check can still account them as file-backed pages. An unprivileged process can populate enough zero mappings to overflow file_map_count and hit the existing BUG_ON(). The PTE path can do this with the shared zero page, and the PMD path can do the same with huge zero mappings. Skip special zero mappings in the user page-table accounting paths. Keep the PTE-side pte_special() check, and identify huge zero PMDs from the mapped folio instead of pmd_special(). That covers architectures where pmd_special() is a no-op without adding huge_zero_pfn checks to the generic counter helpers.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74605", "url": "https://ubuntu.com/security/CVE-2026-74605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventfs: Use children field for rcu head and add memory barriers When an eventfs inode is freed, it sets ei->is_freed and then uses its ei->list to add it to the srcu link list as the list field is a union with the rcu list head. As the ei->list is used to iterate over an SRCU protected list without taking the eventfs_mutex, there's nothing stopping the iteration over that list to see the ei->rcu instead of the ei->list and it will read a corrupt target. To fix this, change the union of the rcu list head with the children list. On freeing the eventfs inode, set the is_free and execute a smp_wmb() before adding the eventfs inode to the SRCU list. On iteration of the ei->children list, at the start, execute a smp_rmb() and then read the is_freed of the ei to see if the children list is still valid. If is_freed is set, then the ei_child read is not valid and the loop should exit immediately.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74626", "url": "https://ubuntu.com/security/CVE-2026-74626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_netdev: Preserve RX queue depth on allocation failure ntb_netdev_rx_handler() hands the received skb to the network stack before allocating its replacement. If the allocation fails, nothing is reposted. Every failure therefore takes one buffer out of the RX queue while the interface remains up, and enough failures eventually stall reception. A retry path could refill the queue later, but ntb_netdev has none. Allocate the replacement first instead. If that fails, drop the packet and repost the same skb. This keeps the queue full and lets packet delivery resume as soon as memory is available again.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74645", "url": "https://ubuntu.com/security/CVE-2026-74645", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/lru_sort: error out for >10000 active_mem_bp damos_quota_score() can trigger division by zero if the target value is zero. DAMON_LRU_SORT lets users set the target value for the hot memory scheme via active_mem_bp parameter. It avoids setting it as the target value if the parameter value is zero. However, it also sets the cold memory scheme with a target value that is calculated as '10000 - active_mem_bp + 2'. Hence, if a user sets active_mem_bp 10002, the cold memory scheme's quota goal target value can be zero. As a result, division by zero can be triggered. Fix by returning an error when the user tries to start DAMON with >10000 active_mem_bp parameter value. It makes no sense to set active_mem_bp with 10002. It also requires module parameters write permission to reproduce the issue. That said, the consequence is quite bad. One reliable way to reproduce the issue is like below: # cd /sys/module/damon_lru_sort/parameters # echo 1000 > wmarks_high # echo 995 > wmarks_mid # echo 0 > wmarks_low # echo 10002 > active_mem_bp # echo Y > enabled # dmesg -w [...] [ 597.421247] Oops: divide error: 0000 [#1] SMP NOPTI [ 597.428848] RIP: 0010:damos_quota_score+0x6f/0x480 This issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74674", "url": "https://ubuntu.com/security/CVE-2026-74674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix incorrect flush address in direct page table reclaim When zap_pte_range reclaims a page table, it does: pte_free_tlb(tlb, pmd_pgtable(pmdval), addr); and this is unconditionally wrong: if this code executes, addr *always* points one past the end of the range covered by the table. The addr parameter is used to flush the TLB (really the paging-structure-cache) to drop references to the to-be-freed table, and any architecture that cares about the parameter will flush the wrong address. (But they'll still free the correct page). I think it's worth contemplating why the kernel works at all. If we hit the offending line of code, we will first clear the PMD entry (line 1954, zap_empty_pte_table), then we will issue pending flushes if force_flush is set (tlb_flush_mmu_tlbonly(tlb)), then we will skip the retry on line 1979 (phew!), and then we will do the offending pte_free_tlb call. *Or* we will clear the PMD entry immediately before pte_free_tlb (line 1983, zap_pte_table_if_empty). If we have any pending flushes (i.e. we actually zapped any last-level entries) at the time we clear the PMD entry, then the flush really ought to flush all references to the table (Linus certainly seems to think it will on all architectures [0]). The condition under which we have no accumulated flushes at the time of the clear is very complex (the whole zap_pte_range function has absurdly complex control flow). If we do hit the bad case, then we will end up clearing the PMD entry after the last time the range is flushed, and any CPU is free to cache a reference to the (empty) page table. If this happens due to an ordinary read or write, it would segfault, so it would be rare. But the cache could be speculatively filled as well. Then we'll flush the wrong address and then free and possibly reuse the table. On x86, even flushing the wrong address works on non-KPTI Intel systems because INVLPG flushes *all* paging-structure-caches, not just the ones for the target address. But INVPCID does not, and flush_tlb_one_user will use INVPCID if it's available. And then we're toast. AMD systems are more susceptible: we set the EFER.TCE bit, which makes even INVLPG only flush the target address. I think this might fix an issue in ripgrep reported here: https://github.com/BurntSushi/ripgrep/issues/3494 [0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74686", "url": "https://ubuntu.com/security/CVE-2026-74686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rqspinlock: Reset tail when preserving queue on deadlock Currently, the destruction of the waiter queue is suppressed for rqspinlock in cases where a deadlock is detected. Deadlock checks happen relatively frequently (on entry for AA, within 1ms for ABBA), and waiter threads may not be involved in locking scenarios involving deadlocks. Thus, it is useful to not flush the queue and let other waiters take a stab at acquiring the lock after we detect a deadlock and exit. However, we need to follow the same logic as what we did previously for the waitq_timeout label: reset the tail, and if we cannot, signal the next waiter appropriately. In case of deadlocks, this signal would just mark the MCS node as unlocked, and in case of timeouts, it would signal RES_TIMEOUT_VAL. The difference thus is in the value propagated, which decides whether the queue remains active or gets flushed. Not doing the tail reset, and waiting for the next waiter can lead to cases where we are the final waiter, and thus no next waiter arrives, leading to intermittent stalls in this path. Once the next waiter does join, we will be unblocked. In the theoretical case when the next waiter never joins, we risk stalling indefinitely. This can only happen for ABBA deadlocks, since entry into the wait queue is guarded with AA checks. A precise sequence of executions leading up to this scenario can be: CPU 0 holds lock A. CPU 1 holds lock B. CPU 2 attempts lock B, becomes the pending waiter for B. CPU 0 attempts lock B. B has locked+pending bits set, thus CPU 0 queues. CPU 1 attempts lock A. CPU 0 detects an ABBA deadlock. Once deadlock detection happens for CPU 0, it will sit waiting for the next waiter in the queue to populate node->next, which will experience delays until such a waiter arrives. Fix this by adjusting the logic for the check for deadlocks preceding the waitq_timeout label. It would make sense to consolidate code for both cases and use 'ret' to distinguish the value being propagated, but that is left as an exercise for a future refactoring task to avoid diff noise in this patch.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74699", "url": "https://ubuntu.com/security/CVE-2026-74699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix memory leak in exec_queue_set_hang_replay_state() The q->replay_state is blindly overwritten, which can potentially leak memory that was previously allocated by vmemdup_user(). Return an error if q->replay_state is not empty. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit f6b6cc1118bdbc4265fa8b3bdf8565b26f13e56e)", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74706", "url": "https://ubuntu.com/security/CVE-2026-74706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnge: Fix NULL pointer dereference in aux device release If allocation of auxr_dev fails during auxiliary device setup, the error path calls auxiliary_device_uninit(), which eventually invokes bnge_aux_dev_release(). The release callback unconditionally dereferences aux_priv->auxr_dev->pdev to retrieve the parent bnge_dev. Since auxr_dev has not yet been allocated on this failure path, the dereference results in a NULL pointer exception Retrieve the parent bnge_dev from the auxiliary device's parent instead of auxr_dev, and free auxr_dev only when it was successfully allocated. This allows the release callback to correctly clean up partially initialized auxiliary devices.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74713", "url": "https://ubuntu.com/security/CVE-2026-74713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_iotlb: bound map allocation in add_range vhost_iotlb_add_range_ctx() only retires an old entry when the table has a non-zero limit, has exactly reached that limit and has VHOST_IOTLB_FLAG_RETIRE set. Non-retiring tables can keep allocating entries after reaching their configured limit. Existing vhost devices allocate their IOTLB with max_iotlb_entries from vhost.c, which defaults to 2048 and is tunable by module parameter. Use the caller-provided limit at the allocation point instead of adding a separate default in the common IOTLB helper, and reject non-positive values in vhost paths that can report an error. Other vhost IOTLB users should not create zero-limit tables when entries can be populated from userspace or guest-controlled requests. Add caller-side max_iotlb_entries parameters for mlx5 vDPA, VDUSE and vhost-vDPA. Reject non-positive VDUSE and vhost-vDPA values, and require at least two entries for vdpa_sim and mlx5 vDPA paths that install full-range mappings, since those mappings are split into two IOTLB entries. Handle full-range mappings in the common helper by checking that the IOTLB can hold both split entries before inserting the first half. This avoids returning an error after leaving a half mapping behind. When the table is full, keep the existing retire behavior for retiring tables and return -ENOSPC for non-retiring tables. Reuse the retired map node instead of freeing it and allocating a replacement, so a stream of IOTLB updates cannot keep forcing GFP_ATOMIC allocations after the table has reached its limit. If a zero-limit IOTLB still reaches the common helper, treat it as a configuration error and return -EINVAL. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74715", "url": "https://ubuntu.com/security/CVE-2026-74715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix netns reference imbalance in conntrack kfuncs The opts argument of the BPF conntrack kfuncs can point to a shared map value. __bpf_nf_ct_lookup() and __bpf_nf_ct_alloc_entry() read opts->netns_id separately when acquiring and releasing the network namespace reference. The reference imbalance can occur as follows: CPU 0 CPU 1 read opts->netns_id (-1) skip get_net_ns_by_id() write opts->netns_id (id) read opts->netns_id (id) put_net(net) /* no matching get */ The reverse transition leaks the reference. Repeating the unmatched put can destroy a live namespace and crash later users. The kernel reported: Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] RIP: 0010:bpf_prog_test_run_xdp+0x52c/0x1700 Call Trace: __sys_bpf+0x1662/0x50c0 __x64_sys_bpf+0x73/0xb0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception Snapshot every input field of opts with READ_ONCE() before validating or using it. The netns_id snapshot keeps the namespace get/put pair balanced, while the other snapshots keep the remaining options from changing partway through an invocation. The individual reads can still observe an inconsistent combination during a concurrent update, but each selected field value remains stable for that invocation.", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74716", "url": "https://ubuntu.com/security/CVE-2026-74716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix locally exploitable BUG_ON in amdxdna_insert_pages() In amdxdna_insert_pages(), vm_flags_mod() sets VM_MIXEDMAP and clears VM_PFNMAP. If an unprivileged userspace process mmaps a non-imported GEM object and then calls madvise(MADV_DONTNEED), the PTEs will be successfully cleared because VM_MIXEDMAP allows this (unlike VM_PFNMAP). When userspace subsequently accesses the memory, drm_gem_shmem_fault() handles the page fault and attempts to map the backing shmem page via vmf_insert_pfn() which calls vmf_insert_pfn_prot(). Because the backing shmem page is normal system memory (pfn_valid(pfn) is true) and the VMA now has VM_MIXEDMAP set, won't this predictably trigger the explicit assertion BUG_ON((vma->vm_flags & VM_MIXEDMAP) && pfn_valid(pfn)) Fix by removing the vm_flags_mod() call and replacing the vm_insert_pages() pre-population with the handle_mm_fault() loop that was already used for the import (dma-buf) path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74721", "url": "https://ubuntu.com/security/CVE-2026-74721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amxdna: Fix page-insertion errors in amdxdna_insert_pages() Two error paths in amdxdna_insert_pages() called vma->vm_ops->close(vma) before returning an error code to the caller. This is incorrect: amdxdna_gem_obj_mmap() registers an HMM interval notifier before calling amdxdna_insert_pages(), and on a hard error it jumps to hmm_unreg to undo that registration. Calling vm_ops->close() manually — which drops the shmem pages_pin_count and the GEM object reference that backs the VMA — before the mmap syscall has even returned causes those resources to be released while the VMA is still alive. The kernel VMA teardown will call vm_ops->close() a second time when the process later unmaps the range, producing a reference count underflow. Replace both hard-error returns with a deferred-fault approach that keeps the VMA alive and retries page insertion through the HMM range-fault path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74723", "url": "https://ubuntu.com/security/CVE-2026-74723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: lzo: reject inline extents without valid headers [BUG] For a crafted btrfs image, the following KASAN can be triggered when reading an inline lzo compressed file extent: BUG: KASAN: slab-out-of-bounds in lzo_decompress+0x57d/0x700 Read of size 4 at addr ffff888006f2e644 by task btrfs_lzo_inlin/77 Call Trace: dump_stack_lvl+0x5b/0x70 print_report+0xd1/0x610 kasan_report+0xe0/0x110 __asan_report_load_n_noabort+0x13/0x20 lzo_decompress+0x57d/0x700 btrfs_decompress+0x140/0x1c0 uncompress_inline+0x147/0x1b0 btrfs_get_extent+0xb23/0x10a0 btrfs_do_readpage.constprop.0+0x538/0x1ac0 btrfs_readahead+0x32f/0x5f0 read_pages+0x16f/0x850 page_cache_ra_unbounded+0x296/0x490 do_page_cache_ra+0xd9/0x130 page_cache_sync_ra+0x3ee/0x6f0 filemap_get_pages+0x306/0x15c0 filemap_read+0x329/0xd00 btrfs_file_read_iter+0x1f8/0x2b0 vfs_read+0x4ef/0x720 ksys_read+0xf8/0x1d0 __x64_sys_read+0x71/0xb0 x64_sys_call+0x1ab0/0x1b70 do_syscall_64+0x61/0x470 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [CAUSE] For an inline lzo compressed file extent, there should always be one lzo header, recording the total length of the compressed data, followed by one segment header, recording the compressed lzo payload. But if a crafted inline lzo compressed file extent contains only an lzo header, without the segment header or payload, lzo_decompress() will still try to read the segment header, causing a read beyond the item boundary. Furthermore if the inline lzo compressed file extent is the first item of the leaf, it will be at the extent buffer boundary. The above out-of-boundary read will go beyond the extent buffer boundary, triggering the above KASAN report. [FIX] Validate the total length of the inlined lzo compressed file extent, to make sure there is at least one LZO header and one segment header, and a non-zero payload. [ Rework the commit message to remove slop ]", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74729", "url": "https://ubuntu.com/security/CVE-2026-74729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read put_fifo_with_discard() acts as both producer and consumer on the kfifo: it calls kfifo_skip() (advances out) and kfifo_put() (advances in) from the IRQ handler without synchronizing with snoop_file_read(), which also consumes via kfifo_to_user(). On SMP systems this concurrent access can leave (in - out) larger than the ring buffer, so __kfifo_to_user()'s clamp to (in - out) is ineffective and kfifo_copy_to_user() can attempt a copy_to_user() past the kmalloc-2k backing store: usercopy: Kernel memory exposure attempt detected from SLUB object 'kmalloc-2k' (offset 0, size 2049)! kernel BUG at mm/usercopy.c! Call trace: usercopy_abort __check_heap_object __check_object_size kfifo_copy_to_user __kfifo_to_user snoop_file_read vfs_read Serialize kfifo access with a per-channel spinlock shared between the IRQ handler (producer) and the file reader (consumer). Annotate @fifo with __guarded_by(&lock) and opt the driver into context analysis so the compiler enforces that all fifo access holds the lock.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74733", "url": "https://ubuntu.com/security/CVE-2026-74733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: pca953x: fix pca953x_irq_bus_sync_unlock regmap lock Locking is disabled in the regmap config as this driver uses its own lock. This means that all calls to regmap functions (read or write) must hold the i2c_lock. The function pca953x_irq_bus_sync_unlock() did not do this, and it was therefore possible that multiple threads could cause an incorrect register to be read/written. A previous patch partly fixed this, but only protected the write to the interrupt mask register, and not the read from the direction register.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74585", "url": "https://ubuntu.com/security/CVE-2026-74585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound the DROM dual link port number before indexing sw->ports tb_drom_parse_entry_port() validates the device-supplied header->index against sw->config.max_port_number before indexing sw->ports[], but the sibling field entry->dual_link_port_nr -- a 6-bit value also read from the DROM -- indexes the same array with no such check. A malicious or malformed Thunderbolt device can set dual_link_port_nr beyond the allocated sw->ports[] (max_port_number + 1 entries), producing an out-of-bounds tb_port pointer that is stored and later dereferenced. Reject a port entry whose dual_link_port_nr exceeds max_port_number, the same bound already applied to header->index.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74586", "url": "https://ubuntu.com/security/CVE-2026-74586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: clear new_transport when removing a peer sctp_process_asconf_param() stores a newly added peer transport in asoc->new_transport. After all parameters in the ASCONF chunk have been processed, sctp_sf_do_asconf() uses this pointer to send a HEARTBEAT to the new transport. An authenticated ASCONF from a remote SCTP peer can add a transport and remove it again with a wildcard DEL-IP parameter in the same chunk. The wildcard deletion preserves the transport on which the ASCONF arrived, but removes the newly added transport through sctp_assoc_del_nonprimary_peers(). The removal does not clear asoc->new_transport, leaving it pointing to the removed transport. sctp_sf_do_asconf() then creates a HEARTBEAT whose chunk->transport points to the removed transport without holding a transport reference. During local address replacement, src_out_of_asoc_ok keeps this HEARTBEAT on control_chunk_list. After the transport is freed by RCU, a successful ASCONF_ACK for the replacement address releases the queued HEARTBEAT and sctp_outq_select_transport() reads the freed transport's state. The issue was found during a static audit of SCTP objects. With an authenticated peer, the reproducer triggered the same KASAN report in 2 of 2 unpatched runs on a KASAN-enabled netdev/main kernel: BUG: KASAN: slab-use-after-free in sctp_outq_select_transport Read of size 4 at addr ffff88800b9bd95c by task python3/197 Call Trace: sctp_outq_select_transport+0x549/0x8b0 [sctp] sctp_outq_flush+0x306/0x2c60 [sctp] sctp_transport_immediate_rtx+0xaf/0x260 [sctp] sctp_process_asconf_ack+0xa48/0xf70 [sctp] Allocated by task 197: sctp_transport_new+0x68/0x650 [sctp] sctp_assoc_add_peer+0x258/0x12a0 [sctp] sctp_process_asconf+0x5e9/0x1090 [sctp] Last potentially related work creation: __call_rcu_common.constprop.0+0x77/0xb70 sctp_assoc_del_nonprimary_peers+0x7c/0xd0 [sctp] sctp_process_asconf+0xd9c/0x1090 [sctp] The first invalid access was a four-byte read of transport->state at net/sctp/outqueue.c:833. The same reproducer completed the full authenticated ASCONF and local-address replacement sequence with this change without a KASAN report or oops. Clear new_transport when its peer is removed, before it can be used to create the HEARTBEAT.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74587", "url": "https://ubuntu.com/security/CVE-2026-74587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix use-after-free of cached ASCONF chunk addip_last_asconf caches the outstanding outbound ASCONF chunk. The normal ASCONF-ACK completion path releases the chunk and clears the pointer. However, sctp_asconf_queue_teardown() releases the cached chunk without clearing addip_last_asconf. During peer restart handling, sctp_sf_do_dupcook_a() queues SCTP_CMD_PURGE_ASCONF_QUEUE, which invokes sctp_asconf_queue_teardown() while the association remains alive and leaves the pointer dangling. A delayed authenticated ASCONF-ACK can then reach sctp_sf_do_asconf_ack(), which accesses the stale chunk and passes it to sctp_process_asconf_ack(), causing a use-after-free and a second release. Clearing the pointer exposes a race with T4 expiry. Peer restart handling queues the timer stop before the purge, but SCTP_CMD_TIMER_STOP uses timer_delete(), which does not wait for a callback already running on another CPU. Such a callback can reach sctp_sf_t4_timer_expire() after the purge and dereference NULL. Clear addip_last_asconf after releasing the cached chunk, and make sctp_sf_t4_timer_expire() consume a stale T4 expiry if no outstanding ASCONF remains.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74588", "url": "https://ubuntu.com/security/CVE-2026-74588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: keep chunk->transport in step with the list it is queued on __sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport: \tif (chunk->tsn_gap_acked) { \t\tlist_move_tail(&chunk->transmitted_list, \t\t\t &transport->transmitted); \t\tcontinue; \t} The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctp_assoc_rm_peer() from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk is left with a dangling pointer. sctp_assoc_rm_peer() scrubs peer->transmitted and asoc->outqueue.out_chunk_list, but the chunk is on neither. The pointer is not followed while tsn_gap_acked is set. A SACK that reneges on the TSN clears the flag, and the next SACK reaches \ttchunk->transport->flight_size -= sctp_data_size(tchunk); inside the freed transport. KASAN reports a slab-use-after-free read in sctp_check_transmitted(), freed from sctp_assoc_rm_peer(). Both the removal and the SACKs come from the association peer. Set chunk->transport at the move. The ordinary resend path needs nothing: it reaches its list_move_tail() only after sctp_packet_append_chunk() returned SCTP_XMIT_OK, and __sctp_packet_append_chunk() has rebound the chunk by then. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74589", "url": "https://ubuntu.com/security/CVE-2026-74589", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix sk_redir use-after-free in send verdict sk_psock_msg_verdict() takes a socket reference for psock->sk_redir. tcp_bpf_send_verdict() copies that pointer while holding the source socket lock, but does not take a reference for the local copy before dropping the lock around tcp_bpf_sendmsg_redir(). When apply_bytes keeps the cached verdict active, another sendmsg() on the same source socket can consume the remaining bytes and release the cached reference while the first thread still holds only the raw local pointer: CPU 0 CPU 1 sk_redir = psock->sk_redir apply_bytes remains nonzero release_sock(sk) lock_sock(sk) apply_bytes reaches zero psock->sk_redir = NULL release_sock(sk) tcp_bpf_sendmsg_redir(sk_redir) sock_put(sk_redir) tcp_bpf_sendmsg_redir(sk_redir) The final sock_put() can free sk_redir before CPU 0 dereferences it. KASAN reported: BUG: KASAN: slab-use-after-free in tcp_bpf_sendmsg_redir+0xf39/0x1020 Read of size 8 at addr ffff888108537090 by task poc/87 Call Trace: tcp_bpf_sendmsg_redir+0xf39/0x1020 tcp_bpf_sendmsg+0x977/0x1a50 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 85: sk_prot_alloc+0x56/0x210 sk_clone+0x6f/0x14b0 inet_csk_clone_lock+0x24/0x740 tcp_create_openreq_child+0x25/0x2710 tcp_v4_syn_recv_sock+0x10a/0xe00 Freed by task 0: __kasan_slab_free+0x43/0x70 slab_free_after_rcu_debug+0xa6/0x1e0 rcu_core+0x50a/0x1850 Last potentially related work creation: __sk_destruct+0x3da/0x540 sk_psock_destroy+0x81e/0xab0 process_one_work+0x63a/0x1070 Take a temporary socket reference while the source socket lock still protects psock->sk_redir, and drop it after tcp_bpf_sendmsg_redir() returns. This keeps each unlocked use independent of cached-verdict ownership.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74590", "url": "https://ubuntu.com/security/CVE-2026-74590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsverity: Fix bpf_get_fsverity_digest() dynptr assumptions The BPF verifier and the dynptr abstraction ensure that the memory space referenced by a dynptr remains valid. They do not, however, provide any guarantee that the contents of the memory are stable. kfuncs are expected to remain memory-safe even if concurrent modifications occur. bpf_get_fsverity_digest() didn't follow that: it could crash if arg->digest_size was concurrently modified. Fix that by using the known-good value hash_alg->digest_size instead. Also widen 'dynptr_sz' and 'out_digest_sz' to u64 to match the return type of __bpf_dynptr_size(). It doesn't appear that it can actually be more than INT_MAX currently (since __bpf_dynptr_data_rw() excludes file-based pointers), but the correct type might as well be used.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74591", "url": "https://ubuntu.com/security/CVE-2026-74591", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: __filemap_add_folio() restore index before retrying In __filemap_add_folio()'s split-a-conflict loop, xas_set_order() is applied repeatedly: each application modifies xas.xa_index, rounding it down according to the split_order attempted at that stage: and if all goes as intended, it eventually (or immediately) converges on an xas_try_split() to the required folio_order, with xas.xa_index now the same as index: then xas_store() puts the new folio into the xarray there. But if a new node was needed, and GFP_NOWAIT allocation did not get one, the lock is dropped, xas_nomem() used to allocate, and sequence retried. If (that part of) the xarray is unchanged when the lock is reacquired, no problem. But what if the conflict was meanwhile resolved by another thread (perhaps even doing the same thing, inserting a folio at that same index)? Isn't there a danger of now putting our folio into the xarray at an intermediate rounded-down index? With !folio_contains() bug to follow, when CONFIG_DEBUG_VM=y is checking for that. Fix this with an xas_set_order() to restore the original xas.xa_index at the bottom of the loop, so the retry does a full re-evaluation after reacquiring the lock, and cannot reach xas_store() with the wrong index. Production was suffering from rare SIGILLs and SIGSEGVs, executable text found a page away from where it belonged, !folio_contains() bug hit when debug enabled: symptoms not seen since this patch went in.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74592", "url": "https://ubuntu.com/security/CVE-2026-74592", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Instantiate file_truncate and path_truncate hooks Instantiate the file_truncate and path_truncate LSM hooks to reset the action cache flags (IMA_DONE_MASK) as soon as truncation is requested, so the file, based on policy, is re-collected, re-measured, re-audited, and re-appraised on next access.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74594", "url": "https://ubuntu.com/security/CVE-2026-74594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/psi: Shut down rtpoll_timer in psi_cgroup_free() psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath and can race psi_trigger_destroy() taking down the last rtpoll trigger under rtpoll_trigger_lock: psi_schedule_rtpoll_work() psi_trigger_destroy() rcu_read_lock(); task = rcu_dereference(rtpoll_task); rcu_assign_pointer(rtpoll_task, NULL); timer_delete(&rtpoll_timer); mod_timer(&rtpoll_timer, ...); rcu_read_unlock(); synchronize_rcu(); kthread_stop(task_to_destroy); The group can then be freed with the re-armed timer still pending, and poll_timer_fn() runs on freed memory. 461daba06bdc (\"psi: eliminate kthread_worker from psi trigger scheduling mechanism\") deleted the timer synchronously after the synchronize_rcu(), which prevented this but raced trigger creation instead: the deletion could cancel the timer that a new trigger set armed during the grace period and, as creation also reinitialized the timer at the time, corrupt it. 8f91efd870ea (\"psi: Fix race between psi_trigger_create/destroy\") moved the initialization into group_init() and the deletion into the locked section, trading the creation races for the window above. Neither placement in the destruction path works. A pending timer firing while the group is alive is harmless though. poll_timer_fn() just wakes the rtpoll waitqueue and doesn't re-arm itself. Bind the timer to the group's lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it by then. timer_shutdown_sync() because the timer is never armed again.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74595", "url": "https://ubuntu.com/security/CVE-2026-74595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy() fscrypt_ioctl_set_policy() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing an encryption policy to be set, instead of the idmap of the mount the ioctl was issued on. fscrypt is used by filesystems that support idmapped mounts (e.g. ext4, f2fs), so on such a mount this compares the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EACCES and an unrelated caller wrongly allowed. Use file_mnt_idmap(filp) instead.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74597", "url": "https://ubuntu.com/security/CVE-2026-74597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip6ip6_err() ip6ip6_err() clones an outer IPv6 ICMP error skb, pulls it to the quoted inner IPv6 packet, and then passes the clone to icmpv6_send(). The clone still carries the outer packet's inet6_skb_parm in skb->cb. If the outer packet had a Home Address Option, IP6CB(skb2)->dsthao remains non-zero after skb_pull(). icmpv6_send() later calls mip6_addr_swap(), which uses that stale dsthao offset against the quoted inner packet. A malformed inner destination-options header can then make the HAO lookup and address swap run past the end of the quoted packet and corrupt skb_shared_info. Clear skb2->cb[] before pulling the quoted inner IPv6 packet so the reply path does not reuse metadata left by the outer IPv6 stack.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74598", "url": "https://ubuntu.com/security/CVE-2026-74598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix Route Information option length validation rt6_route_rcv() validates the Route Information option (RFC 4191) length against the prefix length, but both checks are off by one. rinfo->length is the ND option length in units of 8 octets and it *includes* the 8-byte option header, so an option carrying N bytes of prefix has length == 1 + N/8. RFC 4191 section 2.3 requires length 3 when Prefix Length is greater than 64, and 2 or 3 when it is greater than 0. The code accepts length >= 2 and length >= 1 respectively. ipv6_addr_prefix() then copies prefix_len/8 bytes out of rinfo->prefix, so a Router Advertisement with (prefix_len=128, length=2) or (prefix_len=64, length=1) makes the kernel read up to 8 bytes past the end of the option. Those bytes end up in the prefix of the route that gets installed, so they are visible to userspace: # RA with a Route Information option (prefix_len=128, length=2) # followed by a source link-layer address option, 01 01 de ad be ef ca fe $ ip -6 route show 2001:db8:dead:beef:101:dead:beef:cafe via fe80::1234 dev veth0 proto ra ^^^^^^^^^^^^^^^^^^ the next option, read out of bounds When the Route Information option is the last one in the packet, those eight bytes come from the skb tail room instead. Reject the option lengths RFC 4191 does not allow.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74599", "url": "https://ubuntu.com/security/CVE-2026-74599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/ptdump: always stabilise against page table freeing using init_mm Previous commits have established the invariant that kernel page table freeing is performed while an mmap read lock on init_mm is held, which fixes races between ptdump and kernel page table freeing over init_mm. However, x86 and arm64 can perform a ptdump over an mm other than init_mm via ptdump_walk_pgd() and since kernel memory ranges are shared across non-kernel mm's, this means that the race still exists for these cases. Fix this by acquiring a nested mmap write lock for init_mm in ptdump_walk_pgd(). This is safe as we take this after mmap write locking the mm, and nothing acquires the init_mm lock first before locking an arbitrary mm, so no deadlock is possible. Also update walk_page_range_debug() to assert that init_mm is write locked, add a comment explaining why and remove some redundant code, and eliminate the unnecessary and confusing invocation of walk_kernel_page_table_range(). We can safely remove the non-NULL check for walk.mm, as the mmap lock asserts would NULL pointer deref if it was (and of course no callers do this). The first point at which ptdump can race kernel page table freeing is commit b6bdb7517c3d (\"mm/vmalloc: add interfaces to free unmapped page table\"), so we target this in the Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74601", "url": "https://ubuntu.com/security/CVE-2026-74601", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Use current_context for safe per-CPU buffer swap The ring_buffer_swap_cpu() function currently checks the per-CPU committing counter to determine if a buffer is actively being written to before performing the swap. However, there exists a race window where this check can be bypassed: ring_buffer_lock_reserve cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_a rb_reserve_next_event rb_start_commit // inc committing if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) {...} __rb_reserve_next rb_move_tail rb_end_commit(cpu_buffer); // dec committing => 0 /* interrupt hits here, successfully swaps! */ local_inc(&cpu_buffer->committing); ring_buffer_unlock_commit cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_b rb_commit rb_end_commit RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing)) // triggers warning The committing counter can temporarily drop to 0 during a single write operation (within rb_move_tail), creating a window where swap can succeed even though the write is still in progress. This leads to inconsistent buffer state and triggers the RB_WARN_ON in rb_commit(). Replace the committing counter check with current_context checks, which are set at the entry of ring_buffer_lock_reserve() and remain valid throughout the entire write operation, providing a reliable indicator of buffer busy state during swap.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74602", "url": "https://ubuntu.com/security/CVE-2026-74602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Initialise reader page order in rb_allocate_cpu_buffer() In rb_allocate_cpu_buffer(), bpage->order was omitted, leaving it as 0. This is an issue for a ring-buffer with subbufs bigger than PAGE_SIZE if when freed: free_buffer_page() relies on this value. Align the value with the actual allocation size (buffer::subbuf_order).", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74603", "url": "https://ubuntu.com/security/CVE-2026-74603", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ocp: Fix board ID over-read The EEPROM board ID is a fixed 13-byte field and is not guaranteed to contain a NUL terminator. Passing it directly to devlink_info_version_fixed_put() treats it as a C string and may read beyond the field. Format at most OCP_BOARD_ID_LEN bytes into the existing local buffer before reporting the ID. Use a precision limit because the snprintf() output size alone does not bound the source string scan.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74604", "url": "https://ubuntu.com/security/CVE-2026-74604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"thermal/drivers/hwmon: Cleanup coding style a bit\" Revert commit 030a48b0f6ce (\"thermal/drivers/hwmon: Cleanup coding style a bit\") that introduced a use-after-free into the error path of thermal_add_hwmon_sysfs() by removing a valid check from it.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74606", "url": "https://ubuntu.com/security/CVE-2026-74606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventfs: Fix use-after-free in eventfs_remove_rec() eventfs_remove_rec() recursively removes the child at the current loop position. After the recursive call returns, list_for_each_entry() advances by reading list.next from the removed child. If free_ei() drops the final reference, release_ei() reuses the list/rcu union to queue an SRCU callback. The child may be freed before that read. The eventfs_mutex serializes list updates, but it does not keep the removed child alive or prevent the SRCU callback from running. Use list_for_each_entry_safe() to save the next sibling before recursively removing the current child.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74607", "url": "https://ubuntu.com/security/CVE-2026-74607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Serialize accesses to the owner and mirror list with separate lock Interaction between KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM and KVM_CAP_VM_COPY_ENC_CONTEXT_FROM can cause two separate issues: - in sev_migrate_from(), when the destination KVM is a mirror, the mirror entry is moved from the source's list to the owner's mirror_vms list, without holding the owner's lock unlike other writers of the owner's mirror list (sev_vm_copy_enc_context_from(), sev_vm_destroy()). A concurrent COPY or destroy can race with sev_migrate_from() and corrupt the list. - In sev_vm_destroy(), the *owner* is still active and could receive concurrently a KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM that causes sev->enc_context_owner to change. In this case the incorrect VM receives kvm_put_kvm(). The second issue needs particular care because the owner could disappear altogether (even though the race window is impossibly small) between reading it and locking it. There is thus no way to perform the checks under the owner lock without putting struct kvm under SLAB_TYPESAFE_BY_RCU (which would allow kvm_get_kvm_safe() under RCU critical section). It is much simpler to just use a global lock, since the critical sections are so small and the new lock is always a leaf lock.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74608", "url": "https://ubuntu.com/security/CVE-2026-74608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free in cifs_try_adding_channels() cifs_try_adding_channels() takes a temporary reference to an interface before dropping iface_lock. If cifs_ses_add_channel() fails, it drops that reference and then increments iface->weight_fulfilled. A concurrent interface list refresh can remove the list reference while channel creation is in progress. In that case, the failure-path kref_put() releases the last reference and frees iface. Updating weight_fulfilled afterward then accesses freed memory. Increment weight_fulfilled before dropping the temporary reference, keeping iface alive for the final access.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74609", "url": "https://ubuntu.com/security/CVE-2026-74609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: read le->link under the node lock in tipc_node_link_down() tipc_node_link_down() caches the link pointer before taking n->lock: \tstruct tipc_link *l = le->link;\t\t/* unlocked */ \tif (!l) \t\treturn; \ttipc_node_write_lock(n); \tif (!tipc_link_is_establishing(l)) {\t/* deref l */ \t... \t\ttipc_link_reset(l);\t\t/* write into l */ \tif (delete) { \t\tkfree(l); \t\tle->link = NULL; The delete=true caller frees that very object under n->lock, so the lock does not protect the cached pointer against it: - CPU A, delete=false: tipc_rcv() on TIPC_LINK_DOWN_EVT, or the link supervision timer via tipc_node_timeout(), reads l unlocked and then dereferences it under n->lock; - CPU B, delete=true: netlink TIPC_NL_BEARER_DISABLE -> bearer_disable() -> tipc_node_delete_links() -> tipc_node_link_down(n, bearer_id, true) -> kfree(l). The link is freed with plain kfree(), not kfree_rcu(), and for UDP bearers disable_media() only schedules the asynchronous cleanup_bearer() work, so its synchronize_net() runs after the links are already gone. An in-flight CPU A that has read l therefore dereferences freed memory once B frees it: a use-after-free read in tipc_link_is_establishing(), and a use-after-free write via tipc_link_reset() on the establishing branch. The following trace was captured on 7.2.0-rc5-00284-gaf39eb111ce6: BUG: KASAN: slab-use-after-free in tipc_link_is_establishing (net/tipc/link.c:285) Read of size 4 at addr ffff88802e2aa068 by task swapper/2/0 tipc_link_is_establishing (net/tipc/link.c:285) tipc_node_link_down (net/tipc/node.c:1076) tipc_node_timeout (net/tipc/node.c:843) Allocated by task 9549: tipc_link_create (net/tipc/link.c:490) tipc_node_check_dest (net/tipc/node.c:1279) tipc_disc_rcv (net/tipc/discover.c:252) tipc_udp_recv (net/tipc/udp_media.c:389) Freed by task 9549: tipc_node_link_down (net/tipc/node.c:1084) tipc_node_delete_links (net/tipc/node.c:1320) bearer_disable (net/tipc/bearer.c:414) __tipc_nl_bearer_disable (net/tipc/bearer.c:992) Move the le->link read inside tipc_node_write_lock(), so it is serialised against the kfree() in the delete path. A racing teardown now either has not run yet, and we see a valid link, or has already run, and we see NULL.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74610", "url": "https://ubuntu.com/security/CVE-2026-74610", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: don't leave a full plaintext sk_msg ring unpushed When the copy path in tls_sw_sendmsg_locked() adds the fragment that fills the plaintext sk_msg ring, it does not set full_record, so the record is left full and unpushed. A later splice() then adds to an already full ring: sk_msg_page_add() has no fullness check of its own, so sg.end wraps onto sg.start and the ring appears empty. Fragments added after that overwrite live entries, and sg.size no longer matches what is reachable between sg.start and sg.end, so pushing the record runs the scatterwalk off the end of the scatterlist. An unprivileged user can trigger this on a loopback TCP socket with the \"tls\" ULP attached: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:memcpy_from_scatterwalk+0x32/0xc0 Call Trace: skcipher_walk_next+0x1d1/0x2c0 gcm_encrypt_aesni_avx+0x1e9/0x220 bpf_exec_tx_verdict+0x3bb/0x860 tls_sw_sendmsg+0xa1a/0xca0 __sys_sendto+0x1da/0x1f0 Set full_record in the copy path when the ring becomes full, and push a record that is already full on entry to the sendmsg loop.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74611", "url": "https://ubuntu.com/security/CVE-2026-74611", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: rx: restore msg_iter before TLS 1.3 optimistic retry tls_decrypt_sg() advances msg->msg_iter when it maps user pages for the optimistic TLS 1.3 zero-copy path. If the decrypted record turns out not to be unpadded application data, tls_decrypt_sw() retries into a kernel skb, but leaves the iterator advanced. The subsequent copy from the skb then writes decrypted bytes again at a later point in the caller iovecs while recvmsg() reports only the post-retry length. A TLS peer can trigger this after the receiver enables TLS_RX_EXPECT_NO_PAD. Revert the iterator by the number of bytes consumed by the optimistic mapping before retrying without zero-copy. Add a selftest which sends a TLS 1.3 control record with TLS_RX_EXPECT_NO_PAD enabled and verifies that recvmsg() does not overwrite later iovecs beyond the returned length.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74580", "url": "https://ubuntu.com/security/CVE-2026-74580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost: reset the vring metadata cache on vring reconfiguration vq->meta_iotlb[] caches the vhost_iotlb_map that backs each vring metadata region, and iotlb_access_ok() returns early on a cache hit, taking the hit as proof that the region has already been validated: \tif (vhost_vq_meta_fetch(vq, addr, len, type)) \t\treturn true; The cache is reset on VHOST_IOTLB_UPDATE and VHOST_IOTLB_INVALIDATE, on device IOTLB (re)initialisation and on vq reset, but not when VHOST_SET_VRING_ADDR replaces vq->desc, vq->avail and vq->used, nor when VHOST_SET_VRING_NUM changes the region sizes. With a device IOTLB attached both ioctls are accepted while the vq is live, and neither validates the addresses at ioctl time: vq_access_ok() and vq_log_used_access_ok() return true early because the addresses are GIOVAs, deferring validation to prefetch time. Once the cache has been populated that deferred validation no longer runs -- vq_meta_prefetch() hits the stale entry and returns true -- and vhost_vq_meta_fetch() keeps translating through the old mapping as \tmap->addr + addr - map->start for an address the mapping no longer covers. vhost_copy_to_user() and vhost_copy_from_user() consume the result with __copy_to_user() and __copy_from_user(), which do not check it either, so a subsequent used ring update or descriptor fetch accesses memory outside the region the IOTLB actually maps. Reset the metadata cache whenever the vring is reconfigured, so the new addresses are pushed back through iotlb_access_ok()'s slow path.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-74612", "url": "https://ubuntu.com/security/CVE-2026-74612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: fix skb length accounting after XDP frag adjustment veth exposes non-linear skb fragments through an xdp_buff. If an XDP program adjusts the fragment area, veth_xdp_rcv_skb() copies xdp_frags_size back to skb->data_len but leaves skb->len containing the old fragment contribution. After a fragment shrink, this makes skb_headlen() larger than the actual linear area. In the reproduced UDP receive path, __skb_datagram_iter() copied 1024 bytes past the actual linear tail to userspace, starting at struct skb_shared_info. The copied bytes included the affected skb's nr_frags, xdp_frags_size, and a kernel pointer from skb_shinfo(skb)->frags[0]. Real packet data was displaced by the same amount and truncated at the end. Subtract the old data_len before replacing it and add the new data_len afterwards, keeping skb->len and skb->data_len synchronized. Additionally, bpf_xdp_pull_data() can advance data_end while leaving frags present. The skb is then still non-linear, so the old __skb_put(skb, off) triggers SKB_LINEAR_ASSERT(). Use skb_set_tail_pointer() and update skb->len explicitly instead, following bpf_prog_run_generic_xdp(). Unlike __skb_put(), skb_set_tail_pointer() does not require a linear skb. A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by 1024 bytes from its fragment area. Before the fix, all 10 runs produced corrupted payloads. After the fix, all 10 runs matched the expected payload exactly. A forced-tailroom reproducer also exercises bpf_xdp_pull_data() with frags still present; the old code triggers SKB_LINEAR_ASSERT(), while this fix passes 10/10 runs.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74613", "url": "https://ubuntu.com/security/CVE-2026-74613", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: avoid refilling the RX queue after teardown Commit b917507e5ad9 (\"vsock/virtio: stop workers during the .remove()\") made the RX worker jump to its common exit when rx_run is clear. That exit still refills the RX queue when the buffer count is low, so work queued across virtio_vsock_vqs_del() can add buffers after the virtqueues have been deleted. BUG: KASAN: slab-use-after-free in virtqueue_add_sgs Read of size 4 by task kworker/0:1 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtqueue_add_sgs (drivers/virtio/virtio_ring.c:2796) virtio_vsock_rx_fill (net/vmw_vsock/virtio_transport.c:332) virtio_transport_rx_work (net/vmw_vsock/virtio_transport.c:701) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Freed by task 141: kfree (mm/slub.c:6566) vp_del_vq (drivers/virtio/virtio_pci_common.c:259) vp_del_vqs (drivers/virtio/virtio_pci_common.c:285) virtio_vsock_freeze (net/vmw_vsock/virtio_transport.c:912) virtio_device_freeze (drivers/virtio/virtio.c:658) virtio_pci_freeze (drivers/virtio/virtio_pci_common.c:601) pci_pm_freeze (drivers/pci/pci-driver.c:1098) device_suspend (drivers/base/power/main.c:1968) Kernel panic - not syncing: KASAN: panic_on_warn set ... Jump to a no-refill exit when rx_run is clear, leaving the normal exit to replenish a running queue.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74614", "url": "https://ubuntu.com/security/CVE-2026-74614", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: read virtqueues under worker locks Commit bd50c5dc182b (\"vsock/virtio: add support for device suspend/resume\") made the *_run flags transition from false to true when restore installs replacement virtqueues. The RX, TX and event workers read their virtqueue before locking and checking the corresponding flag, so a worker delayed across freeze and restore can observe the replacement queue's running state while retaining a pointer to the deleted queue. Read each virtqueue under its mutex after checking the run flag, keeping the pointer and state in the same queue generation.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74615", "url": "https://ubuntu.com/security/CVE-2026-74615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not arm the ageing timer on a device that is down vxlan_changelink() arms vxlan->age_timer whenever the requested ageing interval differs from the configured one: \tif (conf.age_interval != vxlan->cfg.age_interval) \t\tmod_timer(&vxlan->age_timer, jiffies); There is no netif_running() test, so the timer is armed even on a device that was never brought up. The only synchronous cancel in the driver is the timer_delete_sync() in vxlan_stop(), which is .ndo_stop. netif_close_many() drops devices without IFF_UP before __dev_close_many() runs, so that cancel is skipped for such a device. vxlan_setup() sets dev->needs_free_netdev = true and age_timer is a member of struct vxlan_dev, so free_netdev() releases the allocation the timer lives in while it is still queued on a timer_base. expire_timers() unlinks the entry before it loads timer->function, so the timer core writes through the freed object's list pointers: BUG: KASAN: slab-use-after-free in __run_timers+0x208/0x654 Write of size 8 at addr ffff00001adace68 by task true/192 __asan_store8+0x84/0xac __run_timers+0x208/0x654 run_timer_softirq+0x154/0x18c Allocated by task 189: alloc_netdev_mqs+0x64/0x720 rtnl_create_link+0x4ac/0x520 rtnl_newlink+0x758/0xd00 Freed by task 191: netdev_release+0x40/0x58 netdev_run_todo+0x4a4/0x8c0 rtnl_dellink+0x200/0x4e8 The rtnl operations involved are netns-scoped, so an unprivileged user can perform them in a new user and network namespace. Arming the timer on a down device never had an effect: vxlan_cleanup() returns early on !netif_running(), and vxlan_open() arms the timer for any non-zero interval once the device is brought up. Add the missing test. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74616", "url": "https://ubuntu.com/security/CVE-2026-74616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xdp: reject clones that overrun skb_shared_info tailroom xdpf_clone() clones broadcast copies into a single page and sets frame_sz to PAGE_SIZE. __xdp_build_skb_from_frame() later treats that page like a normal XDP frame and expects the usual skb_shared_info tailroom at the end of the buffer. The current check only rejects frames whose linear xdp_frame header, headroom, and packet data exceed PAGE_SIZE. A source frame backed by a larger allocation can still satisfy that check while extending into the clone's required shared-info area. When such a clone is converted back into an skb, build_skb_around() places skb_shared_info over live packet bytes and later writes can corrupt XDP return metadata. Reject clones unless their linear area fits inside SKB_WITH_OVERHEAD(PAGE_SIZE), matching the tailroom requirement already enforced by the XDP-to-skb conversion path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74617", "url": "https://ubuntu.com/security/CVE-2026-74617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dibs: initialise dibs->lock in dibs_dev_alloc() dibs->lock is initialised by dibs_dev_add(), but a dibs device can already take interrupts before that call: ism_probe() runs ism_dev_init(), and hence request_irq(), before it calls dibs_dev_add(). No client can have registered a dmb at that point, so no dmb interrupt can occur, but a GID event interrupt can, and ism_handle_irq() takes dibs->lock unconditionally on entry, before it inspects anything else. Initialise the lock in dibs_dev_alloc() instead, so that it is valid as soon as a driver can publish the device to its interrupt handler.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74618", "url": "https://ubuntu.com/security/CVE-2026-74618", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't warn when the mount is completed from another user namespace fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in bm_fill_super(): create a user and a mount namespace in a child, call fsopen(\"binfmt_misc\") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere: WARNING: fs/binfmt_misc.c:938 at bm_fill_super+0xa2/0xc0 [binfmt_misc] CPU: 15 UID: 1000 PID: 3243382 Comm: fswarn Call Trace: get_tree_keyed+0x7d/0xb0 bm_get_tree+0x34/0x90 [binfmt_misc] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check. It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn. Keep refusing the mount and stop warning about it. Nothing in bm_fill_super() depends on the two namespaces matching, it derives everything from sb->s_user_ns.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74619", "url": "https://ubuntu.com/security/CVE-2026-74619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: don't warn when the mount is completed from another user namespace fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in ovl_fill_super(): create a user and a mount namespace in a child, call fsopen(\"overlay\") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere: WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay] CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn Call Trace: get_tree_nodev+0x71/0xa0 ovl_get_tree+0x15/0x20 [overlay] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check. It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn. Keep refusing the mount and stop warning about it. ovl_parse_param() already spells a user namespace check this way for Opt_override_creds.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74620", "url": "https://ubuntu.com/security/CVE-2026-74620", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_gact, act_police: range check the fallback control action tcf_action_check_ctrlact() range checks the primary control action: \tif (!opcode) \t\tret = action > TC_ACT_VALUE_MAX ? -EINVAL : 0; TC_ACT_VALUE_MAX is TC_ACT_TRAP, so kernel-internal verdicts above it cannot be set that way. But act_gact and act_police each carry a second, independent control action supplied by user space that never reaches that helper - TCA_GACT_PROB.paction and TCA_POLICE_RESULT. Both only reject TC_ACT_GOTO_CHAIN, so any other value is stored verbatim and returned verbatim from the action. In particular user space can store TC_ACT_CONSUMED, which is TC_ACT_VALUE_MAX + 1 and is deliberately not part of the UAPI value range. That verdict tells every caller the action took ownership of the skb, so nobody frees it: sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for it. The result is one leaked sk_buff plus its data buffer per packet traversing the filter, unbounded, for all traffic on the chain including kernel-generated packets. Both are trivially deterministic. act_gact clamps tcfg_pval to >= 1, so with pval = 1 gact_determ() returns the fallback for every packet. act_police has no mandatory rate, so rate = 0 leaves tcfp_mtu = ~0 and tcf_police_mtu_check() always passes. TC_ACT_CONSUMED was added by commit 720f22fed81b (\"net: sched: refactor reinsert action\"), after both goto-chain guards were written: commit 9469f375ab09 (\"net/sched: act_gact: disallow 'goto chain' on fallback control action\") and commit c08f5ed5d625 (\"net/sched: act_police: disallow 'goto chain' on fallback control action\"). Neither guard was widened when the new verdict appeared. Factor the existing range test out of tcf_action_check_ctrlact() as tcf_action_valid() and apply it to both fallbacks. The helper cannot call tcf_action_check_ctrlact() directly because that also allocates a goto_chain, which is exactly what these two sites must not do. Reproduced on v7.2-rc6: kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet. With this patch both configurations are rejected with -EINVAL and kmemleak reports none.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74621", "url": "https://ubuntu.com/security/CVE-2026-74621", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix sk_buff leak when the header checks reject a packet tcf_ct_handle_fragments() runs its header sanity checks before handing anything to the defragmentation engine: \tif (family == NFPROTO_IPV4) \t\terr = tcf_ct_ipv4_is_fragment(skb, &frag); \telse \t\terr = tcf_ct_ipv6_is_fragment(skb, &frag); \tif (err || !frag) \t\treturn err; tcf_ct_ipv4_is_fragment() returns -EINVAL or -ENOMEM; tcf_ct_ipv6_is_fragment() adds -EPROTO when ipv6_find_hdr() fails. None of them frees or queues the skb, so on that path the caller still owns it. tcf_ct_act() however funnels every non-zero return into the ownership-transfer exit: \terr = tcf_ct_handle_fragments(net, skb, family, p->zone, &defrag); \tif (err) \t\tgoto out_frag; \t... out_frag: \tif (err != -EINPROGRESS) \t\ttcf_action_inc_drop_qstats(&c->common); \treturn TC_ACT_CONSUMED; TC_ACT_CONSUMED means the action took ownership of the skb, so no caller frees it - sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for that verdict. The skb is therefore orphaned: one sk_buff plus its data buffer is leaked per malformed packet, unbounded. Note the drop counter is already incremented for these errors, so the statistics claim a drop that never happens. Three different ownership states reach out_frag: today - the skb may be queued by the defrag engine (-EINPROGRESS), already freed by nf_ct_handle_fragments(), or still owned by us. Tell the caller which of those it is, and free the packet ourselves in the last case, which restores the TC_ACT_SHOT behaviour that predated the Fixes: commit. Reproduced on v7.2-rc6 with a 54-byte frame carrying a 40-byte IPv6 header with nexthdr = 0 (hop-by-hop) and nothing after it, on a clsact ingress chain with \"action ct\". kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet; with this patch it reports none.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74622", "url": "https://ubuntu.com/security/CVE-2026-74622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: free RX pages of consumed but not refilled buffers aq_ring_rx_deinit() only walks [sw_head, sw_tail), the region posted to hardware. Since the page reuse strategy was added, a cleaned RX buffer keeps its page (and its DMA mapping) in the ring for reuse, and refill is batched: aq_ring_rx_fill() returns early until AQ_CFG_RX_REFILL_THRES slots are free. Slots that were consumed but not yet reposted therefore sit in the complementary [sw_tail, sw_head) gap with a live page, and the deinit walk never visits them: up to a refill batch worth of pages and DMA mappings leak on every interface down. Walk the whole ring instead and release whatever is still there. Also bail out if the buffer ring is already gone: a partial aq_ptp_ring_alloc() failure frees the ring but leaves aq_nic set, so aq_ptp_ring_deinit() still gets here on the unwind path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74623", "url": "https://ubuntu.com/security/CVE-2026-74623", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: free stranded TX buffers on ring deinit aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean() call, which frees at most AQ_CFG_TX_CLEAN_BUDGET (256) descriptors and stops at hw_head, which no longer moves once aq_vec_stop() has stopped the hardware and NAPI. Completed descriptors beyond the budget and everything still posted in [hw_head, sw_tail) keep their skb or xdp_frame when the interface goes down: aq_vec_ring_free() then frees the buffer ring and the references are lost for good. Today this is a silent memory leak on every interface down under TX/XDP_TX load. With the conversion of the RX path to page_pool posted for net-next it becomes much more visible: XDP_TX frames carry fragment references on the RX ring's page_pool, so a single stranded frame keeps the pool's inflight count above zero forever. page_pool_destroy() then never completes, the pool is leaked together with its pages, and \"page_pool_release_retry() stalled pool shutdown\" is warned every 60 seconds from that point on, on every ifdown, XDP detach or ring resize under XDP_TX load. Bring back aq_ring_tx_deinit() as it was before the removal and use it for teardown again, with one extension: TX rings can hold xdp_frames nowadays, so release those too. They are returned with xdp_return_frame() since this runs in process context.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74624", "url": "https://ubuntu.com/security/CVE-2026-74624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: defer invalid log until after unlock TCP and SCTP conntrack paths can emit invalid-packet logs while ct->lock is still held. When invalid logging is routed to nfnetlink_log and conntrack export is enabled, the log path can re-enter conntrack netlink glue and dump the same conntrack again. Protocol attribute dumping may take ct->lock, so logging while holding that lock can deadlock. Defer the TCP invalid logs by storing only the minimal log context while ct->lock is held and emitting the log after unlocking. Also make the TCP timeout-lowering invalid path return whether a log is needed, then emit that log after unlocking. Do the same for the SCTP invalid state-transition log that can be reached while ct->lock is held. Add a lockdep assertion to nf_ct_l4proto_log_invalid() so future callers that log invalid conntracks while holding ct->lock are caught outside TCP and SCTP as well.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74625", "url": "https://ubuntu.com/security/CVE-2026-74625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: release template ct on non-IP path A bridge nftables ct zone set rule can attach a conntrack template to an skb before nf_ct_bridge_pre() sees it. For non-IPv4 and non-IPv6 EtherTypes, nf_ct_bridge_pre() currently overwrites skb->_nfct with IP_CT_UNTRACKED without releasing the existing template reference. That makes the per-cpu template, and any temporary templates allocated for concurrent use, unreachable and leaks memory until the host runs out of slab. Reset the skb conntrack state before marking the frame untracked so the existing template reference is dropped on the non-IP path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74627", "url": "https://ubuntu.com/security/CVE-2026-74627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: devmem: prevent net-iov / page mixing We should either have net_iov or page backed frags in a single skb, otherwise it blows up down the stack. Don't allow mixing in zerocopy_fill_skb_from_devmem().", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74628", "url": "https://ubuntu.com/security/CVE-2026-74628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free of the socket by its timers The x25 timers are armed with mod_timer() and cancelled with timer_delete(), so a pending timer holds no reference on the socket and a cancel does not wait for a callback already running on another CPU. x25_heartbeat_expiry() also rearms unconditionally, so it can reinstall sk->sk_timer after __x25_destroy_socket() has passed its cancel point. The following __sock_put() frees the socket while the timer is still queued, and the next expiry uses freed memory. KASAN reports a slab-use-after-free on the kmalloc-2k object freed by close(). timer_delete_sync() cannot be used here: x25_heartbeat_expiry() and x25_timer_expiry() both reach the cancels from inside the timer they would wait on, through __x25_destroy_socket() and x25_disconnect(). Arm the timers with sk_reset_timer() and cancel them with sk_stop_timer() so that an armed timer owns a reference, and release it in both expiry handlers. Rearm the heartbeat only while sk_hashed(sk) is still true, since __x25_destroy_socket() unlinks the socket before dropping it. Arm the deferred destroy timer the same way and drop its reference in x25_destroy_timer(). Reproduced on net with KASAN, with the heartbeat period shortened so the window recurs. With this patch the reproducer no longer triggers a report and /proc/net/x25 drains. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74629", "url": "https://ubuntu.com/security/CVE-2026-74629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/dibs: Correct freeing of dmb_clientid_arr A dibs device interrupt handler can be active after dibs_dev_del() and may still access dmb_clientid_arr. (UAF) In case of a failure in dibs_dev_add() being called by dibs_lo_dev_probe() dmb_clientid_arr is freed twice (double free). Free dmb_clientid_arr in dibs_dev_release() after last reference is gone. Note that allocating in dibs_dev_add() instead of dibs_dev_alloc() is ok for now, because no dmbs can be registered before dibs_dev_add().", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74630", "url": "https://ubuntu.com/security/CVE-2026-74630", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent in6_dev_get() from resurrecting inet6_dev in6_dev_get() reads dev->ip6_ptr under RCU and then unconditionally increments its refcount. Device teardown can clear the pointer and drop the last reference between these operations. The increment then resurrects an object whose RCU free has already been queued, so callers can use it after it is freed. Use refcount_inc_not_zero() and return NULL when the object has already reached zero. RCU keeps the memory accessible through the attempted reference acquisition, and a successful increment pins the object for the caller. An independent run on the exact unpatched 6f5156d7a31a (v7.2-rc3) kernel reproduced the invalid reference acquisition as UID 1000: refcount_t: addition on 0; use-after-free. ip6_mc_source+0xef4/0x17e0 It was followed by the corresponding reference underflow in ip6_mc_source(). The supplied trace from the same unpatched revision additionally shows the access after the RCU read-side section ends: BUG: KASAN: slab-use-after-free in mutex_lock+0x76/0xe0 Write of size 8 at addr ffff888015b50240 by task poc/1219 Bug found and triaged by OpenAI Security Research and validated by Trail of Bits.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74631", "url": "https://ubuntu.com/security/CVE-2026-74631", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: smc: fix splice entry lifetime imbalance in smc_rx_splice smc_rx_splice() passes pages to splice_to_pipe() before taking the references that cover the lifetime of each splice entry. In the VM-backed RMB path, splice_to_pipe() may drop unqueued entries through smc_rx_spd_release(), while queued entries are released later via the pipe buffer callback. The old post-splice accounting also derives the number of queued VM pages from an offset mutated while building the descriptor, and a multi-page splice pairs one sock_hold() with multiple sock_put() calls. Take the page and socket references for every candidate entry before splice_to_pipe(), and drop the matching private state, page reference, and socket reference from smc_rx_spd_release() for entries that never get queued. This fixes a refcount imbalance that can underflow page refcounts and trigger a use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74632", "url": "https://ubuntu.com/security/CVE-2026-74632", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix huge_zero_pfn race Patch series \"mm/huge_memory: fix huge_zero_pfn race\", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn() and consequently is_huge_zero_pmd() will misidentify the huge zero folio as being an ordinary THP folio. This can result in the huge zero folio being split and otherwise treated incorrectly. The solution to this is very subtle as there is an atomic fast path, and thus ordering in weakly ordered architectures has to be treated very carefully. The first commit fixes the issue by introducing a spinlock around huge_zero_[pfn, folio, refcount] write, with careful consideration paid to load/store ordering in the fast path. It is placed first and kept as small as possible so that it can be backported on its own. The second commit is a pure cleanup which reworks the CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent logic from the dynamically allocated one. This patch (of 2): If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted by huge_zero_refcount and returned by mm_get_huge_zero_folio(). When the caller is done with the huge zero page, its reference count is decremented. Only a shrinker can set the reference count to zero. A race can unfortunately occur between a shrinker decrementing the reference count to zero and a concurrent page fault. This is because shrink_huge_zero_folio_scan() might, if very unlucky, be preempted between setting huge_zero_refcount to zero and writing an invalid value. During this time get_huge_zero_folio() could write to huge_zero_pfn before shrink_huge_zero_folio_scan() resumes. In this event the huge zero folio will be persistently misidentified causing the THP code path to be entered inappropriately for the huge zero folio: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() sets refcount to 0 | xchg() sets huge_zero_folio to NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid huge_zero_folio v | Write valid huge_zero_pfn Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite! This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly returning false for a huge zero page which could result in issues like the huge zero folio being incorrectly split. Note that the issue is with huge_zero_pfn not huge_zero_folio, as get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set huge_zero_folio. Fix the issue by introducing a spinlock, huge_zero_lock, to prevent concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount. There needs to be significant care taken here to ensure correctness: The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which is outside of the critical section, and means huge zero allocation is gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74633", "url": "https://ubuntu.com/security/CVE-2026-74633", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix NULL pointer dereference in module event cache removal A module-only event filter such as \":mod:foo\" is cached with a NULL event_mod->match when foo has not been loaded. If a later write tries to remove a specific match from the same module, remove_cache_mod() passes the NULL cached match to strcmp(), causing a NULL pointer dereference. The issue can be reproduced from userspace: echo ':mod:trace_events_kunit_missing' > /sys/kernel/tracing/set_event echo '!foo_bar:mod:trace_events_kunit_missing' >> /sys/kernel/tracing/set_event The second write must be a concatenation (\">>\") to not include O_TRUNC as that would cause ftrace_clear_events() to clear the cached modules lines. The crash was reproduced on x86_64 QEMU while KUnit workers contended on the event tracing path: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode RIP: 0010:strcmp+0x10/0x30 Call Trace: __ftrace_set_clr_event_nolock+0x373/0x4a0 ftrace_set_clr_event+0xf0/0x180 ftrace_event_write+0xdf/0x110 vfs_write+0xf6/0x440 ksys_write+0x68/0xe0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f Check event_mod->match before comparing it, consistent with the existing NULL checks for the cached system and event fields. The mismatched removal continues to return -EINVAL; a broad cached module filter is removed with \"!:mod:\".", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74634", "url": "https://ubuntu.com/security/CVE-2026-74634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Prevent subbuf order change when resizing is disabled Because ring_buffer_subbuf_order_set() frees buffer pages, we can't allow it when resizing is disabled. A non-consuming reader is at risk of use-after-free (rb_advance_iter()). Return -EBUSY on resize_disabled, matching ring_buffer_resize() behaviour.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74635", "url": "https://ubuntu.com/security/CVE-2026-74635", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: bitblit: bound-check glyph index in bit_cursor() bit_cursor() fetches the glyph under the cursor with \tc = scr_readw(vc_pos); \tsrc = vc_font.data + ((c & charmask) * w * height); where charmask is 0x1ff when vc_hi_font_mask is set. The screen buffer value comes directly from scr_readw() and may be larger than the current font's glyph count. Syzkaller triggers this via vcs_write(). The Call Trace shows vcs_write() in vc_screen.c writing an arbitrary 16-bit value with writev() to /dev/vcsa, which vcs_write_buf() in vc_screen.c stores via vcs_scr_writew() without checking charcount. The stored value is later read in bit_cursor() in bitblit.c. When the font is changed from a font with 512 glyphs to a font with 256 glyphs, the screen buffer can retain characters with the high bit set from the previous mode, which could also produce the same out-of-bounds access. BUG: KASAN: global-out-of-bounds in soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70 Read of size 16 at addr ffff800086c57970 Call Trace: soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70 bit_cursor+0xa90/0x1108 drivers/video/fbdev/core/bitblit.c:365 fbcon_cursor+0x344/0x498 drivers/video/fbdev/core/fbcon.c:1427 hide_cursor+0xdc/0x2d0 drivers/tty/vt/vt.c:883 update_region+0x100/0x18c drivers/tty/vt/vt.c:669 vcs_write+0x8ec/0xaf0 drivers/tty/vt/vc_screen.c:685 bit_putcs_aligned() and bit_putcs_unaligned() already clamp the glyph index to vc_font.charcount. Apply the same clamp in bit_cursor() after extracting the attribute and masking, before indexing fontdata. The fix completes the bounds checking started in commit 18c4ef4e765a (\"fbdev: bitblit: bound-check glyph index in bit_putcs*\"), which missed the cursor path. This change should be safe because the clamp reuses the existing contract from fbcon: charcount is maintained under console_lock in con_font_set() and fbcon_font_set(), and hi_font_mask is cleared when switching from 512 to 256 glyphs. When stale screen data with high bits remains after a font switch, or when vcs_write() stores an arbitrary value, clamping the index to 0 prevents the out-of-bounds read without changing cursor semantics — the same fallback bit_putcs uses.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74636", "url": "https://ubuntu.com/security/CVE-2026-74636", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race between update_event_fields and, event_define_fields The following sequence may leads race between event_define_fields() and update_event_fields(): CPU0 (loads module A) CPU1 (loads module B) =============================== =============================== load_module(A) load_module(B) notifier_call_chain notifier_call_chain trace_module_notify trace_module_notify mutex_lock(&event_mutex) trace_event_update_all() trace_module_add_events(A) down_write(&trace_event_sem) __register_event(call_A) __add_event_to_tracers(call_A) event_define_fields(call_A) for each f: list_for_each_entry(field, list_add(&f->link, &class->fields, link) &class->fields) field = class->fields->next; Where access to the class->fields is not protected by the event_mutex in trace_event_update_all(). This produces the following panic: Unable to handle kernel access ... at virtual address 0000000000000018 pc : update_event_fields+0xf8/0x368 Call trace: update_event_fields+0xf8/0x368 trace_event_update_all+0x7c/0x2b4 trace_module_notify+0x4c/0x1dc notifier_call_chain+0x84/0x168 blocking_notifier_call_chain_robust+0x64/0xd4 load_module+0x10c8/0x123c __arm64_sys_finit_module+0x230/0x31c Fix by taking event_mutex in trace_event_update_all() before trace_event_sem.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74637", "url": "https://ubuntu.com/security/CVE-2026-74637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix group leader use-after-free after sibling detach perf_group_detach() handles leader and sibling detach differently. When the group leader is detached, all siblings are promoted to singleton events and their group_leader pointer is reset to themselves. When a sibling is detached, it is removed from the leader's sibling_list, but its group_leader pointer is left pointing at the old leader. That is harmless when the sibling is being closed and freed immediately, as in the DETACH_DEAD path. It is not safe when the sibling is detached but kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the sibling is removed from the context, while its file descriptor can still keep it alive. A typical failing sequence is: - A group contains leader L and sibling S. - CPU hot-unplug detaches S with DETACH_GROUP, removing it from L->sibling_list but leaving S->group_leader == L. - L is later closed and freed. - A PERF_IOC_FLAG_GROUP ioctl on S follows S->group_leader and dereferences the freed leader. This was reproduced by running the perf event fuzzer, CPU hotplug, and a stress workload concurrently: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT pc : perf_ioctl+0x34c/0xc68 x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908) Call trace: perf_ioctl+0x34c/0xc68 (P) __arm64_sys_ioctl+0xa0/0xf4 invoke_syscall+0x58/0xe4 el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x40/0xc0 el0t_64_sync_handler+0x68/0xdc el0t_64_sync+0x1c4/0x1c8 The fault happened in perf_ioctl(), where perf_event_for_each() follows the stale group_leader pointer and perf_event_for_each_child() then dereferences the freed leader's context. Fix the use-after-free by promoting the detached sibling to a singleton. Also fix __event_disable() cgroup accounting and event state change.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74638", "url": "https://ubuntu.com/security/CVE-2026-74638", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Serialize the scheduler timeout handlers V3D exposes several independent hardware queues (BIN, RENDER, TFU and CSD) but has only a single, global reset. A timeout on any one queue therefore has to stop, reset and restart the schedulers of every other queue as well. That makes concurrent timeout handlers unsafe. `reset_lock` was never able to make them safe, as a driver-side lock can only cover the driver's &drm_sched_backend_ops.timedout_job callback. The scheduler handles the timed out job and its pending list around that callback, outside of the driver's control, so a global reset triggered by one queue can still interfere with another queue that is in the middle of handling a timeout of its own. Consequently, if a reset happens in the CSD queue while a CL-intensive application is running, the global reset stops and restarts the CL queue's scheduler while that queue is handling a timeout of its own. As drm_sched_stop() and drm_sched_start() subtract and add the credits of every job sitting on the pending list of the scheduler they are called on, and as the CL queue's handler concurrently takes its job off that same list and puts it back, the stop and the start no longer see the same set of jobs. The CL queue is left with more credits in flight than its limit: [ 327.302739] ------------[ cut here ]------------ [ 327.302744] WARNING: CPU: 2 PID: 43 at drivers/gpu/drm/scheduler/sched_main.c:102 drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] [ 327.302884] CPU: 2 UID: 0 PID: 43 Comm: kworker/u16:1 Not tainted 6.18.39-v8-16k+ #3 PREEMPT [ 327.302889] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [ 327.302893] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched] [ 327.302984] Call trace: [ 327.302987] drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] (P) [ 327.302997] process_scheduled_works+0x180/0x3d0 [ 327.303010] worker_thread+0x268/0x3e8 [ 327.303016] kthread+0x140/0x250 [ 327.303022] ret_from_fork+0x10/0x20 [ 327.303031] ---[ end trace 0000000000000000 ]--- From that point on, the credit count of the CL queue is broken, causing a complete GPU hang and UI freeze. The DRM scheduler already provides a mechanism to serialize the timeout handlers of different schedulers: an ordered workqueue passed as drm_sched_init()'s @timeout_wq parameter. By default, each scheduler queues its timeout work on the system workqueue, which runs the handlers concurrently. Give all of the queues a shared ordered workqueue instead, as recommended by the DRM scheduler documentation for hardware that has distinct queues but resets globally.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74639", "url": "https://ubuntu.com/security/CVE-2026-74639", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: us144mkii: re-anchor capture URBs on resubmission capture_urb_complete() resubmits each capture URB without anchoring it: \tusb_get_urb(urb); \tret = usb_submit_urb(urb, GFP_ATOMIC); Anchoring is a property of a submission, not of the URB. The giveback path calls usb_unanchor_urb() before urb->complete(), so an URB resubmitted from its own completion handler is off the anchor. The capture URBs are anchored once, at stream start, so from the first completion onward tascam->capture_anchor is empty. tascam_free_urbs(), tascam_disconnect(), tascam_suspend() and the stop-work path all call usb_kill_anchored_urbs(&tascam->capture_anchor) to reap the capture URBs before anything is freed. With the anchor empty those calls return immediately and the URBs stay queued on the host controller. tascam_free_urbs() then returns the capture transfer buffers with usb_free_coherent(), and snd_card_free() releases the snd_card allocation that embeds tascam (card->private_data). The controller completes the queued URBs afterwards, writing device-supplied data into the freed transfer buffer, and capture_urb_complete() dereferences the freed driver object. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in dummy_timer Write of size 512 at addr ffff000015b62000 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 64: usb_alloc_coherent tascam_alloc_urbs tascam_probe Freed by task 170: usb_free_coherent tascam_free_urbs tascam_disconnect usb_unbind_interface BUG: KASAN: slab-use-after-free in capture_urb_complete Read of size 4 at addr ffff0000170ee878 Freed by task 170: release_card_device snd_card_free tascam_disconnect Restore the usb_anchor_urb() between the reference count bump and the resubmission. That also makes the handler's usb_unanchor_urb() failure arm meaningful again and restores usb_kill_anchored_urbs() as a barrier on the disconnect, suspend and stop-work paths. The anchoring was removed on the premise that the URB is already anchored from the initial submission, which does not hold once the first giveback has run. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74640", "url": "https://ubuntu.com/security/CVE-2026-74640", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: FCP: fix OOB write in fcp_meter_ctl_get() fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size by the driver's own limit of 255 \tif (map.map_size < 1 || map.map_size > 255 || \t map.meter_slots < 1 || map.meter_slots > 255) \t\treturn -EINVAL; and passes it to fcp_add_new_ctl() as the control's channel count, where it is stored as elem->channels. Every control read writes into struct snd_ctl_elem_value, whose integer array is declared long value[128], so the limit is 128, not 255. fcp_meter_ctl_get() stores one 64-bit word per channel into that array with no bound of its own: \tfor (i = 0; i < elem->channels; i++) { \t\tint idx = private->meter_level_map[i]; \t\tint value = idx < 0 ? 0 : le32_to_cpu(resp[idx]); \t\tucontrol->value.integer.value[i] = value; \t} snd_ctl_elem_read_user() serves that object from memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of kmalloc-2048. offsetof(struct snd_ctl_elem_value, value) is 72, so element i is written at byte 72 + 8 * i and element 144 already lands past the allocation. At map_size 255 the last store ends at byte 2112, 888 bytes past the object and 64 bytes into the adjacent slab object. The stored words come from the device and meter_level_map[] selects which word lands in which slot, so extent and contents are both controlled. The core does not catch this. snd_ctl_check_elem_info() is reached only from __snd_ctl_elem_info(), which snd_ctl_elem_read() calls under CONFIG_SND_CTL_DEBUG; without that option snd_ctl_skip_validation() is a compile-time true. __snd_ctl_add_replace() validates kcontrol->count and never inspects elem->channels. Installing an oversized map needs CAP_SYS_RAWIO, but the control outlives the hwdep descriptor that created it, so the out-of-bounds stores are issued by any process able to read controls on /dev/snd/controlC0. KASAN on 7.2.0-rc5 (arm64), triggered by an unprivileged control read: BUG: KASAN: slab-out-of-bounds in fcp_meter_ctl_get Write of size 8 at addr ffff000017af04c8 by task fcp_trigger/185 __asan_store8 fcp_meter_ctl_get snd_ctl_elem_read snd_ctl_ioctl Allocated by task 185: memdup_user snd_ctl_ioctl The buggy address is located 0 bytes to the right of allocated 1224-byte region [ffff000017af0000, ffff000017af04c8) Bound the map size by the ABI limit rather than by 255, and bound the store loop at the sink so it cannot run past the value array whatever elem->channels holds. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74641", "url": "https://ubuntu.com/security/CVE-2026-74641", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usx2y: bound the hwdep mmap fault offset snd_us428ctls_vm_fault() turns the faulting page offset into a kernel address with no bound of any kind: \toffset = vmf->pgoff << PAGE_SHIFT; \tvaddr = (char *)(...)->us428ctls_sharedmem + offset; \tpage = virt_to_page(vaddr); \tget_page(page); \tvmf->page = page; \treturn 0; snd_us428ctls_mmap() checks only the length of the mapping, never the offset, and us428ctls_sharedmem is a single page from alloc_pages_exact(). For a character device file_mmap_size_max() returns ULONG_MAX, so the mm layer imposes no ceiling either. Every page offset above zero resolves to a struct page outside the object, and the handler installs it into the caller's address space read-write; the vma is not marked read-only. The caller picks the page frame with a single mmap() argument and gets read-write access to a page of kernel memory it does not own; an offset that lands in an unpopulated vmemmap region oopses instead. A process that can open the hwdep node of an attached US-X2Y reaches this after loading the FPGA image through the same node; no capability check is involved. On 7.2.0-rc5 (arm64), mmap() with a large offset: Unable to handle kernel paging request at virtual address fffffdffc45d5ac8 pc : snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y] Call trace: snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y] __do_fault __handle_mm_fault handle_mm_fault el0_da Reject any offset outside the shared region. The pcm hwdep handler in usx2yhwdeppcm.c computes its address the same way and needs the same bound. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74643", "url": "https://ubuntu.com/security/CVE-2026-74643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: samples/damon/mtier: error out for zero quota goal target values Patch series \"mm/damon: avoid division by zero from damos_quota_score()\". DAMON_SAMPLE_MTIER and DAMON_LRU_SORT allow the user to trigger division by zero in damos_quota_score(). Avoid it by adding parameters validation checks. This patch (of 2): damos_quota_score() can trigger division by zero if the target_value is zero. DAMON_SAMPLE_MTIER lets users set the target_value via node0_mem_{used,free}_bp parameters. It doesn't guard zero value case, though. As a result, users can trigger division by zero. Fix the issue by returning an error when the user tries to start DAMON with zero node0_mem_{used,free}_bp parameter values. DAMON_SAMPLE_MTIER is just a sample module, but the consequence is quite bad. Also the zero node0_mem_free_bp parameter might look like a reasonable setup to some users. Hence, the issue might really happen in the real world. One reliable way to reproduce the issue is like below: # cd /sys/module/damon_sample_mtier/parameters # echo 4096 > node0_start_addr # echo 8192 > node0_end_addr # echo 8192 > node1_start_addr # echo 81920 > node1_end_addr # echo 0 > node0_mem_free_bp # echo Y > enabled # dmesg -w [...] [18792.235916] Oops: divide error: 0000 [#1] SMP NOPTI [...] [18792.242787] RIP: 0010:damos_quota_score+0x6f/0x480 [...] This issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74644", "url": "https://ubuntu.com/security/CVE-2026-74644", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/ops-common: putback folios on invalid migrate nid damon_pa_migrate() and damos_va_migrate() isolate folios into a local list and then call damon_migrate_pages(). When target_nid is invalid (including the scheme default NUMA_NO_NODE / -1), damon_migrate_pages() returns early without putting the folios back to the LRU. Callers then discard the list head while those folios remain isolated with an extra reference taken by folio_isolate_lru(). The pages stay off the LRU for as long as the mapping exists (anon active+inactive counts drop while RSS does not), and the leftover references can pin the pages after the mapping is gone. Put the folios back on the invalid-nid path so ignored migration requests still return them to the LRU.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74646", "url": "https://ubuntu.com/security/CVE-2026-74646", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke When an invoke is interrupted by a signal, wait_for_completion_interruptible() returns -ERESTARTSYS and fastrpc_internal_invoke() moves every buffer from fl->mmaps onto cctx->invoke_interrupted_mmaps. This list_del()/list_add_tail() walk runs without holding fl->lock, the lock that serialises fl->mmaps in fastrpc_req_mmap() and fastrpc_req_munmap() everywhere else. Take fl->lock around the move, matching every other fl->mmaps accessor.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74647", "url": "https://ubuntu.com/security/CVE-2026-74647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Remove buffer from list prior to unmap operation fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74648", "url": "https://ubuntu.com/security/CVE-2026-74648", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: validate monitor transmit frame lengths rtw_cfg80211_monitor_if_xmit_entry() removes the radiotap header and then reads the 802.11 frame control field without checking that a base 802.11 header remains. The data path also pulls the calculated 802.11, QoS and SNAP header span before confirming that the skb contains it. A truncated frame can therefore cause out-of-bounds reads or leave insufficient data for the Ethernet address writes. Reject frames that do not contain the base 802.11 header and data frames that do not contain their complete calculated header span.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74649", "url": "https://ubuntu.com/security/CVE-2026-74649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix missing shared-key auth challenge length check The WEP shared-key authentication handler uses the challenge-text element's attacker-controlled length without checking it against the fixed 128-byte chg_txt buffer. In OnAuthClient() the length from rtw_get_ie() - up to 255 - is used to perform memcpy() into the 128-byte pmlmeinfo->chg_txt, so a malicious AP sending a malformed WLAN_EID_CHALLENGE element can overflow/underfill chg_txt by up to 127 bytes. It is reachable over the air, before association, during shared-key authentication. In the case of an overflow, the driver can write out of bounds. In the case of an underfill, the driver can echo stale buffer memory. The challenge text is defined to be exactly 128 octets, which is already provided as the WLAN_AUTH_CHALLENGE_LEN define; require the element to be exactly that length before use.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74650", "url": "https://ubuntu.com/security/CVE-2026-74650", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in WMM_param_handler() WMM_param_handler() copies a fixed-size WMM parameter element out of a received information element without checking that the element is long enough, causing an out-of-bounds read for a short WMM IE. The handler reads sizeof(struct WMM_para_element) (18) bytes at pIE->data + 6, so it requires pIE->length to be at least 24 (WLAN_WMM_LEN), but it never validates the length. Two of its three callers reach it after matching only the WMM OUI: OnAssocRsp() in rtw_mlme_ext.c matches a 6-byte OUI, and join_cmd_hdl() matches a 4-byte OUI, before calling the handler. A vendor-specific IE carrying the WMM OUI but a length between 6 and 23, placed in an association response or in the IE blob handed to join_cmd_hdl(), passes the OUI check and then makes the memcmp() and memcpy() at pIE->data + 6 read past the end of the element. OnAssocRsp() parses a frame received from the AP, so this is reachable from a remote peer. The remaining caller in rtw_wlan_util.c already guards the handler with \"pIE->length == WLAN_WMM_LEN\". Move the equivalent check into the handler itself so every caller is covered; the sibling IE handlers in the same parsing loop (HT_caps_handler(), HT_info_handler(), ERP_IE_handler()) likewise bound their accesses by pIE->length.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74651", "url": "https://ubuntu.com/security/CVE-2026-74651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_get_wpa_ie() rtw_get_wpa_ie() reads bytes at fixed offsets into a vendor-specific information element without checking that the element is long enough, causing an out-of-bounds read for a short trailing IE. The function locates a vendor-specific IE (EID 221) with rtw_get_ie() and then compares a 4-byte OUI+type at pbuf + 2 and reads a 2-byte version word at pbuf + 6. Those accesses require the IE body to be at least 6 bytes, but rtw_get_ie() only guarantees that the element fits within the buffer; it does not enforce a minimum body length. A vendor-specific IE whose length byte is 0 to 5, placed at the end of the buffer, therefore makes these reads run past the end of the IE and past the end of the buffer itself. The buffer holds information elements taken from received management frames and from the IE blob passed to rtw_cfg80211_set_wpa_ie(), which is kmemdup'd to its exact length, so the read can run off the end of the allocation. The sibling helpers rtw_get_sec_ie(), rtw_get_wapi_ie() and rtw_get_wps_ie() in this file already reject too-short vendor-specific IEs before their OUI memcmp(); rtw_get_wpa_ie() was never brought in line with them, and needs a minimum of 6 rather than 4 bytes because of the version word. Add the missing length check.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74652", "url": "https://ubuntu.com/security/CVE-2026-74652", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: amba-pl011: cancel RS485 hrtimers after freeing IRQ The RS485 trigger hrtimers are embedded in the devm-managed port and can fire after it is freed. The IRQ handler can arm a timer, so free the IRQ first and then cancel both timers. Complete the RS485 stop without arming a timer, and cancel the timers in remove() for the suspend-then-unbind path, where shutdown is not called. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74653", "url": "https://ubuntu.com/security/CVE-2026-74653", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx The NXP LPC32xx UART (PORT_LPC3220) can latch an RX character-timeout interrupt while the RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT (0x0c) but LSR.DR is clear. A character timeout is only cleared by reading RHR, but serial8250_rx_chars() reads RHR only when LSR.DR is set, so nothing ever clears the condition. The interrupt is level-triggered and re-fires immediately, so on a single-core ARM926 the resulting interrupt storm livelocks the CPU. It is reproducible when userspace repeatedly opens the front-panel port (ttyS1): serial8250_do_set_termios() re-enables interrupts on unlock and the handler then spins forever with iir=0xcc lsr=0x60 ier=0x05, tripping the soft-lockup detector in serial8250_handle_irq_locked(). LPC32xx has no dedicated 8250 glue driver, it's driven by the generic 8250_of. Add a hardware specific handle_irq for PORT_LPC3220, wired up in of_platform_serial_setup() the same way fsl8250_handle_irq is installed. The handler follows dw8250_handle_irq(): on an RX timeout with an empty FIFO (LSR.DR and LSR.BI clear) it does one throwaway RHR read to clear the condition, then calls serial8250_handle_irq_locked(). No real received data is ever discarded, and it is a no-op on healthy UARTs which never report a timeout with DR clear. This is the same class of bug already worked around in other 8250 drivers; see commit 424d79183af0 (\"serial: 8250_dw: Avoid \"too much work\" from bogus rx timeout interrupt\") which reports the identical iir=0xcc/lsr=0x60. See also UART_RX_TIMEOUT_QUIRK in 8250_omap, and the note in 8250_bcm7271.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74654", "url": "https://ubuntu.com/security/CVE-2026-74654", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dma: Clear stale RX state on shutdown serial8250_release_dma() terminates RX DMA and releases the channel, but leaves rx_running set. If the port is closed while an RX transfer is active, the stale state remains while rxchan is NULL until the channel is requested again on the next open. The DesignWare BUSY workaround added by commit a7b9ce39fbe4 (\"serial: 8250_dw: Ensure BUSY is deasserted\") calls serial8250_rx_dma_flush() from the LCR write path during startup. This happens before serial8250_request_dma() obtains a new RX channel. On reopen, the stale rx_running state therefore makes the flush path pass a NULL channel to dmaengine_pause(), causing a kernel Oops. Clear rx_running after terminating RX DMA, matching the TX cleanup. Also make the flush helper return if the DMA object or RX channel is not available so startup and teardown paths cannot pass a NULL channel to the DMAengine API.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74655", "url": "https://ubuntu.com/security/CVE-2026-74655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom-geni: fix TX DMA buffer flush When transmit flushing a qcom-geni UART during an ongoing TX DMA, the UART gets stuck infinitely repeating corrupted TX DMA frames. The DMA-mode uart_ops does not provide a flush_buffer callback, so an in-flight transfer can complete after serial core has reset the transmit kfifo, underflowing its length and resubmitting page-sized transfers indefinitely. Add one that stops the transfer and clears tx_remaining and tx_queued. The stop path was also broken: it unmapped the buffer while the serial engine could still read it, and never reset the TX DMA state machine. Cancel the main sequencer command first, then reset the state machine and wait for it before unmapping. Drop the early return so a pending mapping is also cleaned up when the main command is inactive. The bug can be triggered from userspace with a large write immediately followed by TCOFLUSH. A following tcdrain will hang forever. The bug was reproduced and this fix was validated on Arduino Uno Q (QRB2210) using /dev/ttyHS1.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74656", "url": "https://ubuntu.com/security/CVE-2026-74656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fix use-after-free in fib_nhc_update_mtu() fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but RTNL does not serialize this walk with PMTU exception updates. The walk uses rcu_dereference_protected() with a constant true condition without holding fnhe_lock. The following interleaving can therefore occur: CPU 0 CPU 1 fib_nhc_update_mtu() update_or_create_fnhe() load fnhe spin_lock_bh(&fnhe_lock) fnhe_remove_oldest() unlink fnhe kfree_rcu(fnhe, rcu) access fnhe after grace period KASAN reported: BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410 Read of size 8 at addr ffff888107d49000 by task poc/90 Call Trace: fib_nhc_update_mtu+0x3df/0x410 fib_sync_mtu+0x7a/0xd0 fib_netdev_event+0x229/0x3f0 netif_set_mtu_ext+0x33a/0x570 dev_set_mtu+0x88/0x120 The same walk updates fnhe_pmtu and fnhe_mtu_locked. These fields form a pair and other writers serialize them with fnhe_lock. RCU alone prevents reclamation, but would still allow concurrent writers to leave a mixed pair. Walk the table under RCU and acquire fnhe_lock only while updating each exception. RCU keeps the current entry alive while the short critical section serializes its paired PMTU fields. This avoids holding the global lock while scanning all 2048 buckets for every nexthop.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74657", "url": "https://ubuntu.com/security/CVE-2026-74657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops fib_nlmsg_size() still estimates nexthop space as if every gateway is encoded as an IPv4 RTA_GATEWAY attribute. IPv4 routes can also carry an IPv6 gateway, which fib_nexthop_info() dumps as RTA_VIA. As a result, route notifications can allocate an skb that is too small. fib_dump_info() then fails with -EMSGSIZE and rtmsg_fib() hits the WARN_ON() that marks such failures as a fib_nlmsg_size() bug. With panic_on_warn set, this becomes a kernel panic. Mirror the actual nexthop dump layout in fib_nlmsg_size(): account for IPv6 nexthop gateways dumped as RTA_VIA, for the no-header rtnexthop layout used inside RTA_MULTIPATH, and for RTA_FLOW only when it is actually present.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74658", "url": "https://ubuntu.com/security/CVE-2026-74658", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent robust futex exit race some more A robust futex unlock stores 0 over the whole futex value - wiping FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot notification: the protocol relies on its recipient to either acquire the futex (and eventually unlock while aware of the remaining contention) or re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed before it can do either, the kernel must jump in and wake the next task down the line. This is a known complication of the futex protocol with a previous partial fix in commit ca16d5bee598 (\"futex: Prevent robust futex exit race\"). Unfortunately, that fix is insufficient. If a third task re-acquired the futex through the uncontended fast path in the meantime, the notification is lost: robust exit processing sees that it is owned by another task and does nothing, while the new owner sees no FUTEX_WAITERS when it unlocks and wakes nobody. The remaining waiters sleep forever behind a free futex: A owns the futex, B and C sleep in FUTEX_WAIT uval == A | FUTEX_WAITERS A robust unlock: store 0, FUTEX_WAKE(1) wakes B uval == 0 D fast path acquire: cmpxchg(0 -> D) uval == D, no FUTEX_WAITERS B killed before acting on the wakeup B exit walk, pending op: owner D != B -> no action D unlock: no FUTEX_WAITERS -> no wake C sleeps forever This is clearly a shortcoming in the implementation, which fails to keep the FUTEX_WAITERS bit consistent. Work around this by augmenting the robust list exit processing to also perform the extra wakeup if the futex word is owned by another thread but FUTEX_WAITERS is not set. This does not fix the problem of a non-contended take over/release and free sequence, which has been discussed for years and has been addressed by commit 3ca9595d9fb6 (\"futex: Add support for unlocking robust futexes\") and subsequent changes, but failed to take the problem described above into account. A more complete solution which is based on the in kernel unlock of contended robust futexes has been discussed in the context of this change and should show up in mainline sooner than later. [ tglx: Amend change log slightly and fixup coding style ]", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74659", "url": "https://ubuntu.com/security/CVE-2026-74659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: mrp: fix uninitialised bytes on the wire br_mrp_alloc_test_skb() builds MRP test frames on an skb from dev_alloc_skb(), which does not clear the linear data area. On the MRA ring-role branch the sub-option TLV header is appended with \tsub_tlv = skb_put(skb, sizeof(*sub_tlv)); \tsub_tlv->type = BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR; so sub_tlv->length is never written, and the two trailing alignment bytes are appended with a bare skb_put() that does not clear them either. The neighbouring oui and sub_opt regions are explicitly zeroed, so three uninitialised bytes are left in every MRA MRP_Test frame that goes out. Put the sub-option TLV header and the alignment padding in a single skb_put_zero(), which clears both. The AUTO_MGR sub-TLV carries no payload, so the zeroed length field is already the value it should have.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74660", "url": "https://ubuntu.com/security/CVE-2026-74660", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebt_nflog: pin the NFLOG backend nf_log_unregister() runs after the per-net teardown so its final RCU grace period also drains readers that obtained the logger from a per-net binding. However, ebt_nflog passes an explicit ULOG log type to nf_log_packet() without holding a reference on the selected logger module, unlike the xt_NFLOG and nft_log frontends. An ebtables nflog rule can therefore remain callable while nfnetlink_log is unloaded. The resulting interleaving is: CPU 0 CPU 1 nfnetlink_log_fini() unregister_pernet_subsys() kfree(nfnl_log_pernet(net)) ebt_nflog_tg() nf_log_packet() nfulnl_log_packet() instance_lookup_get_rcu() The global ULOG logger is still registered at this point, so CPU 1 dereferences the per-net state after CPU 0 has freed it. KASAN reported: BUG: KASAN: slab-use-after-free in instance_lookup_get_rcu Read of size 8 at addr ff110001052e6210 by task poc/92 Call Trace: instance_lookup_get_rcu+0x1ce/0x1f0 [nfnetlink_log] nfulnl_log_packet+0x248/0x2fb0 [nfnetlink_log] nf_log_packet+0x204/0x300 ebt_nflog_tg+0x351/0x550 ebt_do_table+0xedf/0x22b0 Allocated by task 90: __kmalloc_noprof+0x186/0x470 ops_init+0x6d/0x420 register_pernet_operations+0x2f6/0x670 register_pernet_subsys+0x23/0x40 Freed by task 93: kfree+0x131/0x3c0 ops_undo_list+0x3e3/0x700 unregister_pernet_operations+0x232/0x490 unregister_pernet_subsys+0x1c/0x30 nfnetlink_log_fini+0x34/0x450 [nfnetlink_log] Acquire the ULOG logger module reference when an ebt_nflog rule is validated and release it when the rule is destroyed. Request the NFLOG backend for legacy callers when needed, matching xt_NFLOG. This prevents module teardown until all ebt_nflog rules have stopped using the logger.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74661", "url": "https://ubuntu.com/security/CVE-2026-74661", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: fix netdev use-after-free in beacon worker mac802154_beacon_worker() reads local->beacon_req under RCU and derives the sub-interface from the request, but then drops the RCU read lock and continues to use both sdata and the embedded wpan_dev. mac802154_stop_beacons_locked() cancels only pending beacon work, clears local->beacon_req and frees the request. A beacon worker that is already running can therefore continue after interface teardown and dereference the freed netdev private area. The scan worker already pins the netdev before leaving RCU. Apply the same lifetime rule to the beacon worker: take a netdev reference while the request is still protected by RCU, and release it on all paths that continue after the reference is acquired.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74662", "url": "https://ubuntu.com/security/CVE-2026-74662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: publish queues before arming timer inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74663", "url": "https://ubuntu.com/security/CVE-2026-74663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: reject overly deep qdisc hierarchies Deep qdisc hierarchies can lead to excessive recursion in qdisc tree walkers and exhaust the kernel stack. The existing loop check does not cover the create-and-graft path, so a hierarchy can still be extended by creating a new child qdisc below an already deep parent. Store the hierarchy depth in struct Qdisc and update it when qdiscs are grafted. Reject new child qdiscs once the parent is already at the maximum allowed depth.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74664", "url": "https://ubuntu.com/security/CVE-2026-74664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: reallocate update replies for mismatched IDs ovs_flow_cmd_new() preallocates the optional reply skb before it takes ovs_mutex and before it knows which existing flow will be updated. That is normally fine because the skb is sized from the request flow identifier. That identifier also becomes the inserted flow's identifier. For updates, however, a request with a UFID may miss the UFID lookup and then fall back to the flow key lookup. That lookup can legitimately find an existing key-identified flow. UFIDs are optional and the flow key is the primary identifier. For echoed replies, ovs_flow_cmd_fill_info() writes the matched flow's identifier, not the request identifier used for the preallocation. A short request UFID can therefore leave too little room for the key identifier. The fill can then fail with -EMSGSIZE and hit the BUG_ON(error < 0) in the update path. Once the update target has been resolved, reallocate the reply skb if the matched flow needs a larger reply than the request identifier allowed. Do this before replacing the actions so the request can still fail cleanly if the rare extra allocation fails.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74665", "url": "https://ubuntu.com/security/CVE-2026-74665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix skb length accounting after generic XDP frag adjustment Generic XDP exposes non-linear skb fragments through an xdp_buff. If an XDP program adjusts the fragment area, bpf_prog_run_generic_xdp() copies xdp_frags_size back to skb->data_len but leaves skb->len containing the old fragment contribution. After a fragment shrink, this makes skb_headlen() larger than the actual linear area. In the reproduced UDP receive path, __skb_datagram_iter() copied 1024 bytes past the actual linear tail to userspace, starting at struct skb_shared_info. The copied bytes included the affected skb's nr_frags, xdp_frags_size and a kernel pointer from skb_shinfo(skb)->frags[0]. Real packet data was displaced by the same amount and truncated at the end. Subtract the old data_len before replacing it and add the new data_len afterwards, keeping skb->len and skb->data_len synchronized. A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by 1024 bytes from its fragment area. Before the fix, all 10 runs produced corrupted payloads. After the fix, all 10 runs matched the expected payload exactly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74666", "url": "https://ubuntu.com/security/CVE-2026-74666", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: synchronize pressure clearing with ring reconfiguration packet_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. Move the existing receive hook assignment into the same sk_receive_queue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix. Serialize packet_recvmsg() pressure clearing with the same queue lock only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear and the socket has moved away from tpacket_rcv, packet_set_ring() has already detached the socket and waited for synchronize_net(), so no new packet input can set the flag again. packet_poll() already holds sk_receive_queue.lock, so it uses the new unlocked helper directly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74667", "url": "https://ubuntu.com/security/CVE-2026-74667", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: reset the MAC header on the packet-socket transmit path packet_parse_headers() resets the MAC header only for a SOCK_RAW frame whose socket did not bind a protocol. A protocol-bound SOCK_RAW socket, any SOCK_DGRAM frame, and the legacy SOCK_PACKET path therefore leave skb->mac_header unset here. For frames sent via __dev_queue_xmit() this is harmless: it resets the MAC header unconditionally. But the packet-socket PACKET_QDISC_BYPASS path uses dev_direct_xmit(), which does not, so the frame reaches ndo_start_xmit() with the MAC header unset. A driver that reads eth_hdr(skb) on transmit then dereferences skb->head + (u16)~0, an out-of-bounds access ~64 KiB past the head -- the same class fixed for one consumer in commit f5089008f90c (\"macsec: do not read an unset MAC header in macsec_encrypt()\"). packet_parse_headers() runs only on the transmit path, where skb->data points at the start of the L2 header for every packet-socket type regardless of its length: SOCK_RAW and SOCK_PACKET carry a user-supplied header and SOCK_DGRAM has one built by dev_hard_header(). Reset the MAC header unconditionally, mirroring __dev_queue_xmit(), so the frame is anchored on the bypass path too. Found by 0sec (https://0sec.ai) using automated source analysis; verified against source and matched to the macsec KASAN report in f5089008f90c. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74668", "url": "https://ubuntu.com/security/CVE-2026-74668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in TX_RING send path tpacket_snd() reads dev->hard_header_len independently for skb allocation and header construction in tpacket_fill_skb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hard_header_len negative. Snapshot hard_header_len once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacket_fill_skb(). The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74582", "url": "https://ubuntu.com/security/CVE-2026-74582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in non-ring send paths packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-74669", "url": "https://ubuntu.com/security/CVE-2026-74669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear IPv4 options after rebasing tunnel ICMP errors ip_vs_in_icmp() rebases an skb from the outer ICMP packet to the quoted original request before passing it to icmp_send(). However, IPCB(skb)->opt still describes the outer IPv4 header. A timestamp option in the outer header can therefore leave an offset that points into the quoted transport header after the rebase. __ip_options_echo() treats a byte at that stale location as the option length and copies it into the fixed-size option storage on the __icmp_send() stack, causing a stack out-of-bounds write. Clear the stale option metadata after resetting the network header. Keep the remaining control block fields, including the ingress interface used by the ICMP response path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74670", "url": "https://ubuntu.com/security/CVE-2026-74670", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: stop estimator after disabled calc phase IPVS estimator kthread 0 starts with zeroed chain and tick limits until its initial calculation phase completes. If network namespace teardown clears ipvs->enable during that phase, ip_vs_est_calc_phase() can return without installing positive limits. The kthread can then continue into its main loop and drain est_temp_list with zero chain_max, tick_max and est_max_count values. Each enqueue consumes one available tick row, but est_count never reaches the zero est_max_count value. After all rows are consumed, the row lookup returns IPVS_EST_NTICKS and ip_vs_enqueue_estimator() writes past the ticks and tick_len arrays. Exit kthread 0 after the calculation phase if the kthread is stopping or IPVS has been disabled. That keeps temporary estimators from being drained after the limits failed to initialize. Estimator kthreads can now self-exit before teardown or reload stops kd->task. Keep an extra task reference after creation and release it with kthread_stop_put(), so kd->task remains valid until the stop paths consume that reference.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74671", "url": "https://ubuntu.com/security/CVE-2026-74671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix out-of-bounds read in xattr_verify() The digest-length check in xattr_verify() mixes int and size_t: \tif (xattr_len - sizeof(xattr_value->type) - hash_start >= \t\t\tiint->ima_hash->length) sizeof() yields size_t, so the usual arithmetic conversions promote the whole left-hand side to unsigned 64-bit before the subtraction runs. For a truncated xattr this underflows instead of going negative: a 1-byte IMA_XATTR_DIGEST_NG xattr (xattr_len == 1, hash_start == 1) turns \"1 - 1 - 1\" into SIZE_MAX, which is trivially >= ima_hash->length. The check then passes and the following memcmp() reads iint->ima_hash->length bytes starting past the end of the buffer vfs_getxattr_alloc() allocated for it. Nothing upstream clamps xattr_len back into a safe range first: ima_get_hash_algo() only special-cases xattr_len < 2 to pick a default algorithm, and evm_verifyxattr() returns INTEGRITY_UNKNOWN rather than failing when no HMAC key is loaded, so a truncated security.ima value reaches the length check as-is. Rewrite the comparison so every operand stays a signed int and no implicit conversion to size_t can occur.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74672", "url": "https://ubuntu.com/security/CVE-2026-74672", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF Patch series \"mm: fix UAF caused by race between ptdump and vmap pgtable freeing\", v6. Kernel page table walkers fall into two broad categories - those ranges where no exclusion is required via walk_kernel_page_table_range_lockless() and those where exclusion is required via walk_kernel_page_table_range() or walk_page_range_debug(). The former category is used only by arm64 arch code operating on ranges it both wholly owns and does not concurrently write. The latter category consists of kernel page table walkers operating on ranges that are wholly owned (but which need exclusion against concurrent writers). The lock used for exclusion is the mmap lock, and for kernel ranges this is the mmap lock on init_mm. ptdump is a special case being both the only user of walk_page_range_debug(), and the only case in which it walks ranges it does not own. This presents a problem, as page tables may be freed under ptdump. And indeed there is a use-after-free bug in the kernel as a result, which this series addresses. vmap promotes page tables to huge leaf entries where possible, freeing the lower page table when it does. It does this with no meaningful locks held against concurrent ptdump walks. As a result, use-after-free can currently occur. This series addresses the issue by having the vmap huge promotion logic acquire the mmap read lock while both setting the huge page table entry and freeing the prior leaf page table. The ptdump code already acquires the mmap write lock, so by doing so we ensure that the ptdump walker only ever observes either the huge page table entry or the existing page table entry, and nothing is freed underneath it. A mitigation for this issue was already applied for arm64 in commit fa93b45fd397 (\"arm64: Enable vmalloc-huge with ptdump\"), which this series has to deal with carefully. This mitigation resolves the issue by acquiring the mmap read lock on init_mm on vmap page table free if a ptdump is in progress. However the fix in this series would cause a deadlock if we were to simply apply it for arm64 without also reverting the change. This is because vmap may acquire the read lock before ptdump attempts to acquire the write lock, which then gets queued, and rwsem starvation rules mean that the (unacknowledged) nested mmap read lock in the arm64 code would also block, meaning the original read lock is never released and thus deadlock. This series works around this by #ifndef CONFIG_ARM64'ing the mmap read lock in vmap logic, then partially reverting commit fa93b45fd397 (\"arm64: Enable vmalloc-huge with ptdump\"), keeping the enablement of huge vmap support, and removing the ifdeffery with the partial revert patch. There are related issues that are also addressed in this series: * x86 page attribute logic, specifically Change Page Attributes (CPA), implements a feature whereby huge ranges can be collapsed into huge leaf entries. This can similarly cause a UAF when done in parallel with a ptdump walk, so similarly acquire the init_mm mmap lock to avoid this. * The CPA logic allows concurrent page table manipulation and CPA collapse, meaning the former risks accessing a page table the latter frees. Fix this by acquiring mmap write lock on init_mm across the whole CPA collapse operation and read lock on the page table manipulation. * x86 and arm64 permit walks of non-kernel mm's (both allowing efi mm walks, and in x86's case arbitrary mm's), so we ensure kernel mappings remain stable by locking the init_mm as well as the mm being walked. The ordering of patches is established for both strict dependencies (the arm64 partial revert in particular has to be done after the vmap changes) and logical ones (the non-kernel mm fix only makes sense once the vmap/CPA fixes are in place). This patch (of 3): Currently there is a nasty ra ---truncated---", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74673", "url": "https://ubuntu.com/security/CVE-2026-74673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: evdev - fix information leak in evdev_pass_values() In evdev_pass_values(), the input_event structure is allocated on the kernel stack and populated field-by-field. However, it is never fully initialized. On architectures where struct input_event contains explicit or implicit padding (such as the 32-bit __pad field on SPARC64), these padding bytes are left uninitialized. When this event structure is subsequently passed to the client buffer and later copied to userspace, the uninitialized padding bytes leak kernel stack memory, potentially exposing sensitive information. Similar issues exist in __evdev_queue_syn_dropped and __pass_event. Fix this by explicitly zeroing the entire event structure with memset() before populating its fields. This ensures all padding bytes are cleared before the data crosses the security boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74675", "url": "https://ubuntu.com/security/CVE-2026-74675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: stabilize tty reference in kbd_keycode with tty_port_tty_get kbd_keycode() reads vc->port.tty without acquiring a tty reference, racing against con_shutdown() which clears port.tty under a different lock. Use tty_port_tty_get()/tty_kref_put() to hold a proper reference for the duration the tty pointer is needed.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74676", "url": "https://ubuntu.com/security/CVE-2026-74676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: add permission check for KDSKBMETA ioctl KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all other keyboard setter ioctls in vt_k_ioctl() enforce, allowing a process to change meta mode on a non-controlling console without authorization.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74677", "url": "https://ubuntu.com/security/CVE-2026-74677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: ipheth: fix carrier_work UAF on disconnect ipheth_sndbulk_callback() re-arms the carrier-check work on any non-zero URB status: \telse \t\tschedule_delayed_work(&dev->carrier_work, 0); Nothing ties that to the interface being up, so the work can be armed again after ipheth_close() has already drained it, and stay armed until the netdev whose private area embeds it is freed. On unplug with a TX URB in flight, ipheth_disconnect() drains the work through unregister_netdev() -> ipheth_close() -> cancel_delayed_work_sync() and only then calls ipheth_kill_urbs(). usb_kill_urb() completes the in-flight TX URB with -ENOENT, so ipheth_sndbulk_callback() runs after the drain and re-arms carrier_work. The same completion also re-arms the work if the interface is only brought down while a TX URB is in flight, and ipheth_carrier_check_work() then keeps re-queueing itself once a second. unregister_netdev() does not call ipheth_close() for an already-down interface, so nothing drains it on the later unplug either. In both cases free_netdev() frees the netdev while carrier_work is still pending, and ipheth_carrier_check_work() dereferences freed memory. Tie the work to the interface state instead of chasing the completion: disable it in ipheth_close() and enable it in ipheth_open(), so a schedule_delayed_work() from the URB completion is a no-op whenever the interface is not up. disable_delayed_work_sync() also waits for a running instance, so it fully replaces the cancel_delayed_work_sync() it takes the place of. The work starts out disabled in ipheth_probe() so the enable/disable counts balance from the first open. Reproduced under KASAN on linux-next (next-20260731) with dummy_hcd and raw-gadget standing in for the device, driving the second path above (the interface is already down, so unregister_netdev() does not call ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in __run_timers(), freed by ipheth_disconnect() and re-armed from ipheth_sndbulk_callback() via queue_delayed_work_on(). The same trigger on a kernel differing only by this patch reports 0 of 15, and the carrier check still functions across open/close cycles. The reproducer needs an attached USB device that stops draining bulk OUT, plus a link down and unplug, driven as root. It is not a privilege boundary crossing and no exploit primitive was developed. Found by 0sec (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74678", "url": "https://ubuntu.com/security/CVE-2026-74678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: ax88179_178a: fix skb leak in ax88179_tx_fixup() When the interface has NETIF_F_SG enabled and skb_linearize() fails in ax88179_tx_fixup(), the function returns NULL without freeing the skb. usbnet_start_xmit() treats a NULL return from tx_fixup() as a drop (info->flags does not set FLAG_MULTI_PACKET for this driver), jumping to the \"drop\" label where it does `if (skb) dev_kfree_skb_any(skb)`. Because tx_fixup() returned NULL, the local skb variable in usbnet_start_xmit() is NULL, so the original skb is never freed — a memory leak on every TX frame whose linearization fails (i.e. under memory pressure). Free the skb before returning, matching the error handling already used for the pskb_expand_head() failure path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74679", "url": "https://ubuntu.com/security/CVE-2026-74679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Use unsigned int for ndp_index The variable ndp_index is declared as a signed integer, but it stores the return value of get_ncm(), which is unsigned. A malicious host can supply a large offset that overflows the signed ndp_index, making it negative. Because ndp_index is compared against unsigned bounds, this negative value bypasses sanity checks and leads to an out-of-bounds read when calculating the address of the NDP block (ntb_ptr + ndp_index). Fix this by changing ndp_index to unsigned int to ensure consistent unsigned comparisons throughout the function.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74680", "url": "https://ubuntu.com/security/CVE-2026-74680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm() If cxacru_cm() encounters an error while submitting or waiting for snd_urb, it aborts and returns the error without killing the already submitted rcv_urb. This leaves the rcv_urb active. When this happens during initialization (e.g., in cxacru_atm_start()), the driver may ignore the error and proceed to call cxacru_poll_status(), which invokes cxacru_cm() again. Attempting to submit the still-active rcv_urb triggers a warning in usb_submit_urb(): cxacru 1-1:1.0: send of cm 0x84 failed (-104) ATM dev 0: cxacru_atm_start: CHIP_ADSL_LINE_START returned -104 ------------[ cut here ]------------ URB ffff88812658d200 submitted while active WARNING: drivers/usb/core/urb.c:379 at usb_submit_urb+0x79/0x18b0 drivers/usb/core/urb.c:379 ... Call Trace: cxacru_cm+0x21a/0xf10 drivers/usb/atm/cxacru.c:631 cxacru_cm_get_array drivers/usb/atm/cxacru.c:722 [inline] cxacru_poll_status+0x178/0x1110 drivers/usb/atm/cxacru.c:828 cxacru_atm_start+0x185/0x360 drivers/usb/atm/cxacru.c:814 usbatm_atm_init+0x144/0x3a0 drivers/usb/atm/usbatm.c:927 usbatm_usb_probe+0x15cb/0x1db0 drivers/usb/atm/usbatm.c:1178 cxacru_usb_probe+0x17f/0x220 drivers/usb/atm/cxacru.c:1370 ... To fix this, ensure that rcv_urb is properly killed if cxacru_cm() aborts early. We can safely call usb_kill_urb() on rcv_urb in the error path, as it is safe to call even if the URB is not active (e.g., if it failed to submit in the first place, or if it already completed).", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74681", "url": "https://ubuntu.com/security/CVE-2026-74681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: misc: usbio: check ibuf_len against rxbuf_len in bulk msg ibuf_len is the bulk IN (receive) buffer size, but the EMSGSIZE check in usbio_bulk_msg() compares it against txbuf_len — the bulk OUT endpoint size. Both are taken independently from different endpoints in usbio_probe(), so the check is wrong when they differ. Use rxbuf_len for the IN direction. This matches the buffer that actually holds the response data.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74682", "url": "https://ubuntu.com/security/CVE-2026-74682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write on Type II inbound URBs data_ep_set_params() sizes each URB transfer buffer before it adds the Format Type II transfer delimiter: \tu->packets = urb_packs; \tu->buffer_size = maxsize * u->packets; \tif (fmt->fmt_type == UAC_FORMAT_TYPE_II) \t\tu->packets++; /* for transfer delimiter */ \tu->urb = usb_alloc_urb(u->packets, GFP_KERNEL); buffer_size is computed from the pre-increment packet count and never recomputed, so for a Type II endpoint the buffer is one packet short of the packet count the URB is built with. prepare_inbound_urb() then lays out one iso frame per packet and never consults buffer_size: \toffs = 0; \tfor (i = 0; i < urb_ctx->packets; i++) { \t\turb->iso_frame_desc[i].offset = offs; \t\turb->iso_frame_desc[i].length = ep->curpacksize; \t\toffs += ep->curpacksize; \t} \turb->transfer_buffer_length = offs; \turb->number_of_packets = urb_ctx->packets; The last descriptor therefore points one packet past the end of the transfer buffer, where the host controller writes device data on every inbound transfer. prepare_silent_urb() and prepare_playback_urb() bound their fill loops by ctx->buffer_size, so only capture is affected. fmt_type comes from the device's audio streaming descriptors, so any device advertising a Type II capture format hits this once userspace sets hw_params on the stream. KASAN on 7.2.0-rc5 (arm64) with a dummy_hcd/raw-gadget device, one report per inbound transfer: BUG: KASAN: slab-out-of-bounds in dummy_timer Write of size 64 at addr ffff0000186171c0 by task cons02/166 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 166: usb_alloc_coherent snd_usb_endpoint_set_params The buggy address is located 0 bytes to the right of allocated 64-byte region [ffff000018617180, ffff0000186171c0) Compute buffer_size after the delimiter packet has been accounted for, and bound the fill loop by buffer_size, as prepare_silent_urb() already does on the outbound side. This grows every Type II URB allocation by one maxsize packet. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74683", "url": "https://ubuntu.com/security/CVE-2026-74683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: evdev - sanitize event type index when fetching event masks The user-supplied event type index passed to EVIOCGMASK / EVIOCSMASK ioctls is used to index the static counts array in evdev_get_mask_cnt() and client evmasks array in evdev_get_mask(). While the event type is architecturally bounded by EV_CNT, speculative execution may mispredict bounds checks and perform out-of-bounds loads. Sanitize the event type index in evdev_get_mask_cnt() branchlessly using array_index_mask_nospec(). This clamps the index to 0 for safe array access and forces the returned count to 0 speculatively when the index is out of bounds. We do not need additional array_index_nospec() calls in evdev_get_mask() because evdev_get_mask_cnt() speculatively forces the count (and resulting xfer_size) to 0 for out-of-bounds types, preventing any speculative memory access to client evmasks array.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74684", "url": "https://ubuntu.com/security/CVE-2026-74684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tap: set skb->dev before parsing virtio net header in tap_get_user_xdp() The commit 4f61f133f354 (\"net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null\") fixed a crash in tap_get_user() by assigning skb->dev before calling tun_vnet_hdr_to_skb(). This is required because virtio_net_hdr_to_skb() may invoke dev_parse_header_protocol(), which dereferences skb->dev. Without the assignment, a NULL pointer dereference can occur. However, tap_get_user_xdp() still parses the virtio-net header before assigning skb->dev. When the vhost TX path passes an XDP buffer containing a GSO virtio-net header but the protocol is set to zero on purpose, tun_vnet_hdr_to_skb() can reach dev_parse_header_protocol() while skb->dev is still NULL, resulting in a crash. Fix this by looking up the tap device and assigning skb->dev before calling tun_vnet_hdr_to_skb(), matching the ordering already used in tap_get_user(). Preserve the existing RCU read-side critical section across dev_queue_xmit().", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74685", "url": "https://ubuntu.com/security/CVE-2026-74685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (ltc4282) Clamp negative current limits When a negative value is passed to ltc4282_write_curr(), the signed long val is cast directly to u64: drivers/hwmon/ltc4282.c:ltc4282_write_curr() { /* need to pass it in millivolt */ u32 in = DIV_ROUND_CLOSEST_ULL((u64)val * st->rsense, DECA * MICRO); ... } This cast converts negative inputs into large positive values. The subsequent division result overflows the u32 in variable, truncating to a pseudo-random positive value. When this is passed to ltc4282_write_voltage_byte(), it is clamped to the maximum limit instead of zero. Clamp val to 0 and to the maximum supported upper limit before the cast and assign the result to a 64-bit temporary variable before the division to avoid the underflow and an also possible overflow.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74687", "url": "https://ubuntu.com/security/CVE-2026-74687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: at91sam9_wdt: prevent timer rearm during teardown at91_ping() rearms the watchdog timer from its callback. timer_delete() neither waits for a running callback nor prevents it from rearming the timer, so probe failure or driver removal can leave the timer accessing the devm-allocated at91wdt after it has been freed. Use timer_shutdown_sync() on both teardown paths. It waits for a running callback and rejects any attempt by the callback to rearm the timer.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74688", "url": "https://ubuntu.com/security/CVE-2026-74688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: clear control chunk transport if it is being removed sctp_make_heartbeat_ack() caches the destination transport in chunk->transport without taking a reference. When src_out_of_asoc_ok is enabled, the HEARTBEAT ACK may remain queued on control_chunk_list instead of being transmitted immediately. If the peer transport is removed while the chunk is still queued, sctp_assoc_rm_peer() drops the transport and schedules it for RCU freeing, but only clears cached transport pointers in out_chunk_list. The queued control chunk therefore retains a dangling transport pointer. Once an ASCONF_ACK clears the suppression and the queued control chunk is transmitted, SCTP dereferences the stale transport pointer, leading to a use-after-free. Fix this by also clearing chunk->transport for queued control chunks in control_chunk_list when removing the transport.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74689", "url": "https://ubuntu.com/security/CVE-2026-74689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/atm: fix slab-out-of-bounds read in vcc_setsockopt() vcc_setsockopt() contained an ineffective optlen check: if (__SO_LEVEL_MATCH(optname, level) && optlen != __SO_SIZE(optname)) return -EINVAL; If __SO_LEVEL_MATCH(optname, level) evaluated to false (e.g. if the caller passed a mismatched level), the length check optlen != __SO_SIZE(optname) was short-circuited and bypassed. Execution then fell through to switch(optname), calling copy_from_sockptr() assuming optval contained sufficient space. Furthermore, even if level matched, a cgroup BPF setsockopt filter could shrink optlen after entry. Because copy_from_sockptr() on kernel pointers uses memcpy(), this leads to a KASAN slab-out-of-bounds read when optlen is smaller than the expected structure size. Fix this by using copy_safe_from_sockptr(), which unconditionally validates that optlen is at least the expected size before copying. Also change the local 'value' variable type from 'unsigned long' to 'int' so that SO_SETCLP matches its sizeof(int) ABI encoding on 64-bit systems.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74690", "url": "https://ubuntu.com/security/CVE-2026-74690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ism: Fix UAF of sba and ieq during ism_dev_exit() A ism interrupt handler can be active in parallel with ism_dev_exit(), accessing freed data structures. No new interrupts will be generated after unregister_ieq(). Drain ongoing interrupt handlers by free_irq(), before freeing ism data structures.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74691", "url": "https://ubuntu.com/security/CVE-2026-74691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Tear down DMA paths before stopping the rings tbnet_tear_down() stops both rings and frees their frame buffers before calling tb_xdomain_disable_paths(). tb_ring_stop() zeroes the ring's descriptor base and tbnet_free_buffers() unmaps and frees the pages the frames sit in, so by the time __tb_path_deactivate_hop() polls the hop's 'pending' bit, anything still in flight has nowhere to drain to. The teardown sequence has been in this order since the driver was added. The setup path has not: commit ff7cd07f3064 (\"net: thunderbolt: Enable DMA paths only after rings are enabled\") moved the path enable to the end of tbnet_connected_work() and documented why: \t/* Both logins successful so enable the rings, high-speed DMA \t * paths and start the network device queue. \t * \t * Note we enable the DMA paths last to make sure we have primed \t * the Rx ring before any incoming packets are allowed to \t * arrive. \t */ Teardown was never updated to match, so the rings and the paths now come down in the same order they go up instead of in reverse. On an ASMedia ASM4242 host router the 'pending' bit then never clears: every teardown burns the full 500 ms timeout and __tb_path_deactivate_hop() returns -ETIMEDOUT. Raising the timeout to 5 s does not help, so the hop is not slow to drain, it never drains at all. The failure is invisible above the thunderbolt core. __tb_path_deactivate_hops() is void and only calls tb_port_warn(); tb_path_deactivate(), tb_tunnel_deactivate() and __tb_disconnect_xdomain_paths() are void as well, and tb_disconnect_xdomain_paths() ends in an unconditional \"return 0\". So tb_xdomain_disable_paths() reports success and the netdev_warn() below it never fires. Repeated teardowns eventually take the XDomain control channel down, after which the peer node is gone and only a power cycle brings the controller back. Deactivating the paths first fixes it. Measured with kretprobes on a stock v6.17 tree with no other patches applied, on a link that was up and had just carried traffic: before: __tb_path_deactivate_hop() returns 0 for the first hop, then -ETIMEDOUT for the second 500335 us later after: 0 for both, 525 us apart Alternating the two orderings ABBA over three load levels, four teardowns per arm: every teardown failed before the change (21 of 21 that ran), none failed after (0 of 24). The before arms ran short because the link died partway through. The same split shows up when the interface is enslaved to a bond instead of just brought down, which is how I ran into this in the first place. Throughput and latency after the change are unchanged. Hosts whose routers drain the hop despite the stale descriptor base see no functional difference, since the paths end up deactivated either way.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74692", "url": "https://ubuntu.com/security/CVE-2026-74692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix TOCTOU race between smc_listen_out() and listener close smc_listen_out() reads lsmc->sk.sk_state without the listener lock, then acquires lock_sock_nested() only after the check passes. This opens a window where smc_close_active() can transition the listener to SMC_CLOSED, call smc_close_cleanup_listen() to drain the accept queue, and release the lock, all between the lockless read and the delayed lock acquisition: smc_listen_work (smc_hs_wq) smc_close_active() ------------------------------- ------------------------- release_sock(child) if (sk_state == SMC_LISTEN) TRUE lock_sock(listener) sk_state = SMC_CLOSED smc_close_cleanup_listen() release_sock(listener) flush_work(tcp_listen_work) lock_sock_nested(listener) smc_accept_enqueue(listener, child) /* child enqueued on dead listener */ smc_close_active() flushes only tcp_listen_work. Work items already dispatched onto smc_hs_wq for the CLC handshake continue running unguarded. smc_accept_enqueue() takes a sock_hold() on the child that is never released, so the child smc_sock, its clcsock, and the reference all leak. A remote peer that opens TCP connections while the server calls close() can exhaust kernel memory. Move lock_sock_nested() to before the sk_state check so that the test and the enqueue are atomic under the listener lock.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74693", "url": "https://ubuntu.com/security/CVE-2026-74693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: prestera: validate firmware header length prestera_fw_hdr_parse() reads the firmware header before checking that the firmware image contains that header. Reject images shorter than struct prestera_fw_header before decoding the magic and version fields.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74694", "url": "https://ubuntu.com/security/CVE-2026-74694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: fix heap OOB read in NCSI_CMD_SEND_CMD payload length ncsi_send_cmd_nl() takes the number of bytes to copy from the attacker-controlled ncsi_pkt_hdr.length field of the in-band packet header, while the source buffer is the NCSI_ATTR_DATA netlink attribute whose readable size is nla_len() - sizeof(ncsi_pkt_hdr). The two length sources are never cross-checked: only nla_len() >= sizeof(struct ncsi_pkt_hdr) is enforced. With hdr->length set larger than the attribute payload (up to 65535 against at most 2032 readable bytes), ncsi_cmd_handler_oem() copies past the end of the netlink attribute buffer with unsafe_memcpy(), leaking up to ~64KB of kernel heap memory into the transmitted NCSI command packet. The destination skb is sized by the declared payload, so the write side does not overflow - this is a pure OOB read / information leak, reachable with CAP_NET_ADMIN on systems with a registered NCSI device (e.g. OpenBMC on Aspeed BMC SoCs, where NET_NCSI=y is standard). Reject commands whose declared payload extends past the end of the data attribute. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74695", "url": "https://ubuntu.com/security/CVE-2026-74695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_flow_table: drop existing skb dst before skb_dst_set_noref() Incoming skbs passing through netfilter flowtable offload hooks (or XFRM offload path) might already carry a ref-counted dst_entry assigned during earlier RX or routing steps. Calling skb_dst_set_noref() when skb already holds a ref-counted dst overwrites skb->_skb_refdst, leaking the previous dst_entry reference count and triggering a DEBUG_NET_WARN_ON_ONCE assertion in skb_dst_check_unset(): WARNING: at skb_dst_check_unset include/linux/skbuff.h:1170 WARNING: at skb_dst_set_noref include/linux/skbuff.h:1234 WARNING: at nf_flow_offload_ip_hook+0xf6c/0x2b60 net/netfilter/nf_flow_table_ip.c:864 Drop any existing dst_entry reference with skb_dst_drop(skb) before setting the non-referenced flowtable destination.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74696", "url": "https://ubuntu.com/security/CVE-2026-74696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TFO max_qlen accounting across reuseport migration A listener's TCP_FASTOPEN max_qlen stops being accurate and lets through far more pending Fast Open requests than it was configured for. This only shows up with SO_REUSEPORT listener migration, where closing a listener hands its still-pending TFO children over to a surviving one. fastopenq.qlen is charged in tcp_fastopen_create_child() when the child is created and uncharged in reqsk_fastopen_remove() when the handshake completes. The uncharge follows rsk_listener of the request the child points at, and inet_reqsk_clone() has repointed the child at a new request owned by the new listener, so the ++ and the -- land on two different sockets. The new listener's qlen drifts negative and its limit no longer binds. Charge the new listener during migration, like reqsk_queue_migrated() already does for queue->young and queue->qlen.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74697", "url": "https://ubuntu.com/security/CVE-2026-74697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Disable EOP for TPA on all chips to prevent data corruption EOP (End of frame padding) on the AGG ring may cause overlapping of zero padding at the end of one segment with the next segment's data. If Relaxed Ordering (RO) is enabled, the zero padding may overwrite valid data in the next segment and corrupt the data. Older chips (P5 and older) do not automatically disable RO when EOP is enabled. On some ARM systems, data corruption was reported on 57508 (P5) chips with RO enabled. Always disable EOP on all chips on the AGG rings when TPA is enabled to fix the data corruption.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74698", "url": "https://ubuntu.com/security/CVE-2026-74698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix BQL reset on SQ re-activation mlx5e_queue_start() deactivates and re-activates all channels but closes only the queue being restarted. mlx5e_activate_txqsq() then unconditionally calls netdev_tx_reset_queue(), zeroing the BQL counters of channels that kept their in-flight TX WQEs. The next completion then over-charges and trips the BUG_ON() in dql_completed(): kernel BUG at lib/dynamic_queue_limits.c:99! RIP: 0010:dql_completed+0x23d/0x280 Call Trace: mlx5e_poll_tx_cq+0x668/0xa60 mlx5e_napi_poll+0x5b/0x7b0 net_rx_action+0x15a/0x580 Reset BQL only when the SQ has no bytes in flight (sq->cc == sq->pc). In the case that reset is skipped, the outstanding WQEs will eventually complete and rebalance the dql. The dql->limit is carried across the reset.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74700", "url": "https://ubuntu.com/security/CVE-2026-74700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers Another challenge with unlocked filters. There is a short window in tc_new_tfilter where a tcf_proto can be found and briefly referenced by a totally unrelated, unlocked classifier's request and cause a race. Feng created a poc which created this race with two threads, one creating a u32 filter and other a flower filter in the same chain/prio: 1. Both threads enter tc_new_tfilter, both find the chain empty, both drop filter_chain_lock 2. u32 finishes tcf_proto_create(\"u32\") first, calls tcf_chain_tp_insert_unique() -> inserts u32_tp into the chain 3. flower finishes tcf_proto_create(\"flower\") later, calls tcf_chain_tp_insert_unique() -> tcf_chain_tp_find() now sees u32_tp already there, takes a reference on it, destroys flower's own tp_new and returns u32_tp to the caller. Flower then hits the kind mismatch check (because it requested for kind \"flower\" but tp->ops->kind is \"u32\") and goes through the errout path which calls tcf_proto_put() on u32_tp. If the u32 thread has already gone through its own errout (its change() call failed on the PoC's empty options) and dropped its create and insert refs, flower's put is the last one and drops u32_tp's refcnt to zero. At this point tp->ops->destroy() runs in a context that never took rtnl_lock. When that happens, it might cause a UAF like the following (illustrated by the PoC): [ +0.000710] BUG: KASAN: slab-use-after-free in u32_init (net/sched/cls_u32.c:393) [ +0.000281] Read of size 8 at addr ffff888120022f00 by task poc_feng_xue/524 Call Trace: u32_init (net/sched/cls_u32.c:393) tc_new_tfilter (net/sched/cls_api.c:2378) Allocated by task 526: u32_init (net/sched/cls_u32.c:378) tc_new_tfilter (net/sched/cls_api.c:2378) Freed by task 522: kfree u32_destroy (net/sched/cls_u32.c:662) tcf_proto_destroy (net/sched/cls_api.c:446) tcf_proto_put (net/sched/cls_api.c:459) tc_new_tfilter (net/sched/cls_api.c:2459) Fix this by having tcf_proto_destroy() take rtnl_lock around tp->ops->destroy() for locked classifiers whenever rtnl is not held. To explain why I used a temp variable \"not_lockless\" I'd like to point to a semi-related note on rtnl_held vs TCF_PROTO_OPS_DOIT_UNLOCKED (adding here for future cleanup if deemed necessary): The rtnl_held parameter and the TCF_PROTO_OPS_DOIT_UNLOCKED flag are redundant sources of truth for whether rtnl_lock is held. Among the nine classifier destroy(..rtnl_held..) callbacks, only flower consults the rtnl_held parameter which it propagates to tc_setup_cb_destroy() and tc_setup_cb_call(). The other eight (u32, flow, bpf, cgroup, route, basic, fw, mall) ignore it entirely;-> those that call tc_setup_cb_destroy() (u32, bpf, mall) hardcode true always instead of forwarding the parameter. A future cleanup should remove the rtnl_held parameter from the destroy callback signature entirely and have callers rely solely on their knowledge whether they are running in an unlocked context.", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74701", "url": "https://ubuntu.com/security/CVE-2026-74701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/openvswitch: check Ethernet header length in key_extract() When a packet arrives on an ARPHRD_NONE device (e.g. TUN), ovs_flow_key_extract() trusts the user-provided skb->protocol field: if it is ETH_P_TEB, the packet is classified as MAC_PROTO_ETHERNET and key_extract() is called without ensuring the skb has ETH_HLEN (14) bytes of linear data. key_extract() unconditionally pulls 2 * ETH_ALEN bytes for MAC addresses and parse_ethertype() pulls 2 more, either of which triggers a kernel BUG in __skb_pull() when the linear area is too small. kernel BUG at include/linux/skbuff.h:2848! RIP: 0010:key_extract+0xa7e/0xd90 net/openvswitch/flow.c:933 ovs_flow_key_extract+0x419/0xa70 ovs_vport_receive+0x222/0x390 netdev_frame_hook+0x3e0/0x630 tun_get_user+0x2d0c/0x38e0 Fixed by calling check_header() in key_extract() before accessing the Ethernet header.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74702", "url": "https://ubuntu.com/security/CVE-2026-74702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: reject feature changes after endpoint vhost_scsi_setup_vq_cmds() runs from VHOST_SCSI_SET_ENDPOINT and allocates each command's protection scatterlist array (prot_sgl) according to the acknowledged VIRTIO_SCSI_F_T10_PI bit. The command pools are not rebuilt when VHOST_SET_FEATURES changes that bit later. Although virtio feature bits must not change after feature negotiation, vhost_scsi_set_features() currently accepts such a request after the endpoint is active and updates acked_features. Enabling T10-PI after endpoint setup therefore leaves prot_sgl NULL while the I/O path follows the new feature bit. For a 129-page protection payload, vhost_scsi_mapal() passes the missing first chunk to sg_alloc_table_chained(): sg_alloc_table_chained(table, 129, first_chunk=NULL, nents_first_chunk=inline_sg_cnt) sg_pool_index() then hits: BUG_ON(nents > SG_CHUNK_SIZE); /* 129 > 128 */ The kernel reported the following call trace and register state: Call Trace: ? __sg_alloc_table+0x1d8/0x250 ? __pfx_vhost_run_work_list+0x10/0x10 [vhost] sg_alloc_table_chained+0x59/0xf0 ? __pfx_sg_pool_alloc+0x10/0x10 ? vhost_scsi_calc_sgls.constprop.0+0x43/0x60 [vhost_scsi] vhost_scsi_handle_vq+0xf02/0x1700 [vhost_scsi] ? __pfx_vhost_scsi_handle_vq+0x10/0x10 [vhost_scsi] vhost_scsi_handle_kick+0x37/0x50 [vhost_scsi] vhost_run_work_list+0x8e/0xd0 [vhost] vhost_task_fn+0xe1/0x210 ret_from_fork+0x348/0x540 RIP: 0010:0x4 CR2 = 0x4 RSP: 0018:ffffc90000dbf940 EFLAGS: 00010202 RAX: ffffffff82396810 RBX: ffff88811dc28b80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000081 VHOST_F_LOG_ALL is a vhost-specific runtime feature and remains the only exception. Reject changes to any feature other than VHOST_F_LOG_ALL while the endpoint is active. This preserves the existing runtime log toggle while preventing feature-dependent command resources and data-path state from becoming inconsistent. Userspace must clear the endpoint before changing any other negotiated feature and set the endpoint up again afterward.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74703", "url": "https://ubuntu.com/security/CVE-2026-74703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: Validate T10 PI scatterlist counts When T10 PI is negotiated, vhost-scsi splits protection bytes from the data iterator before mapping the request scatterlists. A malformed request can claim protection bytes that cover or exceed the full payload length. The former leaves no data bytes to map, while the latter underflows exp_data_len before advancing the iterator. Both cases can let a zero data SGL count reach sg_alloc_table_chained(), which triggers BUG_ON(!nents). Reject protection lengths that cover or exceed the payload before subtracting prot_bytes and advancing the iterator. Also propagate negative errors from the protection SGL calculation before calling the allocator, matching the data SGL path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74704", "url": "https://ubuntu.com/security/CVE-2026-74704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: drop WARN_ON(1) for malformed packets in ACK filter The sch_cake ACK filter parses packets to find the TCP header and filter duplicated ACKs if the flow is backlogged. The parsing code contains a WARN_ON(1) which can be triggered by a malformed IP header in certain cases. Depending on the system configuration, this leads either to either spamming dmesg with warnings, or a panic if panic_on_warn is set. The code already correctly skips the offending packet in the branch that triggers the warning, so the WARN_ON itself doesn't really serve any purpose. So just drop it altogether to avoid the inconvenient side effects.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74705", "url": "https://ubuntu.com/security/CVE-2026-74705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: fix potential use-after-free in tunnel segmentation __skb_udp_tunnel_segment() gets the UDP header before ensuring the tunnel header is in the skb head. If the pull reallocates skb->head, the saved UDP header pointer is no longer valid. Get the UDP header after the pull to avoid a potential use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74707", "url": "https://ubuntu.com/security/CVE-2026-74707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: validate metadata when processing requests The zero-copy path validates TX metadata while obtaining the descriptor context, then reads it again later when preparing the hardware request. User space can change the metadata between those operations and bypass the original validation. Validate the metadata in xsk_tx_metadata_request() and use the resulting flags snapshot for every feature check. Read request fields once so all zero-copy drivers process only values observed after successful validation.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74708", "url": "https://ubuntu.com/security/CVE-2026-74708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: validate launch-time metadata size Launch-time metadata extends beyond the first 16 bytes of struct xsk_tx_metadata. Reject the request when the registered metadata area does not contain the complete field. Snapshot the validated flags for the generic transmit path and use that snapshot for request and completion processing, avoiding inconsistent decisions if user space changes the flags concurrently. Note that only xsk_skb_metadata is properly using the flags, __xsk_buff_get_metadata ignores them. Next commits address that.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74709", "url": "https://ubuntu.com/security/CVE-2026-74709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: clear metadata pointer when no timestamp is requested User space can change metadata flags after request processing. Rereading them during completion can therefore make the kernel write a timestamp that was not requested when the packet was submitted. Clear the metadata pointer during request processing unless timestamp completion is requested. Completion handling can then use the pointer itself instead of rereading the flags. On the mlx5 multi-packet WQE path metadata is evaluated per batch: xsk_tx_metadata_request() runs only for the descriptor that starts a session, just like the checksum offload that is applied once through the shared WQE. Only that descriptor's pointer is reset, so completion handling can record a timestamp for the other descriptors of the session regardless of their own XDP_TXMD_FLAGS_TIMESTAMP bit. The write stays inside the metadata area; the single-WQE, other zero-copy, and generic paths reset the pointer per descriptor and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74710", "url": "https://ubuntu.com/security/CVE-2026-74710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: require at least 16 bytes of TX metadata AF_XDP accepts a TX metadata length as small as eight bytes, but every supported request needs the flags plus at least one eight-byte request field. Such short metadata also lets the kernel read beyond the registered area. Require 16 bytes rather than sizeof(struct xsk_tx_metadata) to preserve compatibility with applications that do not use launch-time metadata.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74711", "url": "https://ubuntu.com/security/CVE-2026-74711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus) Fix type confusion in notification logic Sashiko reports: At the start of the loop in pmbus_notify(), the code unconditionally casts every attribute to a struct sensor_device_attribute: drivers/hwmon/pmbus/pmbus_core.c:pmbus_notify() { for (i = 0; i < data->num_attributes; i++) { struct device_attribute *da = to_dev_attr(data->group.attrs[i]); struct sensor_device_attribute *attr = to_sensor_dev_attr(da); int index = attr->index; ... } However, data->group.attrs can contain other types like struct pmbus_samples_reg or struct pmbus_sensor, which only embed a base struct device_attribute. If da is a struct pmbus_samples_reg, dev_attr is the last member. Casting it to struct sensor_device_attribute and reading the index field appears to access memory past the end of the allocation, which might trigger a slab-out-of-bounds read. Additionally, if da is a struct pmbus_sensor, casting it causes the index field to overlap with the page, phase, and reg fields. Could this produce a garbage mask on little-endian systems that spuriously matches the target reg, page, and flags during an alert? Fix the problem by using struct sensor_device_attr in struct pmbus_sensor and struct pmbus_label. Since those attributes never trigger a notification, set the value of attr->index to -1 for them. Use this value to distinguish from boolean attributes which _can_ trigger a notification and use the index field to encode mask, page, and register values.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74712", "url": "https://ubuntu.com/security/CVE-2026-74712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix buffer length in create_direct_keys() We have seen in our CI the following KASAN message: BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core] Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764 [...] [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core] [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core] [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa] [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa] [...] The buggy address is located 4128 bytes inside of allocated 4384-byte region [0000000176794000, 0000000176795120) So in essence we read 16 bytes beyond 4384-byte allocation. create_direct_keys calculates the pointer and length for in and out buffers. The size calculation for in includes the entire structure size (out + in + mtt[]) but the pointer passed to cmd_exec points only to the 'in' field, skipping the 'out' field. This causes mlx5_copy_to_msg() to read beyond the allocated buffer by sizeof(out) bytes when copying command data. Properly calculate the input size to match the pointer and allocation size.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74714", "url": "https://ubuntu.com/security/CVE-2026-74714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch() reqsk_queue_hash_req() publishes a TCP_NEW_SYN_RECV request_sock onto the ehash chain, drops the bucket lock, and only afterwards sets rsk_refcnt to 3. Lockless readers such as __inet_lookup_established() handle this with refcount_inc_not_zero(), but bpf_iter_tcp_established_batch() uses plain sock_hold() while holding the bucket lock, on the assumption that the lock guarantees sk_refcnt > 0. That assumption does not hold for request_sock: CPU 0 CPU 1 ----- ----- tcp_conn_request() reqsk_queue_hash_req() inet_ehash_insert(req) spin_lock(bucket) __sk_nulls_add_node_rcu(req) // rsk_refcnt == 0 spin_unlock(bucket) bpf_iter_tcp_established_batch() spin_lock(bucket) sock_hold(req) <-- addition on 0 spin_unlock(bucket) refcount_set(&req->rsk_refcnt, 3) // clobbers saturated value which surfaces as: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x48/0x90, CPU#1 Call Trace: bpf_iter_tcp_established_batch+0x14e/0x170 bpf_iter_tcp_batch+0x53/0x200 bpf_iter_tcp_seq_next+0x27/0x70 bpf_seq_read+0x107/0x410 vfs_read+0xb9/0x380 The iterator's stolen reference is lost when the publishing CPU's refcount_set() overwrites the count, leaving the socket one reference short. When the last legitimate owner drops its reference the reqsk is freed while still reachable, leading to use-after-free. This reproduces in seconds with tcp_syncookies=0, a handful of threads doing connect()/close() to a local listener while others read an iter/tcp link in a tight loop. Use refcount_inc_not_zero() and skip the socket on failure. A skipped socket is still part of the bucket, so keep counting it in expected. The reallocations are sized from expected, and a request sock whose refcount gets published while the lock is held across the last realloc must already have room. A skipped socket is counted in expected but never batched, so end_sk can be short of expected on a batch that is actually complete. Decide completeness by whether the walk left any socket behind instead. The WARN after the locked realloc checks the same, replacing an end_sk == expected check that could not hold on that path since commit cdec67a489d4 (\"bpf: tcp: Make sure iter->batch always contains a full bucket snapshot\"). If every matching socket in a bucket is mid-init (refcount 0), end_sk stays 0. Advance to the next bucket rather than returning a batch entry that was never filled this round.", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74717", "url": "https://ubuntu.com/security/CVE-2026-74717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fw_tracer, return NULL on create error Tracer creation can fail by returning either NULL or ERR_PTR. The return value is stored without a check on the device, and users treat ERR_PTR and NULL the same way. This also causes a crash in the core dump logic, which is missing the ERR_PTR check and ends up dereferencing it, as shown in the trace below. Switch tracer creation to return NULL on failure only, so callers only need a single NULL check. Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: mlx5_ib ib_uverbs ib_core ipv6 mlx5_core CPU: 1 UID: 0 PID: 12 Comm: kworker/u16:0 Not tainted 6.19.7 #1 PREEMPT(none) Workqueue: mlx5_health0001:01:00.0 mlx5_fw_reporter_err_work [mlx5_core] pstate: a3400009 (NzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] lr : mlx5_fw_tracer_trigger_core_dump_general+0x40/0xe0 [mlx5_core] sp : ffff800081cf3c40 x29: ffff800081cf3c90 x28: 0000000000000000 x27: 0000000000000000 x26: ffff000080018828 x25: 0000000000000000 x24: ffff000080304a05 x23: ffff800081cf3d80 x22: ffff0000847e01a0 x21: 0000000000000000 x20: ffff0000847e01a0 x19: ffffffffffffffa1 x18: ffff80008310bbf0 x17: ffff800080119650 x16: ffff80008010df54 x15: ffff80008010d4ac x14: ffff800079c202e4 x13: ffff80008002fe60 x12: ffff800080119650 x11: ffff80008010df54 x10: ffff80008010d4ac x9 : ffff800079c203d8 x8 : ffff800081cf3c88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000008 x3 : 0000000000000030 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 00000000c5c4000e Call trace: mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] (P) mlx5_fw_reporter_dump+0x30/0x2e0 [mlx5_core] devlink_health_do_dump+0x9c/0x160 devlink_health_report+0x1c0/0x288 mlx5_fw_reporter_err_work+0xac/0xc0 [mlx5_core] process_one_work+0x15c/0x3d8 worker_thread+0x18c/0x320 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: b9400000 5ac00800 7a401800 540003ca (3940a260) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x000000,00078031,75fce5a1,35fffe67 Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception ]---", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74718", "url": "https://ubuntu.com/security/CVE-2026-74718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: fix net namespace reference leak in reload devlink_nl_reload_doit() calls devlink_netns_get(), which returns a net with a held reference. When the requested namespace differs from the current one and the reload action is not DRIVER_REINIT, the function returns -EOPNOTSUPP without releasing the reference. Add the missing put_net() on this error path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74583", "url": "https://ubuntu.com/security/CVE-2026-74583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_route: fix fastmap use-after-free on filter The route4 classifier maintains a 16-slot fastmap cache that stores raw struct route4_filter pointers indexed by (id, iif). The reader (route4_classify) populates this cache via route4_set_fastmap() for every classified packet that hits a filter. The writer (route4_delete, route4_change) clears the cache via route4_reset_fastmap() before RCU-deferred kfree of the filter. This creates a UAF race: 1. Reader walks the RCU-protected bucket chain, finds filter f 2. Writer unlinks f, calls route4_reset_fastmap(), then tcf_queue_work() 3. Reader calls route4_set_fastmap() and writes f into the cache *after* the writer's reset, caching a pointer about to be freed 4. After the RCU grace period, kfree(f) executes 5. Next classified packet on the same (id, iif) tuple hits the stale fastmap entry and reads f->res from freed memory Reproduced with an mdelay(100) accelerator in route4_set_fastmap() and a concurrent add/delete stress test (provided by both zdi and Santosh). Both triggered KASAN slab-use-after-free reports in the route4 fastmap paths. Fix: Introduce a per-filter boolean dying flag to suppress stale fastmap republishing by in-flight readers.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-74719", "url": "https://ubuntu.com/security/CVE-2026-74719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler() The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in smc_llc_event_handler() stores an incoming qentry into the local LLC flow without first checking whether a qentry is already pending. If a malicious or buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is active and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message. The sibling SMC_LLC_DELETE_LINK branch already has the correct !flow->qentry guard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a duplicate message when qentry is already occupied falls through to break and is freed by the kfree(qentry) at the out: label, rather than silently leaking the existing allocation. The response direction (smc_llc_rx_response()) is unaffected: it already guards with flow->qentry at the equivalent site and drops duplicate responses correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74720", "url": "https://ubuntu.com/security/CVE-2026-74720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve pointer state for commuted arithmetic When scalar += pointer is handled in adjust_ptr_min_max_vals(), the destination register inherits the pointer state from the source pointer. Copying only selected fields is fragile because pointer provenance is tracked by several bpf_reg_state fields. Use the caller's temporary offset register to preserve the scalar operand while replacing the destination with the full pointer state. This preserves the frame number for PTR_TO_STACK registers and keeps parent identity fields consistent.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74722", "url": "https://ubuntu.com/security/CVE-2026-74722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leak in btrfs_do_encoded_write() Local fuzzing of 6.12.94 has found the following memory leak: Unreferenced object 0xffff888018050a80 (size 64): comm \"syz.0.17\", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 10 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 10 0a 05 18 80 88 ff ff 10 0a 05 18 80 88 ff ff ................ backtrace (crc a8a6fc29): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] extent_changeset_alloc fs/btrfs/extent_io.h:207 [inline] qgroup_reserve_data+0x1c5/0x7d0 fs/btrfs/qgroup.c:4305 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Unreferenced object 0xffff888018050a00 (size 64): comm \"syz.0.17\", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 ff 0f 00 00 00 00 00 00 ................ 90 0a 05 18 80 88 ff ff 90 0a 05 18 80 88 ff ff ................ backtrace (crc cb5c9580): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ulist_prealloc+0x9c/0x110 fs/btrfs/ulist.c:114 extent_changeset_prealloc fs/btrfs/extent_io.h:217 [inline] __set_extent_bit+0x16b/0x1a70 fs/btrfs/extent-io-tree.c:1086 set_record_extent_bits+0x50/0x90 fs/btrfs/extent-io-tree.c:1821 qgroup_reserve_data+0x274/0x7d0 fs/btrfs/qgroup.c:4312 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by freeing an extent changeset before returning from btrfs_do_encoded_write().", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74724", "url": "https://ubuntu.com/security/CVE-2026-74724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: avoid out-of-bounds write in ip_vs_nat_icmp Sashiko warns that local attacker can modify the packet while it is processed by IPVS. Some places read the IP ihl field multiple times which can cause out-of-bounds access. One such place is ip_vs_nat_icmp where we can write after the validated area. Fix it by providing ciph argument just like it is done for IPv6 and use ciph->len as offset to the embedded transport header. Modify some IPv4 header checks by reading the ihl field only once.", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74725", "url": "https://ubuntu.com/security/CVE-2026-74725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: enic: fix tx_hang_reset use-after-free on device removal enic_remove() cancels the reset and change_mtu_work items but does not cancel tx_hang_reset. A TX timeout that fires while the device is being removed can schedule enic_tx_hang_reset() so that it runs after free_netdev(), resulting in a use-after-free. cancel_work_sync() alone is not sufficient here: the still-live watchdog and notify paths can re-schedule these work items in the window between the cancel and unregister_netdev(). Use disable_work_sync(), which cancels the work and blocks any subsequent schedule_work() from requeuing it, and apply it to the reset and change_mtu_work items as well so the same requeue race is closed for all teardown work.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74726", "url": "https://ubuntu.com/security/CVE-2026-74726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor bond_alb_monitor() reads primary_is_promisc under RCU, then drops RCU and takes RTNL via rtnl_trylock() before undoing the promiscuity it set on the active slave. In that window the active slave can change under RTNL (RTM_DELLINK -> __bond_release_one() -> bond_alb_handle_active_change()), which already drops the promiscuity and clears primary_is_promisc. The monitor still acts on the stale decision: if the slave was removed with no failover, curr_active_slave is now NULL and the deref faults; if it failed over, the stale dev_set_promiscuity(-1) underflows the new slave's promiscuity counter and pins it in IFF_PROMISC. Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: b42 bond_alb_monitor RIP: 0010:bond_alb_monitor (drivers/net/bonding/bond_alb.c:1600) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) Kernel panic - not syncing: Fatal exception Re-check primary_is_promisc (and curr_active_slave) after taking RTNL so the monitor only undoes an increment it still owns. The other bonding monitors already re-read state under RTNL in their commit phase (bond_miimon_commit/bond_ab_arp_commit); bond_alb_monitor() was the only one acting on the pre-trylock decision.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74727", "url": "https://ubuntu.com/security/CVE-2026-74727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: skip rehash for peers already removed from by_id ovpn_nl_peer_set_doit() resolves the target peer via ovpn_peer_get_by_id() before taking ovpn->lock. In the window between the lookup (which only takes a refcount) and the subsequent spin_lock_bh(&ovpn->lock), a concurrent OVPN_CMD_PEER_DEL, keepalive expiry, or socket teardown can take ovpn->lock first, run ovpn_peer_remove() to unhash the peer from all four tables (by_id, by_vpn_addr4/6, by_transp_addr) and release the lock. set_doit then acquires ovpn->lock and calls ovpn_peer_hash_vpn_ip(), which re-inserts the now-removed peer back into the rehashing tables. The same race affects the float path: ovpn_peer_endpoints_update() holds only a refcount and acquires ovpn->lock very late (after async AEAD decrypt and a netlink notification), then rehashes the peer in the by_transp_addr table. The resurrected peer becomes reachable again from the RX lookup (ovpn_peer_get_by_transp_addr) and the TX VPN-IP lookup, even though userspace believes it is gone. Once the data-path refcount drops the peer is freed via call_rcu while the hash entries embedded in it remain linked, opening a UAF window. Bail out of the rehash when hash_entry_id is unhashed, mirroring the sentinel already used by ovpn_peer_remove() to detect the already-removed state. The check is safe under ovpn->lock, which serializes every mutation of hash_entry_id, and is a no-op for the add path because ovpn_peer_add_mp() inserts hash_entry_id before calling ovpn_peer_hash_vpn_ip().", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74728", "url": "https://ubuntu.com/security/CVE-2026-74728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: handle NULL b_addr in xfs_buf_free When xfs_buf_alloc_backing_mem() fails, xfs_buf_free() is called with bp->b_addr still NULL. The code falls through to the folio_put path which calls virt_to_folio(NULL), dereferencing an invalid address and causing a kernel crash. Call Trace: xfs_buf_free+0x25f/0x510 xfs_buf_alloc+0xc98/0x19b0 xfs_buf_find_insert+0x55/0x14d0 xfs_buf_get_map+0x122b/0x17c0 xfbtree_init_leaf_block+0x11c/0x4a0 xfbtree_init+0x1bb/0x460 xrep_rmap_setup_scan+0x100/0x1f0 xrep_rmapbt+0x41/0xc0 Fix this by skipping folio_put() when bp->b_addr is NULL.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74730", "url": "https://ubuntu.com/security/CVE-2026-74730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Pin the 'struct nfs_server' during a FREE_STATEID call Dan Aloni reports that he was able to hit a use-after-free bug if a FREE_STATEID operation gets delayed for whatever reason. Fix this by bumping the refcount of the 'struct nfs_server' object for the duration of the FREE_STATEID so it doesn't get cleaned up from underneath us while operations are still in flight.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74449", "url": "https://ubuntu.com/security/CVE-2026-74449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix divide-by-zero in calculate_mcache_setting on zero viewport If a plane reaches calculate_mcache_setting with a zero-area viewport, calculate_mcache_setting exits early with num_mcaches == 0 and mvmpg_width/height == 0. This will cause a divide-by-zero panic and can also cause an underflow on num_mcaches. Fix this by changing calculate_mcache_setting to bool and adding guards after each calculate_mcache_row_bytes call. If num_mcaches or mvmpg_width/height is zero, return a false. Callers will propagate the failure as a rejected mode, which prevents the panic. (cherry picked from commit 29c0f7c655f47bcbd575ff75e58480df6ec3c9da)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74450", "url": "https://ubuntu.com/security/CVE-2026-74450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix pptable use-after-free amdgpu_dpm_get_pp_table() returns a pointer to a driver-owned power table after dropping adev->pm.mutex. The sysfs path then copies from that pointer. A concurrent pp_table write can replace and free the allocation during the copy, causing a use-after-free. Change the DPM interface to copy into caller-provided storage while the mutex is held. Keep the size-only query for attribute discovery without exposing the driver-owned pointer. (cherry picked from commit f6eed7acfd30099ef7baeb6ba45bb59daad80631)", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74466", "url": "https://ubuntu.com/security/CVE-2026-74466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Close speculative mem read possibility The domain value is extracted from a given CCA or EP11 ioctl struct when a CPRB is about to be sent. Thus this is a user controlled value. Under some special conditions (custom device node used, administrative load) this value is used as an array index after bounds checking, but without speculation barrier. Add the missing array_index_nospec() call to prevent speculative execution where this domain value is used.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74483", "url": "https://ubuntu.com/security/CVE-2026-74483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't leak the user namespace when the mount fails bm_get_tree() takes a reference to the user namespace and hands it to get_tree_keyed() as the sget key. sget_fc() moves that reference into sb->s_fs_info and clears fc->s_fs_info, so from that point on the superblock owns it and bm_free() doesn't see it anymore. The superblock drops it in ->put_super(). But generic_shutdown_super() only calls ->put_super() from inside the if (sb->s_root) branch, so nothing releases it when bm_fill_super() fails: - The kzalloc_obj() failure leaves s_root NULL and the whole branch is skipped. - A simple_fill_super() failure in the file loop leaves s_root set, but s_op still points at simple_super_operations, which has no ->put_super(). bm_fill_super() installs s_ops only once simple_fill_super() returned success, and installing it earlier wouldn't help either because simple_fill_super() overwrites s_op. Either way vfs_get_super() calls deactivate_locked_super() and the reference is gone for good. binfmt_misc mounts are available in a user namespace and both the inode and the dentry cache are SLAB_ACCOUNT, so an unprivileged caller under a tight memory cgroup can fail simple_fill_super() on demand and leak one user namespace per attempt. Drop the reference in ->kill_sb() instead, which runs unconditionally, the same way nfsd and rpc_pipefs release their keyed s_fs_info. That also stops ->put_super() from clearing s_fs_info while the superblock is still on @fs_supers. generic_shutdown_super() leaves it there on purpose so that sget_fc() keeps finding it until kill_sb() has run, but a NULL s_fs_info makes test_keyed_super() miss it, so a concurrent mount for the same user namespace skips the grab_super() wait and creates a second superblock for a namespace that is still being torn down.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74496", "url": "https://ubuntu.com/security/CVE-2026-74496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Fix use-after-free in fou_create() fou_create() publishes struct fou through sk_user_data before adding the new FOU port to the per-netns list. If fou_add_to_port_list() fails, the error path frees fou while it is still reachable through sk_user_data. A concurrent receive can then dereference the freed object in fou_from_sock(). This ordering issue was previously noted in the linked discussion. The failure is reachable when local port 0 is requested. Each socket binds to a different ephemeral port, but fou_cfg_cmp() compares the requested port 0 and reports -EALREADY once an entry already exists. Release the tunnel socket before freeing fou so sk_user_data is cleared first, and defer reclamation with kfree_rcu() to protect concurrent RCU readers. This matches the lifetime handling in fou_release().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74517", "url": "https://ubuntu.com/security/CVE-2026-74517", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUs Cancel (and flush) the I/O APIC's delayed EOI handling work during the \"pre VM destroy\" phase, before vCPUs are destroyed, as processing the EOI broadcast will inject another IRQ if the line is asserted, i.e. will try to deliver an IRQ to the target vCPU(s). Canceling the work after vCPUs are destroyed leads to UAF if the delayed work is processed after vCPUs are destroyed. BUG: KASAN: slab-use-after-free in __kvm_irq_delivery_to_apic_fast+0x9bf/0xa20 arch/x86/kvm/lapic.c:1250 Read of size 8 at addr ffff8880499abea0 by task kworker/1:2/1218 CPU: 1 UID: 0 PID: 1218 Comm: kworker/1:2 Not tainted 7.1.0-rc7 #5 PREEMPT(lazy) Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: events kvm_ioapic_eoi_inject_work Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 __kvm_irq_delivery_to_apic_fast+0x9bf/0xa20 arch/x86/kvm/lapic.c:1250 __kvm_irq_delivery_to_apic+0xd8/0xbf0 arch/x86/kvm/lapic.c:1345 kvm_irq_delivery_to_apic arch/x86/kvm/lapic.h:129 ioapic_service+0x308/0x590 arch/x86/kvm/ioapic.c:492 kvm_ioapic_eoi_inject_work+0x13c/0x190 arch/x86/kvm/ioapic.c:532 process_one_work+0xa59/0x19a0 kernel/workqueue.c:3314 process_scheduled_works kernel/workqueue.c:3397 worker_thread+0x5eb/0xe50 kernel/workqueue.c:3478 kthread+0x370/0x450 kernel/kthread.c:436 ret_from_fork+0x72b/0xd30 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Note, the VM is unreachable once kvm_destroy_vm() starts, and scheduling new work via kvm_ioapic_send_eoi() can only be done via KVM_RUN, i.e. requires a live vCPU. Alternatively, KVM could simply destroy the I/O APIC during the \"pre\" phase of VM destruction, but that gets more than a bit sketchy as KVM expects the I/O APIC to exist if ioapic_in_kernel() is true, and nested virtualization in particular has a bad habit of touching VM-scope state during vCPU destruction. E.g. attempting to free the PIC during the pre phase would lead to a NULL pointer dereference in kvm_cpu_has_extint(), and it's not hard to imagine the I/O APIC having a similar flaw.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74521", "url": "https://ubuntu.com/security/CVE-2026-74521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use memcmp() to compare ClientGUIDs ClientGUID is a fixed-size binary value and can contain embedded NUL bytes. strncmp() stops comparing at the first NUL byte, so different ClientGUID values can incorrectly be treated as equal. Use memcmp() in SMB3 multichannel session binding and FSCTL_VALIDATE_NEGOTIATE_INFO to compare all SMB2_CLIENT_GUID_SIZE bytes.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74526", "url": "https://ubuntu.com/security/CVE-2026-74526", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix potential deadlock in mpi3mr_fault_uevent_emit mpi3mr_fault_uevent_emit() runs from the fault watchdog and reset paths where host I/O may already be blocked. GFP_KERNEL allocations here, both the local kzalloc_obj() and the ones inside kobject_uevent_env() itself, can trigger reclaim that waits on that blocked I/O and deadlock. Use memalloc_noio_save()/restore() to cover the whole call instead of just the local allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74528", "url": "https://ubuntu.com/security/CVE-2026-74528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold conn in hci_past_sync() callback Avoids giving freed pointers to hci_conn_valid(), which kmalloc may have reused. Hold refcount to avoid that.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74529", "url": "https://ubuntu.com/security/CVE-2026-74529", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold conn in hci_connect_pa_sync() callback There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74530", "url": "https://ubuntu.com/security/CVE-2026-74530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that. Handle NULL hcon, return 0 + do nothing to match the previous behavior.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74533", "url": "https://ubuntu.com/security/CVE-2026-74533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix race of kfree vs kref_get_unless_zero hci_conn::iso_data is accessed and modified without lock or RCU. This leads to a race [Task hdev->workqueue] \t[Task 2] iso_recv iso_conn_put(conn) conn = LOAD hcon->iso_data iso_conn_free(conn) iso_conn_hold_unless_zero(conn) hcon->iso_data = NULL kfree(conn) kref_get_unless_zero(&conn->ref) /* UAF */ and also to races in iso_conn_add() vs. iso_conn_free(). Fix by adding spinlock hci_conn::proto_lock and using it to guard hci_conn::iso_data.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74542", "url": "https://ubuntu.com/security/CVE-2026-74542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix folio_queue ENOMEM in writeback by adding a mempool Fix the handling of folio_queue allocation failure in writeback by adding a mempool and passing in gfp_t flags to the rolling buffer functions that allocate memory, using the mempool if gfp != GFP_KERNEL. This is then extended upwards and the gfp to be used for a request is stored in the netfs_io_request struct and is then used for both requests and subrequests, eliminating the sleeping loops there. The failure caused: folio != NULL WARNING: fs/netfs/write_issue.c:603 at netfs_writepages+0x883/0xa10 fs/netfs/write_issue.c:603, CPU#3: syz.0.17/5919", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74544", "url": "https://ubuntu.com/security/CVE-2026-74544", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: validate offshift to prevent shift-out-of-bounds u32_change() copies the user-provided tc_u32_sel.offshift (unsigned char, 0-255) into the kernel knode object without bounds validation. When a packet later hits u32_classify() with TC_U32_VAROFFSET set, it evaluates `ntohs(offmask & *data) >> offshift` where the left operand is a 16-bit value promoted to a 32-bit int. Any offshift >= 32 is undefined behavior per C11 6.5.7p3, triggerable by an unprivileged user via user/network namespaces. UBSAN: shift-out-of-bounds in net/sched/cls_u32.c:236:43 shift exponent 32 is too large for 32-bit type int Fix this by rejecting offshift >= 16 during filter creation in u32_change().", "cve_priority": "negligible", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74554", "url": "https://ubuntu.com/security/CVE-2026-74554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix out-of-bounds clear_bit in ath12k_mac_dp_peer_cleanup() ath12k_mac_dp_peer_cleanup() clears the ML peer ID slot on the free_ml_peer_id_map bitmap by indexing it with dp_peer->peer_id. That is wrong: dp_peer->peer_id for an MLO peer always carries the ATH12K_PEER_ML_ID_VALID bit (BIT(13)), so clear_bit() is invoked with index >= 0x2000, which is far outside the bitmap of ATH12K_MAX_MLO_PEERS (256) bits and corrupts memory adjacent to ah->free_ml_peer_id_map. The intended bitmap entry also never gets cleared, so subsequent ath12k_peer_ml_alloc() calls eventually run out of IDs. The ID without the VALID bit is what ath12k_peer_ml_alloc() returned and is stored in ahsta->ml_peer_id. Use that instead. While there, also reset ahsta->ml_peer_id to ATH12K_MLO_PEER_ID_INVALID so the bitmap and ahsta->ml_peer_id stay in sync. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3", "cve_priority": "low", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74558", "url": "https://ubuntu.com/security/CVE-2026-74558", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: reclaim invalid Tx descriptors in ZC batch path The zero-copy Tx batch parser stops when it encounters an invalid descriptor. If this happens after one or more continuation descriptors, the Tx consumer can be advanced past fragments that are neither submitted to the driver nor returned to userspace through the completion ring. A similar problem occurs when a packet exceeds xdp_zc_max_segs. The descriptors consumed up to the limit are released without completion, and the remaining continuation descriptors can subsequently be interpreted as the beginning of another packet. Parse Tx batches in packet units and distinguish descriptors belonging to complete valid packets from descriptors consumed while draining an invalid or oversized packet. Return the former to the driver and append the latter to the CQ address area so userspace can reclaim their UMEM frames. Treat a standalone invalid descriptor as a one-descriptor reclaim-only packet. Advancing the Tx-ring consumer releases the ring slot, but does not by itself return ownership of the referenced UMEM frame to userspace. Once draining starts, continue until the packet's end-of-packet descriptor is consumed. Preserve the drain state on the socket when EOP has not yet been supplied, so draining can continue during a later call. Leave incomplete but otherwise valid packets on the Tx ring. Shared-UMEM pools using multi-buffer Tx also need packet-framed parsing. Walk their Tx sockets one packet at a time, preserving the existing per-socket fairness scheme, instead of using the legacy one-descriptor fallback. Keep that fallback for shared pools that do not use multi-buffer Tx. Since the drain state is maintained per socket and both the singular and shared paths can resume an interrupted drain, changing the socket list from singular to shared requires no special bind-time transition. CQ entries are positional, and drivers may complete only part of the Tx work returned by xsk_tx_peek_release_desc_batch(). Therefore, reclaim-only entries cannot be published immediately when earlier driver-visible descriptors are still outstanding. Track the number of driver-visible CQ entries preceding the reclaim entries. Let xsk_tx_completed() publish partial hardware Tx completions, and publish the reclaim entries only after every earlier Tx descriptor has completed. Complete a reclaim-only batch immediately when there is no driver-visible work in front of it, and prevent another Tx batch from being appended while reclaim entries remain pending. Also cap batch processing by the size of the pool's temporary descriptor array, as Tx rings belonging to sockets sharing a UMEM may have different sizes. This ensures that every invalid Tx descriptor consumed by the ZC batch path is either submitted to the driver as part of a valid packet or returned to userspace without violating CQ completion ordering.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74561", "url": "https://ubuntu.com/security/CVE-2026-74561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: avoid unlocked f6i_list walk in nh_rt_cache_flush nh_rt_cache_flush() walks nh->f6i_list during an RTNL-serialized nexthop replace without holding nh->lock, racing the unlocked IPv6 route add/delete that mutate the list under nh->lock and free fib6_info entries (nh_rt_cache_flush() is inlined into rtm_new_nexthop()): BUG: KASAN: slab-use-after-free in nh_rt_cache_flush (net/ipv4/nexthop.c:2243) Read of size 8 at addr ffff888012953e18 by task exploit/146 nh_rt_cache_flush (net/ipv4/nexthop.c:2243) replace_nexthop (net/ipv4/nexthop.c:2610) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) Unlike the other f6i_list walks, this one bumps each route's sernum via fib6_update_sernum_upto_root(), which needs tb6_lock; taking nh->lock around it would invert the established tb6_lock -> nh->lock order and deadlock. As the only purpose is to invalidate cached dsts, bump the IPv6 sernum for the whole netns with rt_genid_bump_ipv6() instead, mirroring the rt_cache_flush() already done for IPv4 just above.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74562", "url": "https://ubuntu.com/security/CVE-2026-74562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: take nh->lock for f6i_list walks in replace check and notify fib6_check_nh_list() and __nexthop_replace_notify() walk nh->f6i_list during an RTNL-serialized nexthop replace without holding nh->lock. IPv6 RTM_NEWROUTE/RTM_DELROUTE run without RTNL and mutate that list under nh->lock (fib6_add_rt2node_nh(), fib6_purge_rt()), so both walks race a concurrent route delete that unlinks and frees a fib6_info: BUG: KASAN: slab-use-after-free in rt6_fill_node.isra.0 (net/ipv6/route.c:5799) Read of size 4 at addr ffff888014607e64 by task exploit/143 rt6_fill_node.isra.0 (net/ipv6/route.c:5799) fib6_rt_update (net/ipv6/route.c:6412) __nexthop_replace_notify (net/ipv4/nexthop.c:2542) rtm_new_nexthop (net/ipv4/nexthop.c:2554) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) BUG: KASAN: slab-use-after-free in fib6_check_nh_list (net/ipv4/nexthop.c:1605) Read of size 8 at addr ffff888014a7d068 by task exploit/142 fib6_check_nh_list (net/ipv4/nexthop.c:1605) rtm_new_nexthop (net/ipv4/nexthop.c:2575) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) Both walks only read the entries and take no tb6_lock, so protect them with nh->lock; fib6_rt_update() uses gfp_any(), which returns GFP_ATOMIC under the lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74571", "url": "https://ubuntu.com/security/CVE-2026-74571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: skip global block reserve accounting for rescue mounts [BUG] Mounting with rescue=ibadroots after corrupting the block group tree root triggers a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000100 RIP: 0010:btrfs_update_global_block_rsv+0x9d/0x1c0 [btrfs] Call Trace: fill_dummy_bgs+0xd4/0x120 [btrfs] open_ctree+0xc6e/0x1ca0 [btrfs] btrfs_get_tree+0x50d/0xa40 [btrfs] The same crash occurs with a corrupted raid stripe tree root, via btrfs_read_block_groups() instead of fill_dummy_bgs(). [CAUSE] With rescue=ibadroots, btrfs_read_roots() allows the mount to continue when either root cannot be read, leaving the corresponding root pointer NULL while its on-disk feature bit remains set. btrfs_update_global_block_rsv() then dereferences the missing root based on the feature bit alone. [FIX] Rescue mounts are fully read-only and cannot start transactions, so the global reserve is never consumed. Under btrfs_is_full_ro(), mark the reserve as full and return before performing the accounting. And since we need to check if the fs is mount fully RO, export fs_is_full_ro() as btrfs_is_full_ro(), and move it to fs.h. [ Squash the fs_is_full_ro() export commit into this one. ]", "cve_priority": "low", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74440", "url": "https://ubuntu.com/security/CVE-2026-74440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Wait on external BO kernel fences in exec IOCTL Before arming a user job, xe_exec_ioctl() only added the VM's dma-resv KERNEL slot as a dependency. That slot covers rebinds and the kernel operations of the VM's private BOs, but not external BOs (bo->vm == NULL), which carry their kernel operations (evictions, moves, ...) in their own dma-resv KERNEL slot. The DMA_RESV_USAGE_KERNEL slot is the cross-driver contract for memory management operations that must complete before the BO or its backing store may be used: any accessor is required to wait on the KERNEL fences before touching the resv. By skipping the external BOs' KERNEL slots, the exec path violated that contract and could schedule a user job while a kernel operation on an external BO mapped by the VM was still in flight, racing against it and potentially reading or writing memory that was being moved. Replace the VM-only dependency with an iteration over every object locked by the exec, adding each object's KERNEL slot as a job dependency. This covers the VM resv (rebinds and private BOs) as well as every external BO, mirroring the drm_gpuvm_resv_add_fence() call that later publishes the job fence to the same set of objects. Long-running mode continues to skip this, as before. (cherry picked from commit a6b842acf3ddd1efc53a56de9260cfa718fb35e7)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74441", "url": "https://ubuntu.com/security/CVE-2026-74441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Fix race condition and ordering in port unregistration A synchronization issue exists during port unregistration where pending partner work items can race against workqueue destruction, leading to use-after-free conditions: cros_ec_ucsi cros_ec_ucsi.3.auto: error -ETIMEDOUT: PPM init failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:__queue_work+0x83/0x4a0 Call Trace: __cfi_delayed_work_timer_fn+0x10/0x10 run_timer_softirq+0x3b6/0xbd0 sched_clock_cpu+0xc/0x110 irq_exit_rcu+0x18d/0x330 fred_sysvec_apic_timer_interrupt+0x5e/0x80 Fix this by ensuring strict ordering and proper serialization during teardown: 1. Move ucsi_unregister_partner() to the beginning of the teardown sequence and protect it under the connector mutex lock. 2. Ensure all pending partner tasks are explicitly flushed and finished before the workqueue is destroyed. 3. Switch from mod_delayed_work() to a cancel_delayed_work() and queue_delayed_work() sequence. This guarantees that items currently marked as pending won't be scheduled an additional time, preventing a double release of resources which leads to the following crash: Oops: general protection fault, probably for non-canonical address 0xdead000000000122: 0000 [#1] SMP NOPTI Workqueue: cros_ec_ucsi.3.auto-con2 ucsi_poll_worker RIP: 0010:ucsi_poll_worker+0x65/0x1e0 Call Trace: process_scheduled_works+0x218/0x6d0 worker_thread+0x188/0x3f0 __cfi_worker_thread+0x10/0x10 kthread+0x226/0x2a0 To ensure these rules are applied identically across both the normal teardown and the ucsi_init() error paths, consolidate the cleanup logic into a new helper, ucsi_unregister_port().", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74482", "url": "https://ubuntu.com/security/CVE-2026-74482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios __folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed. Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure() passes when splitting a poisoned tail of a shmem THP that reaches past i_size during truncation, it too is gone from the page cache; so once @folio is unlocked no locked, in-cache folio pins the inode, and a concurrent final iput() can evict and RCU-free it before i_mmap_unlock_read() touches i_mmap_rwsem: BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h:537 [inline] __folio_split+0x732/0x1640 mm/huge_memory.c:4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470 Freed by task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870 Do every mapping dereference while @folio still pins the inode: drop i_mmap_rwsem right after remap_page(), before the loop that unlocks and frees the after-split folios, and clear @mapping so the exit path does not unlock it again. shmem_uncharge() and remap_page() already run before that point, so after this nothing past the unlock loop touches the inode or the mapping. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74442", "url": "https://ubuntu.com/security/CVE-2026-74442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid destroy_workqueue(NULL) on vkms init failure Two paths through vmw_vkms_init() can leave vmw->crc_workq NULL while still leaving the rest of the driver in a state that calls vmw_vkms_cleanup() at module unload: 1. vmw_host_get_guestinfo(GUESTINFO_VBLANK, ...) failing or returning an oversized buffer -- the common case on hosts without a VBLANK guestinfo entry -- early-returned before the workqueue allocation. 2. alloc_ordered_workqueue() returning NULL on memory pressure. vmw_vkms_cleanup() then calls destroy_workqueue(NULL), which dereferences wq->name and panics. Fix the first case by removing the early return: vmw->vkms_enabled is already false on the rpci-failure path so no work will ever be queued, and allocating the workqueue unconditionally keeps the control flow simple. Fix the second case by guarding the cleanup with a NULL check, since alloc_ordered_workqueue() can still fail under low memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74443", "url": "https://ubuntu.com/security/CVE-2026-74443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: bound DMA command body size against suffix pointer vmw_cmd_dma() locates the DMA suffix at \t(unsigned long) &cmd->body + header->size - sizeof(*suffix) without checking that header->size is large enough to contain both cmd->body and the suffix. An undersized header makes the suffix pointer underflow back into the previous command in the bounce buffer. The verifier later writes suffix->maximumOffset, clobbering verified fields of an already-relocated earlier command -- a TOCTOU on the device-visible command stream that lets one command rewrite another's GMR id, surface id, or other authenticated fields. Reject the command if the body is too small for the suffix to fit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74444", "url": "https://ubuntu.com/security/CVE-2026-74444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate DRAW_PRIMITIVES header size before division vmw_cmd_draw() computes \tmaxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl); where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory. Reject undersized headers up front.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74445", "url": "https://ubuntu.com/security/CVE-2026-74445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: reject DX_BIND_QUERY without a DX context vmw_cmd_dx_bind_query() unconditionally dereferences sw_context->dx_ctx_node->ctx. Userspace can trigger a NULL pointer dereference from any render-node fd by submitting an execbuf with dx_context_handle == SVGA3D_INVALID_ID and a SVGA_3D_CMD_DX_BIND_QUERY opcode in the command stream: dx_ctx_node is left NULL and the kernel oopses on the assignment. The same NULL is then re-read in vmw_resources_reserve() via vmw_context_get_dx_query_mob(). All sibling DX handlers fail-close on a missing dx_ctx_node using VMW_GET_CTX_NODE(). Use the same pattern here, returning -EINVAL up front before any relocation state is published.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74446", "url": "https://ubuntu.com/security/CVE-2026-74446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: hold event_mutex while checkpointing CRIU events kfd_criu_checkpoint_events() counts the entries in p->event_idr via kfd_get_num_events(), allocates an array sized to that count, and then walks the same IDR to fill it. Neither the count nor the walk holds p->event_mutex. The CRIU checkpoint caller holds only p->mutex. Event create and destroy (kfd_event_create()/kfd_event_destroy()) take p->event_mutex and do not take p->mutex, so a second thread in the same process can insert or remove events between the count and the walk. If an event is inserted, the walk iterates more entries than were counted and writes past the end of the ev_privs allocation; if an event is removed, the walk dereferences an entry that is being freed. Hold p->event_mutex across the count and the walk so both observe a consistent view of p->event_idr. The lock is released before copy_to_user(), which only touches the local buffer. The caller already holds p->mutex and the create/destroy paths never take p->mutex, so the p->mutex -> p->event_mutex order is not inverted and no deadlock is introduced. (cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa)", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74447", "url": "https://ubuntu.com/security/CVE-2026-74447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix uint32_t overflow in EOP ring buffer size alignment eop_ring_buffer_size in struct queue_properties is a u32. In kfd_queue_acquire_buffers() the expected EOP buffer size is computed as ALIGN(eop_ring_buffer_size, PAGE_SIZE); ALIGN uses typeof(x), so the addition is done in 32-bit. A user-supplied size of 0xFFFFF001 wraps to 0, causing kfd_queue_buffer_get() to skip its exact-size check (gated on size != 0) and accept any BO mapped at the address. On GFX8/GFX9 the MQD cp_hqd_eop_control is then programmed for an 8KB EOP ring backed by a 4KB BO, so CP EOP writes can land past the buffer and fault the GPU. Cast the operand to u64 so the alignment is computed in 64-bit; the size check in kfd_queue_buffer_get() then rejects the oversized request. (cherry picked from commit ae443117b742c357bfef3a7bddabf76fcf86e9ef)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74448", "url": "https://ubuntu.com/security/CVE-2026-74448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix QID bit leak in pqm_create_queue() When MES is enabled and amdgpu_amdkfd_alloc_kernel_mem() fails during the first queue creation for a process, pqm_create_queue() returns early via 'return retval' without going through the err_create_queue cleanup label. This means clear_bit(*qid, pqm->queue_slot_bitmap) is never called, leaving the reserved QID bit permanently set in queue_slot_bitmap. Over time this leaks QID slots, potentially exhausting all available queue slots. Fix this by replacing 'return retval' with 'goto err_allocate_pqn' so that clear_bit() is always called on the error path without touching the uninitialized pqn pointer. AILIKFD-813 (cherry picked from commit a107f74c38edbb80d6ab64dcaeeb292c14e9779f)", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74451", "url": "https://ubuntu.com/security/CVE-2026-74451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: validate firmware interface structure sizes iface_fw_to_cpu_addr() only checks that the firmware-provided MCU virtual address points inside the shared section. The returned pointer is later used as a full firmware interface structure, so accepting an address near the end of the shared section can still lead to out-of-bounds accesses. Pass the expected object size to iface_fw_to_cpu_addr() and reject ranges that do not fit entirely in the shared section.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74452", "url": "https://ubuntu.com/security/CVE-2026-74452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: reject firmware sections with oversized data In panthor_fw_load_section_entry(), the data size to copy is calculated without validating it against the allocated section_size: section->data.size = hdr.data.end - hdr.data.start; If a crafted firmware sets data.size larger than the allocated memory, this could cause a heap buffer overflow in panthor_fw_init_section_mem() memcpy(section->mem->kmap, section->data.buf, section->data.size); Additionally, if the section->data.size exceeds the BO size, could this memset underflow the size calculation, leading to a massive out-of-bounds zeroing of kernel memory? memset(section->mem->kmap + section->data.size, 0, panthor_kernel_bo_size(section->mem) - section->data.size); Reject section entries whose initial data is larger than the section size.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74453", "url": "https://ubuntu.com/security/CVE-2026-74453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Zero the tile state data array before each BIN job The binner BO is a single 16MB buffer split into 512KB slots that are handed out to jobs at submission time and recycled as jobs complete, without ever being cleared. Each slot holds the job's Tile State Data Array (TSDA) at its start, followed by the tile allocation pool. While the tile allocation pool is only walked by the render thread through branches the binner generated during the current job, the TSDA is the PTB's own per-tile bookkeeping and is consumed by the hardware itself. Although the kernel sets the \"Auto-initialise Tile State Data Array\" flag in the tile binning mode configuration, the PTB demonstrably still acts on stale tile state left by the slot's previous user: the binner ends up creating invalid command streams with invalid primitive streams and branches, which can cause GPU hangs as observed in [1][2]. Zero the TSDA when the job's binning slot is configured. This clears 48 bytes per tile (~24KB for a 1080p frame) in the submission path, and guarantees the PTB never sees another job's tile state. The tile count is only checked for being non-zero today, so the 8-bit fields it comes from can describe a tile state array almost six times larger than the slot it has to live in. Bound it before the slot is handed out, since such size decides how much of the slot is left for the tile alloc pool.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74454", "url": "https://ubuntu.com/security/CVE-2026-74454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Supply the overflow slot size in BPOS, not the whole bin BO size vc4_overflow_mem_work() points BPOA at a 512KB slot inside the 16MB binner BO, but writes the size of the whole BO to BPOS. On every binner out-of-memory event the PTB is therefore authorized to write tile lists across all the other slots (which may hold the tile state, tile alloc and overflow memory of in-flight jobs) and, for any slot but the first, past the end of the binner BO into unrelated CMA memory. Since CMA pages are recycled into page cache and user allocations, this is arbitrary memory corruption by GPU DMA. In practice it shows up as GPU hangs with corrupted control list pointers, userspace heap corruption, a GPU that stays permanently wedged after the first hang, and occasional full system crashes, whenever a job overflows the initial binner slot. The bug dates back to the conversion from a dedicated overflow BO (where writing the full BO size was correct) to the slotted binner BO.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74455", "url": "https://ubuntu.com/security/CVE-2026-74455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: validate uCAN receive record lengths pcan_usb_fd_decode_buf() walks uCAN records packed in one USB receive buffer. Require each record to contain the fixed header for its type, and verify CAN payload bytes before copying them into the skb.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74456", "url": "https://ubuntu.com/security/CVE-2026-74456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc() and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also frees the transfer buffer. If usb_submit_urb() fails, the error path frees the buffer explicitly with kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set, usb_free_urb() -> urb_destroy() frees the same buffer a second time, a double free of the transfer buffer. BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0 Free of addr ffff8881069ccb80 by task trigger.sh/285 Call Trace: kfree+0x113/0x3c0 usb_free_urb.part.0+0x91/0xb0 Drop the redundant kfree(buf); usb_free_urb() already releases the transfer buffer. This mirrors commit 03819abbeb11 (\"net: usb: lan78xx: Fix double free issue with interrupt buffer allocation\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74457", "url": "https://ubuntu.com/security/CVE-2026-74457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: add bounds check for USB channel index The channel control index ctrl_idx is derived from rx->len which comes directly from a device USB payload. The mask 0x0f allows values 0-15, but the array size of usb_if->dev[] is only 2. Values 2-15 cause heap out-of-bounds read, eventually causing kernel panic in the IRQ context. Add bounds checking for ctrl_idx before the array access in both pcan_usb_pro_handle_canmsg() and pcan_usb_pro_handle_error().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74458", "url": "https://ubuntu.com/security/CVE-2026-74458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents The wait and bulk receive paths walk variable-length commands from a USB buffer. A nonzero command shorter than CMD_HEADER_LEN can still be dispatched, and the wait path copies a matching command into a fixed caller-owned struct kvaser_cmd using the device-provided length. Reject nonzero commands that do not contain the fixed header or that extend beyond the current USB buffer item. In the wait path, also reject a matching command that exceeds the destination before copying it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74459", "url": "https://ubuntu.com/security/CVE-2026-74459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure es58x_read_bulk_callback() resubmits the RX URB after processing a received packet. If the resubmit succeeds, the URB remains anchored and will be handled by the normal RX path or by teardown. However, if usb_submit_urb() fails, the callback unanchors the URB and then returns directly. This skips the existing free_urb path, so the coherent transfer buffer allocated with usb_alloc_coherent() is not released. Reuse the existing free_urb path after a resubmit failure so that the RX coherent buffer is freed before leaving the callback.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74460", "url": "https://ubuntu.com/security/CVE-2026-74460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: validate CPC message lengths ems_usb_read_bulk_callback() walks CPC messages packed in one USB receive buffer. Check that each declared message fits in the URB payload. Also require the type-specific payload to cover the fields used by the CAN, state, error and overrun handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74461", "url": "https://ubuntu.com/security/CVE-2026-74461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: Cancel hrtimer before clearing slave pointer In i2c_imx_unreg_slave(), the slave pointer is set to NULL after disabling interrupts. However, a pending interrupt might already have started the hrtimer (i2c_imx_slave_timeout) before the pointer was cleared. If the hrtimer fires after i2c_imx->slave is set to NULL, the timer callback i2c_imx_slave_finish_op() will call i2c_imx_slave_event() with a NULL slave pointer, which results in a use-after-free / NULL pointer dereference. Fix by canceling the hrtimer and waiting for it to complete after disabling interrupts, before clearing the slave pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74462", "url": "https://ubuntu.com/security/CVE-2026-74462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: mark I2C adapter when hardware is powered down On some i.MX platforms, certain I2C client drivers keep a periodic workqueue which continues to trigger I2C transfers. During system suspend/resume, there exists a time window between: - suspend_noirq and the system entering suspend - the system starting to resume and resume_noirq In this window, the I2C controller resources such as clock and pinctrl may already be disabled or not yet restored. If a workqueue triggers an I2C transfer in this period, the driver attempts to access I2C registers while the hardware resources are unavailable, which may lead to system hang. Mark the I2C adapter as suspended during noirq suspend and block new transfers until resume, ensuring that I2C transfers are only issued when hardware resources are available.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74463", "url": "https://ubuntu.com/security/CVE-2026-74463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock Fix a severe AB/BA deadlock between the Common Clock Framework (CCF) and the I2C adapter lock, which triggers when an I2C-controlled clock generator client (like the Si5351) is registered or modified under the CCF. During an i2c client clock (generator) frequency change, the CCF acquires its global 'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's chip registers, stalling for the adapter's I2C bus lock. Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO expander handling LEDs) can hold the I2C adapter lock. Inside this parallel transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host controller's input clock to calculate bus timings. This call attempts to acquire the blocked CCF 'prepare_lock', creating a circular dependency that freezes the system. The jz4780 host controller clock itself is static and never changes at runtime. However, calling clk_get_rate() inside the active transfer path introduces an unnecessary dependency on the CCF internal locks. Eliminate this synchronous clk_get_rate() call from the active transfer path by caching the static host peripheral clock rate once - inside the private jz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed() to use this cached value, safely decoupling active I2C transactions from the CCF internal locks without any risk of stale timings. Assisted-by web based Google AI (pinpointing the bug and writing the message).", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74464", "url": "https://ubuntu.com/security/CVE-2026-74464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix skb leak on flow key update failure during ct ovs_ct_execute() always steals or frees the skb on failure while ovs_flow_key_update() does not. So, if it fails and we return right away, the skb ends up leaked. Fix that by breaking instead and letting the common error handling code at the bottom of the loop to free the skb properly. This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless. Reported by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74465", "url": "https://ubuntu.com/security/CVE-2026-74465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix potential UAF on meter attach failure While attaching a newly created meter attach_meter() function makes the new meter visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter) on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508 Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584) ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ... netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible until all the checks are done and the function can't fail anymore. This also makes sure the \"hash\" value is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-31642.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68451", "url": "https://ubuntu.com/security/CVE-2026-68451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA ECC private key requests cca_ecc2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "high", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-68452", "url": "https://ubuntu.com/security/CVE-2026-68452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA AES cipher key requests cca_cipher2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "medium", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-68453", "url": "https://ubuntu.com/security/CVE-2026-68453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix buffer over-read in cca_cipher2protkey Add validation of both the actual key buffer size and token length fields in all the cca_check_sec*token() functions. Additionally check in cca_gencipherkey() for possible underflow with returned key size. The CCA token structures contain user-controlled len fields that were used in operations without proper validation against both the actual buffer size and minimum token structure size. An attacker could set this field larger than the actual buffer size, leading to reading beyond buffer boundaries. This may result in a kernel crash or exposure of memory via sending this as part of a request down to the crypto card. Also an attacker could have used a very small len value and thus enforce a buffer under-run which may produce similar effects as a over-read. So now a key must - key buf length must be at least sizeof the token struct - the key len field inside the token must fit into the range of sizeof key token struct ... key buf length", "cve_priority": "medium", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-74467", "url": "https://ubuntu.com/security/CVE-2026-74467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/qeth: Check CAP_NET_ADMIN for private ioctls Gate the SIOCDEVPRIVATE ioctl commands SIOC_QETH_ADP_SET_SNMP_CONTROL, SIOC_QETH_GET_CARD_TYPE and SIOC_QETH_QUERY_OAT with CAP_NET_ADMIN capable check to ensure unprivileged users cannot invoke them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74468", "url": "https://ubuntu.com/security/CVE-2026-74468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: pch: use raw_spinlock_t for the register lock pch_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. This was confirmed on a PREEMPT_RT kernel with lockdep (PROVE_RAW_LOCK_NESTING and DEBUG_ATOMIC_SLEEP). A grounded PoC mirrored pch_irq_type()'s locking and drove it through the real genirq carrier irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), i.e. the same __irq_set_trigger() edge that __setup_irq() takes for a requested IRQ. With the original spin_lock_irqsave() edge lockdep reported an invalid wait context, immediately followed by: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro] __irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0 Switching the mirrored lock to raw_spinlock_t made both splats go away. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, but all of those critical sections only perform MMIO register accesses (ioread32()/iowrite32()) and irq_set_handler_locked(); none of them contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same class of issue and fix as recently addressed for other GPIO controllers, e.g. commit 286533cb14a3 (\"gpio: sch: use raw_spinlock_t in the irq startup path\") and commit 90f0109019e6 (\"gpio: eic-sprd: use raw_spinlock_t in the irq startup path\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74469", "url": "https://ubuntu.com/security/CVE-2026-74469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: prevent peer transport count overflow sctp_assoc_add_peer() increments the association's 16-bit transport_count for every new unique peer. Adding the 65,536th transport wraps the count to zero. SCTP sock_diag uses transport_count to reserve the INET_DIAG_PEERS payload, then copies one sockaddr_storage for every entry in transport_addr_list. After the wrap, a diagnostic dump reserves an empty payload and writes 8 MiB of peer addresses past the skb tail. Reject a new unique peer when transport_count has reached U16_MAX. Perform the check after the existing-peer lookup so a duplicate address continues to return its existing transport at the limit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74470", "url": "https://ubuntu.com/security/CVE-2026-74470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write resp_report_zones() sizes the reply buffer from the CDB allocation length. The v3 fix rounds alloc_len up with ALIGN() before deriving the descriptor count: \trep_max_zones = (ALIGN((u64)alloc_len, RZONES_DESC_HD) - \t\t\t RZONES_DESC_HD) >> ilog2(RZONES_DESC_HD); \tarr_len = (u64)RZONES_DESC_HD * (rep_max_zones + 1); For alloc_len in 0xFFFFFFC1..0xFFFFFFFF, ALIGN() rounds up to 0x100000000, so arr_len is 4 GB. On 32-bit, kzalloc()'s size_t is 32-bit and truncates 0x100000000 to 0; kzalloc(0) returns ZERO_SIZE_PTR, which passes the !arr check, and desc = arr + 64 is then dereferenced in the loop -> out-of-bounds write / panic. Clamp rep_max_zones to devip->nr_zones. The loop already stops at sdebug_capacity (after nr_zones zones), so a report can never hold more than nr_zones descriptors; the clamp does not change the report, it only bounds arr_len to (nr_zones + 1) * RZONES_DESC_HD, a real device property that can never reach 0x100000000.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74471", "url": "https://ubuntu.com/security/CVE-2026-74471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Check return value of __register_event() in trace_module_add_events() trace_module_add_events() ignores the return value of __register_event() and unconditionally calls __add_event_to_tracers() for each event. If __register_event() fails (for example, if event_init() fails), the trace_event_call is not added to ftrace_events list, but __add_event_to_tracers() still creates a trace_event_file pointing to it. If module loading subsequently fails and module memory is freed, tracing state retains a stale trace_event_call pointer in trace_event_file, leading to a use-after-free when tracefs or tracing subsystem operations are later executed. Fix this by checking the return value of __register_event() and only calling __add_event_to_tracers() if event registration succeeded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74472", "url": "https://ubuntu.com/security/CVE-2026-74472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: reset kernel-owned dev_info fields in ublk_ctrl_add_dev() ublk_ctrl_add_dev() memcpy()s the userspace ublksrv_ctrl_dev_info into ub->dev_info and then fixes up the fields the driver owns, but misses ->state and ->ublksrv_pid. A device added with ->state = UBLK_S_DEV_LIVE passes the \"->state != UBLK_S_DEV_DEAD\" test that ublk_stop_dev_unlocked() uses as its proxy for \"a disk is attached\", while ->ub_disk is still NULL, so DEL_DEV right after ADD_DEV oopses in del_gendisk(). UBLK_S_DEV_QUIESCED plus UBLK_F_USER_RECOVERY dies one step earlier, in ublk_force_abort_dev(). A poisoned ->state also gets START_USER_RECOVERY and the char device read/write path onto a device that was never started, and wedges START_DEV at -EEXIST. A poisoned ->ublksrv_pid just makes GET_DEV_INFO report an unrelated task as the ublk server. Reset both after the memcpy(), as ublk_detach_disk() does. Userspace only ever reads these back, so correcting them silently breaks nothing. ADD_DEV has copied ->state in unsanitized since ublk was merged, but back then it was harmless: the gendisk was allocated during ADD_DEV, and both teardown and the START_DEV -EEXIST check keyed off disk_live() rather than ->state. The oops became reachable once the disk allocation moved to START_DEV and those checks switched to ->state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74473", "url": "https://ubuntu.com/security/CVE-2026-74473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use pskb_network_may_pull() in route_shortcircuit() route_shortcircuit() currently calls pskb_may_pull(skb, sizeof(struct iphdr)) (or ipv6hdr), which checks if bytes are available starting from skb->data. However, in vxlan_xmit(), skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, 20) only checks 20 bytes from skb->data (which is 14 bytes MAC header + 6 bytes of IP header), leaving the rest of the IP header potentially un-pulled in non-linear frags. Subsequent dereferences of ip_hdr(skb)->daddr can read beyond the pulled linear buffer length. Fix this by using pskb_network_may_pull(), which adds skb_network_offset(skb) to the length check to ensure the full network header is present in the linear buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74474", "url": "https://ubuntu.com/security/CVE-2026-74474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use pskb_network_may_pull() for transmit path header pulls In vxlan_xmit(), arp_reduce(), and vxlan_mdb_entry_skb_get(), pskb_may_pull() was being called to verify the availability of network layer headers (ARP, IPv6/ND, IP/IPv6 MDB keys). However, during transmit skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, len) only checks len bytes from skb->data rather than skb_network_offset(skb) + len, which can leave part of the network header in non-linear frags. Replace these remaining pskb_may_pull() calls with pskb_network_may_pull() to properly account for the MAC header offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74475", "url": "https://ubuntu.com/security/CVE-2026-74475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use neigh_ha_snapshot() in route_shortcircuit() The neighbour hardware address n->ha can be updated asynchronously by the neighbour subsystem, protected by n->ha_lock seqlock. Reading n->ha without holding the seqlock loop can lead to torn reads or reading a partially updated MAC address. Use neigh_ha_snapshot() in route_shortcircuit() to safely copy n->ha under read_seqbegin()/read_seqretry() lock protection before using it. Note that arp_reduce() and neigh_reduce() seem to have the same issue left for future patches.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74476", "url": "https://ubuntu.com/security/CVE-2026-74476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: convert frag_list skbs before running XDP A frag_list skb can reach veth with data_len set but nr_frags zero. veth_convert_skb_to_xdp_buff() only converts skbs that are shared, locked, have frags[], or do not have enough headroom. It later uses skb_is_nonlinear() to decide whether to set XDP_FLAGS_HAS_FRAGS and xdp_frags_size. That exposes frag_list data to XDP as if it were stored in frags[], but frags[] is empty. AF_XDP copy mode can then trust the bogus XDP fragment metadata, walk an empty fragment entry, and crash in memcpy() from __xsk_rcv(). Route non-linear skbs through skb_pp_cow_data() before exposing them to XDP, and only advertise XDP frags when the resulting skb has frags[]. skb_copy_bits() already handles frag_list input, and skb_pp_cow_data() builds frags[] output with skb_add_rx_frag(), which is the representation XDP multi-buffer expects.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74477", "url": "https://ubuntu.com/security/CVE-2026-74477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: Fix NULL pointer dereference in hprobe_expire() Forking a task that has a pending uretprobe can oops the kernel with a NULL pointer dereference in the clone() path: BUG: kernel NULL pointer dereference, address: 0000000000000018 Oops: 0002 [#1] SMP NOPTI RIP: 0010:hprobe_expire CR2: 0000000000000018 Call Trace: uprobe_copy_process copy_process kernel_clone __x64_sys_clone do_syscall_64 entry_SYSCALL_64_after_hwframe This was found on real hosts on Meta fleet. I've got the impression that this is what is happening: CPU 1 CPU 2 (traced task) ----- ------------------- hit uprobe, prepare_uretprobe(): hprobe LEASED, refcount >= 1 uprobe_unregister() put_uprobe(): refcount -> 0 fork() -> dup_utask() hprobe_expire(hprobe, true) try_get_uprobe() -> NULL get_uprobe(NULL) <-- Oops Only take the extra reference when the uprobe is non-NULL; a NULL means it is gone and is the correct value to return.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74478", "url": "https://ubuntu.com/security/CVE-2026-74478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: vector: fix use-after-free in vector_mmsg_rx() When vector_mmsg_rx() discards a packet whose overlay header fails verify_header(), it frees the skb and continues the loop: \tif (header_check < 0) { \t\tdev_kfree_skb_irq(skb); \t\tvp->estats.rx_encaps_errors++; \t\tcontinue; \t} The normal and short-packet paths fall through to the bottom of the loop body, which clears the consumed slot and advances the cursors: \t(*skbuff_vector) = NULL; \tmmsg_vector++; \tskbuff_vector++; The verify_header() < 0 path skips that via continue, so the freed skb is left in skbuff_vector[] and the cursors do not advance. The next iteration reads the same slot, gets the freed skb, and frees it again, producing a refcount underflow / use-after-free in the RX path. Discard the slot the same way the other paths do before continuing. Only transports whose verify_header() can return negative are affected: GRE and L2TPv3 do so on a cookie/session-id mismatch (raw/tap do not), so any peer on such a transport can trigger it without authentication.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74479", "url": "https://ubuntu.com/security/CVE-2026-74479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: pktgen: fix proc entry use-after-free pktgen_change_name() replaces pkt_dev->entry while holding t->if_lock. pktgen_remove_device() removes the same entry before _rem_dev_from_if_list() takes that lock. This allows the following interleaving: CPU 0 (NETDEV_CHANGENAME) CPU 1 (kpktgend) if_lock(t) proc_remove(pkt_dev->entry) proc_remove(pkt_dev->entry) pkt_dev->entry = proc_create_data(...) if_unlock(t) The kthread can pass the stale proc_dir_entry to proc_remove() after the rename path has freed it. A reproducer with a widened race window reports: BUG: KASAN: slab-use-after-free in proc_remove+0x78/0x80 Read of size 8 at addr ffff8881478fea70 by task kpktgend_0/67 Call Trace: proc_remove+0x78/0x80 pktgen_remove_device.isra.0+0x11c/0x4c0 pktgen_thread_worker+0x1214/0x6bc0 kthread+0x2c6/0x3b0 Allocated by task 95: __proc_create+0x204/0x790 proc_create_data+0x72/0xe0 pktgen_thread_write+0xd61/0x1510 Freed by task 28: kmem_cache_free+0xcb/0x3d0 proc_free_inode+0x5b/0x80 rcu_core+0x50a/0x1850 The buggy address belongs to the object at ffff8881478fea00 which belongs to the cache proc_dir_entry of size 192 Move proc_remove() into the if_lock-protected list removal helper. Keep it before list_del_rcu() to preserve the ordering required by add_device(). The rename path must then finish replacing the entry before removal, or it observes that the device is no longer on the list.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74480", "url": "https://ubuntu.com/security/CVE-2026-74480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: stop fast-leave after deleting a port group br_multicast_leave_group() iterates mp->ports with pp = &p->next in its fast-leave path. After br_multicast_del_pg() removes p, continuing the loop advances pp through the deleted entry. If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, br_port_group_equal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group. Fast leave only needs to remove one matching port group. Break after br_multicast_del_pg() so the loop stops before dereferencing the removed entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74481", "url": "https://ubuntu.com/security/CVE-2026-74481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_reporting: use system_freezable_wq to fix UAF during suspend During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free / General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0 Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM during freeze without triggering unfrozen reporting work on deleted virtqueues. This aligns with the driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen by the PM core before this * function is called. */ Testing: I have verified these fixes using Google’s virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are no longer reproducible.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74484", "url": "https://ubuntu.com/security/CVE-2026-74484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't let an 'F' entry pin its own instance An entry registered with 'F' opens its interpreter at registration time and holds that file until the entry is freed. Any entry nobody removes by hand only gets closed once the binfmt_misc superblock is shut down. If the interpreter lives on a mount that keeps that superblock alive the two pin each other: binfmt_misc sb -> inode -> entry -> interp_file -> vfsmount -> binfmt_misc sb TL;DR the file is never closed. Once the mount namespace is gone there is nothing left to unregister through either. There are two ways to trigger this bug: - Point the interpreter at the instance itself. Its files are regular files owned by the mounter and both bm_get_inode() and simple_fill_super() leave i_op at empty_iops. So notify_change() falls back to simple_setattr() and chmod +x works. We never set SB_I_NOEXEC and so open_exec() accepts it. - Use the instance as an overlayfs lower layer. The overlay superblock holds a clone_private_mount() of every layer until it is destroyed and that clone is in no namespace. So umount_tree() never reaches it. That's a DoS. And it isn't only the superblock that leaks. It pins the user namespace it was mounted in, so every iteration permanently eats one of the caller's user namespace charges. So let's just do the sane thing. SB_I_NOEXEC makes open_exec() fail on the instance's own files and s_stack_depth makes overlayfs reject the layer before it ever takes a clone. That also covers the ecryptfs and fuse passthrough variants. What 'F' promises is unchanged. The stable tag is narrower than the Fixes tags on purpose. Before sandboxed mounts this needed global root against the single instance everyone shares, and the change doesn't apply to those trees anyway. Note that SB_I_NODEV is implicitly raised for userns mounts but raise it explicitly here as well.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74485", "url": "https://ubuntu.com/security/CVE-2026-74485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: reject a flag character as the field delimiter The registration string starts with a user chosen delimiter that separates the individual fields. So that the field parsers terminate even on a truncated string create_entry() pads the buffer with that same delimiter: \tmemset(buf + count, del, 8); Most fields are scanned for the delimiter with strchr()/scanarg() and happily stop on the padding. The flags field is different: instead of scanning for the delimiter check_special_flags() consumes the flag characters 'P', 'O', 'C' and 'F' and stops at the first byte that is none of them, relying on the trailing delimiter to end the scan. If the delimiter is itself a flag character the padding no longer acts as a terminator. The scan swallows all eight padding bytes and keeps reading past the end of the allocation until it hits a byte that is not a flag character. For example registering \tPaPEPPxPPiP with 'P' as the delimiter (name \"a\", type extension, magic \"x\", interpreter \"i\", empty flags) leaves the flag scan running off the end of the buffer. The registration is rejected in the end because the parser does not stop exactly at buf + count, but only after the out of bounds read has already happened. With an unlucky allocation layout the scan can walk into an unmapped page; under KASAN it is reported as a slab out of bounds read. binfmt_misc mounts are available to unprivileged users in a user namespace so the read is reachable without privileges. Reject a delimiter that is one of the flag characters up front. Such a registration was always rejected anyway, only after the out of bounds read, so no valid registration string changes meaning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74486", "url": "https://ubuntu.com/security/CVE-2026-74486", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: use exe_file_deny_write_access() for the interpreter clone For MISC_FMT_OPEN_FILE entries load_misc_binary() clones the registered interpreter file and denies write access to the clone via plain deny_write_access(). The clone is installed as bprm->interpreter and later released by the exec machinery through exe_file_allow_write_access() which skips the i_writecount increment for files with FMODE_FSNOTIFY_HSM set. The deny and allow side can therefore come to different conclusions when pre-content watches are in play: if a pre-content watch is added to the interpreter after registration every subsequent exec through that entry takes a write denial on the clone that is never paired with a write allowance, driving the interpreter inode's i_writecount further down with each exec and leaving the interpreter unwritable even after the entry and all its users are gone. Take the write denial via exe_file_deny_write_access() so both sides of the pairing base their decision on the same file mode, and propagate failure instead of silently ignoring it: an interpreter that is concurrently open for writing now fails the exec with ETXTBSY, exactly like an interpreter freshly opened via open_exec() would.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74487", "url": "https://ubuntu.com/security/CVE-2026-74487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: restore write access when removing an entry Registering an entry with the MISC_FMT_OPEN_FILE flag opens the interpreter via open_exec() which denies write access to it for as long as the entry exists. Removing the entry closes the interpreter file via filp_close() but never restores write access, leaving the inode's i_writecount permanently negative. Opening the interpreter for writing keeps failing with ETXTBSY long after the entry is gone until the inode is evicted from the inode cache. Commit 90f601b497d7 (\"binfmt_misc: restore write access before closing files opened by open_exec()\") fixed the same imbalance in the error path of bm_register_write() but the actual removal path has been leaking the write denial since the introduction of the flag. Restore write access in put_binfmt_handler() before closing the interpreter file.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74488", "url": "https://ubuntu.com/security/CVE-2026-74488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames mwifiex_11n_dispatch_amsdu_pkt() splits an A-MSDU with ieee80211_amsdu_to_8023s() and walks the resulting subframes. For each subframe it passes the subframe data pointer to mwifiex_process_tdls_action_frame(), but pairs it with skb->len, the length of the A-MSDU parent, instead of rx_skb->len: \trx_skb = __skb_dequeue(&list); \trx_hdr = (struct rx_packet_hdr *)rx_skb->data; \tif (ISSUPP_TDLS_ENABLED(priv->adapter->fw_cap_info) && \t ntohs(rx_hdr->eth803_hdr.h_proto) == ETH_P_TDLS) { \t\tmwifiex_process_tdls_action_frame(priv, (u8 *)rx_hdr, \t\t\t\t\t\t skb->len); \t} The parent is not a valid description of that buffer, and may not be valid memory at all. ieee80211_amsdu_to_8023s() ends with \tif (!reuse_skb) \t\tdev_kfree_skb(skb); and it only sets reuse_skb when the parent is linear, is not a head_frag, and is being consumed as the *last* subframe. So when the parent does not qualify for reuse it has already been freed, and the read of skb->len is a use-after-free. When it is reused, skb->len is the length of the last subframe, applied to every earlier subframe, which over-states the buffer whenever an earlier subframe is shorter. The callee cannot absorb a wrong length, because it derives its own ceiling from the value it is given. Each frame type computes \ties_len = len - sizeof(struct ethhdr) - TDLS_*_FIX_LEN; and the element walk is then bounded entirely against that ceiling, \tfor (end = pos + ies_len; pos + 1 < end; pos += 2 + pos[1]) { \t\tu8 ie_len = pos[1]; \t\tif (pos + 2 + ie_len > end) \t\t\tbreak; so a too-large len moves end past the end of the subframe and the walk reads and copies beyond it. The A-MSDU layout is chosen by the sender, which makes the difference between the last subframe and a shorter earlier one remotely selectable. Reaching this requires TDLS support in firmware and the TDLS ethertype on the subframe. The other caller, mwifiex_process_rx_packet(), is correct: it passes a pointer and a length that describe the same region of the RX buffer. Pass rx_skb->len, the length of the subframe actually being parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74490", "url": "https://ubuntu.com/security/CVE-2026-74490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: avoid use-after-free in poll trace queue dumps TIPC socket tracepoints dump queue state through tipc_sk_dump(). Most queue-dump callsites already serialize that walk under the socket lock or sk->sk_lock.slock, but tipc_poll() calls trace_tipc_sk_poll(..., TIPC_DUMP_ALL, ...) without holding either lock. That lets the poll trace path reach tipc_list_dump() and backlog head/tail dumping while another context dequeues and frees an skb, leaving the trace helper dereferencing a stale queue entry. Stop the unlocked poll trace site from requesting queue dumps. Other queue dump trace callsites keep their existing output under the locking they already provide, while poll still emits the event itself without walking live queue members from an unlocked context.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74491", "url": "https://ubuntu.com/security/CVE-2026-74491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: of/address: Fix NULL bus dereference in of_pci_range_parser_one() The bus matching rework made of_match_bus() return NULL for nodes with ranges/dma-ranges but no local #address-cells. parser_init() stored that NULL bus, and the range iterator later dereferenced it. Reject such nodes in parser_init(), leaving an explicit empty iterator for callers that ignore the init return, and make of_dma_get_max_cpu_address() honour the init failure so a rejected node cannot clamp the DMA limit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74492", "url": "https://ubuntu.com/security/CVE-2026-74492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: do not update comments from kernel-side hash adds mtype_resize() copies comment pointers with memcpy(), not the comment objects themselves. During the window after an entry has been copied but before the table swap and backlog replay, the old table is still published for packet-side updates while the replacement-table entry already holds the same ip_set_comment_rcu pointer. If xt_SET --add-set ... --exist hits that old entry in this window, mtype_add() calls ip_set_init_comment() even though packet-side adds carry no comment payload. That call frees the shared comment through the old entry, so the replacement-table entry now holds a stale pointer. When the queued add is replayed on the new table, mtype_add() calls ip_set_init_comment() again and strlen() dereferences the stale pointer. Fix this in mtype_add() by skipping ip_set_init_comment() when ext->target marks a packet-side add. Userspace adds still update comments, while packet-side adds can no longer free comment storage shared with a resize copy.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74493", "url": "https://ubuntu.com/security/CVE-2026-74493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket use-after-free during link group termination __smc_lgr_terminate() drops conns_lock after finding a connection in lgr->conns_all, but before taking a reference on its socket. The connection is embedded in the socket, and its registration reference protects it only while the connection remains in the tree. A concurrent close can unregister the connection and drop that reference, freeing the socket before the termination worker reaches sock_hold(). The race is reachable when close overlaps link group termination. Local stress testing reproduced the use-after-free and KASAN reported: BUG: KASAN: slab-use-after-free in __smc_lgr_terminate.part.0 [smc] Write of size 4 by task kworker/3:3 Workqueue: events smc_lgr_terminate_work [smc] __smc_lgr_terminate.part.0 [smc] The socket was allocated by smc_create(), freed through slab_free_after_rcu_debug(), and was followed by: refcount_t: addition on 0; use-after-free. __smc_lgr_terminate.part.0 [smc] Take the socket reference while conns_lock still protects the tree entry. The unregister path then cannot drop the last reference until termination has finished using the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74494", "url": "https://ubuntu.com/security/CVE-2026-74494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject repeated SMB2 NEGOTIATE requests Unauthenticated client can send multiple successful SMB2 NEGOTIATE requests on one connection before SESSION_SETUP. While the connection is in KSMBD_SESS_NEED_SETUP, smb2_handle_negotiate() accepts another SMB3.1.1 NEGOTIATE and overwrites conn->preauth_info with a new allocation. Only the final allocation is freed when the connection is released, leaking one object for every additional successful request. A repeated SMB2 NEGOTIATE after a dialect has been selected is a protocol violation. MS-SMB2 section 3.3.5.4 requires the server to disconnect without replying in this case. Set the connection exiting when rejecting the request, in addition to suppressing the response. Reject SMB2 NEGOTIATE unless the connection is new or is waiting for the SMB2 NEGOTIATE that follows an SMB1 multi-protocol negotiate. Serialize both SMB1 and SMB2 negotiation paths under conn->srv_mutex, since they update connection-wide dialect and negotiation state. Move the locking contract to ksmbd_smb_negotiate_common(), where the state and dialect are selected, and add ksmbd_conn_new() for consistent state access.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74495", "url": "https://ubuntu.com/security/CVE-2026-74495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igbvf: Fix leak in TX DMA error cleanup If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb. Because count is incremented before each frag mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping (the head) would leak. This bug was introduced by a 2010 fix for an endless loop in dma_error. All other affected drivers have already been fixed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74497", "url": "https://ubuntu.com/security/CVE-2026-74497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Clamp frame size in implicit-feedback mode snd_usb_handle_sync_urb() scales received sync packet sizes by the sender's stride and stores the result directly in out_packet->packet_size[i]. If a connected USB device sends an oversized sync packet, this frame count can exceed ep->maxframesize. The un-clamped frame count then propagates to the playback endpoint queue, potentially driving packet transfers beyond the endpoint's hardware frame limits. Cap the calculated frame count against ep->maxframesize in snd_usb_handle_sync_urb() to prevent oversized packets from entering the playback queue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74498", "url": "https://ubuntu.com/security/CVE-2026-74498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set When a USB audio endpoint requests full packet transfers via the fill_max descriptor flag, data_ep_set_params() promotes ep->curpacksize to ep->maxpacksize. However, maxsize is left at the original sample-rate derived value. Since u->buffer_size is allocated as maxsize * packets, the resulting DMA buffer is far too small for the requested transfer length. When the USB host controller streams up to curpacksize bytes per packet, it writes past the end of the buffer via DMA, corrupting kernel heap memory. Update maxsize to curpacksize when fill_max is set so that the allocated DMA buffer size matches the actual transfer request size. [ changed to reassign maxsize only when ep->fill_max is set -- tiwai ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74499", "url": "https://ubuntu.com/security/CVE-2026-74499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output() snd_usbmidi_akai_output() computes its fill-loop bound \tbuf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1; as a signed int, so a small device-advertised bulk-OUT max_transfer makes buf_end negative. The loop guard then compares the u32 urb->transfer_buffer_length against that negative int: the usual arithmetic conversion turns buf_end into a large unsigned value, so the guard stays true and each iteration keeps appending SysEx framing and payload bytes past the end of the URB transfer buffer, which is only max_transfer bytes long. A USB device that advertises a tiny bulk-OUT endpoint can therefore trigger an attacker-length- and content-controlled heap out-of-bounds write when a process writes to the created /dev/snd/midiC*D* node. Return early when there is no room for even one SysEx, so the loop is never entered with a bound that would wrap. The loop is the last statement of the function, so bailing out is equivalent to it not running. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74500", "url": "https://ubuntu.com/security/CVE-2026-74500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix stack info leak in RME Digiface status snd_rme_digiface_read_status() reads a four-word status block from the device into an uninitialised on-stack __le32 buf[4] and, whenever the vendor control-IN transfer does not return a negative error, copies all four words into the caller's status[]. snd_usb_ctl_msg() copies the full requested size back into the caller's buffer regardless of how many bytes the data stage actually delivered: \tbuf = kmemdup(data, size, GFP_KERNEL); \terr = usb_control_msg(dev, pipe, request, requesttype, \t\t\t value, index, buf, size, timeout); \tmemcpy(data, buf, size); usb_control_msg() returns the transferred length on a short control-IN, which is a non-negative value, and writes only that many bytes. The remainder of the copy back is the kmemdup()ed image of the caller's buffer, so a device answering with a short data stage leaves the trailing words of buf[] holding leftover kernel stack. The only guard in the caller is err < 0, so those words are stored into status[]. They then reach user space: snd_rme_digiface_get_status_val() selects a 16-bit halfword of status[] per the control's reg/mask, and the eight Digiface status controls together expose the whole 16-byte frame to an unprivileged reader of /dev/snd/controlC*. Zero-initialise the buffer so a short read yields zeros instead of stack residue. This mirrors snd_rme_get_status1(), which already clears its output word before the same kind of vendor read. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74501", "url": "https://ubuntu.com/security/CVE-2026-74501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix use-after-free in ump_to_endpoint() create_midi2_ump() registers a card-owned snd_ump_endpoint and stores a back-pointer to its per-interface snd_usb_midi2_ump object in ump->private_data, but it never installs an ump->private_free hook and never clears that pointer. If a later step of snd_usb_midi_v2_create() fails, its error path calls free_all_midi2_umps(), which kfree()s the snd_usb_midi2_ump object while the already-registered endpoint keeps pointing at it. The created /dev/snd/umpC*D* node stays exposed, so the first operation of any UMP open, ump_to_endpoint(), dereferences the dangling ump->private_data and reads rmidi->eps[dir] out of freed memory. A malicious USB MIDI 2.0 device that makes creation fail after the endpoint is registered can thus trigger a slab use-after-free read on a subsequent open of the UMP node. Clear the endpoint's back-pointer before freeing the object, and let ump_to_endpoint() tolerate a NULL private_data so the open/close/trigger callbacks fail cleanly (their callers already handle a NULL endpoint) instead of dereferencing a stale pointer. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74502", "url": "https://ubuntu.com/security/CVE-2026-74502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ump: fix double free of out_cvts on rawmidi error snd_ump_attach_legacy_rawmidi() allocates the legacy conversion array ump->out_cvts and, on the snd_rawmidi_new() error path, frees it with kfree() but leaves ump->out_cvts pointing at the freed memory. When the endpoint is later torn down, snd_ump_endpoint_free() frees ump->out_cvts a second time, resulting in a double free. The host snd-usb-audio driver attaches the legacy rawmidi for any USB MIDI 2.0 (UMP) device, so a device that makes snd_rawmidi_new() fail reaches this path on enumeration. Clear ump->out_cvts after freeing it on the error path so it is not freed again during teardown. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74503", "url": "https://ubuntu.com/security/CVE-2026-74503", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: Clear SNDRV_TIMER_IFLG_DEAD once the close completes snd_timer_close_locked() marks an instance with SNDRV_TIMER_IFLG_DEAD and returns early when the flag is already set, but the flag is never cleared again. A completed close ends in remove_slave_links(), which leaves timeri->timer NULL, so a second close is already harmless through the timer == NULL path; the early return can only be reached by an instance that was opened again in between. For such an instance the close unlinks nothing, so snd_timer_instance_free() frees an object that is still on timer->open_list_head, still on snd_timer_master_list if it was opened with a slave key, still owns any adopted slaves, and still holds its timer and module references. snd_seq_timer_open() reopens an instance exactly like that: it retries its fallback open on the same object after a failure that has already run snd_timer_close_locked() internally. An unprivileged user with access to /dev/snd/timer and /dev/snd/seq can force that failure, since snd_timer_check_master() returns -EBUSY when a pending slave matches the new master's (slave_class, slave_id) key and the target timer has reached max_instances, and SNDRV_TIMER_IOCTL_SELECT with dev_class = SNDRV_TIMER_CLASS_SLAVE keeps the caller-supplied dev_sclass, so a sequencer queue's key can be forged. The freed instance is afterwards dereferenced by any further snd_timer_open() on that timer, by snd_timer_check_slave(), and by /proc/asound/timers, which faults on the stale ti->owner pointer. The flag only has to be visible while the close is in progress, which is all its other users need. Clear it in remove_slave_links(), under the same timer->lock that sets it, once the instance is off every list.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74504", "url": "https://ubuntu.com/security/CVE-2026-74504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix division by zero in initialize_timer() A userspace-driven ALSA timer (SND_UTIMER) lets an unprivileged user set the backing snd_timer's hardware resolution to an arbitrary 64-bit value via SNDRV_TIMER_IOCTL_CREATE. snd_utimer_create() only rejects zero. When such a timer is bound to a sequencer queue, initialize_timer() computes the tick period as \ttmr->ticks = 1000000000 / (r * freq); where r is that user-controlled resolution and freq is the sequencer update rate in Hz, clamped to MIN_FREQUENCY..MAX_FREQUENCY (10..6250). A resolution of 2^63 makes the 64-bit product r * freq wrap to zero for any even freq, including DEFAULT_FREQUENCY (1000), so the division faults with a divide-by-zero. The division runs under tmr->lock with interrupts disabled, so the oops leaves the spinlock held and hangs the CPU. It is reachable by an unprivileged user with access to /dev/snd/timer and /dev/snd/seq. Oops: divide error: 0000 [#1] SMP KASAN PTI CPU: 7 UID: 1000 PID: 456 Comm: alsa_seq_utimer Not tainted 7.2.0-rc4+ RIP: 0010:initialize_timer.constprop.0+0x20a/0x2d0 snd_seq_timer_start+0x15e/0x2b0 snd_seq_control_queue+0x56f/0xba0 snd_seq_write+0x3e0/0x730 Reject an overflowing product with check_mul_overflow() and fall back to a single tick, which also avoids feeding a wrapped-but-nonzero divisor (e.g. 2^63 * 1000 mod 2^64 == 0, or other resolutions wrapping to a small value) into the period computation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74505", "url": "https://ubuntu.com/security/CVE-2026-74505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Fix UAF at error handling during probe Although 6fire driver had a few fixes for dealing with the early error handling during the probe phase, it forgot a pending URB before freeing the resources, which may lead to a UAF. This patch addresses it by doing the almost same cleanup procedure like the normal disconnect phase at the error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74506", "url": "https://ubuntu.com/security/CVE-2026-74506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix UAF when sending a message In afs_make_call(), there's a race with async call reception and destruction. If a call is dispatched that doesn't have call->write_iter set (used to specify the data content for FS.StoreData), then the first rxrpc_kernel_send_data() will not set MSG_MORE in the msghdr. Once rxrpc_send_data() queues the last request packet, the response could come in at any time and cause the call to be completed and put. However, afs_make_call() will look at the call again to see it ->write_iter should be handled - something it's only allowed to do if it has its own ref on the call. Whilst this is the case for synchronous calls, it isn't true for async calls such as FS.FetchData. There's also a potential UAF in afs_make_call() in the event that an asynchronous call is being sent, but the call fails in some way (e.g. it gets aborted from the server). The problem there is that afs_make_call() tries to abort a call if the rxrpc send fails, but the asynchronous notification from rxrpc may have caused the afs_call to be torn down. generic/650 plays games with randomly taking CPUs offline, and can interject a significant delay such that the call is deallocated before afs_make_call() gets to check call->write_iter - and a UAF ensues (caught by KASAN). BUG: KASAN: slab-use-after-free in afs_make_call+0x1c90/0x2210 [kafs] Read of size 8 at addr ffff888035e050e8 by task fsstress/1409 Fix this by making afs_make_op_call() give the op->call its own ref rather than transferring the caller's ref to it and then dropping the ref when afs_make_call() returns. This also means that the afs_make_call() func never loses its ref on the call now.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74507", "url": "https://ubuntu.com/security/CVE-2026-74507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: validate numbered report payloads When hidp_get_raw_report() waits for a numbered report, hidp_process_data() compares the expected report number with skb->data[0]. A connected HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is removed. KMSAN reports an uninitialized-value use in hidp_session_run(), with the value originating in __alloc_skb() through vhci_write(). The transaction header checks remove the empty-frame reports, but this report remains until the payload check is added. The comparison can also consume a peer-controlled byte beyond the declared L2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made the current code accept that byte as report ID 1 and complete HIDIOCGFEATURE with a zero-byte result. With this change the malformed response is rejected with -EIO, while a subsequent valid response still succeeds. Require a payload byte before comparing a numbered report ID. Unnumbered reports continue to accept an empty payload.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74508", "url": "https://ubuntu.com/security/CVE-2026-74508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: reject frames without a transaction header hidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom. KMSAN reports the use in hidp_session_run(), with the uninitialized value originating in __alloc_skb() through vhci_write(). The control path produces two reports and the interrupt path produces one. The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDP_TRANS_HID_CONTROL | HIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds. Pull the transaction header with skb_pull_data() and discard frames that do not contain it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74509", "url": "https://ubuntu.com/security/CVE-2026-74509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Fix advertising data UAFs hci_find_adv_instance() returns an adv_info pointer that is valid only while hdev->lock is held. The advertising command-sync paths perform instance lookups without that lock and, in some cases, retain the pointer while waiting for a controller response. An advertising termination event can therefore interleave as follows: hci_cmd_sync_work hci_rx_work hci_find_adv_instance() __hci_cmd_sync_status() wait for controller reply hci_dev_lock() hci_remove_adv_instance() kfree(adv) adv->scan_rsp_changed = false KASAN reported: BUG: KASAN: slab-use-after-free in hci_set_ext_scan_rsp_data_sync+0x2e1/0x300 Write of size 1 at addr ffff88810a45d21d by task kworker/u17:0/88 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_set_ext_scan_rsp_data_sync+0x2e1/0x300 hci_schedule_adv_instance_sync+0x390/0x4c0 hci_cmd_sync_work+0x173/0x300 Allocated by task 87: hci_add_adv_instance+0x538/0xac0 add_advertising+0x885/0x1160 Freed by task 89: kfree+0x131/0x3c0 hci_remove_adv_instance+0x1d8/0x3b0 hci_le_ext_adv_term_evt+0x17b/0x730 Protect the instance lookup and payload construction in the extended advertising, scan response, and periodic advertising data paths. Snapshot the advertising parameters under hdev->lock, but release the lock before waiting for the controller. Clear advertising-data dirty bits before issuing their commands and restore them after a failure using a fresh lookup. Likewise, update the reported transmit power through a fresh lookup after the parameter command completes. No adv_info pointer then survives an HCI command wait.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74510", "url": "https://ubuntu.com/security/CVE-2026-74510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix UAF in pair command cancellation The pairing completion and authentication failure callbacks look up the pending MGMT_OP_PAIR_DEVICE command by walking hdev->mgmt_pending. The lookup returned a command that was still linked on the shared pending list, without keeping mgmt_pending_lock held for the later dereference and removal. A concurrent MGMT_OP_CANCEL_PAIR_DEVICE request can remove and free the same pending command before the callback uses it. The reverse race is also possible when cancel_pair_device() gets a command from pending_find() and a callback removes it before the cancel path dereferences it. This can lead to a use-after-free and a second list_del(). Make the pairing lookup helpers transfer ownership of the pending command by removing it from hdev->mgmt_pending while holding mgmt_pending_lock. The callbacks and cancel path then complete the command and free it directly, so racing paths cannot find or free the same command again. Take a temporary hci_conn reference in cancel_pair_device() because the command completion drops the reference stored in the pending command.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74511", "url": "https://ubuntu.com/security/CVE-2026-74511", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74512", "url": "https://ubuntu.com/security/CVE-2026-74512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix potential use-after-free in audit_del_rule() `audit_del_rule()` destroys `e->rule.exe` via `audit_remove_mark_rule()` before unlinking the rule from RCU-visible filter lists and waiting for a grace period. Concurrent readers in `audit_filter()` and `audit_filter_rules()` still dereference `e->rule.exe`, while the fsnotify mark can be freed on an independent lifetime path. This creates a use-after-free window during rule deletion. Fix this by unlinking the rule from the RCU-visible lists and invoking `synchronize_rcu()` before calling `audit_remove_mark_rule()` (and other rule removal helpers). This ensures that all existing RCU readers have exited the critical section before any underlying resources are destroyed.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74513", "url": "https://ubuntu.com/security/CVE-2026-74513", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dibs: fix use-after-free of dmb_node in loopback attach/detach/unregister dibs_lo_attach_dmb(), dibs_lo_detach_dmb() and dibs_lo_unregister_dmb() look up the dmb_node under dmb_ht_lock, drop the lock and only then operate on the node's refcount. Nothing keeps the node alive across that window: __dibs_lo_unregister_dmb() removes the node from the hash table under the write lock and immediately frees it. A concurrent final put can therefore free the node between the lookup and the refcount operation: CPU0 (attach) CPU1 (owner unregisters) read_lock_bh(&dmb_ht_lock) find dmb_node (refcnt == 1) read_unlock_bh(&dmb_ht_lock) refcount_dec_and_test() 1 -> 0 write_lock_bh(&dmb_ht_lock) hash_del(&dmb_node->list) write_unlock_bh(&dmb_ht_lock) kfree(dmb_node) refcount_inc_not_zero(&dmb_node->refcnt) <-- use-after-free The same window exists for the refcount_dec_and_test() calls in the detach and unregister paths. Close the race structurally by making hash table membership and the refcount transitions atomic with respect to each other: - Perform the final refcount_dec_and_test() and hash_del() in a single dmb_ht_lock write-side critical section, in both the unregister and the detach path. Freeing the node still happens after the lock is dropped, which is safe because a node whose refcount reached zero has left the hash table and can no longer be found. - This establishes the invariant that any node found in the hash table holds at least one reference, and that the final reference can only be dropped under the write lock. dibs_lo_attach_dmb() can thus take its reference with a plain refcount_inc() while still holding the read lock; refcount_inc_not_zero() is no longer needed. __dibs_lo_unregister_dmb() no longer touches the hash table and is renamed to dibs_lo_free_dmb() accordingly. Note: commit cc21191b584c (\"dibs: Move data path to dibs layer\") moved the code to its current location; the race was introduced earlier by commit c3a910f2380f (\"net/smc: implement DMB-merged operations of loopback-ism\"). Tested SMC-D via ISM and dibs loopback.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74514", "url": "https://ubuntu.com/security/CVE-2026-74514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Fix memory accounting for pinned/unpinned pages The account_mem() and unaccount_mem() functions call get_uid() which increments the reference count of struct user_struct on every invocation. But we don't decrement the count by calling free_uid(). It also accounted/unaccounted the pages against the current->mm. But its possible the unaccount_mem() can be called from a different process context than the one that originally pinned the pages. Let's fix this by storing the pinning process user_struct and mm_struct when accounting for pinned pages, and subsequently free these resources when the pages are unpinned. [borntraeger@linux.ibm.com: Fixed whitespace]", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74515", "url": "https://ubuntu.com/security/CVE-2026-74515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Reject adapter interrupt forwarding if already enabled The MPCIFC instruction doesn't allow registering adapter interrupts without first unregistering. So reject any request to enable interrupt forwarding if its already enabled for the zPCI device. This also fixes overwriting and thus leaking resources when the ioctl is called multiple times for the same device.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74516", "url": "https://ubuntu.com/security/CVE-2026-74516", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Update x2APIC MSR intercepts if AVIC is inhibited while L2 is active Always update x2APIC MSR intercepts for L1 when AVIC is deactivated, even if L2 is active and KVM is using a separate MSR bitmap to run L2. If AVIC is fully enabled prior to running L2, and is then inhibited while L2 is active (for a VM-scoped inhibit), then KVM will run L1 with AVIC disabled, but with x2APIC MSR intercepts disabled, i.e. will allow L1 to read most of the host's APIC state, send arbitrary interrupts, change task priority, and ultimately trivially DoS the host. E.g. sending a self-IPI in L1 on HYPERV_REENLIGHTENMENT_VECTOR, 0xee, with CONFIG_HYPERV=n in the host kernel as a \"safe\" PoC, yields: Spurious interrupt (vector 0xee) on CPU#425. Acked And hacking KVM to abuse kvm_set_posted_intr_wakeup_handler() to register a handler and WARN on POSTED_INTR_WAKEUP_VECTOR yields: ------------[ cut here ]------------ WARNING: arch/x86/kvm/svm/svm.c:5594 at pi_wakeup_handler+0x9/0x10 [kvm_amd], CPU#156: nested_x2apic_t/316940 CPU: 156 UID: 0 PID: 316940 Comm: nested_x2apic_t Tainted: G S U Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20260209.0-0 02/09/2026 RIP: 0010:pi_wakeup_handler+0x9/0x10 [kvm_amd] Call Trace: sysvec_kvm_posted_intr_wakeup_ipi+0x64/0x80 asm_sysvec_kvm_posted_intr_wakeup_ipi+0x1a/0x20 RIP: 0010:vcpu_run+0x1430/0x1e40 [kvm] kvm_arch_vcpu_ioctl_run+0x2c1/0x600 [kvm] kvm_vcpu_ioctl+0x580/0x6b0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46ff4b ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74518", "url": "https://ubuntu.com/security/CVE-2026-74518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix list corruption in allocate_file_region_entries() allocate_file_region_entries() tops up resv->region_cache with freshly allocated file_region descriptors. The allocation uses GFP_KERNEL, so resv->lock is dropped around it: the new entries are gathered on a stack-local list head, allocated_regions, and spliced into resv->region_cache once the lock is re-acquired. The splice used list_splice(), which moves the entries but does not re-initialize the source head, so allocated_regions is left pointing at an entry that now lives on resv->region_cache. The top-up runs in a while loop that re-checks the cache deficit after re-acquiring the lock. For a shared mapping the resv_map is shared by every mapper of the hugetlbfs inode, so a concurrent region_chg()/region_add()/region_del() on the same resv_map can consume cache entries during the unlocked window and force a second iteration. That iteration calls list_add() on the stale head and corrupts the list; with CONFIG_DEBUG_LIST the __list_add_valid() check trips: list_add corruption. next->prev should be prev (ffffc900011ff7f8), but was ffff88814c281460. (next=ffff88814c545640). kernel BUG at lib/list_debug.c:31! allocate_file_region_entries+0x191/0x420 region_chg+0x267/0x300 hugetlb_reserve_pages+0x387/0xc80 hugetlbfs_file_mmap+0x2ce/0x3f0 mmap_region+0x1348/0x1a80 do_mmap+0x85e/0xb90 vm_mmap_pgoff+0x18c/0x330 ksys_mmap_pgoff+0x2a1/0x3e0 do_syscall_64+0xd7/0x420 Without CONFIG_DEBUG_LIST the bad list_add() silently links a kernel-stack address into resv->region_cache, leading to later use-after-free. This was observed as a real host panic on a dense KVM host where a QEMU guest-RAM hugetlbfs file was mapped MAP_SHARED by both QEMU and a separate SPDK/DPDK vhost-user target, generating concurrent region_* traffic on one shared resv_map. Use list_splice_init() so the source head is re-initialized empty after each splice, making the retry loop safe.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74519", "url": "https://ubuntu.com/security/CVE-2026-74519", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: don't free uninitialized dev_name on error path dt_remember_or_free_map() duplicates dev_name for each map entry. If kstrdup_const() fails, dt_free_map() frees dev_name in all num_maps entries, including entries that have not been initialized. Some pinctrl drivers, including pinctrl-imx, allocate the map with kmalloc() and leave dev_name for the core to initialize. The untouched entries therefore contain uninitialized data which is passed to kfree_const(). Reproduced on qemu's mcimx6ul-evk (pinctrl-imx) with failslab injection while binding the pinctrl-consuming device, under KASAN: BUG: KASAN: double-free in dt_free_map+0x34/0xa4 Free of addr c425a900 by task init/1 kfree from dt_free_map+0x34/0xa4 dt_free_map from dt_remember_or_free_map+0x184/0x198 dt_remember_or_free_map from pinctrl_dt_to_map+0x33c/0x4c8 pinctrl_dt_to_map from create_pinctrl+0x9c/0x5c0 Initialize all dev_name fields to NULL before duplicating the device name, making the full-map cleanup safe after a partial failure.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74520", "url": "https://ubuntu.com/security/CVE-2026-74520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/iommufd: Fix IOPF group ownership UAF iopf_group_alloc() links each last-page IOPF group into the generic IOPF pending list before invoking the domain fault handler. iommufd_fault_iopf_handler() also queued an accepted group in the IOMMUFD deliver list without removing it from the generic pending list. When detach or HWPT replacement drops the device's IOPF reference count to zero, an IOMMU driver may call iopf_queue_remove_device(). That function responds to and frees groups through the generic pending list without removing the same groups from IOMMUFD's deliver list or response xarray. A later read, response, or cleanup can then access the freed group and cause a UAF. Fix this by dequeuing an accepted group from the generic pending list before IOMMUFD queues it for userspace response. Make iopf_group_response() send a response regardless of pending-list membership, so the dequeued group can still be completed by IOMMUFD.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74522", "url": "https://ubuntu.com/security/CVE-2026-74522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __close_file_table_ids() A ksmbd_file can remain alive after logical close while another session holds a temporary reference obtained through ksmbd_lookup_fd_inode(). ksmbd_close_fd() currently marks the file closed and drops the idr-owned reference, but leaves the pointer published in the closing session's idr until the final reference is dropped. If the foreign holder performs the final ksmbd_fd_put(), __put_fd_final() supplies the foreign session's file table to __ksmbd_close_fd(). The object is then freed without being removed from its owner's idr, and the owner session later dereferences the stale pointer during file-table teardown. Remove the volatile id from the owner's idr while ksmbd_close_fd() still holds that table's lock, and clear volatile_id before dropping the idr-owned reference. A later foreign final put then only performs physical destruction and cannot remove the object from the wrong table.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74523", "url": "https://ubuntu.com/security/CVE-2026-74523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: sync udp_tunnel ports outside qede_lock in the recovery path A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports configured wedges the rtnetlink control plane of the whole machine: NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2! [qede_recovery_handler:2665(ens6f0)]Starting a recovery process The recovery path deadlocks on the driver's own mutex: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- taken qede_recovery_handler qede_load udp_tunnel_nic_reset_ntf __udp_tunnel_nic_device_sync info->sync_table == qede_udp_tunnel_sync mutex_lock(&edev->qede_lock) <- same task: deadlock The mutex is not recursive, so the kworker blocks on itself with rtnl_lock held, and neither lock is ever released. Every task that calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnl_mutex.owner decodes to the very kworker blocked at the innermost mutex_lock() above. Re-sync the tunnel ports from qede_sp_task() after the internal lock is dropped, still under rtnl_lock as the udp_tunnel API requires. This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf() under rtnl without the internal lock. qede_recovery_handler() now returns whether it has successfully reloaded an open device, and the caller re-syncs the ports only in that case. This keeps the old gating exactly: a device that was down or a failed recovery returns false, as those paths never reached the udp_tunnel_nic_reset_ntf() call before either. This was the only user of the qede_lock()/qede_unlock() helpers, so remove them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74524", "url": "https://ubuntu.com/security/CVE-2026-74524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove remove_pud_mapping() and remove_p4d_mapping() obtain a child table base with pud_offset(p4dp, 0) and p4d_offset(pgd, 0), then add the index for addr. RISC-V folds page-table levels at runtime. When a level is folded, its offset helper returns the parent entry itself, but the index can still be nonzero. Adding it walks past the parent table. Sv48 folds P4D, while Sv39 folds both P4D and PUD, so memory hot-remove can descend into unrelated memory and pass an invalid page to __free_pages(). This can trigger: kernel BUG at include/linux/mm.h:1810! VM_BUG_ON_PAGE(page_ref_count(page) == 0) arch_remove_memory+0x1e/0x5c try_remove_memory+0x15e/0x200 remove_memory+0x24/0x3c Only add the index when the corresponding page-table level is enabled, matching p4d_offset() and pud_offset().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74525", "url": "https://ubuntu.com/security/CVE-2026-74525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: free TX rings on RX allocation failure When RX descriptor ring allocation fails, init_dma_desc_rings() only frees the partially allocated RX rings and returns. The TX rings that were allocated earlier in the same function are leaked. Rearrange error labels to clean up TX rings upon RX failures.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74531", "url": "https://ubuntu.com/security/CVE-2026-74531", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: hold conn reference in abort_conn_sync() There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74532", "url": "https://ubuntu.com/security/CVE-2026-74532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: Validate length before parsing diagnostics TLV btintel_diagnostics() accesses tlv->val[0] without first validating that the diagnostics VSE is long enough to contain that field, so may cause reading data beyond the received frame. Fix by validating the length before access.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74534", "url": "https://ubuntu.com/security/CVE-2026-74534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix refcounting of iso_conn iso_conn_del() and iso_chan_del() have a race that results to double-put of iso_conn: [Task hdev->workqueue] [Task 2] iso_conn_del iso_chan_del iso_conn_hold_unless_zero iso_conn_lock iso_conn_lock conn->sk = NULL iso_conn_unlock sk = iso_sock_hold(conn) <---------´ if (!sk) iso_conn_put iso_conn_put iso_conn_put /* UAF */ The extra put for !sk in iso_conn_del() is currently required since failing iso_chan_add() may leave iso_conn not associated with any sk. Fix by having iso_pi(sk)->conn own refcount when non-NULL, so iso_conn_del does not need to put it. Adjust the iso_conn_add() refcounting so that conn is put if it does not get associated with an sk.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74535", "url": "https://ubuntu.com/security/CVE-2026-74535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: avoid deadlocks in iso_sock_timeout iso_sock_timeout() takes lock_sock, so sync disabling the timer while holding that lock may deadlock. iso_sock_timeout() may also run concurrently with iso_conn_del(), which leads to UAF [Task 1] [Task hdev->workqueue] iso_sock_timeout iso_conn_del iso_conn_hold_unless_zero iso_chan_del `------------> iso_conn_put caller frees hcon iso_conn_put iso_conn_free conn->hcon->iso_data = NULL; /* UAF */ Fix the deadlock by removing the disable from the lock_sock sections. Move the timer from iso_conn to iso_pinfo to decouple it from iso_conn which may need to be freed in lock_sock section. Convert some of the clear_timer to disable_timer.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74536", "url": "https://ubuntu.com/security/CVE-2026-74536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix leaking sk after socket release iso_sock_kill() tests !sock_flag(sk, SOCK_ZAPPED) || sk->sk_socket || sock_flag(sk, SOCK_DEAD) for early return, but this is always true since sock_orphan(sk) sets SOCK_DEAD, so the sk reference released by socket always leaks, iso_sock_destruct is never called. The socket reference also leaks when __iso_sock_close() does not set SOCK_ZAPPED, since iso_conn_del() does not call iso_sock_kill() after zapping. Fix by replacing SOCK_DEAD by BT_SK_KILLED flag that is not used for something else, and lock_sock to ensure iso_sock_kill() puts sk only after socket release only once. Release and iso_conn_del may run concurrently. Call iso_sock_kill() from iso_conn_del() to clean sk up after zapping. Remove call to iso_sock_kill() from iso_sock_close(), as it's generally no-op there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74537", "url": "https://ubuntu.com/security/CVE-2026-74537", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: hold sk properly in iso_conn_ready sk deref in iso_conn_ready must be done either under conn->lock, or holding a refcount, to avoid concurrent close. conn->sk is currently accessed without either: [Task 1] [Task 2] iso_sock_release iso_conn_ready sk = conn->sk lock_sock(sk) conn->sk = NULL lock_sock(sk) release_sock(sk) iso_sock_kill(sk) UAF on sk deref Fix possible UAF by holding sk refcount in iso_conn_ready(). Also recheck after lock_sock that the socket is still valid. Adjust locking so conn->sk is cleared only under lock_sock.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74538", "url": "https://ubuntu.com/security/CVE-2026-74538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: lock sk in iso_connect_ind Accessing iso_pi(sk)->conn requires lock_sock, which is not taken in the \"ev3\" part of iso_connect_ind. It may also be NULL if socket has transitioned away from the LISTEN/CONNECT states before locking. Fix by adding lock/release. Recheck hcon is valid after lock acquire where needed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74539", "url": "https://ubuntu.com/security/CVE-2026-74539", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: lock sk in iso_sock_getname Accessing iso_pi(sk)->conn requires lock_sock, which is not held here. Fix by adding the lock/release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74540", "url": "https://ubuntu.com/security/CVE-2026-74540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74541", "url": "https://ubuntu.com/security/CVE-2026-74541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: clear iso_data always when detaching conn from hcon When setting conn->hcon = NULL, also conn->hcon->iso_data = NULL is necessary, otherwise later iso_conn_free() will UAF. Fix clearing of iso_data in iso_sock_disconn() Fixes KASAN: slab-use-after-free in iso_conn_hold_unless_zero on iso_sock_release() followed by hci_abort_conn_sync().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74543", "url": "https://ubuntu.com/security/CVE-2026-74543", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: udp_tunnel: fix memory leak in udp_tunnel_nic_unregister() syzbot reported a memory leak [1] in the UDP tunnel NIC offload code. When device registration fails (e.g. in register_netdevice()), netdev core unwinds by sending a single NETDEV_UNREGISTER notification. If work was queued during NETDEV_REGISTER (utn->work_pending is set), udp_tunnel_nic_unregister() returns early: \tif (utn->work_pending) \t\treturn; Because failed registrations do not enter netdev_wait_allrefs_any(), no subsequent NETDEV_UNREGISTER rebroadcast will ever occur. As a result, the struct udp_tunnel_nic allocated in udp_tunnel_nic_alloc() is leaked permanently. Fix this by removing the early return. Instead, synchronously cancel any pending work with cancel_delayed_work_sync() before freeing @utn. To be able to call cancel_delayed_work_sync() while holding RTNL (the work also needs RTNL), switch udp_tunnel_nic_device_sync_work() to rtnl_trylock(). If RTNL is contended, requeue the work with a 1 jiffy delay (via queue_delayed_work()) to prevent high CPU contention while waiting for RTNL lock. The utn->work_pending bookkeeping is no longer needed and is removed, as the workqueue core already tracks the pending/running state of the work. [1] BUG: memory leak unreferenced object 0xffff888127d5f840 (size 96): comm \"syz-executor\", pid 5806, jiffies 4294942188 backtrace (crc 99fdb6c8): __kmalloc_noprof+0x3bf/0x550 udp_tunnel_nic_alloc net/ipv4/udp_tunnel_nic.c:756 [inline] udp_tunnel_nic_register net/ipv4/udp_tunnel_nic.c:833 [inline] udp_tunnel_nic_netdevice_event+0x804/0xab0 net/ipv4/udp_tunnel_nic.c:931 notifier_call_chain+0x59/0x160 kernel/notifier.c:85 call_netdevice_notifiers_info+0x7d/0xb0 net/core/dev.c:2250 register_netdevice+0xc10/0xeb0 net/core/dev.c:11478", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74545", "url": "https://ubuntu.com/security/CVE-2026-74545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: fix double free of multi-frag skb on DMA map failure In rtase_start_xmit(), when the head buffer DMA mapping fails after rtase_xmit_frags() has mapped all fragments, the error path clears the fragment descriptors with rtase_tx_clear_range(), which frees the skb through the last-frag slot and accounts tx_dropped. Control then falls through to the common error label, which frees the same skb a second time and counts it again. Return right after clearing the fragments when the skb owns frags; the no-frag case still drops through and frees the head skb once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74546", "url": "https://ubuntu.com/security/CVE-2026-74546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read If the fan data becomes 0 between the FAN_DATA_VALID() check and the FAN_PERIOD_TO_RPM() conversion, it will result in a divide-by-zero crash due to a race with a concurrent update of the cached fan value. Fix a TOCTOU issue by reading fan data once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74547", "url": "https://ubuntu.com/security/CVE-2026-74547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread When userspace configures 'auto_update_interval' to 0 via sysfs, the background kthread executes schedule_timeout_interruptible(0), which returns immediately. If 'num_temp_sensors' is concurrently or previously set to 0, the msleep_interruptible() delay inside adt7470_read_temperatures() also becomes 0. This combination forces the background thread into a tight, unbounded busy-loop, hogging the CPU and flooding the I2C bus with a continuous stream of transactions. Fix this vulnerability by raising the lower limit of the clamp_val in auto_update_interval_store() from 0 to 500 milliseconds. This guarantees a reasonable minimum sleep window between sensor updates, protecting the system from intentional or accidental I2C bus denial of service.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74548", "url": "https://ubuntu.com/security/CVE-2026-74548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix UAF of txrx_stats in nv_remove nv_remove() frees the per-CPU txrx_stats before unregister_netdev(). Until unregister completes, ndo_get_stats64, the NAPI/xmit data path, and nv_close()/drain may still access txrx_stats, leading to a use-after-free. Free the stats only after unregister_netdev().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74549", "url": "https://ubuntu.com/security/CVE-2026-74549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Prevent access to unsupported weight registers Sashiko reports: During initialization of the nct6116 chip, the driver sets data->pwm_num to 5. However, it assigns several NCT6106 register arrays (such as NCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and NCT6106_REG_WEIGHT_TEMP_*) to data->REG_PWM and data->REG_WEIGHT_TEMP. These arrays only contain 3 elements. In nct6775_update_pwm(), the driver iterates up to data->pwm_num. If data->has_pwm has bits 3 or 4 set (which is structurally possible for nct6116), the loop attempts to read elements at index 3 and 4 from these 3-element arrays. This results in a global out-of-bounds read, which can be caught by KASAN. Furthermore, the driver uses these garbage out-of-bounds values as hardware register addresses for subsequent read and write operations. This leads to invalid hardware register access, potentially causing hardware misconfiguration or system crashes. The underlying problem is that the chip does support up to five fan control channels, but only the first three support weight control. Fix the problem by extending the affected weight register arrays with zeroed fields. The driver uses zeroed register addresses to determine if a register is supported or not, and skips accesses for unsupported registers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74550", "url": "https://ubuntu.com/security/CVE-2026-74550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not send ICMP/NDISC Redirects when peer allocation fails When inet_getpeer_v4() or inet_getpeer_v6() fails to allocate a peer entry under memory pressure or tree size caps, redirect handlers previously fell back to sending un-rate-limited ICMP/NDISC Redirect messages. In IPv4, ip_rt_send_redirect() called icmp_send() directly when peer == NULL. In IPv6, ip6_forward() and ndisc_send_redirect() passed a NULL peer into inet_peer_xrlim_allow(), which returned true when peer == NULL. Because ICMP/NDISC Redirects are not part of the default global rate limit mask (sysctl_icmp_ratemask), sending redirects when peer == NULL creates an un-rate-limited ICMP packet storm. Fix this by failing closed in ip_rt_send_redirect(), ip6_forward(), and ndisc_send_redirect() when peer is NULL.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74551", "url": "https://ubuntu.com/security/CVE-2026-74551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) DMA-align output buffer Sashiko reports: When send_output_report() calls hid_hw_output_report(), the underlying USB HID core calls usb_interrupt_msg() which maps this buffer directly for DMA. When the DMA mapping flushes or invalidates the cacheline, it will corrupt the adjacent variables (mutex, update_interval) that were modified concurrently by the CPU. This causes memory corruption due to cacheline sharing on non-coherent CPU architectures (such as ARM or MIPS). The DMA API debugging tool (CONFIG_DMA_API_DEBUG) will trigger runtime warnings for this violation. Any operation that triggers send_output_report() (like setting a fan speed or updating the interval) causes the USB DMA mapping. On systems with non-coherent caches, this structural bug causes immediate and deterministic memory corruption. Align the output buffer to ARCH_DMA_MINALIGN to fix the problem.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74552", "url": "https://ubuntu.com/security/CVE-2026-74552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm90) Only report alarms if driver is ready Userspace can read sysfs attributes before driver registration is complete, immediately after devm_hwmon_device_register_with_info() has been called. At that time, data->hwmon_dev is not yet initialized. This can trigger a NULL pointer access since lm90_update_device() and with it lm90_update_alarms_locked() will be called. This call schedules report_work and lm90_report_alarms(), which passes the still-NULL data->hwmon_dev to hwmon_notify_event() and triggers a NULL pointer dereference. Fix the problem by only scheduling the report and alert workers data->hwmon_dev is set.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74553", "url": "https://ubuntu.com/security/CVE-2026-74553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Fix number of temperature registers for NCT6116 Unlike NCT6106, NCT6116 only has three temperature registers, and with it only three temperature source and temperature source configuration registers. The register addresses match those of NCT6106 and can be re-used. The code used a separate array to list the temperature source registers for NCT6116, but used the size of the NCT6106 register array to set the number of registers. The NCT6106 register array provides six addresses, while the temperature source register array for NCT6116 only provides three addresses. This causes a KASAN report. BUG: KASAN: global-out-of-bounds in nct6775_probe+0x936/0x46f0 [nct6775] Read of size 2 at addr ffffffffc19561a6 by task modprobe/954 ... Call Trace: dump_stack+0x7d/0xa7 print_address_description.constprop.0+0x1c/0x220 ? __kasan_kmalloc.constprop.0+0xc9/0xd0 ? __kmalloc_node_track_caller+0x194/0x5b0 ? nct6775_probe+0x936/0x46f0 [nct6775] ? nct6775_probe+0x936/0x46f0 [nct6775] ... Fix the problem by hard-coding the number of temperature and temperature configuration registers to three for NCT6116. Drop the unnecessary NCT6116_REG_TEMP_SOURCE array and re-use NCT6106_REG_TEMP_SOURCE.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74555", "url": "https://ubuntu.com/security/CVE-2026-74555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race Commit fbefe22811c3 (\"scsi: libsas: Don't always drain event workqueue for HA resume\") introduced sas_resume_ha_no_sync() to avoid a deadlock: the PHYE_RESUME_TIMEOUT handler, running on the HA event workqueue, calls sas_deform_port() -> sas_destruct_devices(), which removes SCSI devices and waits for the host to become runtime-active. But the host cannot resume until sas_resume_ha() -> sas_drain_work() returns, and the drain is blocked on that very handler. However skipping the drain reintroduces a race: hisi_sas returns from resume before all PHY UP work and libsas discovery work finish. The controller may then autosuspend while disks are still waking up. The disks issue IO to a suspended controller, the IO fails, and the disks get disabled. Fix the deadlock at its source by moving the PHYE_RESUME_TIMEOUT notification to after sas_drain_work(). By then the host resume is about to complete, so device removal through device_link no longer blocks on the resume and the cycle is broken. With the deadlock gone, restore sas_resume_ha() (the draining variant) in hisi_sas and remove sas_resume_ha_no_sync(). The reorder is safe for the other libsas consumers (isci, pm8001, aic94xx, mvsas). During suspend, sas_suspend_devices() calls sas_notify_lldd_dev_gone() for each device, which sets dev->lldd_dev to NULL. When scsi_unblock_requests re-enables I/O in resume, any I/O to a timed-out phy's disk is immediately rejected by the LLDD before reaching hardware: isci returns SAS_DEVICE_UNKNOWN (mapped to DID_BAD_TARGET), and pm8001 returns SAS_PHY_DOWN (mapped to DID_NO_CONNECT). Both complete directly via scsi_done() without entering SCSI EH. This is identical in both the old and new ordering since lldd_dev_gone runs during suspend, before resume. The reorder only affects when the PHYE_RESUME_TIMEOUT handler runs (synchronized by sas_drain_work() vs. asynchronous after resume returns), not whether I/O can reach the device. aic94xx and mvsas do not register any PM ops and never reach this code path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74556", "url": "https://ubuntu.com/security/CVE-2026-74556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer iscsi_tcp_hdr_dissect() receives the data segment of several PDU types into the fixed-size conn->data buffer, which is allocated for ISCSI_DEF_MAX_RECV_SEG_LEN (8192) bytes. For the LOGIN_RSP, TEXT_RSP, REJECT and ASYNC_EVENT opcodes the dissect path already rejects a PDU whose DataSegmentLength exceeds that buffer. The SCSI Command Response (ISCSI_OP_SCSI_CMD_RSP) path also copies its data segment (sense/response data) into conn->data via iscsi_tcp_data_recv_prep(), but it does so without the same check. The only upstream bound on in.datalen is conn->max_recv_dlength, the initiator's advertised MaxRecvDataSegmentLength, which is commonly negotiated well above 8192 (open-iscsi defaults to 262144). A target that returns a SCSI Response with a DataSegmentLength between 8193 and max_recv_dlength therefore overflows the 8192-byte conn->data buffer. Once the same bound applies, ISCSI_OP_SCSI_CMD_RSP is handled exactly like those responses: bound the data segment, receive it into conn->data when present, and otherwise complete the PDU with no data. Fold the opcode into that case group rather than duplicating the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74557", "url": "https://ubuntu.com/security/CVE-2026-74557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer iscsi_scsi_cmd_rsp() copies the sense data of a SCSI Response from the target-supplied data segment. The segment carries a 2-byte sense length followed by the sense bytes, so it must hold 2 + senselen bytes, but the bounds check only requires datalen >= senselen: \tsenselen = get_unaligned_be16(data); \tif (datalen < senselen) \t\tgoto invalid_datalen; \tmemcpy(sc->sense_buffer, data + 2, \t min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE)); A target that returns a SCSI Response whose datalen equals senselen (with senselen <= SCSI_SENSE_BUFFERSIZE) makes the memcpy() from data + 2 read up to two bytes past the received data. Those bytes are stale conn->data contents and end up in the command's sense buffer, which is returned to userspace. Account for the 2-byte sense length prefix in the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74559", "url": "https://ubuntu.com/security/CVE-2026-74559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: drain continuation descs after overflow in xsk_build_skb() Fix generic xmit path multi-buffer logic when packets are either too big (count of descriptors exceed MAX_SKB_FRAGS) or an invalid descriptor is included in fragmented packet. Introduce xdp_sock::drain_cont and act upon this flag - when it is set, keep on consuming descriptors from AF_XDP Tx ring and put them directly onto Cq. Previously these descriptors were silently lost and could never be reached again.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74560", "url": "https://ubuntu.com/security/CVE-2026-74560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: fix buffer leak in xsk_drop_skb() for AF_XDP multi-buffer Tx This patch is inspired by the check[1] from sashiko. It says when overflow happens, the address of cq to be published is invalid. Actually the severer thing is the whole process of publishing the address of cq in this particular case is not right: it should truely publish the address and advance the cached_prod in cq as long as it reads descriptors from txq. The following is the full analysis. xsk_drop_skb() is called in three places, which all discard a partially built multi-buffer skb: 1) xsk_build_skb() -EOVERFLOW error path: packet exceeds MAX_SKB_FRAGS 2) __xsk_generic_xmit() post-loop cleanup: an invalid descriptor in the TX ring prevents the partial packet from completing 3) xsk_release(): socket close while xs->skb holds an incomplete packet In all three cases, the TX descriptors for the already-processed frags have been consumed from the TX ring (xskq_cons_release), and CQ slots have been reserved. However, xsk_drop_skb() calls xsk_consume_skb() which cancels the CQ reservations via xsk_cq_cancel_locked(). Since the buffer addresses never appear in the completion queue, userspace permanently loses track of these buffers. Fix this by letting consume_skb() trigger the existing xsk_destruct_skb destructor, which already submits buffer addresses to the CQ via xsk_cq_submit_addr_locked(). Note that cancelling the descriptors back to the TX ring (via xskq_cons_cancel_n) is not a appropriate option because an oversized packet that always exceeds MAX_SKB_FRAGS would be retried indefinitely, which is an obviously deadlock bug in the TX path. Also move the desc->addr assignment in xsk_build_skb() above the overflow check so that the current descriptor's address is recorded before a potential -EOVERFLOW jump to free_err, consistent with the zerocopy path in xsk_build_skb_zerocopy(). [1]: https://lore.kernel.org/all/20260425041726.85FB3C2BCB2@smtp.kernel.org/", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74563", "url": "https://ubuntu.com/security/CVE-2026-74563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: hold the RCU lock across ipv6_chk_addr() in rds_tcp_laddr_check() rds_tcp_laddr_check() looks up a scoped IPv6 interface with dev_get_by_index_rcu(), drops the RCU read-side lock, and only then passes the bare struct net_device * into ipv6_chk_addr(). dev_get_by_index_rcu() only keeps the device alive within the same RCU read-side section. After rcu_read_unlock(), a concurrent RTM_DELLINK can free the net_device; ipv6_chk_addr() then dereferences the stale pointer in __ipv6_chk_addr_and_flags() (e.g. l3mdev_master_dev_rcu(dev)), reading freed memory. Keep the RCU read-side lock held across the ipv6_chk_addr() call instead of dropping it right after the lookup, so the device cannot be freed while it is in use. BUG: KASAN: slab-use-after-free in __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) Read of size 8 at addr ffff8880106ec000 by task exploit/153 Call Trace: ... kasan_report (mm/kasan/report.c:595) __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) ipv6_chk_addr (net/ipv6/addrconf.c:2031 net/ipv6/addrconf.c:1972) rds_tcp_laddr_check (net/rds/tcp.c:370) rds_bind (net/rds/bind.c:248) __sys_bind (net/socket.c:1920) __x64_sys_bind (net/socket.c:1956) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74579", "url": "https://ubuntu.com/security/CVE-2026-74579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: fix mask build for partial field offload nft_payload_offload_mask() builds the offload match mask for a payload expression that covers only part of a header field. For a partial IPv6 address match (field_len = 16, priv_len = 1) that shift is 1 << 120, which is undefined on the 32-bit int operand. It also trims only one word, so the remaining words stay 0xffffffff (and when priv_len is a multiple of 4 the trim is skipped entirely), leaving the mask covering more bytes than the rule matches. UBSAN: shift-out-of-bounds in net/netfilter/nft_payload.c:278:20 shift exponent 120 is too large for 32-bit type 'int' ... The match is byte-granular and struct nft_data is zero-initialised, so the correct mask is simply the first priv_len bytes set to 0xff. Set those bytes directly and drop the word/shift trimming; this removes the undefined shift and no longer over-masks the trailing bytes.", "cve_priority": "medium", "cve_public_date": "2026-08-17 06:19:00 UTC" }, { "cve": "CVE-2026-74564", "url": "https://ubuntu.com/security/CVE-2026-74564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_hashlimit: validate hashtable supports XT_HASHLIMIT_RATE_MATCH The XT_HASHLIMIT_RATE_MATCH flag mode changes the semantics of the dsthash_ent structure which represents an entry in the hashtable. There is a union area which uses a different layout to express the rate match mode. Update .checkentry path to validate the XT_HASHLIMIT_RATE_MATCH mode flag is requested by two or more different rules that refer to the same hashtable. Otherwise, uninitialized access to the burst field in the union is possible. Reject the use of the XT_HASHLIMIT_RATE_MATCH mode flag if set on by revision less than 3 too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74565", "url": "https://ubuntu.com/security/CVE-2026-74565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: make nft_object rhltable per table The nft_object rhltable is global, this allows for accessing objects that are being dismangled from lookup path by other existing netns. Given the nft_obj_destroy() releases the object inmediately, this might lead to use-after-free of these objects that are being released. Make the existing rhltable per table to address this issue to deal with with the nft_rcv_nl_event() path too. Update nft_obj_lookup() to take the table as non-const, otherwise, compiler complains when passing the objname_ht to rhltable_lookup().", "cve_priority": "high", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74566", "url": "https://ubuntu.com/security/CVE-2026-74566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: make keyring key-chunk byte order agree with keyring_diff_objects() keyring_get_key_chunk() loads description bytes into the index chunk low address first, while keyring_diff_objects() numbers the first differing bit from the low end and folds the absolute byte index into the level without removing the inline-prefix offset the level already carries. The two disagree on byte order and bit position, so the array can be told two keys first differ at a bit that does not differ in the chunk the walker uses, letting crafted descriptions collide into one node. Load the chunk in the order keyring_diff_objects() assumes and drop the inline-prefix length when folding the byte index into the level. This only changes the in-memory ordering used to place keys within a keyring; add, search and read of non-colliding keys are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74567", "url": "https://ubuntu.com/security/CVE-2026-74567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: fix out-of-bounds read in keyring_get_key_chunk() For description-level chunks keyring_get_key_chunk() advances the read pointer by level * sizeof(long) past the inline prefix but only bounds-checks the prefix, so a long enough key description is read past its kmemdup(desc, desc_len + 1) allocation. Compute the full byte offset and bounds-check the description against it before reading. The walk only reaches a description-level chunk when two keys collide through the hash, x, type and domain_tag chunks, so this is reached from an unprivileged add_key(2) with a crafted pair of same-type keys whose index hashes collide; KASAN reports a slab-out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74569", "url": "https://ubuntu.com/security/CVE-2026-74569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in sip_help_tcp() sip_help_tcp() stores the size change of each NAT-rewritten SIP message in s16 diff and accumulates it in s16 tdiff, but a single message can grow by more than S16_MAX while the packet stays under the 65535 enlarge_skb() limit: nf_nat_sip() rewrites every matching URI, and a long Contact list expands the message by tens of kilobytes. diff then wraps, and \"datalen = datalen + diff - msglen\" yields a huge unsigned datalen, so the next iteration's ct_sip_get_header() reads past the linearized skb tail. Widen diff, tdiff and the seq_adjust hook to s32. Both are bounded by the 65535 byte packet limit, and the seqadj core is already s32 (nf_ct_seqadj_set() takes s32), so no previously accepted input is rejected. BUG: KASAN: use-after-free in ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) Read of size 1 at addr ffff888010800000 by task ksoftirqd/1/25 ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) sip_help_tcp (net/netfilter/nf_conntrack_sip.c:1694) nf_confirm (net/netfilter/nf_conntrack_proto.c:183) nf_hook_slow (net/netfilter/core.c:619) ip6_output (net/ipv6/ip6_output.c:246) ip6_forward (net/ipv6/ip6_output.c:690) ipv6_rcv (net/ipv6/ip6_input.c:351) __netif_receive_skb_one_core (net/core/dev.c:6212) process_backlog (net/core/dev.c:6676) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ...", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74572", "url": "https://ubuntu.com/security/CVE-2026-74572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix deadlock between metadata writeback and transaction commit When writing out metadata extent buffers in a zoned filesystem, btree_writepages() holds fs_info->zoned_meta_io_lock across the whole writeback loop, including the call to btrfs_check_meta_write_pointer() -> check_bg_is_active(). For the tree-log block group, check_bg_is_active() may fail to activate the zone and fall back to btrfs_zone_finish_one_bg() to free an active zone. That path waits for the running transaction to commit while still holding zoned_meta_io_lock, but the committer needs that same lock to write out the tree extents, so the two tasks deadlock: Task A (kworker, metadata writeback) Task B (fsstress, transaction commit) ------------------------------------ ------------------------------------- wb_workfn() btrfs_commit_transaction(T) btree_writepages() btrfs_write_and_wait_transaction() btrfs_zoned_meta_io_lock() btrfs_write_marked_extents() btrfs_check_meta_write_pointer() btree_writepages() check_bg_is_active() [treelog_bg] btrfs_zoned_meta_io_lock() btrfs_zone_finish_one_bg() do_zone_finish() btrfs_inc_block_group_ro() btrfs_wait_for_commit() The sibling branch in check_bg_is_active() already drops zoned_meta_io_lock around do_zone_finish() for this exact reason. Do the same in the tree-log branch: release the lock around btrfs_zone_finish_one_bg() and re-acquire it afterwards. The lock only protects fs_info->active_{meta,system}_bg, which this branch does not touch, and ctx->zoned_bg keeps a reference to the block group across the unlock, so nothing is lost while the lock is dropped. This hang occasionally reproduces with fstests generic/475 on a zoned btrfs filesystem.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74573", "url": "https://ubuntu.com/security/CVE-2026-74573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3-iommufd: Require exactly one Stream ID for a vDEVICE arm_vsmmu_vsid_to_sid() maps a guest's vSID to a single physical Stream ID taken from master->streams[0], assuming a device has exactly one stream. A device with several streams gets only its first one mapped, so a guest vSID invalidation cannot reach the others' ATC and IOTLB entries; a device with none makes master->streams a ZERO_SIZE_PTR, read out of bounds. Add an arm_vsmmu_vdevice_init() op to reject the vDEVICE with -EOPNOTSUPP when master->num_streams is not one, rather than mapping it silently.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74574", "url": "https://ubuntu.com/security/CVE-2026-74574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix fdev setup failure cleanup in idxd_cdev_open() The failed_dev_add and failed_dev_name paths drop the file-device reference while wq->wq_lock is still held. If put_device(fdev) drops the last reference, idxd_file_dev_release() runs synchronously and tries to take wq->wq_lock again, deadlocking. Those paths also fall through into the later ctx cleanup labels even though idxd_file_dev_release() owns that cleanup and frees ctx. This can make idxd_xa_pasid_remove(ctx) and kfree(ctx) operate on a freed context. Move idxd_wq_get() before file-device setup can fail, since the release callback always calls idxd_wq_put(). Then unlock wq->wq_lock before put_device(fdev) and return directly from the file-device setup failure path, leaving ctx cleanup to the release callback.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74575", "url": "https://ubuntu.com/security/CVE-2026-74575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Prevent XDomain delayed work use-after-free on disconnect tb_xdp_handle_request() runs on system_wq and queues xd->state_work via queue_delayed_work() in three request handlers: PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake), and LINK_STATE_CHANGE_REQUEST. Similarly, update_xdomain() queues xd->properties_changed_work when local properties change. Concurrently, tb_xdomain_remove() calls stop_handshake() which does cancel_delayed_work_sync() on both delayed works. Later, tb_xdomain_unregister() calls device_unregister() which eventually frees the xdomain. Since commit 559c1e1e0134 (\"thunderbolt: Run tb_xdp_handle_request() in system workqueue\") moved the request handler off tb->wq, the handler and the remove path are no longer serialized. If queue_delayed_work() executes after cancel_delayed_work_sync() but before the xdomain is freed, the delayed work fires on a freed object. Add xd->removing that tb_xdomain_remove() sets under xd->lock before calling stop_handshake(). Each external queue site holds the same lock and checks removing before calling queue_delayed_work(). This provides the mutual exclusion needed: either the queue site acquires the lock first and queues work that the subsequent cancel will see, or the remove path acquires the lock first and the queue site observes removing == true and skips the queue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74576", "url": "https://ubuntu.com/security/CVE-2026-74576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: prevent unbounded recursion in free path with new kmalloc type Commit 280ea9c3154b (\"mm/slab: avoid allocating slabobj_ext array from its own slab\") avoided recursive allocation of obj_exts from kmalloc caches of the same size, by bumping the obj_exts array's allocation size whenever the array size equals the size of the object being allocated. However, as reported by Danielle Costantino and Shakeel Butt, even slabs from kmalloc caches of different sizes can form a cycle by allocating obj_exts arrays from each other [1]: What happened: a KMALLOC_NORMAL slab's obj_exts array (used by allocation profiling / memcg accounting) is itself kmalloc()'d from a KMALLOC_NORMAL cache, so the \"slab holds another slab's obj_exts array\" relation can form cycles. With sizeof(struct slabobj_ext) == 16 and the host's geometry: - kmalloc-512 has 64 objects/slab -> array is 64*16 == 1024 bytes, served from kmalloc-1k; - kmalloc-1k has 32 objects/slab -> array is 32*16 == 512 bytes, served from kmalloc-512. A kmalloc-512 slab and a kmalloc-1k slab therefore hold each other's obj_exts array. Discarding one frees the other's array, which empties and discards that slab, which frees the first's array, and so on: __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() -> __free_slab() recurses along the cycle until the stack is exhausted. With memory allocation profiling, this allows unbounded recursion in the free path and led to a stack overflow on a production host in the Meta fleet [1]: BUG: TASK stack guard page was hit Oops: stack guard page RIP: 0010:kfree+0x8/0x5d0 Call Trace: __free_slab+0x66/0xc0 kfree+0x3f0/0x5d0 ... ( ~125x __free_slab <-> kfree ) ... do_syscall_64 It is proposed [1] to resolve this issue by always serving the obj_exts array allocation from kmalloc caches (or large kmalloc) of sizes larger than the object size. However, as pointed out by Vlastimil Babka [2], this can waste an excessive amount of memory as slabs from large kmalloc sizes (e.g. kmalloc-8k) generally need obj_exts arrays much smaller than the object size. Therefore, rather than bumping the size, let us take a different approach; disallow formation of cycles between kmalloc types when allocating obj_exts arrays. Currently, all obj_exts arrays are served from normal kmalloc caches. Cycles cannot be created if obj_exts arrays of normal kmalloc caches are served from a special kmalloc type that can never have obj_exts arrays. To achieve this, create a new kmalloc type called KMALLOC_NO_OBJ_EXT. KMALLOC_NO_OBJ_EXT caches are created with SLAB_NO_OBJ_EXT flag when either 1) memory allocation profiling is not permanently disabled, or 2) kmalloc types with a priority higher than KMALLOC_CGROUP are aliased with KMALLOC_NORMAL. Sheaf bootstrapping for KMALLOC_NO_OBJ_EXT caches now must be deferred because allocation of a barn can trigger obj_exts array allocation of normal kmalloc caches when the KMALLOC_NO_OBJ_EXT cache for that size is not ready yet. For simplicity, perform bootstrapping of sheaves for all kmalloc caches later. Introduce a new slab alloc flag, SLAB_ALLOC_NO_OBJ_EXT, to prevent allocation of obj_exts arrays, and let kmalloc_slab() override the type to KMALLOC_NO_OBJ_EXT when specified. Note that kmalloc_type() remains unchanged because kmalloc_flags() bypasses the kmalloc fastpath. Do not pass SLAB_ALLOC_NO_RECURSE to kmalloc_flags() in alloc_slab_obj_exts() and instead use SLAB_ALLOC_NO_OBJ_EXT only when the objects are allocated from normal kmalloc caches. While this prevents unbounded recursive allocation of obj_exts, it allows KMALLOC_NO_OBJ_EXT caches to have sheaves. Since sheaf allocations specify SLAB_ALLOC_NO_RECURSE that prevents allocation of both sheaves and obj_exts arrays, the recursion depth is bounded. obj_exts arrays for non- ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74577", "url": "https://ubuntu.com/security/CVE-2026-74577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: initialize rtm_tos in mpls_getroute() mpls_getroute() builds the RTM_NEWROUTE reply to an RTM_GETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (alloc_skb(NLMSG_GOODSIZE, ...)). It sets every field of the header except rtm_tos: \tr = nlmsg_data(nlh); \tr->rtm_family\t = AF_MPLS; \tr->rtm_dst_len\t= 20; \tr->rtm_src_len\t= 0; \tr->rtm_table\t= RT_TABLE_MAIN; \tr->rtm_type\t= RTN_UNICAST; \tr->rtm_scope\t= RT_SCOPE_UNIVERSE; \tr->rtm_protocol = rt->rt_protocol; \tr->rtm_flags\t= 0; struct rtmsg has no padding, so the one uninitialised byte rtm_tos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mpls_dump_route(), which fills the very same header and does set rtm_tos = 0. Initialize rtm_tos to 0, matching mpls_dump_route(). Reproduced with KMSAN by adding an MPLS route and issuing a non-RTM_F_FIB_MATCH RTM_GETROUTE for its label: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x36c/0x33f0 _copy_to_iter+0x36c/0x33f0 __skb_datagram_iter+0x196/0x12c0 skb_copy_datagram_iter+0x5b/0x210 netlink_recvmsg+0x37b/0xef0 ... Uninit was created at: __alloc_skb+0x8ca/0x10e0 mpls_getroute+0x1280/0x3a40 rtnetlink_rcv_msg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized (byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtm_tos)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" } ], "launchpad_bugs_fixed": [ 2170920, 2170001, 2163215, 2166838, 2169175, 2169736, 2169900, 2169641, 2169641, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2168074, 2168012, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167609, 2167609, 2167609, 2167609, 2167609, 2167609, 2167609, 2167609, 2167609, 2167609, 2165251, 2162917, 2166944, 2160475, 2166631, 2165732, 2148534, 2158217, 2158540, 2166235, 2166181, 2166517, 2166363, 2166363, 2166363, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2166730, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2162038, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942 ], "changes": [ { "cves": [], "log": [ "", " * resolute/linux: 7.0.0-42.42 -proposed tracker (LP: #2170920)", "", " * Miscellaneous Ubuntu changes", " - SAUCE: Revert \"powerpc: Don't drop _TIF_RESTOREALL on syscall restart\"", "" ], "package": "linux", "version": "7.0.0-42.42", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 2170920 ], "author": "Mehmet Basaran ", "date": "Thu, 15 Oct 2026 09:48:46 +0300" }, { "cves": [ { "cve": "CVE-2026-98163", "url": "https://ubuntu.com/security/CVE-2026-98163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup: Avoid iteration of dying tasks with zero refcount The commit 260fbcb92bbea (\"cgroup: Move dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()\") extended the lifetime of tasks on the dying_tasks list. The iterators have provision to go through dying_tasks because of dying threadgroup leaders or explicit CSS_TASK_ITER_WITH_DEAD, however, it was expected that such tasks can obtain a new reference (that is possible before cgroup_task_release()/put_task_struct_rcu_user()). The tasks after cgroup_task_release() and before cgroup_task_free() are subject to race when they may or may not have ->usage count > 0. The race window is between css_task_iter_next() invocations when css_set_lock is released and we may arrive at a new ->task_pos. The iterator should not attempt to resurrect tasks whose ->usage count dropped to zero. (When that happens, __put_task_struct_rcu_cb() is already imminent and the returned task_struct would could be used after free.) As for the fix, we cannot simply check the signal->live count of a task on the dying list because that won't distinguish regular zombies waiting to be reaped from RCU remnant tasks that are going to be free'd. Therefore add an extra check to rule out ->usage==0 tasks from any iteration. The repeat: loop in css_task_iter_advance() doesn't consider ->usage count, so add a new loop to css_task_iter_next() to skip de-used tasks on the dying_list. Rough illustration of the possible race R (reader of cgroup.procs) T (thread) L (group leader) --------------------------------- -------------------------------- -------------------------------- L exits, signal->live > 0 cgroup_task_dead(L) css_set_skip_task_iters() // skips only cset->tasks list_add_tail(&L->cg_list, &cset->dying_tasks) css_task_iter_next() take css_set_lock css_task_iter_advance() leader && signal->live != 0 => it->task_pos = &L->cg_list release css_set_lock T exits --signal->live == 0 \t\t\t\t cgroup_task_dead(T) // css_set_lock release_task(T) cgroup_task_release(T) release_task(L) // zap_leader cgroup_task_release(L) put_task_struct_rcu_user(L) ...RCU... put_task_struct(L) L->usage = 0 /* L still on dying_tasks */ ...RCU... __put_task_struct(L) css_task_iter_next() // another iteration take css_set_lock it->task_pos = &L->cg_list get_task_struct(L) => addition on 0 drop css_set_lock cgroup_task_free(L) css_set_skip_task_iters() // dying skip comes too late free_task(L) cgroup_procs_show() task_pid_vnr(L)", "cve_priority": "medium", "cve_public_date": "2026-09-26 09:16:00 UTC" }, { "cve": "CVE-2026-90061", "url": "https://ubuntu.com/security/CVE-2026-90061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: skip double clone set expressions on element insert Both the dynset and newsetelem path clone the existing set expressions when setting set element expressions if no override expressions are provided. This results in a double clone, once to clone the template set expressions then another clone on the new element. Add a flag to annotate if userspace provides a override expression (ie. expression of the same type of the set but different configuration), otherwise borrow the existing expression from the set. Add conditionals to release expression iif they represent an override. Use this new override_exprs flag to dump the dynset expression override to userspace. This simplifies the existing logic and it also fixes a bug with the connlimit expression which results in a module refcount imbalance WARNING splat when resorting on the default set expressions.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90079", "url": "https://ubuntu.com/security/CVE-2026-90079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: fix cn20k mailbox lifetime on repeated rvu_mbox_init() rvu_mbox_init() is called separately for AF-PF mailboxes during probe and for AF-VF mailboxes when SR-IOV is enabled. Each call used to allocate a new ng_rvu object, leaking the first allocation when the pointer was overwritten on the second call. Sharing one ng_rvu across both paths exposed several teardown bugs: the error path freed all cn20k mailbox DMA and kfree()d ng_rvu even when only the failing init type should be unwound, leaving live AF-PF mailbox memory in use after an AF-VF init failure. mutex_init() was also re-run on the AF-VF path while AF-PF mailbox handlers could still hold rvu->mbox_lock. Probe and SR-IOV failure paths did not release cn20k mailbox DMA either, since cleanup only happened in rvu_remove(). Allocate ng_rvu once with devm_kzalloc(), initialize mbox_lock in the same block, unwind only the mailbox memory for the failing init type, and free cn20k mailbox DMA from the probe and pci_enable_sriov() error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90082", "url": "https://ubuntu.com/security/CVE-2026-90082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Cap MSI-X vectors to the device MSI-X table size mana_gd_query_max_resources() sizes gc->num_msix_usable from resp.max_msix and the CPU count, but never from the device MSI-X table. On a 1792 vCPU M-series VM that yields 1793 while the table has 1024 entries, and mana_gd_setup_remaining_irqs() then walks indices 1..1792, running off the end of the region mapped by msix_map_region(): BUG: unable to handle page fault for address: ff8e347f8b99800c RIP: 0010:msix_prepare_msi_desc+0x7a/0x90 RAX: 0000000000004000 RBX: ff4330cb164ea780 RCX: ff8e347f8b998000 Call Trace: __msi_domain_alloc_irqs+0x13a/0x440 msi_domain_alloc_irq_at+0x149/0x1b0 mana_gd_setup+0x351/0x890 mana_gd_probe+0x274/0x390 RAX is index 1024 * PCI_MSIX_ENTRY_SIZE, one entry past the table. msi_insert_desc() does range check the index, but only against the MSI domain hwsize, which matches the table only for devices on an MSI parent domain. With a global PCI/MSI domain hwsize is MSI_XA_DOMAIN_SIZE, so nothing bounds the request. Cap num_msix_usable with pci_msix_vec_count().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90087", "url": "https://ubuntu.com/security/CVE-2026-90087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: do not leak an hci_conn when a second LE connect is rejected create_le_conn_complete() decides whether the failed connection is still pending by comparing it against hci_lookup_le_connect(), which returns the first LE connection in BT_CONNECT. That is the same connection only while at most one is pending. Two can be pending. Connections created on the passive scan path sit in BT_CONNECT with HCI_CONN_SCANNING set and are invisible to hci_lookup_le_connect() until hci_le_create_conn_sync() clears the flag when their command is issued, so the -EBUSY guard in hci_connect_le() does not prevent a second connection from being queued while the first is still on the scan path. Whenever two connections are in BT_CONNECT at once, the lookup may return one connection while create_le_conn_complete() is reporting the failure of the other; the early exit then drops the error and hci_conn_failed() never runs on the connection that failed. The controller also rejects a second HCI_OP_LE_CREATE_CONN issued while another connection creation is still outstanding, per Core Spec Vol 4, Part E. The spec calls for Command Disallowed there; the bcm43438 observed here answers with an LMP/LL error code instead, which bt_to_errno() maps to the -EPROTO (-71) in the log below. The leaked connection stays in BT_CONNECT forever, and because hci_connect_le() refuses to dial while hci_lookup_le_connect() finds anything, every subsequent attempt to reach any peer fails with -EBUSY and no command reaches the controller at all. Seen on a bcm43438 with two BLE peers polled on the same interval (state 5 is BT_CONNECT; both handles are UNSET ones, allocated from the ida above HCI_CONN_HANDLE_MAX): Bluetooth: hci1: Opcode 0x2013 failed: -71 # hcitool con < LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL < LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL A btmon capture across the next ten minutes of connect attempts contains no HCI_OP_LE_CREATE_CONN at all; outgoing LE connections do not recover until the adapter is reset. With this change the same scenario fails the rejected connection cleanly and further connects to both peers go through. Ask about the connection itself instead of about the device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90093", "url": "https://ubuntu.com/security/CVE-2026-90093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: access chan->conn safely in get/setsockopt Since commit b66774b48dd9 (\"Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref\") l2cap_chan::conn has held reference and remains non-NULL also after the corresponding hci_conn is deleted. In this state accessing various fields eg. hci_conn::hdev is invalid, which leads to KASAN crash in l2cap_sock_setsockopt() access of conn->hcon->hdev. Check l2cap_chan::conn.hcon corresponds to an alive hci_conn before trying to use it in l2cap_sock.c. Hold l2cap_chan_lock() in getsockopt/setsockopt to ensure it stays alive, and to avoid data races in l2cap_chan fields.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90095", "url": "https://ubuntu.com/security/CVE-2026-90095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: Fix the condition to enable over-io-uring The existing condition in fuse_uring_cmd() is there only to avoid disabling io-uring for connections that already run with it, missing was a condition to refuse any IORING_OP_URING_CMD if the connection/channel didn't get enabled because of missing FUSE_INIT reply flag FUSE_OVER_IO_URING. Without the reply flag the barrier in fuse_uring_ready() doesn't work and IO could already be going on and cause deadlock states (at a minimum one between fch->bg_lock and queue->lock). The change itself is trivial, but brings behavior change, FUSE_OVER_IO_URING has to be set in the FUSE_INIT_REPLY by fuse servers to accept any IORING_OP_URING_CMD. Libfuse does that and the only non-libfuse implementation I found (fractal-fuse) also does it. Qemu patches for fuse-io-uring are not merged yet, as far as I know. Moved up is the smp_load_acquire(&fch->initialized) check, as a fuse-server implementation might try to setup io-uring before FUSE_INIT is processed and might have gotten -EOPNOTSUPP instead of -EAGAIN. Also fixed is a stale comment that explains the handling of the FUSE_OVER_IO_URING flag in early RFC versions. If there should be a report from any library or application we probably need to revert this commit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90099", "url": "https://ubuntu.com/security/CVE-2026-90099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: account classifier filter allocations to memcg Allocations in the tc classifier *_change() paths (filter objects, per-CPU counters, and per-filter aux data) use plain GFP_KERNEL without __GFP_ACCOUNT, allowing unprivileged users to pin kernel memory outside memcg charging. The shared tcf_exts_init_ex() action array allocation in cls_api.c was also uncharged; this patch closes it along with the per-classifier filter-object/percpu/aux allocations that remain unaccounted. Add GFP_KERNEL_ACCOUNT to: - the shared tcf_exts_init_ex() action array (cls_api.c), common to every filter of every classifier (32 pointers, 256 bytes); - the filter-object, per-CPU-counter, and per-filter aux allocations in cls_basic, cls_bpf, cls_cgroup, cls_flow, cls_flower, cls_fw, cls_matchall, cls_route and cls_u32; - the u32_init_knode() replace-path knode allocation (cls_u32.c), which allocates the same struct tc_u_knode + sel.keys on every replace of an existing knode and was missed by the create-path-only conversion. Also fix the cls_basic error path: basic_change() inserts fnew into the IDR before allocating the per-CPU counter. If alloc_percpu() fails the errout path kfree'd fnew without idr_remove, leaving a dangling pointer in the IDR. With GFP_KERNEL_ACCOUNT the percpu alloc becomes failable on demand (memcg at memory.max), making the dead path attacker-reachable and burning the handle permanently. Add the idr_remove on the percpu failure path, matching the basic_set_parms failure-path pattern. Note: vega@nebusec.ai provided a poc for basic_cls, but it was easy to extend to the other classifiers. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_CLS_* (the classifier being used), CONFIG_NET_CLS_ACT, CONFIG_MEMCG, CONFIG_USER_NS, CONFIG_NET_NS. - Unprivileged user in a fresh user+network namespace (unshare -Urn), or root with CAP_NET_ADMIN. - Create a large number of tc filters (e.g. tc filter add dev lo ingress ... ...) while watching a memcg-limited cgroup: system slab grows far faster than memory.current, pinning kernel memory outside memcg charging.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90104", "url": "https://ubuntu.com/security/CVE-2026-90104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.1: zero referring call lists before decoding decode_cb_sequence_args() allocates csa_rclists with kmalloc_objs(), so each referring_call_list starts uninitialized. decode_rc_list() assigns rcl_refcalls only when rcl_nrefcalls is nonzero. A valid list with zero referring calls therefore leaves the pointer uninitialized, and nfs4_callback_sequence() later passes stale slab contents to kfree(). Allocate csa_rclists with kzalloc_objs() so every rcl_refcalls member is NULL from the beginning, including valid empty referring call lists.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90105", "url": "https://ubuntu.com/security/CVE-2026-90105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: fix reading neigh ha Currently arp/neigh_reduce read neigh ha directly which can lead to partial reads while the neigh is being updated. Use neigh_ha_snapshot to take a stable snapshot of the address similar to route_shortcircuit which already does the right thing.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90106", "url": "https://ubuntu.com/security/CVE-2026-90106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: arp/nd proxy: fix reading neigh ha Currently neigh ha address is read directly, but that can result in torn/partial reads if the neigh is being updated. Use neigh_ha_snapshot to take a stable snapshot of the address.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90111", "url": "https://ubuntu.com/security/CVE-2026-90111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6mr: do not clone dst in ip6mr_cache_report() IPv6 input attaches a non-refcounted (NOREF) dst to skbs under RCU. When an ingress multicast packet misses MFC lookup, ip6mr_cache_unresolved() places the skb onto the unresolved queue, escaping the receive-side RCU grace period. If the underlying route is deleted and freed, and the MFC queue is later resolved with a wrong parent interface, ip6_mr_forward() invokes ip6mr_cache_report(..., MRT6MSG_WRONGMIF), which executes dst_clone(skb_dst(pkt)) on the freed dst entry, triggering a slab use-after-free. Report packets queued to mroute6_sk (a raw socket) and netlink notifications do not require an attached dst entry. Fix this by: 1. Removing dst_clone() in ip6mr_cache_report() and ensuring report skbs do not hold a dst. 2. Dropping skb_dst before queuing unresolved skbs in ip6mr_cache_unresolved(), matching the fact that multicast forwarding resolves outgoing routes anew via ip6_route_output().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90120", "url": "https://ubuntu.com/security/CVE-2026-90120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v5: Check get_logical_index() return value in MADT IAFFID parsing In gic_acpi_parse_iaffid() a given MADT GICC entry might not correspond to a logical cpu recognized by the kernel, resulting in the cpu variable initialization to an error value. Currently, the get_logical_index() return value is not checked for failure, which might result in out-of-bounds memory corruption while trying to index a per_cpu variable array. Add a check to evaluate get_logical_index() return value.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90121", "url": "https://ubuntu.com/security/CVE-2026-90121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v5: Clear per-CPU IRS data on teardown IRS affinity setup publishes an IRS pointer and IAFFID state in the per-CPU data before the remaining IRS initialization can fail. The error path then frees the IRS data without clearing that published state, leaving CPUs associated with freed memory. On initialization failure and normal IRS teardown, clear the per-CPU IRS association by removing the stale pointer to irs_data. Also invalidate the per-CPU IAFFID state for any CPUs that were tied to the IRS before it was freed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90142", "url": "https://ubuntu.com/security/CVE-2026-90142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Fix resize of the RX ring When a AF_XDP socket is attached, the virtnet_rx_resize should resize the rq->xsk_buffs XSK buffer array. Otherwise, when the size grows, the virtnet_rx_resume() causes a write past the end of the array. This is easily reproducable with ethtool -G ens3 rx 32 ./xdpsock -i eth0 -q 0 -r -z & ethtool -G eth0 rx 256", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90154", "url": "https://ubuntu.com/security/CVE-2026-90154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: scope session state changes to bound connections ksmbd_all_conn_set_status() treats every connection whose transient binding flag is set as belonging to the target SessionId. A logoff or session replacement can consequently move an unrelated connection to NEED_RECONNECT or NEED_SETUP. Pass the target session itself and select connections using either the connection-local session xarray or the session's permanent channel list. Use the same association test while waiting for requests to drain. Serialize session-wide status changes under request_lock and do not overwrite EXITING or RELEASING. Protect the shutdown transition with the same lock so a concurrent session update cannot revive a closing connection.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90156", "url": "https://ubuntu.com/security/CVE-2026-90156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: safely discard unregistered deferred locks When vfs_lock_file() defers a lock, smb2_lock() puts its ksmbd_lock on rollback_list before allocating and registering the asynchronous work. If either operation fails, rollback assumes that smb_lock->conn is initialized and dereferences NULL. The deferred file_lock also remains linked into the VFS blocked-lock state while it is freed. Keep the lock off rollback_list until async setup succeeds. On setup failures, explicitly unblock and wake the deferred lock before freeing it and its ksmbd wrapper.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90163", "url": "https://ubuntu.com/security/CVE-2026-90163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: call ksmbd_proc_cleanup() on module init failure When a later initializer fails, the unwind chain releases resources created after procfs and then jumps directly to class_unregister(). Returning an error from module_init() leaves the proc tree and its per-CPU counters allocated.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90164", "url": "https://ubuntu.com/security/CVE-2026-90164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: abort initialization when proc setup fails ksmbd_server_init() calls ksmbd_proc_init() before creating the remaining proc entries and server subsystems. ksmbd_proc_init() tears down partial state on a procfs or percpu_counter allocation failure, but returns void, so ksmbd_server_init() continues as if the counters were usable. Once userspace starts the server, server_ctrl_handle_init() calls ksmbd_proc_reset(), which reaches percpu_counter_set() with a NULL per-CPU counters pointer on SMP systems. The later ksmbd_proc_create() calls also receive a NULL parent and may create entries in the /proc root; ksmbd_proc_cleanup() cannot remove those entries because ksmbd_proc_fs is NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90174", "url": "https://ubuntu.com/security/CVE-2026-90174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-out-of-bounds read in ksmbd_alloc_user() ksmbd_alloc_user() copies resp->hash_sz bytes out of the mountd IPC login response with \tuser->passkey_sz = resp->hash_sz; \tuser->passkey = kmalloc(resp->hash_sz, KSMBD_DEFAULT_GFP); \tif (user->passkey) \t\tmemcpy(user->passkey, resp->hash, resp->hash_sz); resp->hash_sz is a __u16 supplied by the response, but resp->hash[] is only KSMBD_REQ_MAX_HASH_SZ bytes. A malformed or malicious login response can set hash_sz well beyond that (up to 65535), so the memcpy() reads past the end of the response object. ipc_validate_msg() does not bound hash_sz, so reject any response whose hash_sz exceeds the on-stack hash[] buffer before allocating and copying. [ 2030.238706] BUG: KASAN: slab-out-of-bounds in ksmbd_alloc_user+0x278/0x680 [ 2030.240549] Read of size 65535 at addr ffff888121bb6680 by task kworker/4:1/18611 [ 2030.242296] [ 2030.242710] CPU: 4 UID: 0 PID: 18611 Comm: kworker/4:1 Not tainted 7.1.0-next-20260623-virtme #96 PREEMPT(lazy) [ 2030.242732] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 2030.242743] Workqueue: ksmbd-io handle_ksmbd_work [ 2030.242763] Call Trace: [ 2030.242769] [ 2030.242776] dump_stack_lvl+0xa2/0xd0 [ 2030.242794] print_address_description+0x77/0x200 [ 2030.242815] ? ksmbd_alloc_user+0x278/0x680 [ 2030.242831] print_report+0x58/0x70 [ 2030.242848] kasan_report+0x117/0x150 [ 2030.242869] ? ksmbd_alloc_user+0x278/0x680 [ 2030.242888] kasan_check_range+0x3c7/0x3f0 [ 2030.242908] ? ksmbd_alloc_user+0x278/0x680 [ 2030.242925] __asan_memcpy+0x29/0x70 [ 2030.242942] ksmbd_alloc_user+0x278/0x680 [ 2030.242960] ksmbd_login_user+0xc3/0x120 [ 2030.242978] ntlm_authenticate+0x5e6/0x1b00 [ 2030.243017] ? __pfx_ntlm_authenticate+0x10/0x10 [ 2030.243035] ? ksmbd_session_lookup+0x188/0x1d0 [ 2030.243054] ? __pfx_ksmbd_session_lookup+0x10/0x10 [ 2030.243090] ? __sanitizer_cov_trace_switch+0x7b/0x140 [ 2030.243108] smb2_sess_setup+0x1e4a/0x27b0 [ 2030.243126] ? copy_from_kernel_nofault+0x199/0x300 [ 2030.243156] ? __pfx_smb2_sess_setup+0x10/0x10 [ 2030.243173] ? get_smb2_cmd_val+0xe3/0x1c0 [ 2030.243208] handle_ksmbd_work+0x954/0x1280 [ 2030.243230] ? __pfx_handle_ksmbd_work+0x10/0x10 [ 2030.243249] ? process_scheduled_works+0xa07/0x1490 [ 2030.243270] ? process_scheduled_works+0xa07/0x1490 [ 2030.243291] process_scheduled_works+0xa70/0x1490 [ 2030.243320] ? __pfx_process_scheduled_works+0x10/0x10 [ 2030.243340] ? do_raw_spin_lock+0x130/0x300 [ 2030.243358] ? lock_is_held_type+0x7b/0x110 [ 2030.243388] worker_thread+0x932/0xe20 [ 2030.243415] kthread+0x38a/0x470 [ 2030.243431] ? __pfx_worker_thread+0x10/0x10 [ 2030.243451] ? __pfx_kthread+0x10/0x10 [ 2030.243467] ret_from_fork+0x484/0x910 [ 2030.243485] ? __pfx_ret_from_fork+0x10/0x10 [ 2030.243501] ? __switch_to+0xc77/0x12c0 [ 2030.243523] ? __pfx_kthread+0x10/0x10 [ 2030.243540] ret_from_fork_asm+0x1a/0x30 [ 2030.243564] [ 2030.243570] [ 2030.290164] Allocated by task 19279: [ 2030.290911] kasan_save_track+0x3e/0x80 [ 2030.292179] __kasan_kmalloc+0x72/0x90 [ 2030.293217] __kvmalloc_node_noprof+0x3ff/0x6b0 [ 2030.294467] handle_generic_event+0x59b/0x750 [ 2030.295345] genl_family_rcv_msg_doit+0x238/0x340 [ 2030.296553] genl_rcv_msg+0x606/0x7b0 [ 2030.297129] netlink_rcv_skb+0x22b/0x4a0 [ 2030.298500] genl_rcv+0x2d/0x40 [ 2030.299273] netlink_unicast+0x7ba/0x930 [ 2030.300019] netlink_sendmsg+0x8c3/0xb00 [ 2030.301073] __sock_sendmsg+0xec/0x140 [ 2030.301579] __sys_sendto+0x357/0x470 [ 2030.302255] __x64_sys_sendto+0xe3/0x100 [ 2030.303425] do_syscall_64+0x135/0x460 [ 2030.304763] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2030.305594] [ 2030.305819] The buggy address belongs to the object at ffff888121bb6640 [ 2030.305819] which belongs to the cache kmalloc-192 of size 192 [ 2030.309595] The buggy address ---truncated---", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90177", "url": "https://ubuntu.com/security/CVE-2026-90177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check pointer type for all atomic RMW paths Atomic RMW verification records an instruction pointer type only when the current destination is PTR_TO_ARENA. A second path can therefore reach the same instruction with an ordinary pointer without comparing it against the saved arena type. The post-verification fixup uses the saved type to rewrite the instruction to BPF_PROBE_ATOMIC for every path. Record the actual destination type for all atomic RMW paths so the existing mismatch check rejects incompatible uses of one instruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90182", "url": "https://ubuntu.com/security/CVE-2026-90182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-iocost: clear delay state when freeing policy data iocg_kick_delay() turns sufficiently large debt into an explicit block-cgroup delay with blkcg_set_delay(), setting blkg->use_delay to -1 and incrementing blkcg->congestion_count. Clearing it again depends on iocg_kick_delay() running from the period timer, the waitq timer or the issue path. ioc_pd_free() removes the iocg from active_iocgs and cancels its waitq timer, and no further bios can arrive, so once it has run nothing is left which can reduce the debt and clear the delay. The blkcg stays marked congested for the rest of its life. blk_cgroup_congested() then returns true for every task in that cgroup and its descendants: page_cache_sync_ra() cuts readahead to a single page, page_cache_async_ra() skips it altogether, and __folio_throttle_swaprate() takes swap_avail_lock and schedules a throttle on anonymous folio allocation. Clear it explicitly, after the list removal and the synchronous hrtimer_cancel() so that neither timer processing nor an I/O path can re-arm it. The free callback can also see policy data which was never attached to a blkg, hence the pd->blkg check.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90183", "url": "https://ubuntu.com/security/CVE-2026-90183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: clear delay state when freeing policy data io.latency can throttle a group which has no latency target of its own. When a sibling misses its target, check_scale_change() scales down its peers, and a peer that reaches queue depth one gets blkcg_use_delay() called on it on every further scale-down, even with min_lat_nsec == 0. iolatency_pd_offline() resets the target through iolatency_set_min_lat_nsec(), which clears the delay only on a nonzero to zero transition, so it never clears such a peer. Freeing the policy data then leaves blkg->use_delay set and blkcg->congestion_count elevated with nothing left that can drop it. blk_cgroup_congested() then returns true for every task in that cgroup and its descendants for as long as the cgroup lives: page_cache_sync_ra() cuts readahead to a single page, page_cache_async_ra() skips it altogether, and __folio_throttle_swaprate() takes swap_avail_lock and schedules a throttle on anonymous folio allocation. Clear the delay in iolatency_pd_free(). By then bio-held blkg references have drained, or the queue is frozen for policy deactivation, so check_scale_change() cannot re-arm it. The free callback can also see policy data which was never attached to a blkg, hence the pd->blkg check.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90206", "url": "https://ubuntu.com/security/CVE-2026-90206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix max_qid race between configfs and controller allocation The function nvmet_subsys_attr_qid_max_store() can race against nvmet_alloc_ctrl() when a subsystem's max_qid limit is modified. Suppose max_qid is currently 64. If nvmet_alloc_ctrl() executes: ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1); and at this exact point, a userspace process changes max_qid to 128, nvmet_subsys_attr_qid_max_store() will set the new max_qid value. It attempts to delete active controllers to force a reconnect, but the new controller won't be deleted because it hasn't been added to the subsys->ctrls list yet. nvmet_alloc_ctrl() then proceeds and adds the new controller to the subsys->ctrls list. Later, when nvmet_install_queue() is called, it will see max_qid set to 128, but the memory allocated for sqs is only sized for 64 entries. This results in a KASAN out-of-bounds warning and potential memory corruptions. Fix this by protecting the queue allocations and list insertion in nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem) to modify the attribute, this safely prevents the configfs writer from modifying max_qid during controller creation. Copy the max_qid from the subsystem to the controller's structure during the allocation; ctrl->max_qid never changes as long as the controller remains in LIVE state, so this will prevent similar race conditions.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90208", "url": "https://ubuntu.com/security/CVE-2026-90208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/samsung_pwm: Switch to raw_spinlock_t type Samsung PWM timer might be used as a clock source on some legacy systems. When PREEMPT_RT is enabled on ARM, regular spinlock is converted to a sleeping lock (mutex-based), which must not be used in atomic context such as hard interrupt handlers. Switch the samsung_pwm_lock to the raw_spinlock, which remains a true non-sleeping spinlock even under PREEMPT_RT.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90211", "url": "https://ubuntu.com/security/CVE-2026-90211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, s390: Clear fetch destination on faulting arena atomic Same missing register clear as on riscv64. A RMW atomic on an arena pointer is converted to BPF_PROBE_ATOMIC and gets an exception table entry, but bpf_jit_probe_atomic_pre() only fills in the arena base and the probe offset, leaving probe->reg at the -1 that bpf_jit_probe_init() set, which bpf_jit_probe_post() writes into the entry and ex_handler_bpf() then reads back as \"there is nothing to clear\". That is right for a plain BPF_{ADD,AND,OR,XOR}, which only writes memory, but an RMW carrying BPF_FETCH also reads the old value into a register: src_reg for BPF_{ADD,AND,OR,XOR} | BPF_FETCH and BPF_XCHG, and r0 for BPF_CMPXCHG. So on a fault over an unmapped arena page the program resumes at the landing pad with whatever that register held before the atomic instead of the 0 that every other BPF_PROBE_* access delivers. Fill probe->reg in from bpf_atomic_load_reg(). Unlike x86-64 and arm64, s390x does not report arena violations from its exception handler, so there is no access direction to correct here, only the missing register clear.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90212", "url": "https://ubuntu.com/security/CVE-2026-90212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/efi: Avoid voluntary preemption with efi_mm installed Gus reports a bad kernel memory access when using software PAN (CONFIG_ARM64_SW_TTBR0_PAN=y) on a machine with support for EFI runtime services: Unable to handle kernel access to user memory outside uaccess routines at virtual address 00000000f322ff30 Mem abort info: ESR = 0x0000000096000004 FSC = 0x04: level 0 translation fault Internal error: Oops: 0000000096000004 [#1] SMP Workqueue: efi_rts_wq efi_call_rts pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : efi_call_rts+0xd8/0x288 Call trace: efi_call_rts+0xd8/0x288 (P) process_one_work+0x178/0x4f8 worker_thread+0x194/0x328 This is because the fpsimd context management code called from __efi_fpsimd_begin() can preempt voluntarily, returning later to the EFI code with an incorrect value for TTBR0_EL1 thanks to the deferred mm switching used by the software PAN implementation. Since EFI runtime services cannot preempt voluntarily and because the fpsimd switching code does not rely on the TTBR0_EL1 mappings, simply reorder the fpsimd switch so that it occurs before we change the page-table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90217", "url": "https://ubuntu.com/security/CVE-2026-90217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Compare iterator types during state pruning An iterator stack slot can be MEM_RCU or PTR_UNTRUSTED. These states must not be equal, or the verifier can prune an unsafe path. Compare the pointer type for STACK_ITER slots.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90231", "url": "https://ubuntu.com/security/CVE-2026-90231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix unconfined user namespace restriction forced stack If a task is already confined by a stack the unprivileged transition restriction on unconfined is not correctly, applied. This results in an escape if two transitions through an unconfined profile can be executed. Fix this by pushing the check into the per profile label build. The check will always be done against unconfined and result in a stack of just the unconfined component when necessary.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90234", "url": "https://ubuntu.com/security/CVE-2026-90234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Return a delegation the client fails to record When an NFS server grants a delegation in an OPEN reply, nfs_inode_set_delegation() records it on the client. However, three of its error flows return without sending DELEGRETURN. A delegation can be relinquished only by DELEGRETURN (RFC 8881 Section 20.2.4), so dropping one silently leaves the server believing the client still holds it. If the server happens to recall that delegation, the client answers CB_RECALL with NFS4ERR_BADHANDLE because it has no record of the stateid. The server revokes the delegation and moves it onto its cl_revoked list, because the client never sends the FREE_STATEID that would drain it. Every subsequent SEQUENCE reply then carries SEQ4_STATUS_RECALLABLE_STATE_REVOKED, and the client's state manager loops issuing TEST_STATEID across its delegations without ever clearing the condition. The window is easy to reach now that a server offers a write delegation on any write OPEN: a delegation recalled for one opener races a re-open that the server answers with a fresh write delegation. Instead of dropping it, hand the delegation back during these error flows.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90237", "url": "https://ubuntu.com/security/CVE-2026-90237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: move custom expectation support to helper Originally, the ct expectation support called nf_ct_helper_ext_add() for confirmed conntracks, which is invalid, triggering a splat. This was fixed by commit 1710eb913bdc (\"netfilter: nft_ct: skip expectations for confirmed conntrack\") which restricted it to unconfirmed conntracks. However, early insertion of expectations into the expectations list when the conntrack is unconfirmed leads to stale entries pointing to the wrong hlist_head through .pprev due to ct extension reallocation. Commit 7c9664351980 (\"netfilter: move nat hlist_head to nf_conn\") moved the nat hlist_head to nf_conn for this reason: 1. ... 2. When reallocation of extension area occurs we need to fixup the bysource hash head via hlist_replace_rcu. I'd rather not increase the size of the struct nf_conn for this feature has very limited scope: only one expectation can be created at a time given expect_clash() will make nf_ct_expect_related() reports EBUSY. For this reason, relax nf_ct_expect_related() not to drop packets in case expectation creation fails, therefore, expectation creation becomes best effort. To address this issue, add an internal ct helper and attach it to the conntrack entry to streamline the custom ct expectation support with existing ct helpers. Expose a new nf_conntrack_helper_release() function to release the internal helper that is allocated and attached to the conntrack entry to create the custom expectations. The nft_ct module removal always waits for rcu grace period, then the NULL helper callback is observed after this. This patch also restricts the creation of expectations to different helpers other than this custom helper that is created for this type of expectations.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90242", "url": "https://ubuntu.com/security/CVE-2026-90242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix iopf_refcount leak on RID domain replacement intel_iommu_attach_device() enables IOPF for the new domain but never disables it for the old one. device_block_translation(), called at the start of the function, tears down translation but does not touch any IOPF state; blocking_domain_attach_dev() has to call iopf_for_domain_remove() explicitly before invoking it for exactly this reason. identity_domain_attach_dev() has the same problem. Its comment claims that no PRI handling is needed because the device has been put in the blocking state, but the blocking state and the IOPF reference count are independent of each other. As a result, replacing a domain that has an iopf_handler with another domain at RID level leaks a reference in info->iopf_refcount. The count never drops back to zero, so iopf_queue_remove_device() is never called and iommu_disable_pci_pri() triggers its WARN_ON(info->iopf_refcount) when the device is released. The PASID paths already handle this correctly by way of iopf_for_domain_replace(); convert the two RID paths to do the same. Using the replace helper rather than a bare remove keeps the enable before the disable, so the reference count does not transiently reach zero and evict the device from the IOPF queue.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90246", "url": "https://ubuntu.com/security/CVE-2026-90246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix integer overflow in verify_tags() bounds check verify_tags() validates the tagset table unpacked from a policy blob. For each set it reads a count and checks that advancing the index by that count stays inside sets.table[]: \tu32 cnt = tags->sets.table[i]; \tif (i+cnt >= tags->sets.size) { i, cnt and sets.size are all u32, so i+cnt is evaluated modulo 2^32. sets.table[] is filled by unpack_tagsets() with aa_unpack_u32(), so every entry is a raw unbounded 32-bit word taken from the policy blob, and verify_tags() is the function that is supposed to validate it. A count close to U32_MAX makes the sum wrap to a small value, the guard passes, and the inner loop then walks sets.table[++i] past the end of the kcalloc(size, sizeof(u32)) allocation. Note that sets.size is bounded by 65535, because unpack_tagsets() reads it with aa_unpack_array() as a u16, so the wrap cannot be reached by growing the table; it is reached purely through the attacker-supplied count. With sets.size = 2 and sets.table = { 0, 0xffffffff }: i = 0: cnt = 0, guard 0 + 0 >= 2 is false, inner loop does not run i = 1: cnt = 0xffffffff, guard (1 + 0xffffffff) mod 2^32 == 0 >= 2 is false, so the guard is bypassed and the inner loop reads sets.table[2] -- one element past a two element allocation The walk continues until an out-of-bounds value happens to be >= hdrs.size or the access faults, so a crafted policy yields an out-of-bounds read on the policy load path (aa_replace_profiles -> aa_unpack -> unpack_policydb -> unpack_tags -> verify_tags). unpack_tags() runs before the perms and DFA tables are unpacked, so no other table needs to be well formed to reach it. Policy load is gated by aa_may_manage_policy(), which checks CAP_MAC_ADMIN relative to the subject's own user namespace rather than the init user namespace, so with the default unprivileged_userns_apparmor_policy=1 the path is reachable from an unprivileged task in a matched-level nested namespace, not only by a globally privileged one. Perform the addition in u64 so that it cannot wrap, restoring the intended i + cnt < sets.size guarantee.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90256", "url": "https://ubuntu.com/security/CVE-2026-90256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use proto_lock for l2cap_data to fix l2cap_disconn_ind hci_conn::l2cap_data is accessed without locks in l2cap_disconn_ind via hci_conn_timeout (disc_work) -> hci_proto_disconn_ind -> l2cap_disconn_ind. This is UAF if the l2cap_conn is deleted concurrently. disc_work is disabled sync in hci_conn_del(), so we cannot take hci_dev_lock in disc_work. Fix by using proto_lock to guard l2cap_data, in addition to hdev->lock which is held in other access paths.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90261", "url": "https://ubuntu.com/security/CVE-2026-90261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: flush active metadata block group at btree_writepages() start btree_writepages() writes the btree inode's dirty metadata in ascending logical address order. On a zoned filesystem only one metadata and one system block group is active for writing at a time, and check_bg_is_active() (via btrfs_check_meta_write_pointer()) pivots the active block group as writeback moves from one block group to the next. If the active block group sits at a higher logical address than another block group that also holds dirty metadata, the ascending walk reaches the lower one first and, to write it, has to finish the active block group and activate the lower one. It cannot finish a block group that still has unsent IO, and during WB_SYNC_ALL && !for_sync (commit) writeback it deliberately refuses to wait for that IO under fs_info->zoned_meta_io_lock, as that can deadlock. The pivot thus cannot issue the submission itself either, so it gives up: btrfs_check_meta_write_pointer() returns -EAGAIN, which btrfs_write_and_wait_transaction() treats as fatal and aborts the transaction, forcing the filesystem read-only. This happens intermittently under metadata-heavy relocation (e.g. fstests btrfs/187). Flush the active metadata and system block groups at the start of btree_writepages(), under the fs_info->zoned_meta_io_lock it already holds, so they have no unsent IO left and the later pivot can finish them and make forward progress.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90263", "url": "https://ubuntu.com/security/CVE-2026-90263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: check if root is readonly when setting posix acl For a filesystem which has btrfs read-only property set to true, all write operations including acl and xattr should be denied. However, acl can still be set even if btrfs ro property is true. This happens because no function on the set_acl code path checks the root is readonly or not. It was checked in btrfs_setxattr_trans() but got removed in commit 353c2ea735e4 (\"btrfs: remove redundant readonly root check in btrfs_setxattr_trans\") That commit didn't check if all the callers properly check the root's read-only flag. A previous fix is commit b51111271b03 (\"btrfs: check if root is readonly while setting security xattr\"). Always check if the root is read-only before performing the set acl operation.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90267", "url": "https://ubuntu.com/security/CVE-2026-90267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix special_vec mempool leak when scsi_alloc_sgtables() fails sd_set_special_bvec() allocates a special payload page for UNMAP and WRITE SAME commands. If scsi_alloc_sgtables() fails afterward in sd_setup_unmap_cmnd() or sd_setup_write_same{10,16}_cmnd(), the SCSI midlayer does not call uninit_command() because RQF_DONTPREP is not set yet, leaking the page. Call sd_uninit_command() on error, and clear RQF_SPECIAL_PAYLOAD after freeing the page.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90270", "url": "https://ubuntu.com/security/CVE-2026-90270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: Disable driver unbind to avoid UAF When a user unbinds an MSC and that MSC is the only MSC left for a component then the corresponding mpam_component will be freed. If the user then goes on to read the schemata file in the resctrl filesystem then the mpam_component will be accessed from resctrl_arch_get_config() leading to a use after free. As the MPAM driver is not a module the unbind sysfs interface is the only way to trigger the remove. Instead of dealing with the complexity of allowing some unused MSC to unbind just remove the unbind sysfs interface.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90271", "url": "https://ubuntu.com/security/CVE-2026-90271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: Fix a NULL pointer dereference on unbinding after an error interrupt If a user unbinds an MSC after mpam_disable() has been run in response to an error interrupt then a dereference of a NULL pointer occurs as mpam_disable() sets the drvdata to NULL. Add an early return to the driver remove callback to avoid this.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90273", "url": "https://ubuntu.com/security/CVE-2026-90273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable In the perf enable path, there are missing cases where cscfg_csdev_disable_active_config() is not called: - Branch broadcast is selected but not supported by the hardware - etm4_enable_hw() fails This can lead to a leak of config_desc->active_cnt. Fix this by properly calling cscfg_csdev_disable_active_config() in these error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90288", "url": "https://ubuntu.com/security/CVE-2026-90288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: renesas: rcar-gen2: Fix double of_node_put on phy creation failure for_each_child_of_node_scoped() releases the node reference on scope exit, so the explicit of_node_put(np) in the devm_phy_create() error path drops it twice. Drop the redundant of_node_put() and let the scoped cleanup handle it.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90289", "url": "https://ubuntu.com/security/CVE-2026-90289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Resize MST HDCP per-connector arrays to 32 AMDGPU_DM_MAX_DISPLAY_INDEX is 31. It suggest a maximum number of 32 connectors. But the way it's used is like MAX_DISPLAY_COUNT. Hence we're off by one with DRM core, which supports a max of 32 connectors. Rename AMDGPU_DM_MAX_DISPLAY_INDEX to AMDGPU_DM_MAX_DISPLAY_COUNT to match its actual use, and increase the size to 32 to match the originally intended size.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90300", "url": "https://ubuntu.com/security/CVE-2026-90300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Clear buf on error in __bpf_get_task_stack Both bpf_get_task_stack and bpf_get_task_stack_sleepable helpers that use __bpf_get_task_stack have buf defined as ARG_PTR_TO_UNINIT_MEM argument and we should initialize the buf on every return path. Adding missing buf memset for __bpf_get_task_stack fail paths. This provides deterministic buffer contents, which is useful when the buffer is used directly as a map key.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90301", "url": "https://ubuntu.com/security/CVE-2026-90301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: o2hb: quiesce negotiate handlers and timeout work Heartbeat regions publish struct o2hb_region as the private data for the NEGO_TIMEOUT and NEGO_APPROVE o2net handlers as soon as make_item() creates the configfs region. The approve handler can call o2hb_arm_timeout(), so a peer can touch the region timeout work before dev_store() has finished building the heartbeat runtime, or after teardown has started to shut that runtime back down. The final configfs put also has to keep reg alive until the last in-flight o2net callback drops its handler reference. o2net_unregister_handler_list() blocks future handler lookups, but it does not wait for sc_rx_work that already passed o2net_handler_get(). That drain needs to cover local listener teardown as well, where the o2net ordered workqueue may already be inside destroy_workqueue(). Fix the lifetime rule in both directions. Initialize the region delayed works before publishing reg through the o2net handler table, keep new or stopping regions non-armable with hr_stopping, and quiesce both delayed works on failed-start and teardown paths even when no heartbeat thread is left to call o2hb_disarm_timeout(). Then unregister handlers before tearing down handler-visible region state and make the drain wait for the active or destroying o2net ordered workqueue before release frees reg. The buggy scenario involves two paths, with each column showing the order within that path: region lifecycle: late negotiate callback: 1. make_item() registers the 1. o2net_process_message() gets a region handlers before heartbeat handler for reg. dev_store() has built a 2. The callback runs after the lookup runnable heartbeat context. lock is dropped and dereferences reg. 2. A failed start or rmdir 3. An approve or timeout path tries to stops the heartbeat thread, queue reg's delayed work, or release quiesces existing work, and races the callback body after handler drops the final configfs ref. unregister. 3. region_release() must drain 4. The callback or delayed work can handler-visible o2net rx work outlive reg unless lifecycle code before freeing reg. keeps the region non-armable and drains the active-or-destroying o2net workqueue. Validation reproduced this kernel report: KASAN slab-use-after-free in __run_timers+0x22c/0x5b0 Write of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __run_timers+0x22c/0x5b0 kasan_report+0xe0/0x110 _raw_spin_unlock_irqrestore+0x27/0x60 try_to_wake_up+0x191/0xf70 timer_expire_remote+0xae/0xf0 run_timer_softirq+0x19b/0x1a0 handle_softirqs+0x156/0x660 __irq_exit_rcu+0xc4/0x160 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x6c/0x80 asm_sysvec_apic_timer_interrupt+0x1a/0x20 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 o2hb_heartbeat_group_make_item+0x3c/0x600", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90310", "url": "https://ubuntu.com/security/CVE-2026-90310", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90311", "url": "https://ubuntu.com/security/CVE-2026-90311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: hwmon: Remove hwmon class device along with its parent The current code creates one hwmon device per thermal zone type and that device is registered under the first thermal zone of the given type. That turns out to be problematic when the thermal zone holding the hwmon device is removed. For example, say that there are two ACPI thermal zones on a system /sys/devices/virtual/thermal/thermal_zone0/ /sys/devices/virtual/thermal/thermal_zone1/ The current code registers a hwmon class device for thermal_zone0 only: /sys/devices/virtual/thermal/thermal_zone0/hwmon0/ because the type is \"acpitz\" for both of them, but it adds a sysfs attribute that belongs to thermal_zone1 under it: /sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp2_input There is also /sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input which belongs to thermal_zone0. When thermal_zone0 is removed, say because the ACPI thermal driver is unbound from the underlying platform device, thermal_remove_hwmon_sysfs() skips the removal of hwmon0 because of the temp2_input attribute belonging to thermal_zone1 which effectively prevents thermal_zone0 removal from making progress. Address this by making thermal_remove_hwmon_sysfs() remove the entire hwmon class device interface for the given thermal zone type when the thermal zone device holding it is removed. To prevent races with thermal_add_hwmon_sysfs() that may interfere with this, carry out the entire addition and removal of hwmon sysfs interfaces for thermal zones under thermal_hwmon_list_lock. Also adjust the layout of the labels in thermal_add_hwmon_sysfs() to the current kernel coding style to align with the new \"unlock\" label.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90315", "url": "https://ubuntu.com/security/CVE-2026-90315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI/sysfs: Add lockdown checks to legacy I/O and memory handlers Currently, the legacy I/O and memory sysfs handlers do not check security_locked_down(LOCKDOWN_PCI_ACCESS), leaving the legacy_io and legacy_mem files unprotected when the kernel is locked down. Commit eb627e17727e (\"PCI: Lock down BAR access when the kernel is locked down\") added the check to pci_write_config(), pci_mmap_resource(), and pci_write_resource_io() to prevent userspace from programming DMA-capable hardware that could be used to modify kernel code, but did not cover the legacy handlers. As a result, root can still write arbitrary I/O ports and map the legacy I/O and memory spaces while the kernel is locked down, which is the same capability the lockdown is meant to remove. Add the same check to pci_write_legacy_io(), pci_mmap_legacy_mem(), and pci_mmap_legacy_io(). These generic handlers cover both architectures that define HAVE_PCI_LEGACY (such as Alpha and PowerPC). [bhelgaas: add Link]", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90320", "url": "https://ubuntu.com/security/CVE-2026-90320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate external xattr entries when reading metadata ocfs2_validate_xattr_block() checks the xattr block header before the block reaches higher-level xattr users, but it does not verify that a non-indexed block's xh_count and entry offsets fit inside the block. Indexed buckets likewise reach list/get consumers after ECC without an entry-bounds check. Use the flat xattr entry validator for non-indexed external xattr blocks, and use a bucket-specific validator for indexed buckets at metadata read time. The bucket validator keeps the entry array bounded by the first bucket block while checking name/value offsets against the bucket block they target. Reject corrupted external xattr metadata before listxattr() or getxattr() can walk out-of-range entry arrays or name/value offsets. Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2_xattr_list_entries+0xd7/0x190 Read of size 1 at addr ffff88810a654007 by task ocfs2_xattr_lis/630 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 kasan_report+0xe0/0x110 ocfs2_xattr_list_entries+0xd7/0x190 ocfs2_listxattr+0x3f6/0x610 listxattr+0x90/0xe0 path_listxattrat+0xed/0x220 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90321", "url": "https://ubuntu.com/security/CVE-2026-90321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate inline xattrs during inode block validation Patch series \"ocfs2: validate xattr entry bounds\", v7. This series validates OCFS2 xattr entry name/value bounds when xattr metadata is read and validated, before getxattr() or listxattr() can walk out-of-range entry arrays or offsets from corrupted metadata. This patch (of 2): ocfs2_validate_inode_block() verifies a dinode before OCFS2 users walk metadata from it, but inline xattr metadata is still checked only in operation-specific consumers. The existing ibody lookup helper validates inline header placement and entry count, but inode block validation does not reject entry name/value bounds. Add a flat xattr entry validator and call it from inode block validation for inline xattrs. Keep the operation paths on their existing header/count lookup checks; the full entry bounds check now runs when the inode block is validated at read time. Reject corrupted inline xattr metadata before ocfs2_xattr_ibody_get() or listxattr() can walk past the inline storage. Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2_xattr_find_entry+0x5a/0x170 Read of size 2 at addr ffff8881242a2000 by task python3/529 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 kasan_report+0xe0/0x110 ocfs2_xattr_find_entry+0x5a/0x170 ocfs2_xattr_get_nolock+0x20a/0x820 ocfs2_xattr_get+0x10c/0x1e0 __vfs_getxattr+0xe2/0x130 vfs_getxattr+0x185/0x1b0", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90323", "url": "https://ubuntu.com/security/CVE-2026-90323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: validate auto buf reg before taking uring_cmd With UBLK_F_AUTO_BUF_REG, invalid sqe->addr can fail after ublk_fill_io_cmd() has set UBLK_IO_FLAG_ACTIVE. The uring_cmd is completed while the tag stays active, which can hang teardown. Split validation from buffer apply so the check has no side effects, then take the uring_cmd and store the already-validated buffer. Apply the same order in FETCH so io->buf is not written before __ublk_fetch() state checks.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90330", "url": "https://ubuntu.com/security/CVE-2026-90330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix FF device cleanup on init failure hidpp_ff_init() creates the input force-feedback device with input_ff_create(), then allocates the HID++ FF private data, effect ID array, and workqueue. If any of those allocations fail after input_ff_create() succeeds, the function returns an error without destroying the FF device. Add an unwind path that frees the private allocations made by hidpp_ff_init() and calls input_ff_destroy() for failures after input_ff_create() succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90331", "url": "https://ubuntu.com/security/CVE-2026-90331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: asus: refactor the two workqueues and init sequence Multiple issues have been found within the hid-asus driver: - unchecked size in asus_raw_event() - unclean teardown of asus_probe on failure - possible use-after-free in asus_probe - multiple workqueue used for jobs where one was enough - sleeping calls in atomic context - packets of incorrect size being sent to the keyboard controller Join the two workqueues into one reusing the stopping mechanism of the brightness workqueue, use the joined workqueue to also move the asus_wmi_send_event() sleeping call away from atomic context and add a size check in asus_raw_event().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90332", "url": "https://ubuntu.com/security/CVE-2026-90332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: ep: Flush cached MSI write before unmapping the iATU The MSI-X path already flushes any posted MSI-X write before tearing down its iATU mapping. That was added by commit c22533c66cca (\"PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry\") to make sure the write reaches the Root Complex before the outbound window that translates it disappears. The MSI path has the same problem but no equivalent flush. When the Endpoint driver caches an MSI target address and later observes that the Root Complex has changed it, dw_pcie_ep_raise_msi_irq() unmaps the existing iATU entry and reprograms it for the new address. Between the last MSI writel() and the unmap there may still be a posted write sitting in the fabric, and unmapping the iATU entry can drop or misroute that write. Fix this by reading back from the mapped MSI window before the unmap. The readback drains any posted MSI writes through the same iATU entry that mapped them, which is the same logic the MSI-X path uses. [mani: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90335", "url": "https://ubuntu.com/security/CVE-2026-90335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: skip cdev_del() when no cdev is registered TTY device registration can fail before a cdev is allocated. Serial core keeps the port so setserial can still use it, and later removal passes the NULL cdev slot to cdev_del(), causing a NULL-pointer dereference. Only delete the cdev when the slot is not NULL.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90336", "url": "https://ubuntu.com/security/CVE-2026-90336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: core: clear freed pointers on uart_register_driver() failure uart_register_driver() leaves drv->state pointing to freed memory when tty_alloc_driver() fails. If tty_register_driver() fails, drv->tty_driver also retains a pointer after its reference is dropped. Drivers that use drv->state as an \"already registered\" flag can then skip registration on the next probe and pass the freed state to uart_add_one_port(). This issue was found with failslab on QEMU's raspi1ap board by failing registration and binding the PL011 port again. Clear both pointers on their failure paths, as uart_unregister_driver() already does.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90337", "url": "https://ubuntu.com/security/CVE-2026-90337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: core: do fallible allocations before the console can be registered serial_core_add_one_port() allocates uport->tty_groups after uart_configure_port(), which may register the console. If the allocation fails, the driver unwinds the port while its console remains registered. The earlier uport->name allocation has a related failure path that leaves state->uart_port linked to a port being freed. Failslab reproduced a NULL dereference in PL011 console output and a KASAN use-after-free in i.MX console output after failed binds. Allocate the name and tty_groups before linking the port and configuring it. Reserve space for the optional driver attribute group because config_port() may populate uport->attr_group during configuration.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90342", "url": "https://ubuntu.com/security/CVE-2026-90342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix mmap_lock deadlock on arena lock failure Reported by the Sashiko AI review. arena_vm_fault() returns VM_FAULT_RETRY when it can't take arena->spinlock, but it never took mmap_lock. The fault path assumes a VM_FAULT_RETRY handler already dropped mmap_lock and re-takes it on the retry, so mmap_lock gets taken twice and can deadlock: \tdo_user_addr_fault() \t{ \t\tfault = handle_mm_fault(...); // calls arena_vm_fault() \t\tif (fault & VM_FAULT_RETRY) \t\t\tgoto retry; // re-locks mmap_lock \t\tmmap_read_unlock(mm); \t} Return VM_FAULT_SIGBUS instead, for two reasons: 1. We could keep VM_FAULT_RETRY, but then we'd have to drop the fault lock first and cap the retry ourselves, the way __folio_lock_or_retry() does. 2. A failed raw_res_spin_lock_irqsave() already means a possible deadlock was detected, so retrying just hits the same lock again. So returning VM_FAULT_RETRY here is overkill.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90345", "url": "https://ubuntu.com/security/CVE-2026-90345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix P2P action frame handling without device vif Some P2P action frame paths assume the P2P device vif is always available. That is not true when userspace sends non-P2P public action frames through the primary interface, or when action-frame abort runs after the P2P device vif has not been created. Fall back to the primary vif when aborting an action frame without a P2P device vif, and guard P2P device saved IE access before using it for peer channel search.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90346", "url": "https://ubuntu.com/security/CVE-2026-90346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: clean up color-change beacon data on errors nl80211_color_change() calls nl80211_parse_beacon() for the beacon_next template, which can allocate params.beacon_next.mbssid_ies and .rnr_ies. A parsing failure returned directly instead of using the out: cleanup, leaking any allocations completed before the error. Allocate the nested attribute table before parsing beacon_next. Its allocation failure can then return before beacon data exists, while a later parsing failure uses out: to release the parsed data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90347", "url": "https://ubuntu.com/security/CVE-2026-90347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry Commit e057b9477232 (\"arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates\") attempted to resolve a long-standing issue with syscall entry tracing, where a tracer is able to manipulate the first syscall argument without being subjected to seccomp or audit checking. Unfortunately, that fix was incomplete [1], as it failed to update 'orig_x0' between a tracer updating x0 during a seccomp ptrace exit (SECCOMP_RET_TRACE) and the seccomp filter being re-evaluated. Rather than add hooks to the core seccomp code, instead move the synchronisation code into the ptrace GPR and syscall setting code so that 'orig_x0' is kept up to date with x0 whenever we're stopped on the syscall entry path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90355", "url": "https://ubuntu.com/security/CVE-2026-90355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: clear stale link state on full reset After a full chip reset, mac80211 reconfig replays interface, link and channel context setup. mt7996_vif_link_add() short-circuits when the link_id is still marked in mvif->valid_links, a state introduced for postponing link teardown to interface removal. The reset path frees the link structures without clearing those bits, so the replayed setup never re-creates dev_info/bss_info/STA records in the restarted firmware and never re-registers the link wcid, leaving the device inoperative. The reset path also leaks every allocated MLD index: per-link indices and the per-vif group/remap indices are re-allocated from scratch during reconfig, but the old bits stay set in the masks, so repeated full resets exhaust the index space. Clear valid_links in the reset vif iterator and reset the MLD index masks alongside the existing omac_mask clearing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90359", "url": "https://ubuntu.com/security/CVE-2026-90359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject >8 byte return values on return-reading trampoline paths btf_distill_func_proto() builds the function model used for the fentry/fexit/fmod_ret/fsession trampolines and struct_ops. It has accepted a 16-byte __int128 return value since the trampoline was introduced: __get_type_size() returns the integer's type size, and the return-type check only rejected ret < 0. But the BPF trampoline preserves only 8 bytes of the return value (RAX on x86, i.e. R0). For an attach type that reads the target's return value the second half (RDX / R3) is neither saved nor restored, so a program attached to a function returning a 16-byte value corrupts the value seen by the real caller and itself observes only half of it. struct_ops trampolines have the same limitation. This affects the attach types that read the target's return value: fexit, fmod_ret and fsession (plus the _multi variants of fexit and fsession), and struct_ops. fentry/fentry_multi run before the target returns and are unaffected. Reject a >8 byte return value for these attach types in bpf_check_attach_target() and bpf_check_attach_btf_id_multi(), and for struct_ops in bpf_struct_ops_desc_init().", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90365", "url": "https://ubuntu.com/security/CVE-2026-90365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: cancel reset and rc work on device unregister Both drivers cancelled dump_work on unregister but left reset_work and rc_work to be flushed only by destroy_workqueue() in mt76_free_device(), which runs after the hw is unregistered and the hardware stopped. A reset_work that fires in that window calls ieee80211_restart_hw() and re-arms mac_work on an unregistered hw, and rc_work touches station state being torn down. Cancel both up front, alongside dump_work.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90369", "url": "https://ubuntu.com/security/CVE-2026-90369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix out-of-bounds access in mmio copy helpers mt76_mmio_write_copy() and mt76_mmio_read_copy() iterate up to ALIGN(len, 4), so a length that is not a multiple of four reads past the source buffer (write_copy) or writes past the destination (read_copy). Copy the aligned body in the loop and handle the remaining tail through a 4-byte bounce buffer, keeping the register access width unchanged.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90380", "url": "https://ubuntu.com/security/CVE-2026-90380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt792x: fix use-after-free in mt76_rx_poll_complete A use-after-free issue occurs in mt76_rx_poll_complete due to a race condition. The STA has already been removed, but the rx_status still had a pointer to the wcid in the STA. Set the links' wcid pointers to be NULL for a MLD in mt7925_sta_pre_rcu_remove() BUG: KASAN: invalid-access in mt76_rx_poll_complete+0x280/0x470 Call trace: dump_backtrace+0xec/0x128 show_stack+0x18/0x28 dump_stack_lvl+0x40/0xc8 print_report+0x1b8/0x710 kasan_report+0xe0/0x144 do_bad_area+0x120/0x260 do_tag_check_fault+0x20/0x34 do_mem_abort+0x54/0xa8 el1_abort+0x3c/0x5c el1h_64_sync_handler+0x40/0xcc el1h_64_sync+0x7c/0x80 mt76_rx_poll_complete+0x280/0x470 mt76_dma_rx_poll+0x114/0x51c mt792x_poll_rx+0x60/0xf8 napi_threaded_poll_loop+0xe0/0x450 napi_threaded_poll+0x80/0x9c kthread+0x11c/0x158 ret_from_fork+0x10/0x20", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90381", "url": "https://ubuntu.com/security/CVE-2026-90381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix handling channel context with different bands in mt76_switch_vif_chanctx() When performing channel switches on different radios within a short timeframe, channel contexts with different bands can be carried for each struct ieee80211_vif_chanctx_switch. Rework mt76_switch_vif_chanctx() to properly handle this scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90384", "url": "https://ubuntu.com/security/CVE-2026-90384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: release the folio batch on iomap callback failures A sashiko review of an unrelated patch points out that the folio batch mechanism used for iomap zero range fails to release the batch in a couple error scenarios. If either calls to ->iomap_end() or ->iomap_begin() fail, the direct return paths bypass the batch cleanup. The ->iomap_end() case is not a practical issue at the moment because there is no user of the mechanism that returns an error from this path. The ->iomap_begin() case is theoretically possible because XFS can invoke the fill helper and error out at various points thereafter. This subtly complicates things because XFS does not transfer iomap_flags to the iomap data structure in the error path. To deal with both of these issues, first make sure to invoke the cleanup helper in the error path for either fs callback. Second, update the helper to clear the flag unconditionally and release the batch so long as it is populated. This more clearly delineates the purpose of the flag to control the I/O path and not necessarily the status of the fbatch, so add a comment around this as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90401", "url": "https://ubuntu.com/security/CVE-2026-90401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: remove REQ_NOWAIT support from raid1/10/456 REQ_NOWAIT support in md personalities that can block internally is fundamentally incomplete. While reads can avoid some blocking paths, write requests can still encounter cases where one mirror succeeds while another returns -EAGAIN. At that point md cannot distinguish queue pressure from a real device failure, so it can neither record a bad block nor safely retry the write without REQ_NOWAIT, leaving mirrors with divergent data. Rather than continue advertising REQ_NOWAIT support for personalities that cannot implement it correctly, remove it from raid1, raid10 and raid456. Keep REQ_NOWAIT for linear and raid0, which only remap bios to their underlying devices; stacked limits will still clear the feature if any component device lacks REQ_NOWAIT support.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90408", "url": "https://ubuntu.com/security/CVE-2026-90408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix overreads in ath12k_wmi_process_csa_switch_count_event() There is no policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, so the parse infrastructure does not enforce a minimum length for the event struct. Additionally, the num_vdevs field is taken directly from firmware and used as a loop bound over the vdev_ids array without checking that it fits within the TLV payload. Either condition can cause an out-of-bounds read. Add a TLV policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT so the parse infrastructure enforces a minimum length for the fixed-size event struct. Add a helper ath12k_wmi_tlv_data_len() to recover the payload length of a parsed TLV from the header preceding its data pointer. Use it in ath12k_wmi_process_csa_switch_count_event() to bound num_vdevs before the loop. Compile tested only.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90409", "url": "https://ubuntu.com/security/CVE-2026-90409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Add vm_bind region with kbo range overlap check When a VM is created, caller has to specify the range of the address space carve-out set aside for mapping kernel BO's. That means vm_bind mappings of UM-exposed BO's should not intersect with that region, but at the moment we're not checking this. At first, I thought of giving these values to drm_gpuvm_init() through its reserve_{offset, range} arguments, but it turns out that is meant for VM address spans that are not managed through the usual drm_gpuvm split/merge circuit, so storing the end of the user VA range at VM creation time and doing a quick check in the vm_bind ioctl path was the simplest workaround. The new check also makes sure vm_bind range doesn't overflow the size of a 64-bit unsigned integer. That was already being done further down the call stack inside drm_gpuvm_sm_map -> drm_gpuvm_range_valid, but it's best to fail early in the driver before GPUVM functions are invoked so that we won't waste time allocating vm_bind context resources.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90412", "url": "https://ubuntu.com/security/CVE-2026-90412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix return status of RMI log page on allocation failure nvmet_execute_get_log_page_rmi() leaves 'status' holding NVME_SC_SUCCESS (set by the successful nvmet_req_find_ns() call) when the kzalloc() for the log buffer fails. It then jumps to the out label and completes the request with a success status, so the host is told the command succeeded while no data was transferred. Initialize 'status' to NVME_SC_INTERNAL, matching the smart log handler, so an allocation failure is reported as an internal error.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90417", "url": "https://ubuntu.com/security/CVE-2026-90417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Fix dereg_skb leak and double free in write_tpt_entry() When the device is in the fatal error state, write_tpt_entry() returns -EIO before handing the caller's preallocated skb to the transmit path; its allocation-failure returns do the same. c4iw_dereg_mr() ignores the error and frees mhp, leaking mhp->dereg_skb. c4iw_get_dma_mr() instead frees the skb a second time after dereg_mem() already consumed it, a double free. Make write_tpt_entry() the sole owner of a non-NULL skb, freeing it on every return preceding handoff to c4iw_ofld_send(): fatal error, tpt and stag allocation failure. c4iw_ofld_send() consumes the skb on success and error alike, so drop the redundant kfree_skb() in c4iw_get_dma_mr() after dereg_mem().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90421", "url": "https://ubuntu.com/security/CVE-2026-90421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: Fix UAF when probe runs concurrent to dyn ID removal Dynamic IDs are only guaranteed to be valid when dynids.lock is held, as remove_id_store() can free the node. Thus, make a copy in pci_match_device(). Also, clarify that the id parameter is only valid during probe.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90427", "url": "https://ubuntu.com/security/CVE-2026-90427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Don't fall back to a freed smmu after devm_krealloc() __tegra241_cmdqv_probe() uses devm_krealloc() to grow @smmu into the larger tegra241_cmdqv, which frees the original @smmu once it relocates. A failure after that returned NULL, and the caller then dereferenced the freed @smmu on its fallback path. Return an int and take @smmu by reference instead, then update *smmu to the reallocated pointer after devm_krealloc() succeeds, so the caller and its fallback path both use the live @smmu rather than the freed original.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92479", "url": "https://ubuntu.com/security/CVE-2026-92479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: Avoid NULL CQE dereference when reporting invalid tags The single-doorbell completion path can call ufshcd_compl_one_cqe() with a NULL CQE. If no command is associated with the completion tag, the warning message dereferences the CQE while reporting the error. Avoid that dereference and include the invalid tag in the warning.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92480", "url": "https://ubuntu.com/security/CVE-2026-92480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Validate string descriptors The string descriptor length includes a two-byte header while the UTF-16 payload starts after it. utf16s_to_utf8s() expects a count of UTF-16 code units, not bytes. Passing the payload byte count can make it read beyond the descriptor buffer. Validate that the payload has an even byte count, pass a code-unit count to the converter, and allocate sufficient UTF-8 output space. The raw string buffer starts after the descriptor header but its size is bLength. Copying bLength bytes from that pointer can read beyond the response buffer. Allocate a zeroed bLength-sized buffer and copy only the UTF-16 payload. This preserves the raw buffer size consumed by the RPMB device-ID ABI while avoiding the overread.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92482", "url": "https://ubuntu.com/security/CVE-2026-92482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: use devm_gpiochip_add_data() for GPIO chip The gpio_chip is allocated with device-managed memory but registered with the non-managed gpiochip_add_data(). This was harmless while the drivers were built-in, but once they can be built as modules and unbound/rmmod'd, devm frees the gpio_chip's memory while it is still registered, causing a use-after-free. Register it with devm_gpiochip_add_data() so it shares the same device-managed lifecycle, which also lets the manual gpiochip_remove() error paths go away.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92483", "url": "https://ubuntu.com/security/CVE-2026-92483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: liveupdate: Remember FLB retrieve() status LUO keeps track of successful retrieve attempts on an FLB. It does so to avoid multiple retrievals of the same FLB. Multiple retrievals cause problems because once the FLB is retrieved, the serialized data structures are likely freed and the FLB is likely in a very different state from what the code expects. All this works well when retrieve succeeds. When it fails, luo_flb_retrieve_one() returns the error immediately, without ever storing anywhere that a retrieve was attempted or what its error code was. If the user attempts to retrieve another file registered with the same FLB, LUO will attempt to call the FLB's retrieve() callback again. The retry is problematic for much of the same reasons listed above. The FLB is likely in a very different state than what the retrieve logic normally expects (e.g. some KHO pages may have already been restored and freed). There is no sane way of attempting the retrieve again. Remember the error retrieve returned and directly return it on a retry. This is done by changing the retrieved bool to a retrieve_status integer. A value of 0 means retrieve was never attempted, a positive value means it succeeded, and a negative value means it failed and the error code is the value. This is similar to commit f85b1c6af5bc (\"liveupdate: luo_file: remember retrieve() status\") which did the same for LUO files.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92485", "url": "https://ubuntu.com/security/CVE-2026-92485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix WARNING in bpf_tracing_link_release The trampoline could be corrupted by the blindly 'tr->flags = BPF_TRAMP_F_TAIL_CALL_CTX' in verifier. 1. A fexit attached to a tail_call_reachable prog. 'tr->flags' became 'BPF_TRAMP_F_CALL_ORIG | BPF_TRAMP_F_TAIL_CALL_CTX'. And, the trampoline would poke the target prog's nop insn using jmp insn instead of call insn. 2. Another fexit loaded with the same tail_call_reachable prog target. 'tr->flags' became 'BPF_TRAMP_F_TAIL_CALL_CTX'. 3. Close the first fexit link. Due to no BPF_TRAMP_F_CALL_ORIG in 'tr->flags', the trampoline will fail to restore the prog's nop insn using call insn. [ 3.410719] WARNING: kernel/bpf/syscall.c:3551 at bpf_tracing_link_release+0x53/0x60, CPU#1: test_progs/98 ... [ 3.428793] bpf_link_free+0x58/0x130 [ 3.429293] bpf_link_release+0x23/0x30 Fix the warning by updating 'tr->flags' with '|=' and lock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92503", "url": "https://ubuntu.com/security/CVE-2026-92503", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix ABBA deadlock in ext4_xattr_inode_cache_find() Syzbot/stress-ng reported an ABBA deadlock in ext4 when exercising concurrent xattr workloads (using the ea_inode mount/format option). The deadlock occurs between the running transaction and the eviction thread: - Task 1 (stress-ng): Holds a reference to a shared mbcache_entry (ce) and calls ext4_xattr_inode_cache_find() -> ext4_iget() to retrieve the corresponding EA inode. Since the EA inode is currently being evicted, ext4_iget() blocks in __wait_on_freeing_inode() waiting for eviction to complete. - Task 2 (eviction thread): Currently evicting the same EA inode in ext4_evict_ea_inode(). It calls mb_cache_entry_wait_unused(oe) which blocks waiting for Task 1 to release the reference to the mbcache_entry. To break this deadlock, implement a new ext4_iget() configuration flag named EXT4_IGET_NOWAIT. When set, perform a non-blocking lookup of the inode via VFS's find_inode_nowait() API. If the inode is currently being evicted (marked with I_FREEING or I_WILL_FREE) or created (I_CREATING), or if it is not present in the VFS inode cache (cache miss), simply skip it (returning -ENOENT) rather than waiting for eviction/creation to complete, breaking the ABBA cycle. Since we return -ENOENT immediately on a cache miss, we never attempt to allocate a new inode or call iget_locked(), completely eliminating any TOCTOU race window. If the returned inode is I_NEW, wait for its initialization to clear via wait_on_new_inode(). If initialization fails and the inode is unhashed during wait_on_new_inode() waking up (e.g., due to an I/O read error in another thread), safely drop the reference and return -ENOENT. This unhashed check is executed unconditionally on all cache-hit pathways to properly handle concurrent initialization failures. Finally, standard validation checks (including is_bad_inode, EXT4_EA_INODE_FL, file_acl, and xattr flags) are executed as normal inside check_igot_inode() to fully guarantee VFS-layer safety. In ext4_xattr_inode_cache_find(), invoke ext4_iget() with the new EXT4_IGET_NOWAIT flag to perform the non-blocking cache search.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93043", "url": "https://ubuntu.com/security/CVE-2026-93043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disallow interpreter fallback for gotox insn The interpreter does not recognize the BPF_JMP|BPF_JA|BPF_X insn, which is used for insn_array map. Thereafter, it would hit the BUG_ON() in ___bpf_prog_run() at run time. [ 2.563726] BPF interpreter: unknown opcode 0d (imm: 0x0) [ 2.564557] ------------[ cut here ]------------ [ 2.565206] kernel BUG at kernel/bpf/core.c:2349! [ 2.565882] Oops: invalid opcode: 0000 [#1] SMP PTI Set jit_required as true when insn_array map is used in the prog in order to disallow interpreter fallback for gotox insn in core.c::__bpf_prog_select_runtime().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93044", "url": "https://ubuntu.com/security/CVE-2026-93044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disallow interpreter fallback for arena-related insns Since the interpreter does not support the arena-related insns, interpreter fallback should not be allowed for these insns in core.c::__bpf_prog_select_runtime(). Currently, when the interpreter executes the arena ST/LDX/STX insns, it would hit the BUG_ON() in ___bpf_prog_run() at run time. [ 2.579196] BPF interpreter: unknown opcode a2 (imm: 0x0) [ 2.579998] ------------[ cut here ]------------ [ 2.580652] kernel BUG at kernel/bpf/core.c:2349! [ 2.581314] Oops: invalid opcode: 0000 [#1] SMP PTI Set jit_required as true when arena map is used in the prog to disallow interpreter fallback for arena-related insns.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93047", "url": "https://ubuntu.com/security/CVE-2026-93047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Associate BOs with every job that accesses them A submission can expand into a chain of jobs (e.g. bin + render + cache clean). Implicit synchronization in v3d_submit_lock_reservations() is gated on each job's bo[], but the BO list was only ever attached to the last job of the chain. When that last job is a trailing CACHE_CLEAN job, the job that actually consumes the BOs (that is, a RENDER or CSD job) was left with bo_count == 0 and picked up no implicit dependencies. It could therefore be dispatched to the hardware and read a BO while another context was still writing it, leading to data corruption. Attach the BOs to the job that consumes them, so (1) it acquires the correct implicit dependencies during reservation locking and (2) they are kept mapped until the end of the submission. Give it references to all consuming job's BOs through v3d_job_reference_bos() instead of looking the handles up a second time; that avoids a redundant lookup and guarantees both jobs reference the exact same objects. As the CACHE_CLEAN job now carries a BO array as well, add a per-job `has_implicit_dep` flag so that only the consuming jobs take implicit dependencies. The CACHE_CLEAN job (a global flush) and the BIN job (binning waiting on another context is not a realistic scenario) are excluded.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93069", "url": "https://ubuntu.com/security/CVE-2026-93069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: OPP: Fix cleanup ordering Commit 173e02d67494 (\"OPP: Initialize scope-based pointers inline\") added initialization for all pointers. In some cases, the ordering was changed so that *opp_table was initialized after *opp. This also changes the order of the registered cleanup functions. When the cleanup happens, this can cause use-after-free errors when the last reference is released and the release function _opp_kref_release tries to access the already freed opp->opp_table. Initialize *opp_table before *opp again to fix this and ensure the correct cleanup order.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93081", "url": "https://ubuntu.com/security/CVE-2026-93081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix SCMI device destroy lifetimes scmi_child_dev_find() drops the reference returned by device_find_child() before returning the scmi_device pointer. A concurrent unregister can then release the device while the destroy path is still using the returned pointer. Make the lookup helper return the device_find_child() reference and keep it until scmi_device_destroy() has finished unregistering the child. Also split device_unregister() in __scmi_device_destroy() so the SCMI bus ID is not made reusable until after device_del() has removed the old scmi_dev.N name from sysfs. This avoids a new SCMI device reusing the same ID while the old device is still registered. The final device release callback is also a possible cleanup path when SCMI children are deleted by driver core recursion rather than __scmi_device_destroy(). Release the SCMI bus ID from a common helper used by destroy, register-failure and final-release paths, and clear scmi_dev->id after freeing it so the final release cannot free the same ID again.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93094", "url": "https://ubuntu.com/security/CVE-2026-93094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix dp_link_peer dangling references on AP vdev rollback ath12k_mac_vdev_create() for an AP vdev creates the bss self-peer via ath12k_peer_create(), which finishes by calling ath12k_dp_link_peer_assign() to publish the dp_link_peer in the dp_hw->dp_peers[peerid_index] RCU table, in the dp_peer's link_peers[] array, and in the per-addr rhashtable. If a step after ath12k_peer_create() fails the function jumps to err_peer_del, which open-codes a WMI peer_delete and waits for the unmap / delete_resp events. The wait_for_peer_delete_done() path relies on ath12k_dp_link_peer_unmap_event() freeing the dp_link_peer when the unmap arrives, but err_peer_del never calls ath12k_dp_link_peer_unassign() first. The published references in the dp_hw RCU table, dp_peer->link_peers[] and the rhashtable are left pointing at the dp_link_peer that unmap_event then frees, producing dangling pointers and use-after-free on subsequent lookups. Replace the open-coded sequence with a call to ath12k_peer_delete(), which already does ath12k_dp_link_peer_unassign() before sending the WMI command. This drops the published references before the dp_link_peer is freed, in the same order as the normal teardown path in ath12k_mac_remove_link_interface(). Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93096", "url": "https://ubuntu.com/security/CVE-2026-93096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/features: Serialize multi-part Get/Set Feature transfers A Get or Set Feature payload larger than the mailbox payload size is split into several mailbox commands. mbox_mutex only serializes individual mailbox commands and is dropped between iterations of these loops. Nothing serializes the multi-part transfer as a whole. cxl_get_feature() and cxl_set_feature() are reachable concurrently from fwctl (per-fd RPCs run under a read-held registration lock) and from the EDAC scrub/ECS/repair paths, so two transfers to the same mailbox can interleave their parts and corrupt the device's transfer context. Add a per-mailbox feat_mutex and hold it across the whole transfer in both functions. It nests outside mbox_mutex (which is taken inside cxl_internal_send_cmd()), and is taken nowhere else, so no lock-ordering inversion is introduced.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93099", "url": "https://ubuntu.com/security/CVE-2026-93099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix UAF from worker threads when domains are removed The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters and may sleep while doing so. They are scheduled via delayed_work embedded in struct rdt_l3_mon_domain. Architecture allocates and frees these domains from CPU hotplug callbacks under cpus_write_lock(), and the workers acquire cpus_read_lock() to keep the domain alive across their access. A use-after-free can occur when a worker is blocked waiting for cpus_read_lock() while the hotplug core holds cpus_write_lock(): the architecture frees the rdt_l3_mon_domain that contains the worker's work_struct. When the worker unblocks, the container_of() it performs on the embedded work pointer dereferences freed memory. Drop cpus_read_lock() from the workers and instead drain pending and in-flight work synchronously before the architecture can free the domain. Since architecture offlines the domain under cpus_write_lock() after it has been unlinked from the RCU list and a grace period has elapsed, no new work can be scheduled. The cancel only needs to wait out existing work. Drop rdtgroup_mutex during CPU offline around cancel_delayed_work_sync() so that a worker waiting on the mutex can complete before re-pinning the work on a different CPU. When offlining a CPU the architecture may iterate over resources in any order. For example, the MBA control domain may be offlined before or after a corresponding L3 monitor domain. Ensure that resctrl fs cancels the workers no matter what order the architecture offlines the domains.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93104", "url": "https://ubuntu.com/security/CVE-2026-93104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rvt: Return NULL after port allocation failure rvt_alloc_device() deallocates the IB device when its port array cannot be allocated but then returns the pointer to the released allocation. Callers treat any non-NULL value as valid and dereference it, resulting in a use-after-free. Return NULL immediately after deallocation so callers can propagate the allocation failure.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93105", "url": "https://ubuntu.com/security/CVE-2026-93105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: esp: do not unref managed frag pages in esp_ssg_unref() esp_ssg_unref() releases the page references held on the source scatterlist after the AEAD operation completes. It calls skb_page_unref() on every frag page for an out-of-place transform (req->src != req->dst), and in the error path of esp_output_tail() (already_unref == true) on the request's own scatterlist. This is wrong when the skb carries managed frags (SKBFL_MANAGED_FRAG_REFS). Managed frags are owned by a zerocopy ubuf and the skb does not hold a per-frag page reference; io_uring SEND_ZC with a registered buffer attaches the bvec pages this way via io_sg_from_iter(). The rest of the stack honours this invariant: skb_release_data() skips the per-frag unref when SKBFL_MANAGED_FRAG_REFS is set, and skb_zcopy_managed() is the guard used at the other unref sites. esp_ssg_unref() is missing that guard, so for a managed-frag skb it drops a page reference the skb never acquired. This can underflow the page reference count and free a page that is still in use. Guard the function with skb_zcopy_managed() so both unref paths are skipped for managed-frag skbs, matching skb_release_data().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93116", "url": "https://ubuntu.com/security/CVE-2026-93116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: asus-wmi: fix resource leaks on probe failure During driver initialization in asus_wmi_add(), various subsystems are registered sequentially. However, the error path labels are out of order relative to the registration sequence. Specifically: 1. If asus_wmi_custom_fan_curve_init() fails, the driver jumps to fail_custom_fan_curve. Because this label is placed below fail_sysfs, it bypasses the cleanup calls for the input device and sysfs groups, which were successfully registered before, leaking those resources. 2. If asus_screenpad_init() fails, the driver jumps to fail_screenpad. Because fail_screenpad is placed below fail_backlight, it bypasses the cleanup calls for backlight and rfkill, leaking those resources. Fix these resource leaks by reordering the error path labels in asus_wmi_add() to match the exact reverse order of the resource allocations.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93122", "url": "https://ubuntu.com/security/CVE-2026-93122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uac: validate rate list length before storing UAC1 and UAC2 configfs rate-list attributes parse a comma-separated list of sampling rates and store each parsed value in fixed-size arrays. The arrays have UAC_MAX_RATES entries, but the store paths do not check that the input contains at most that many tokens before writing through opts->name##s[i++]. Writing more than ten rates therefore writes past the end of the p_srates[] or c_srates[] array in struct f_uac1_opts or struct f_uac2_opts. With CONFIG_UBSAN_BOUNDS enabled, writing an 11-entry rate list to the UAC1 p_srate attribute reports: UBSAN: array-index-out-of-bounds drivers/usb/gadget/function/f_uac1.c:1669:1 index 10 is out of range for type 'int [10]' __ubsan_handle_out_of_bounds.cold f_uac1_opts_p_srate_store configfs_write_iter vfs_write ksys_write do_syscall_64 The same reproducer against the UAC2 p_srate attribute reports: UBSAN: array-index-out-of-bounds drivers/usb/gadget/function/f_uac2.c:2087:1 index 10 is out of range for type 'int [10]' __ubsan_handle_out_of_bounds.cold f_uac2_opts_p_srate_store configfs_write_iter vfs_write ksys_write do_syscall_64 Reject additional tokens once UAC_MAX_RATES entries have been parsed. Also keep the original kstrdup() pointer for kfree(), because strsep() advances the parsing cursor. Freeing the advanced cursor leaks the original buffer on successful parses and can free an interior pointer on some error paths.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93125", "url": "https://ubuntu.com/security/CVE-2026-93125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max check_kfunc_args() detects a kfunc argument named rdonly_buf_size or rdwr_buf_size and stores reg->var_off.value into meta->r0_size, a u64, and does not bound it. check_kfunc_call() later copies that value into the returned register's mem_size field: meta->r0_size = reg->var_off.value; ... regs[BPF_REG_0].mem_size = meta.r0_size; regs[BPF_REG_0].mem_size is u32. A constant whose upper 32 bits are set gets truncated instead of causing a load-time rejection, so the verifier records a PTR_TO_MEM register with an approximately 4 GiB mem_size for whatever allocation the kfunc returned. A later access check against that register uses the truncated, wrong bound. Reject rdonly_buf_size/rdwr_buf_size values that exceed U32_MAX at the point meta->r0_size is set.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93127", "url": "https://ubuntu.com/security/CVE-2026-93127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Drop scalar id on sign-extending narrowing stack fills When a spilled scalar is filled back with a sign-extending narrowing load (BPF_MEMSX), check_stack_read_fixed_off() copies the spilled register including its scalar id, but coerce_reg_to_size_sx() then sign-extends the filled register's value. If the same slot is also filled with a plain zero-extending load (BPF_MEM), both destination registers share the id yet hold different values. A later 'if == const' then refines the sign-extended register through sync_linked_regs() to a value it does not have at runtime (e.g. the verifier believes 0x80000000 while the register is 0xffffffff80000000), which can be turned into an out-of-bounds access. Drop the shared scalar id at the sign-extension site in check_mem_access() when sign extension actually changes the value, mirroring the BPF_MOVSX handling in check_alu_op() (no_sext = reg_umax < 2^(size*8-1)).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93129", "url": "https://ubuntu.com/security/CVE-2026-93129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-base: Fix handling of ultra performance key The commit message of commit 5fbd827eb9c2 (\"platform/x86: dell-wmi: Recognise or support new switches\") states that the ultra performance key contains additional data after the type and code fields. The event data passed to dell_wmi_process_key() is already parsed, so \"buffer\" already starts after those two fields. Use the correct index for accessing the first data field to avoid a potential buffer overread.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93135", "url": "https://ubuntu.com/security/CVE-2026-93135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject programs with inlined helpers if JIT is not available When an architecture (such as LoongArch, ARM64, and RISC-V) implements bpf_jit_inlines_helper_call(), the verifier skips rewriting the helper call offset (insn->imm) in bpf_do_misc_fixups(). This is because the helper is expected to be inlined by the JIT compiler later. Therefore, insn->imm remains as the raw helper enum ID. However, if JIT is disabled at runtime (net.core.bpf_jit_enable=0) or if JIT compilation fails dynamically (e.g., due to OOM), the program falls back to the BPF interpreter. When the interpreter executes (__bpf_call_base + insn->imm) with the unpatched raw ID, it jumps into an invalid address space, triggering an instruction alignment fault or a kernel panic. Although these helpers have valid C implementations in the kernel, the omission of offset rewriting makes runtime interpreter fallback fatal. Fix this by setting 'prog->jit_required = 1' when helper call rewriting is skipped for JIT inlining. This ensures that such programs are safely rejected if JIT is not available, preventing the runtime kernel panic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93144", "url": "https://ubuntu.com/security/CVE-2026-93144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject writes through untrusted BTF pointers check_ptr_to_btf_access() lets program-type btf_struct_access callbacks validate writes before the default BTF access path rejects non-read accesses. That bypasses the read-only policy for untrusted BTF pointers created by helpers such as bpf_rdonly_cast(). Reject non-read accesses through PTR_UNTRUSTED BTF pointers at the common entry point, before the callback branch to handle all cases.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93148", "url": "https://ubuntu.com/security/CVE-2026-93148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject MEM_ALLOC BTF accesses past object bounds BTF struct walks relax the struct-size check for accesses through a trailing flexible array. That is valid for ordinary BTF type walking, but PTR_TO_BTF_ID | MEM_ALLOC values point to objects allocated with the static BTF type size. When walking a MEM_ALLOC object, reject the access before applying the flexible-array relaxation if the access range extends past the struct size. Apply the same policy to struct ID matching so kfunc and kptr type checks do not walk past the allocated object bounds either.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93153", "url": "https://ubuntu.com/security/CVE-2026-93153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bng_re: return a timeout when firmware responses stall __wait_for_resp() documents that it returns a non-zero error when a firmware command does not complete, and bng_re_rcfw_send_message() already marks the firmware as stalled when the helper returns -ENODEV. However, the helper ignores wait_event_timeout() expiry. If the response slot remains in use after the timeout and after the polled CREQ service attempt, the loop starts another full timeout period and can repeat forever. Return -ENODEV after a timed out wait that still has no response. The existing caller then marks FIRMWARE_STALL_DETECTED and returns -ETIMEDOUT to the command issuer.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93164", "url": "https://ubuntu.com/security/CVE-2026-93164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes/x86: Move optimized uprobe from nop5 to nop10 Andrii reported an issue with optimized uprobes [1] that can clobber redzone area with call instruction storing return address on stack where user code may keep temporary data without adjusting rsp. Fixing this by moving the optimized uprobes on top of 10-bytes nop instruction, so we can squeeze another instruction to escape the redzone area before doing the call, like: lea -0x80(%rsp), %rsp call tramp Note the lea instruction is used to adjust the rsp register without changing the flags. We use nop10 and following transformation to optimized instructions above and back as suggested by Peterz [2]. Optimize path (int3_update_optimize): 1) Initial state after set_swbp() installed the uprobe: cc 2e 0f 1f 84 00 00 00 00 00 From offset 0 this is INT3 followed by the tail of the original 10-byte NOP. After a previous unoptimization bytes 5..9 may still contain the old call instruction, which remains valid for threads already there. 2) Rewrite the LEA tail and call displacement: cc [8d 64 24 80 e8 d0 d1 d2 d3] From offset 0 this traps on the uprobe INT3. Bytes 1..9 are not executable entry points while byte 0 is trapped. 3) Publish the first LEA byte: [48] 8d 64 24 80 e8 d0 d1 d2 d3 From offset 0 this is: lea -0x80(%rsp), %rsp call Unoptimize path (int3_update_unoptimize): 1) Initial optimized state: 48 8d 64 24 80 e8 d0 d1 d2 d3 Same as 3) above. 2) Trap new entries before restoring the NOP bytes: [cc] 8d 64 24 80 e8 d0 d1 d2 d3 From offset 0 this traps. A thread that had already executed the LEA can still reach the intact CALL at offset 5. 3) Restore bytes 1..4 of the original NOP while keeping byte 0 trapped and byte 5 as CALL. cc [2e 0f 1f 84] e8 d0 d1 d2 d3 From offset 0 this still traps. Offset 5 is still the CALL for any thread that was already past the first LEA byte. 4) Publish the first byte of the original NOP: [66] 2e 0f 1f 84 e8 d0 d1 d2 d3 From offset 0 this is the restored 10-byte NOP; the CALL opcode and displacement are now only NOP operands. Offset 5 still decodes as CALL for a thread that was already there. Tthere is only a single target uprobe-trampoline for the given nop10 instruction address, so the CALL instruction will not be changed across unoptimization/optimization cycles. Therefore, any task that is preempted at the CALL instruction is guaranteed to observe that CALL and not anything else. Note as explained in [2] we need to use following nop10: PF1 PF2 ESC NOPL MOD SIB DISP32 NOP10: 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00 -- cs nopw 0x00000000(%rax,%rax,1) which means we need to allow 0x2e prefix which maps to INAT_PFX_CS attribute in is_prefix_bad function. Also changing the uprobe syscall error when called out of uprobe trampoline to -EPROTO, so we are able to detect the fixed kernel. The optimized uprobe performance stays the same: uprobe-nop : 3.129 ± 0.013M/s uprobe-push : 3.045 ± 0.006M/s uprobe-ret : 1.095 ± 0.004M/s --> uprobe-nop10 : 7.170 ± 0.020M/s uretprobe-nop : 2.143 ± 0.021M/s uretprobe-push : 2.090 ± 0.000M/s uretprobe-ret : 0.942 ± 0.000M/s --> uretprobe-nop10: 3.381 ± 0.003M/s usdt-nop : 3.245 ± 0.004M/s --> usdt-nop10 : 7.256 ± 0.023M/s [1] https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/ [2] https://lore.kernel.org/bpf/20260518104306.GU3102624@noisy.programming.kicks-ass.net/#t", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93168", "url": "https://ubuntu.com/security/CVE-2026-93168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a condition that is never fulfilled, the CPU busy-waits for prolonged time and the timeout triggers only with a massive delay causing a CPU stall. This happens due to a huge underestimation of wall clock time in poll_timeout_us_atomic. Commit 7349a69cf312 (\"iopoll: Do not use timekeeping in read_poll_timeout_atomic()\") changed the behavior to no longer use ktime_get at the expense of underestimation of wall clock time which appears to be very large for delay_us=0. Instead of timing out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for loop in poll_timeout_us_atomic takes) which is in the range of several minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero value for delay_us. Use delay_us=10 to keep the delay in the hot path of starting DMA transfers minimal but still avoid CPU stalls in case of unexpected hardware failures. One-off measurement with delay_us=0 causes the cpu to busy wait around 7 minutes in the timeout case. After applying this patch with delay_us=10 the measured timeout was 1053428 microseconds which is roughly equivalent to the expected 1000000 microseconds specified in XILINX_DMA_LOOP_COUNT. Add a constant XILINX_DMA_POLL_DELAY_US for delay_us value.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93176", "url": "https://ubuntu.com/security/CVE-2026-93176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix dangling pointer in plane reset function amdgpu_dm_plane_drm_plane_reset() frees the old state before allocating a new one. If kzalloc() fails, the function returns without updating the state pointer, leaving a dangling pointer to already freed memory. Fix this by allocating the new state first. On allocation failure, the old state remains untouched and the function safely returns. Found by Linux Verification Center (linuxtesting.org) with SVACE. [adjust for movement around current amd-staging-drm-next]", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93179", "url": "https://ubuntu.com/security/CVE-2026-93179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/powerplay: fix VoltageObjectInfo zero-stride loop and OOB read Reject voltage objects whose usSize is smaller than the header or would advance the cursor past the table end, preventing an infinite loop or heap OOB read when the VBIOS supplies a malformed VoltageObjectInfo table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93181", "url": "https://ubuntu.com/security/CVE-2026-93181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Fix uncore_box ref/unref ordering In uncore_event_cpu_online(), uncore_box_ref() was called before uncore_change_context(). uncore_box_ref() gates on box->cpu >= 0, but box->cpu is still -1 at that point because uncore_change_context() has not run yet. As a result, the box is never initialized on the first CPU to come online in a die, leaving it permanently uninitialized in the single-CPU-per-die case. Thus, box->refcnt is one count below the true value, and in the CPU offline path, the box will be torn down on the second-to-last CPU. In uncore_event_cpu_offline(), uncore_box_unref() was called after uncore_change_context(), so box->cpu is already -1 when the collector CPU goes offline, which prevents it from tearing down the box. Fix by swapping the call order in both paths so that uncore_box_{ref,unref}() runs at the point where box->cpu reflects the correct context. Move allocate_boxes() out of uncore_box_ref() to enable this reordering.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89788", "url": "https://ubuntu.com/security/CVE-2026-89788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix tree connection use-after-free in smb2_tree_connect() ksmbd_tree_conn_connect() publishes a new tree connection in sess->tree_conns with a single reference and returns its pointer to smb2_tree_connect(). The handler continues to initialize the object and build the response after publication. A concurrent session logoff can erase the connection and drop that reference, freeing the object while the handler still uses it. BUG: KASAN: slab-use-after-free in smb2_tree_connect+0xe3d/0xf90 smb2_tree_connect (fs/smb/server/smb2pdu.c:2872) handle_ksmbd_work process_one_work worker_thread kthread After xa_store() succeeds, take a second reference before releasing tree_conns_lock. The original reference belongs to the xarray entry and the second belongs to the creating smb2_tree_connect() handler. Keep the references balanced in every path: - On normal exit or an error after publication, smb2_tree_connect() drops its creator reference. Error cleanup also calls ksmbd_tree_conn_disconnect(), which drops the xarray reference only if it removes the exact entry. - SMB2 TREE_DISCONNECT uses the same helper to remove the entry and drop its xarray reference. The request's existing lookup reference remains owned by the request and is released by the existing cleanup. - Session LOGOFF removes each entry and drops its xarray reference. If it wins the race, later cleanup sees that the entry is gone and does not drop that reference again. To enforce this ownership, claim the disconnected state and erase the exact entry atomically under tree_conns_lock. This guarantees one drop for the xarray reference and one drop by each in-flight user, regardless of which teardown path wins. If logoff removes the entry before initialization completes, fail the connect instead of marking the detached object TREE_CONNECTED.", "cve_priority": "high", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93201", "url": "https://ubuntu.com/security/CVE-2026-93201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-pcache: validate seg_id fields from persistent memory cache_pos_decode(), cache_key_decode() and the last-kset branches of cache_replay(), the writeback worker and the GC worker take a cache segment id from the cache device metadata and index cache->segments[] with it without checking it against cache->n_segs. That metadata is only CRC-protected with a fixed public seed, so whoever supplies the cache device on a table load (CAP_SYS_ADMIN) controls the id; an out-of-range value forms a wild pcache_cache_segment pointer that is dereferenced and written through -- an out-of-bounds read and write driven by on-disk data. Add cache_seg_id_valid() and reject an out-of-range id at each decode site, failing the operation with -EIO instead of indexing past the array. Bound the id against the initialized-segment count (cache_info.n_segs) rather than the physical device total. A forged cache_info.n_segs below seg_num otherwise leaves segments[cache_info.n_segs..seg_num) as zeroed structs whose data pointer is NULL, so a forged id in that window would still be dereferenced. A later patch guarantees cache_info.n_segs <= seg_num, and a driver-created cache sets the two equal, so valid images are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89792", "url": "https://ubuntu.com/security/CVE-2026-89792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds reads in share config responses Validate IPC share configuration payload sizes before consuming variable-length fields. Bound veto list parsing and account for the separator byte when deriving the path length.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90051", "url": "https://ubuntu.com/security/CVE-2026-90051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: reject non zerocopy devmem tx Devmem tcp tx doesn't work without zero-copy, however it's not currently enforced if NETIF_F_SG isn't present. In this case, tcp_sendmsg_locked() will try the copy path and try to copy data from an iovec which consists of offsets into the dma-buf and would normally fail. Moreover, d9c56501c72fd (\"net: tcp: block mixing readable and unreadable frags\") relies on that and assumes that the devmem binding is present IFF we're using the zero-copy path, which can be used to mix net-iov and pages in a single skb, and break invariants. Let's reject devmem tx without zero-copy. Note, the parameter check the patch is modifying is too loose, we can create an io_uring request with dmabuf_id and all ZC flags, but which won't have the binding. We replace it with stricter validation.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90053", "url": "https://ubuntu.com/security/CVE-2026-90053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_htb: limit htb_classify inner-class filter hops htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet. Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at the point the inner filter chain is picked up, after the TC_ACT_* switch has consumed the classifier verdict, so a terminal TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr to __NET_XMIT_STOLEN and the packet is not charged as a drop by this qdisc or its parent. The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than from the qdisc hierarchy depth limit. Class levels run from 0 to TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can take at most TC_HTB_MAXDEPTH hops. That descent is what a sane configuration does, but it is assumed here rather than enforced: htb_find() resolves a classid against every class in the qdisc, so a filter may equally select a sibling or an ancestor. The normal root -> inner -> leaf path takes a single hop, so the bound does not affect legitimate classification. htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT, whereas previously every NULL return sat inside that ifdef. The NULL handler in htb_enqueue() therefore cannot stay conditional either, so drop the ifdef around it. This matches hfsc_enqueue(), which has always handled a NULL class unconditionally. Without it, a kernel built without actions would dereference a NULL class instead of dropping. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Create an HTB qdisc on a device (e.g. lo), add an inner class 1:1 with a leaf child 1:10, install a root u32 filter selecting 1:1, and an inner-class u32 filter on 1:1 also selecting 1:1. - Send one packet (ping). On the unfixed kernel the classify loop spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90054", "url": "https://ubuntu.com/security/CVE-2026-90054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix corruption of urgent data on multi-segment retransmit On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: \t/* tcp_write_xmit() */ \tlimit = mss_now; \tif (tso_segs > 1 && !tcp_urg_mode(tp)) \t\tlimit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: \t/* __tcp_retransmit_skb() */ \tlen = cur_mss * segs;\t\t/* segs > 1, no urg_mode check */ \t... \t/* tcp_gso_segment(): bumps seq only, urg_ptr is copied */ urg_ptr is an offset from the segment's own seq, so a copied value points at a different place on each segment. The receiver rebuilds the absolute urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead of the one OOB byte: \tseg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok) \tseg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS) \tseg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS) The real OOB byte is never pointed at, so the receiver stops splicing it out and delivers it as normal in-band data, corrupting the stream. Guard the retransmit length like the xmit path: keep segs = 1 while in urgent mode.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90055", "url": "https://ubuntu.com/security/CVE-2026-90055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90056", "url": "https://ubuntu.com/security/CVE-2026-90056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: only stop PTP if it was initialized fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90057", "url": "https://ubuntu.com/security/CVE-2026-90057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: remove slip_hangup() to fix use-after-free in slip_receive_buf() Jaeyoung Chung and Eulgyu Kim reported a slab-use-after-free read in slip_receive_buf() when racing against tty hangup. tty_ldisc_hangup() calls ld->ops->hangup() while holding only a read lock on tty->ldisc_sem (via tty_ldisc_ref()). Because slip_hangup() simply called slip_close(), it ran concurrently with reader functions such as slip_receive_buf(). slip_close() unregisters and frees the net device and its private struct slip, causing concurrent reader threads in slip_receive_buf() to dereference freed memory. Line discipline close() is already guaranteed to be called under the write lock of tty->ldisc_sem during hangup processing (in tty_ldisc_reinit() or tty_ldisc_kill()). Remove slip_hangup() so teardown is serialized cleanly by slip_close().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90058", "url": "https://ubuntu.com/security/CVE-2026-90058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai. Cap the final qdisc_pkt_len() to QDISC_PKT_LEN_MAX so the size-table amplification cannot drive deficit schedulers into an unbounded loop. A legitimate size table (e.g. qfq's overhead 999999999, which is handled by dropping) is still accepted. Introduce cap QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSO_MAX_SIZE (524280), and an ATM-style size table (53/48 cell tax) amplifies that to ~578 KB, both comfortably below 1 MiB. At the same time, 1 MiB bounds the deficit refill loop to ~1M iterations per packet with quantum=1, which completes in a few milliseconds well under the demonstrated softlockup threshold (~10^9 iterations). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=15, data=[32768]). - Add a class with a tiny quantum of 1 and send one small packet; the deficit loop spins billions of times under the qdisc lock and trips the softlockup detector (panic with kernel.softlockup_panic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90059", "url": "https://ubuntu.com/security/CVE-2026-90059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: restore NET_IP_ALIGN in the RX DMA offset Since the RX path was converted to zero-copy, the page pool page is handed to the stack directly as the skb head, and the offset the DMA engine writes at is what determines the alignment of the packet headers. Before the conversion the payload was copied into an skb obtained from napi_alloc_skb(), which reserves NET_SKB_PAD + NET_IP_ALIGN. The conversion moved the headroom into stmmac_rx_offset() but did not carry over NET_IP_ALIGN, so on architectures where NET_IP_ALIGN is 2 the IP header now lands misaligned: 64 (NET_SKB_PAD) + 14 (ethernet) + 20 (IP) = 98 Same for the XDP branch: 256 (XDP_PACKET_HEADROOM) + 14 (ethernet) + 20 (IP) = 290 On ARM32 this is fatal, because ldm and ldrd trap on unaligned addresses even when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set. Any received echo request panics the machine, e.g: Unhandled fault: alignment exception (0x001) at 0x81873062 Internal error: : 1 [#1] SMP ARM Hardware name: Altera SOCFPGA Arria10 PC is at icmp_echo+0x38/0xa8 LR is at icmp_rcv+0x22c/0x370 Call trace: icmp_echo from icmp_rcv+0x22c/0x370 icmp_rcv from ip_protocol_deliver_rcu+0x2c/0x224 ip_protocol_deliver_rcu from ip_local_deliver+0xc8/0x1a0 ip_local_deliver from ip_sublist_rcv_finish+0x3c/0x50 ip_sublist_rcv_finish from ip_list_rcv_finish+0x110/0x118 ip_list_rcv_finish from ip_list_rcv+0xc8/0xdc ip_list_rcv from __netif_receive_skb_list_core+0x170/0x1c0 ... napi_complete_done from stmmac_napi_poll_rx+0xcb0/0x1030 Code: e24dd068 e59020a0 e28dc010 e0822001 (e8920003) Kernel panic - not syncing: Fatal exception in interrupt The faulting instruction is the ldm of *icmp_hdr(skb) in icmp_echo(). Fix by adding NET_IP_ALIGN back to the RX offset, which restores the alignment the stack used to get. Note that commit a955318fe67e (\"stmmac: align RX buffers\") made a similar change in 2021 and was reverted by commit 12d125b4574b (\"stmmac: Revert \"stmmac: align RX buffers\"\") because it caused packet corruption. That patch raised the offset from 0 without adjusting the buffer size accounting, so the DMA engine could arguably write past the end of the RX buffers, though this was never root caused. Commit df542f669307 (\"net: stmmac: Switch to zero-copy in non-XDP RX path\") since derives the page pool allocation from stmmac_rx_offset(), so the extra bytes are accounted for.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90060", "url": "https://ubuntu.com/security/CVE-2026-90060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Don't add invalid kcontrols to LED layer The kcontrol LED state layer tries to track the all associated kcontrol elements with naive assumptions that they are readable. But one can create a write-only element that has no get callback (even a user element can do it), and this may lead to a NULL dereference at the call chain of snd_ctl_led_notify(), as found by syzkaller. For avoiding the Oops, add a sanity check of the kcontrol's info and get callbacks, and just skip the invalid kcontrols before assigning the kctl to the LED layer.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90062", "url": "https://ubuntu.com/security/CVE-2026-90062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: move hardware offload step after building the chain blob Allocate the chain blob before the ruleset offload to reduce chances of entering an inconsistent state where the offloaded ruleset in the nic and the software ruleset differ.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90063", "url": "https://ubuntu.com/security/CVE-2026-90063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90065", "url": "https://ubuntu.com/security/CVE-2026-90065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: release the internal TCP sock on IPPROTO_SMC socket creation failure IPPROTO_SMC sockets create an internal TCP sock (\"clcsock\") from the proto->init hook. When socket creation fails after proto->init has run - e.g. a cgroup BPF program attached to BPF_CGROUP_INET_SOCK_CREATE denies the socket - sk_common_release() only invokes sk_prot->destroy if it is set, but neither smc_inet_prot nor smc_inet6_prot defines it, and smc_destruct() returns early unless sk_state is SMC_CLOSED. As a result, every failing socket(AF_INET, SOCK_STREAM, IPPROTO_SMC) call leaks one tcp_sock, so an unprivileged task able to attach a deny-all BPF_CGROUP_INET_SOCK_CREATE program to its own cgroup can grow kernel memory unboundedly. Add a .destroy hook to both protos that releases the clcsock via smc_clcsock_release(). smc_sk_init() hashes the sock into the smc hashinfo before the clcsock is created, and smc_diag dumps walk that hash dereferencing smc->clcsock without taking clcsock_release_lock, while sk_common_release() calls .destroy before .unhash. Unhash the sock before releasing the clcsock, as __smc_release() does, so a concurrent dump cannot observe the release; the second unhash in sk_common_release() is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90066", "url": "https://ubuntu.com/security/CVE-2026-90066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-multi-modify ftrace_direct_multi_init() assigns kthread_run()'s return value to simple_tsk without an IS_ERR() check. When kthread_run() fails it returns ERR_PTR(-ENOMEM), but init still returns 0, so the module loads with simple_tsk holding an error pointer. On unload, ftrace_direct_multi_exit() then passes that ERR_PTR to kthread_stop(), leading to a null-pointer-dereference. Check the return value of kthread_run() with IS_ERR(); on failure, unregister the ftrace direct call and propagate the error code.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90067", "url": "https://ubuntu.com/security/CVE-2026-90067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: validate banner payload length When parsing the Ceph messenger v2 protocol banner, the `payload_len` field is decoded from the banner prefix. If a client sends a banner with a `payload_len` of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in `populate_in_iter()`: ------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 According to the msgr2 protocol specification, the banner payload is expected to contain at least two 64-bit integers (`server_feat` and `server_req_feat`). Therefore, `payload_len` must be at least 16 bytes. Fix this by adding a check in `process_banner_prefix()` to reject a `payload_len` smaller than 16 bytes. This prevents the 0-length read and correctly aborts the connection with a protocol error.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90068", "url": "https://ubuntu.com/security/CVE-2026-90068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: Fix off-by-one check on the second enum channel The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to snd_soc_enum_item_to_val(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end. The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used >= there, and the snd_soc_put_enum_double() in soc-ops.c still does. Only adav80x pairs a value table with two shifts, and its second channel looks accidental, but the control does report two values. Writing three into it reads off the end of adav80x_mux_values. The core catches that only under CONFIG_SND_CTL_INPUT_VALIDATION, which defaults off.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90069", "url": "https://ubuntu.com/security/CVE-2026-90069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: acomp - allocate async request context when cloning ACOMP_REQUEST_ON_STACK() reserves only enough storage for the synchronous fallback. When an async implementation is selected, callers clone that stack request before retrying, but acomp_request_clone() currently copies only the stack-sized object. The clone therefore has no storage for the async provider request context, and providers such as QAT write past the allocation through acomp_request_ctx(). KASAN does report a slab OOB write. Allocate a zeroed clone large enough for the runtime acomp request size, copy only the bytes present in the source object, and preserve the existing fallback-on-allocation-failure behavior. Use the runtime reqsize because an implementation may adjust it during tfm initialization.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90070", "url": "https://ubuntu.com/security/CVE-2026-90070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Return zero on status read failure st33zp24_status() ignores the result of the transport read and returns data even when no byte was received. The I2C transport, for example, skips i2c_master_recv() when the register-select write is short or fails, leaving data uninitialized. The resulting stack value can be interpreted as TPM_STS flags and let status checks complete spuriously. The status callback cannot propagate a transport error. Return zero unless recv() reports exactly one byte. With no status bits set, callers retry or take their existing timeout or error path instead of acting on an invalid status value. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90071", "url": "https://ubuntu.com/security/CVE-2026-90071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: restore skb->dev on the slave failure path teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6377 mm/slub.c:6692) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90072", "url": "https://ubuntu.com/security/CVE-2026-90072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90073", "url": "https://ubuntu.com/security/CVE-2026-90073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare \"tc qdisc add ... hhf\" succeeds with a clamped quantum but \"tc qdisc add ... hhf limit 1000\" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90074", "url": "https://ubuntu.com/security/CVE-2026-90074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp default quantum to avoid signed overflow fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(), causing an infinite loop and soft lockup. Emulate fq_pie_policy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90075", "url": "https://ubuntu.com/security/CVE-2026-90075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_codel: clamp default quantum and mtu fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(), causing an infinite loop and soft lockup. Emulate fq_codel_change() and constrain to [256, FQ_CODEL_QUANTUM_MAX]. The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit below, and fq_codel_change() never updates it. codel_should_drop() tests \"*backlog <= params->mtu\"; with mtu == 0x80000000 (~2 GiB) and the default 32 MiB memory_limit, the test is always true, so CoDel is silently and completely disabled (no drops, no ECN). Declare a single clamped mtu and assign both q->quantum and q->cparams.mtu from it, which also removes the double psched_mtu() call. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90076", "url": "https://ubuntu.com/security/CVE-2026-90076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq: add overflow bounds to quantum and initial quantum fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 * psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill loop adds 0 to f->credit (which stays <= 0) and goto begin loops forever under the qdisc lock, creating a soft lockup. Clamp psched_mtu() to [1, 1 << 20] before multiplying so the product cannot wrap, then cap the result at 1 << 20, matching the bound already enforced on TCA_FQ_QUANTUM in fq_change(). Conditions to recreate the bug: a device whose MTU (plus hard_header_len) is large enough that 2 * psched_mtu() wraps (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90077", "url": "https://ubuntu.com/security/CVE-2026-90077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix a resource leak in copy_net_ns() error handling path Currently, preinit_net() does two things: (1) call ns_common_init() which might fail (2) initialize resources which does not fail However, preinit_net() is returning early when (1) fails, and copy_net_ns() is jumping to the dec_ucounts: label. As a result, resources allocated by net_alloc() are leaking. We need to call key_remove_domain() and net_passive_dec() in order to release resources allocated by net_alloc(). We cannot simply jump to the put_userns: label when preinit_net() failed, for (2) is not yet done. But we can reorder (1) and (2), for there is no dependency between (1) and (2). Therefore, this patch decouples (1) from preinit_net() and changes preinit_net() back to a void function, and calls ns_common_init() after preinit_net() succeeded. Then, we can jump to immediately after ns_common_free() of the put_userns: label.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90078", "url": "https://ubuntu.com/security/CVE-2026-90078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: fix length calculations and avoid invalid header warnings syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act(): !skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55 There are a few issues in tcf_skbmod_act(): 1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress. 2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length. 3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets). Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90080", "url": "https://ubuntu.com/security/CVE-2026-90080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup af_xdp_zc_qidx tracks receive queues using AF_XDP zero-copy and is allocated during PF/VF probe. Representors and other non-AF_XDP paths leave the pointer NULL, but several call sites used test_bit() on it unconditionally. Switching to devlink eswitch mode creates representors and runs otx2_init_hw_resources(), which reaches otx2_pool_aq_init() and oopses when dereferencing the NULL bitmap. Add NULL checks before every af_xdp_zc_qidx test_bit() use in the RSS, ethtool, XSK, and pool init paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90081", "url": "https://ubuntu.com/security/CVE-2026-90081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in rds_cong_map_updated() rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued. rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90083", "url": "https://ubuntu.com/security/CVE-2026-90083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ife: Only operate on Ethernet frames act_ife encapsulates/decapsulates the original Ethernet header and uses skb->dev->hard_header_len as the length of that header. That is only correct for Ethernet devices: on a device where hard_header_len does not match the L2 header that was actually pulled (PPP reports PPP_HDRLEN while nothing is stripped on ingress), the ingress skb_push()/skb_pull() use the wrong length and can hit skb_under_panic when headroom is tight. IFE is Ethernet-only by design - it builds an outer ethhdr, rewrites h_source/h_dest/h_proto, and calls eth_type_trans() on decode - so instead of trying to make the offsets work for arbitrary link types, simply drop packets that do not carry an Ethernet header. Checking skb->dev->type alone is not enough. We have to cater for a corner case where mirred can redirect an skb from a non-Ethernet device to an Ethernet one, and skb->dev then says nothing about the framing the skb actually has: an skb redirected from ppp0 reaches the target's ingress hook with mac_len 0 and no Ethernet header at all. So at ingress also require mac_len to be ETH_HLEN. On egress mac_len is not maintained, so the device type is all we have; a bogus redirect there yields a malformed frame rather than an out-of-bounds push, and it would be malformed with or without IFE. That corner case is not theoretical - redirecting from ppp0 into a veth that has an ife encode action on its ingress hook panics without this patch: skbuff: skb_under_panic: len:98 put:14 head:ffff88800e410000 data:ffff88800e40fff5 tail:0x57 end:0x640 dev:veth3 kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:224 net/core/skbuff.c:2657) tcf_ife_act (net/sched/act_ife.c:829 net/sched/act_ife.c:874) tc_run (net/core/dev.c:4463) netif_receive_skb (net/core/dev.c:6463 net/core/dev.c:6522) tcf_mirred_to_dev (net/sched/act_mirred.c:248 net/sched/act_mirred.c:328) tcf_mirred_act (net/sched/act_mirred.c:489) tc_run (net/core/dev.c:4463) process_backlog (net/core/dev.c:6728) With Ethernet framing guaranteed, use ETH_HLEN instead of hard_header_len.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-89780", "url": "https://ubuntu.com/security/CVE-2026-89780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: restore skb->dev on deaggregated frames rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90084", "url": "https://ubuntu.com/security/CVE-2026-90084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-vf: fix workqueue and netdev race in probe/remove Initialize the VF workqueue before register_netdev() so ndo_set_rx_mode does not queue work on a NULL workqueue. Unregister the netdev before destroying the workqueue, and add proper probe error cleanup.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90085", "url": "https://ubuntu.com/security/CVE-2026-90085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: fix NULL deref in NIX TM tree debugfs read path rvu_dbg_nix_tm_tree_display() dereferences pfvf->sq_ctx without checking whether the SQ context has been allocated. Reading /sys/kernel/debug/octeontx2/nix/tm_tree for a NIX LF whose transmit queues are not set up triggers a kernel oops. Guard the read path the same way rvu_dbg_nix_tm_tree_write() already does and return -EINVAL with a seq_file message when sq_ctx is NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-89789", "url": "https://ubuntu.com/security/CVE-2026-89789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free gtp_newlink()'s error path frees tid_hash and addr_hash without waiting for an RCU grace period after clearing sk_user_data. A concurrent gtp_encap_recv() in softirq may still hold the gtp_dev pointer obtained via rcu_dereference_sk_user_data() and access the freed memory. BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152) Call Trace: gtp0_pdp_find+0x1f6/0x200 gtp_encap_recv+0x527/0x24b0 udp_queue_rcv_one_skb+0x75f/0xc10 Add synchronize_net() before the kfree calls in out_hashtable, which covers all error paths from both gtp_encap_enable() and gtp_create_sockets().", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90086", "url": "https://ubuntu.com/security/CVE-2026-90086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: honor XDP_TX_METADATA in zero-copy path The zero-copy path reads TX metadata whenever the UMEM has metadata space, even if the descriptor does not set XDP_TX_METADATA. Pass descriptor options through the metadata helpers and ignore metadata unless the option is set. This does not fix the existing per-WQE metadata handling for mlx5 MPWQEs. Only the descriptor that starts a session passes through xsk_tx_metadata_request() and configures offload state shared by the batch. Metadata on descriptors joining an open session is therefore not validated and does not configure its requested offloads. In addition, a non-NULL metadata pointer from such a descriptor is treated as a timestamp completion request even when XDP_TXMD_FLAGS_TIMESTAMP is not set, so its metadata union can be overwritten with an unrequested timestamp. Fixing mixed metadata states within one MPWQE requires a separate change.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90088", "url": "https://ubuntu.com/security/CVE-2026-90088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90089", "url": "https://ubuntu.com/security/CVE-2026-90089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Validate the FW dump header length nxp_process_fw_dump() pulls the ACL header off the frame and then reads seq_num and buf_len from a struct nxp_fw_dump_hdr placed at skb->data, without checking that the ACL payload is long enough to contain it. h4_recv_buf() collects HCI_ACL_HDR_SIZE bytes of header followed by the number of payload bytes named in that header, so skb->len is 4 + dlen with dlen supplied by the controller and possibly smaller than the 8 byte dump header, or zero. A short frame with connection handle 0xfff therefore reads both fields from beyond the received data. Beyond the read itself, buf_len is what terminates a dump: a value of zero makes the driver call hci_devcd_complete() and reset the controller, so a truncated frame can end a dump early. Use skb_pull_data() to validate and pull the FW dump header before accessing its fields. Warn and reject the chunk if the header is truncated.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90090", "url": "https://ubuntu.com/security/CVE-2026-90090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size of 256 bytes, but hands the host controller the SKB buffer as is: \terr = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data, \t\t\t round_up(skb->len, MTK_SDIO_BLOCK_SIZE)); Only skb->len bytes hold packet data, so the controller reads up to 255 bytes of uninitialised memory and sends it to the device over the SDIO bus. Depending on how much tailroom slack the SKB allocation happens to carry, that read can also extend past the end of the buffer. Compute the padded length up front, ensure the SKB has tailroom for it, and zero-fill the padding with skb_put_zero(). skb->len then covers the padding, so sdio_writesb() no longer needs to round up. byte_tx keeps counting the header and the payload only, and the error path restores the SKB so that the caller can requeue it. Writing behind skb->tail is only safe because the driver owns the buffer, which \"Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX\" ensures.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90091", "url": "https://ubuntu.com/security/CVE-2026-90091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan For L2CAP sockets without owning sk->sk_socket, reading l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() -> l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks, but access in l2cap_sock_cleanup_listen() has unsafe lockless read. [Task 1] [Task 2 (hdev->workqueue)] l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref) Task 1 may observe NULL which causes null-ptr-deref. Fix the race by taking lock_sock() in l2cap_sock_kill() to synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL. Clarify code comments vs. locking.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90092", "url": "https://ubuntu.com/security/CVE-2026-90092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN New sk should not be added to parent socket accept queue after last l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and state set to BT_CLOSED, as that can result to UAF on dereferencing the dangling parent reference. l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown, due to chan->state accessed without consistent locking: [Task 1] [Task 2] l2cap_sock_release(parent) l2cap_connect l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm l2cap_chan_lock(pchan) l2cap_chan_close l2cap_sock_teardown_cb pchan->state = BT_CLOSED l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan) l2cap_new_connection l2cap_sock_new_connection_cb l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan) l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */ Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in l2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes where missing, to avoid data races. Although the data races on pchan->state should be fixed too, this defensive sk_state check probably makes sense in any case.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90094", "url": "https://ubuntu.com/security/CVE-2026-90094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: process: Fix context switching MTE store-only tag check SCTLR_EL1.TCSO0 is set when user opt-in for MTE store-only tag check mode. However, it is not part of SCTLR_USER_MASK which imply that on context switch we never clear SCTLR_EL1.TCSO0, so we are leaking that setting into another task. Fix that by including SCTLR_EL1_TCSO0_MASK into SCTLR_USER_MASK", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90097", "url": "https://ubuntu.com/security/CVE-2026-90097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition The VMBus module initialization function, hv_acpi_init(), currently does nothing when running in the root partition and root is not nested in another VM. But the initialization function reports success, so the VMBus module is indeed loaded. VMBus functionality is not actually needed, but the VMBus module must be loaded so that hv_vmbus_exists() can answer correctly. Furthermore, the mshv_root dependency on the VMBus module is needed as described in the commit message for 840b740a35bf (\"mshv: Add conditional VMBus dependency\"). Loading the VMBus module without actually initializing it causes failures if the module should later be unloaded. The module unload code tries to clean up things that were never initialized, resulting in memory faults and a panic. Fix this by having VMBus module exit function perform the same check for non-nested root partition, and do nothing in such a case, just like hv_acpi_init(). In the long run, the code that manages the Hyper-V provided SynIC should be refactored to better coordinate the requirements of root partition scenarios and normal VM scenarios, and to hopefully remove the hv_vmbus_exists() dependnecy between mshv_root and VMBus modules. Preventing the current unload failure scenario is an expediency until such a refactoring is done.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90100", "url": "https://ubuntu.com/security/CVE-2026-90100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: netc: fix period truncation and potential divide-by-zero in PEROUT The max_period bound in net_timer_enable_perout() was computed as: max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period; which exceeds U32_MAX when integral_period > 0 (e.g. 0x100000002 for the default 333333333 Hz clock). A period_ns that passes this check but exceeds U32_MAX is then silently truncated when stored into the u32 struct netc_pp::period field. A truncated value of zero can reach netc_timer_set_perout_alarm(), where the local u32 period variable would also be 0, causing a divide-by-zero in roundup_u64(delta, period) whenever the stime < min_time branch is taken (which always happens for a start time of {0, 0}). Additionally, netc_timer_enable_periodic_pulse() and netc_timer_enable_fiper() both compute: fiper = pp->period - integral_period; A zero pp->period results in an unsigned wraparound to 0xFFFFFFFD, mis-programming the FIPER hardware register. Fix all three issues by capping max_period at NETC_TMR_DEFAULT_FIPER (0xFFFFFFFF). This ensures that any period_ns passing the range check fits in a u32 without truncation, so the stored value is always valid and non-zero. The accepted range is reduced by integral_period ns (typically only a few nanoseconds), which is negligible in practice.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90101", "url": "https://ubuntu.com/security/CVE-2026-90101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix call to hardware monitoring event handler The first parameter of hwmon_notify_event() is supposed to be the hardware monitoring device. The bnxt driver calls it with the platform device as first parameter instead. This API break results in undefined behavior and may result in a crash. Pass the hardware monitoring device as parameter instead to fix the problem.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90102", "url": "https://ubuntu.com/security/CVE-2026-90102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: key the data server cache on the NFS version nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath address set alone, and struct nfs4_pnfs_ds records no version. That suffices for the files layout driver, which always connects with version 4, but flexfiles takes its version tuple from GETDEVICEINFO per device, and one address can legitimately serve both NFSv3 and NFSv4. Two deviceids on one address with different ds_versions[0].version therefore share a single nfs4_pnfs_ds, and whichever mirror connects first pins ds_clp to its own version. The other one is handed that client anyway, so it selects rpc_call_ops for a version the connection does not speak, and the mismatched sequence-slot handling dereferences NULL. Add the version to the cache key so the two cannot alias, giving each version its own nfs4_pnfs_ds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90103", "url": "https://ubuntu.com/security/CVE-2026-90103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix LAYOUTSTATS send buffer exhaustion encode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that. ff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4, an nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server whose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encode_layoutstats() additionally writes the deviceid4 and the layoutupdate4 lou_type word, neither of which the macro accounts for. The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdr_reserve_space() returns NULL once that happens, and the two ff_layout_encode_io_latency() calls run with dss_info->mirror->lock held, so a NULL return there leaves the lock permanently held. Raise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the reservation.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90107", "url": "https://ubuntu.com/security/CVE-2026-90107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: free pending qentry in smc_llc_flow_stop() before memset smc_llc_flow_stop() resets a flow struct with a blind memset: \tspin_lock_bh(&lgr->llc_flow_lock); \tmemset(flow, 0, sizeof(*flow)); \tflow->type = SMC_LLC_FLOW_NONE; \tspin_unlock_bh(&lgr->llc_flow_lock); If flow->qentry is non-NULL at this point the pointer is overwritten without the allocation being freed, leaking one kmalloc object. A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set flow->qentry after the legitimate message has been consumed by the waiter via smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that window the duplicate is stashed into flow->qentry, and then lost when smc_llc_flow_stop() zeros the struct. Call smc_llc_flow_qentry_del() inside the lock before the memset. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal case where no entry is pending is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90108", "url": "https://ubuntu.com/security/CVE-2026-90108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: free stashed qentry before overwrite in REQ_ADD_LINK to ADD_LINK transition When smc_llc_event_handler() transitions the local LLC flow from SMC_LLC_FLOW_REQ_ADD_LINK to SMC_LLC_FLOW_ADD_LINK on arrival of an ADD_LINK request, it calls smc_llc_flow_qentry_set() unconditionally: \tif (lgr->llc_flow_lcl.type == SMC_LLC_FLOW_REQ_ADD_LINK) { \t\tlgr->llc_flow_lcl.type = SMC_LLC_FLOW_ADD_LINK; \t\tsmc_llc_flow_qentry_set(&lgr->llc_flow_lcl, qentry); \t\t... \t} A CONFIRM_LINK or ADD_LINK_CONT arriving while flow->type is SMC_LLC_FLOW_REQ_ADD_LINK is stashed into flow->qentry via the SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT handler (which stores into flow->qentry for any non-NONE flow type). When the subsequent ADD_LINK arrives, the REQ_ADD_LINK branch overwrites flow->qentry with the new pointer without first freeing the stashed allocation, leaking one kmalloc object. The stashed entry has no consumer: smc_llc_wait() is only called from llc_add_link_work, which is not yet scheduled while the flow type remains REQ_ADD_LINK. No waiter is sleeping on llc_msg_waiter at this point. It is safe to unconditionally free any stashed qentry before the overwrite. Call smc_llc_flow_qentry_del() before smc_llc_flow_qentry_set() in the REQ_ADD_LINK branch. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal path where no entry is stashed is a no-op.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90109", "url": "https://ubuntu.com/security/CVE-2026-90109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue gred_enqueue(), bfifo_enqueue() and plug_enqueue() admit a packet when the current backlog plus the packet length fits within the queue limit: sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (gred default VQ) gred_backlog+qdisc_pkt_len(skb) <= q->limit (gred configured VQ) sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (bfifo) sch->qstats.backlog + skb->len <= q->limit (plug) sch->qstats.backlog and q->backlog are u32, and qdisc_pkt_len()/skb->len are unsigned int, so all sums are computed in 32 bits and wrap at 2^32. Once the true backlog exceeds 4 GiB the wrapped sum becomes small and admission keeps succeeding, so the queue grows without bound and the kernel can be driven to OOM. Promote the sums to u64 so admission stops once the true backlog exceeds the limit. The limit is u32, so the bounded queue stays below 2^32 and the stored u32 backlog never wraps. The bug can only be reproduced as root (albeit with ridiculous setup): attach a gred (or bfifo/plug) qdisc with a limit near 4 GiB, leaving the default VQ unconfigured (for gred), and drive >4 GiB of queued traffic (e.g. via a size table / stab to inflate qdisc_pkt_len, or sustained high-rate traffic). The u32 backlog+len sum wraps at 2^32, admission keeps succeeding, and the queue grows unboundedly to OOM.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90110", "url": "https://ubuntu.com/security/CVE-2026-90110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inetpeer: randomize RB-tree node comparison using SipHash The inetpeer rate limiting system stores peer entries in a Red-Black tree keyed deterministically on the remote IP address. Because tree lookups walk the RB-tree using standard lexicographical comparisons (inetpeer_addr_cmp), an off-path adversary can predict the exact topology of the tree and the sequence of nodes traversed during lookups (the gc_stack candidate list). By combining deterministic tree traversal with aggressive garbage collection (triggered when tree size exceeds inet_peer_threshold), an attacker can selectively force the eviction of targeted inet_peer nodes. When an evicted node is subsequently re-created upon receiving a new packet, its rate-limiting token bucket (rate_tokens, rate_last) is reset to full capacity. This creates a side-channel primitive allowing off-path attackers to bypass IP-keyed ICMP rate limits and infer open UDP ports (similar to SAD DNS style attacks). Mitigate this by randomizing the RB-tree node comparison logic using SipHash with a secret key (inetpeer_hash_key) initialized via net_get_random_once(). Nodes are ordered in the tree by SipHash(addr, key) rather than raw IP addresses. Because the secret key is unknown to external entities, the tree layout and lookup traversal paths are unpredictable to off-path adversaries, breaking the deterministic eviction gadget. Cache the computed 64-bit SipHash (hash) in struct inet_peer and compute the target hash (dhash) once at the beginning of inet_getpeer() to avoid recomputing SipHash at every step of the RB-tree walk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90112", "url": "https://ubuntu.com/security/CVE-2026-90112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlcnic: validate unified ROM sections before loading The unified ROM parser reads directory, product, and data-descriptor fields from the firmware file. Existing validation forms table and data ends with unchecked additions and multiplications. Malformed values can wrap before they are compared with the firmware size. The parser also dereferences typed pointers at firmware-controlled offsets. Valid descriptor extents alone are insufficient for the consumers. The loader reads a fixed-size bootloader regardless of its declared size, the version parser assumes a 17-byte tail, and a partial final firmware word is read as a full u64. A truncated image can therefore make the driver read beyond the firmware allocation during validation or loading. Replace the pointer-returning parser with bounded range helpers. Validate table entry sizes, descriptor indices, section ranges, the fixed bootloader load length, and the version tail before exposing any section. Read all file fields with unaligned little-endian accessors and assemble a partial final word from only the bytes that remain. Apply the same range checks to the legacy image before reading its fixed fields.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89790", "url": "https://ubuntu.com/security/CVE-2026-89790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid divide by zero in rt6_multipath_rebalance rt6_multipath_rebalance() calculates the total eligible nexthop weight in one pass and programs upper bounds in a second pass. Since RTM_NEWROUTE is RTNL-free, a concurrent ignore_routes_with_linkdown update can make the first pass return zero while the second sees an eligible nexthop, causing rt6_upper_bound_set() to divide by zero. UBSAN: division-overflow in net/ipv6/route.c:4845:17 Oops: divide error: 0000 [#1] SMP KASAN NOPTI rt6_upper_bound_set() net/ipv6/route.c:4845 rt6_multipath_rebalance() fib6_add_rt2node() ip6_route_multipath_add() inet6_rtm_newroute() Skip upper-bound calculation when the first pass reports a zero total. This respects the lock-free performance considerations here and solves insecure scenarios.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90113", "url": "https://ubuntu.com/security/CVE-2026-90113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: update queue NAPI association on queue reset In netdevsim, receive queues (struct nsim_rq) embed their own struct napi_struct. When queue reset is performed (e.g. via queue_reset debugfs), nsim_queue_start() swaps in a newly allocated struct nsim_rq, and nsim_queue_mem_free() later deletes and frees the old one. However, nsim_queue_start() failed to update the queue-to-NAPI mapping via netif_queue_set_napi(). As a result, dev->_rx[idx].napi continued to point to the old NAPI struct. After the old queue was freed, a subsequent queue dump via Netlink (NETDEV_CMD_QUEUE_GET) triggered a KASAN slab-use-after-free read in nla_put_napi_id() when accessing rxq->napi->napi_id. Fix this by calling netif_queue_set_napi() in nsim_queue_start() to associate the new NAPI with the RX queue, and clear the association with netif_queue_set_napi(..., NULL) in nsim_del_napi() during teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90114", "url": "https://ubuntu.com/security/CVE-2026-90114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: Reject descending VLAN tunnel ranges A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta. The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable. Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90115", "url": "https://ubuntu.com/security/CVE-2026-90115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: fix NULL pointer dereference in __xsk_rcv() In the __xsk_rcv() multi-buffer path, xsk_buff_alloc() is called in a loop without checking its return value. xsk_buff_can_alloc() only counts fill queue entries without validating their addresses, so it can succeed while xsk_buff_alloc() rejects all remaining entries and returns NULL. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:__xsk_rcv+0x426/0xc20 (net/xdp/xsk.c:350) Call Trace: xsk_generic_rcv+0x26d/0x5f0 xdp_do_generic_redirect+0x3c5/0xcf0 do_xdp_generic+0x92f/0xe70 __netif_receive_skb_core.constprop.0+0xf7e/0x2b30 Fix this with a two-stage transaction. First allocate and stage all buffers required for the packet, recycling all staged buffers with xsk_buff_free() if any allocation fails. Only after this stage succeeds, copy the data, reserve the RX descriptors, and release the buffers in an error-free loop.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90116", "url": "https://ubuntu.com/security/CVE-2026-90116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mtpav: shut down output timer before card teardown snd_mtpav_output_timer() rearms chip->timer while holding chip->spinlock and accesses the card-private mtpav state. snd_mtpav_free() currently takes the same lock and calls timer_delete() when the timer is active. This only removes a pending timer; it does not wait for a callback that is already running and does not prevent the callback from rearming the timer. A callback running on another CPU can therefore continue after snd_mtpav_free() releases the lock and access the card-private state while the card is being torn down. It can also rearm the timer after timer_delete() has returned. Call timer_shutdown_sync() without holding chip->spinlock. This waits for any running callback to finish and prevents further rearming before the card-private mtpav state is released.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90119", "url": "https://ubuntu.com/security/CVE-2026-90119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup snd_ice1712_probe() performs multiple initialization steps after snd_card_new(), but directly returns on failures from later steps without releasing the ALSA card, causing resource leaks when probing fails. Use snd_devm_card_new() together with scope-based cleanup via __free(snd_card_unref), and clear the card pointer after successful registration to keep it alive.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90122", "url": "https://ubuntu.com/security/CVE-2026-90122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: visconti: Make sure clk_init_data is fully initialized The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. visconti_clk_register_gate() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90124", "url": "https://ubuntu.com/security/CVE-2026-90124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/renesas-rzg2l: Fix loss of interrupt rzg2l_clear_irq_int() and rzg2l_clear_tint_int() perform a read-modify-write on the ISCR/TSCR status registers to clear the bit for the interrupt just handled. Since these registers are write-0-to-clear per bit, this is racy: If another interrupt's status bit gets set between the read and the write, that bit is written back as 0 by the software-constructed value, clearing an interrupt that hasn't been serviced yet and losing it. This can be reproduced by triggering multiple interrupts at once, e.g.: gpioset -c gpiochip0 355=0 353=0 328=0 352=0 Fix this by writing back only the bit being cleared, with all other bits set to 1, instead of read-modify-writing the whole register. Since 1-bits are left unchanged by hardware, concurrently-set status bits for other interrupts are preserved.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90125", "url": "https://ubuntu.com/security/CVE-2026-90125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix request buffer leak in smb2_new_read_req() smb2_new_read_req() allocates the request buffer with smb2_plain_req_init() but only publishes it to the caller with *buf = req at the very end of the function. Two error returns sit in between: \trc = smb2_plain_req_init(SMB2_READ, io_parms->tcon, server, \t\t\t\t (void **) &req, total_len); \tif (rc) \t\treturn rc; \tif (server == NULL) \t\treturn -ECONNABORTED; \t[...] \t\trdata->mr = smbd_register_mr(server->smbd_conn, \t\t\t\t\t &rdata->subreq.io_iter, \t\t\t\t\t true, need_invalidate); \t\tif (!rdata->mr) \t\t\treturn -EAGAIN; On either of them the buffer is neither released nor handed back, so it is leaked. The caller cannot clean up after it: smb2_async_readv() does 'goto out' on a non-zero return, which skips the cifs_small_buf_release(buf) at async_readv_out, and buf has not been assigned at that point in any case. The write path has never had this problem. smb2_async_writev() registers the memory region inline and jumps to its release label instead of returning: \twdata->mr = smbd_register_mr(...); \tif (!wdata->mr) { \t\trc = -EAGAIN; \t\tgoto async_writev_out; \t} Commit b7972092199f (\"cifs: smbd: Retry on memory registration failure\") changed both sides from -ENOBUFS to -EAGAIN in a single patch, which puts the two shapes next to each other. Only the -EAGAIN return is reachable in practice, because smb2_plain_req_init() calls smb2_reconnect() first and that already fails with -EIO when server is NULL, before anything is allocated. Both returns are given the same treatment here rather than leaving one of them correct only by accident. Because -EAGAIN is a replayable error, the failure also reaches the retry block at the end of smb2_async_readv(), which marks the subrequest NETFS_SREQ_NEED_RETRY, so a failing registration can be retried rather than ending the I/O, and every attempt that reaches it leaks another buffer. smb2_should_replay() short-circuits on tcon->retry, so on a hard mount the attempt count is not bounded by the retrans setting. Only the asynchronous read path is affected. The synchronous SMB2_read() caller passes rdata == NULL and the memory registration block is guarded on rdata. The memory registration failure path was pointed out by the Sashiko AI reviewer while it was reviewing an unrelated patch to smb2_async_readv().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90126", "url": "https://ubuntu.com/security/CVE-2026-90126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf8563: fix clock provider leak on unbind pcf8563_clkout_register_clk() registers the CLKOUT clock provider with of_clk_add_provider(), but nothing ever unwinds it: there is no of_clk_del_provider() call and the driver has no remove callback. Each of_clk_add_provider() allocates a struct of_clk_provider, takes a reference on the OF node and adds an entry to the global of_clk_providers list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an of_node reference. The clock itself is already device-managed (devm_clk_register()); only the provider registration was not. Use devm_of_clk_add_hw_provider() so the provider is removed automatically on unbind. Tie it to the parent i2c device, whose OF node carries the #clock-cells and clock-output-names properties (the RTC class device has no OF node of its own).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90127", "url": "https://ubuntu.com/security/CVE-2026-90127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio: rtc: time out alarm requests RTC class operations run with rtc_device.ops_lock held. The virtio RTC alarm requests currently wait without a timeout for the device to return their requestq buffers. On surprise removal, virtio-pci marks the virtqueues broken before unregistering the virtio device. If an alarm request is waiting when the device stops responding, viortc_remove() blocks in viortc_class_stop() while trying to acquire ops_lock. The request cannot complete and device removal hangs until the waiting task is signalled. Use the same 60-second timeout as clock read requests for alarm reads, alarm programming, and alarm interrupt enable requests. The existing message reference counting keeps a timed-out request alive until a late response or device teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90128", "url": "https://ubuntu.com/security/CVE-2026-90128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: fix wrong list iterated in add_direct_chain error path In add_direct_chain(), newly allocated direct MR entries are added to the local list 'tmp', which is spliced into mr->head only on success. On the error path, the cleanup loop was incorrectly iterating over mr->head instead of tmp. Fix by iterating over 'tmp' in the err_alloc cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90129", "url": "https://ubuntu.com/security/CVE-2026-90129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_balloon: quiesce balloon work before device shutdown Commit 8bd2fa086a04 (\"virtio: break and reset virtio devices on device_shutdown()\") added a generic virtio bus .shutdown handler that breaks and resets every virtio device during device_shutdown(), i.e. on reboot and kexec. virtio_balloon provides no .shutdown of its own, so that generic path runs while the balloon's asynchronous work is still armed. Once the device has been broken, virtqueue_add_inbuf() in virtballoon_free_page_report() returns -EIO and trips its WARN_ON_ONCE(). On a kernel booted with panic_on_warn that turns an ordinary reboot, for example a kexec based upgrade, into a fatal panic in the middle of device_shutdown(), so the machine never reaches the new kernel. Relaxing that single WARN_ON_ONCE() would only hide the symptom: the inflate/deflate and OOM paths do not warn, they call wait_event(vb->acked, ...) and would instead block forever on a broken queue that can no longer complete. The device has to be quiesced, not just kept quiet. Add a .shutdown handler that quiesces the balloon via the shared virtballoon_quiesce() helper while the device is still alive, and only then breaks and resets it via virtio_device_shutdown(). Unlike virtballoon_remove() the balloon workqueue is not destroyed, as shutdown does not free the device and cancel_work_sync() together with stop_update already prevent any further work from being queued.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90130", "url": "https://ubuntu.com/security/CVE-2026-90130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa_sim: fix cleanup after worker creation failure vdpasim_create() leaves vdpasim->worker as an ERR_PTR when kthread_run_worker() fails. The error path then drops the device reference, which releases the partially initialized simulator. vdpasim_free() unconditionally passes the worker pointer to kthread_destroy_worker(), so the ERR_PTR is dereferenced and can trigger a general protection fault. Store the worker error, clear the pointer, and only clean up the worker when it was successfully initialized. Also make the release path tolerate partially initialized objects by guarding virtqueue and IOTLB cleanup, since the same release path can be reached from other initialization failures. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90135", "url": "https://ubuntu.com/security/CVE-2026-90135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add missing ref_tracker_dir_exit() to alloc_netdev_mqs() sashiko is reporting that trying to read /sys/kernel/debug/ref_tracker/* causes use-afer-free crash when either alloc_percpu() or dev_addr_init() in alloc_netdev_mqs() failed, for commit 4d92b95ff2f9 (\"net: add net device refcount tracker infrastructure\") added ref_tracker_dir_exit() to only free_netdev() path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90136", "url": "https://ubuntu.com/security/CVE-2026-90136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/hsmp: Reject negative power cap writes in hwmon hsmp_hwmon_write() takes the user-supplied hwmon value as a signed long and assigns \"val / MICROWATT_PER_MILLIWATT\" to msg.args[0], which is a __u32. MICROWATT_PER_MILLIWATT is an unsigned long, so a negative write to power1_cap (e.g. \"echo -1 > power1_cap\") is first converted to a huge unsigned value by the division and then stored into the u32 argument. As a result a nonsensical, multi-gigawatt socket power limit is sent to the SMU via HSMP_SET_SOCKET_POWER_LIMIT instead of the write being rejected. Reject negative values with -EINVAL before the conversion. Tested with HSMP enabled: CAP=$(dirname $(grep -l amd_hsmp_hwmon \\ /sys/class/hwmon/hwmon*/name | head -1))/power1_cap # negative write echo -1000000 > $CAP ; echo \"ret=$?\" # valid positive write must still work echo 400000000 > $CAP ; echo \"ret=$?\" Before: # echo -1000000 > $CAP ; echo \"ret=$?\" ret=0 <- accepted; bogus limit sent to SMU # echo 400000000 > $CAP ; echo \"ret=$?\" ret=0 After: # echo -1000000 > $CAP ; echo \"ret=$?\" bash: echo: write error: Invalid argument ret=1 <- rejected with -EINVAL # echo 400000000 > $CAP ; echo \"ret=$?\" ret=0 <- valid write still works", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90137", "url": "https://ubuntu.com/security/CVE-2026-90137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: fix password encoding bounds check The password PSWD_ENCODINGS parser reads password_obj[elem + pos_values] while copying the supported password encodings from the ACPI package. The outer loop only guarantees that elem is within password_obj_count. The encoding count is bounded by MAX_ENCODINGS_SIZE, but that does not guarantee that the ACPI package contains enough entries for all elem + pos_values accesses. A malformed package can therefore declare a non-zero encoding count without providing enough string objects, causing the parser to read past the ACPI package array and pass an out-of-bounds string pointer and length to hp_convert_hexstr_to_str(). Add the same computed-index bounds check used by the other offset-based package parsing loops before reading password_obj[elem + pos_values].", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90138", "url": "https://ubuntu.com/security/CVE-2026-90138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: don't check the listener's sk_err in vsock_accept() Syzbot reported an issue which can be reproduced with these steps: \tr0 = socket(AF_VSOCK, SOCK_STREAM, 0) \tbind(r0, {VMADDR_CID_ANY, PORT}) \tconnect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (self-connect) \tlisten(r0, backlog) -> 0 \tr1 = socket(AF_VSOCK, SOCK_STREAM, 0) \tconnect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0 \taccept(r0) -> -1, EPROTO (stale sk_err) Basically, it creates a socket (r0) and triggers a self-connect after binding it. This self-connect fails with EPROTO because it loops back to r0 while the socket is still in the TCP_SYN_SENT state, causing it to be incorrectly dispatched to the connecting-client path. The unexpected packet type encountered there sets sk_err to EPROTO. After that, it invokes a listen() call on the same socket. This listen() call succeeds because the kernel's listening path never inspects or clears sk_err. Then, a new socket (r1) is created as a normal client and connects to r0. However, vsock_accept() rejects this incoming connection because the listener's sk_err still holds the EPROTO error from the earlier failed self-connect. This rejection causes the child socket created for r1's connection to never be freed on virtio or hyperv transports; only the VMCI transport implements pending_work to revisit and clean up a rejected socket. For a non-blocking connect(), vsock_connect() may return -EINPROGRESS immediately, and vsock_connect_timeout() can later set sk->sk_err asynchronously. Since no vsock transport ever sets sk_err on a socket while it is in TCP_LISTEN state, checking it in vsock_accept() serves no purpose and only carries forward errors left behind by earlier, unrelated connection attempts on the same socket. Remove the checks so accept() no longer rejects valid incoming connections because of a stale error, which also avoids the resource leak described above.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90139", "url": "https://ubuntu.com/security/CVE-2026-90139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: check for NULL root inode in fuse_fill_super_submount fuse_iget() can return NULL when its inode allocation fails, but fuse_fill_super_submount() passed the result straight to get_fuse_inode() and decremented fi->nlookup without checking it: root = fuse_iget(sb, parent_fi->nodeid, ...); fi = get_fuse_inode(root); fi->nlookup--; Inside fuse_iget() the inode allocation can fail and return NULL. The submount root takes the iget5_locked() path, whose alloc_inode() can fail under memory pressure (the auto-submount branch can fail the same way in new_inode() or fuse_alloc_submount_lookup()): inode = iget5_locked(sb, nodeid, fuse_inode_eq, fuse_inode_set, &nodeid); if (!inode) return NULL; A NULL root makes get_fuse_inode() a container_of() on NULL and the nlookup decrement a write to a bogus address, oopsing the mount. With CONFIG_KASAN the following null pointer dereference is reported when the root inode allocation of an auto-submount fails (e.g. under memory pressure): ================================================================== BUG: KASAN: null-ptr-deref in fuse_get_tree_submount+0x656/0x8b0 Read of size 8 at addr 00000000000002b0 by task ls/942 CPU: 0 PID: 942 Comm: ls Tainted: G W 6.6 #15 Call Trace: fuse_get_tree_submount+0x656/0x8b0 vfs_get_tree+0x48/0x140 fc_mount+0x13/0x50 fuse_dentry_automount+0x7a/0xb0 __traverse_mounts+0xca/0x330 step_into+0x339/0xac0 path_lookupat+0xc5/0x2f0 filename_lookup+0x163/0x2a0 vfs_statx+0xd5/0x200 do_statx+0x83/0xd0 __x64_sys_statx+0xa0/0xc0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ================================================================== Return -ENOMEM instead; the caller tears down the partially built superblock on error, matching the other error returns in this function.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89779", "url": "https://ubuntu.com/security/CVE-2026-89779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate ef->size covers the record's name and value When an EA record has a non-zero ef->size, ntfs_read_ea() only checks that the record fits in the remaining buffer (ea_size > bytes), not that ef->size is large enough to hold the record's own name_len + 1 + elength. A crafted image can pass validation with, e.g., ef->size = 24 but elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of the undersized record, reading past the kmalloc(info->size) allocation and leaking heap memory to userspace via getxattr(): BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302) Read of size 65535 at addr ffff888100794550 by task exploit __asan_memcpy (mm/kasan/shadow.c:105) ntfs_get_ea (fs/ntfs3/xattr.c:302) ntfs_getxattr (fs/ntfs3/xattr.c:848) __vfs_getxattr (fs/xattr.c:441) vfs_getxattr (fs/xattr.c:474) do_getxattr (fs/xattr.c:800) path_getxattrat (fs/xattr.c:868) do_syscall_64 (arch/x86/entry/syscall_64.c:94) The buggy address is located 80 bytes inside of allocated 84-byte region in cache kmalloc-96 Compute the size the record needs and require ef->size to cover it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89781", "url": "https://ubuntu.com/security/CVE-2026-89781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read in read_log_rec_buf() read_log_rec_buf() copies a log record into a caller buffer starting at \tu32 off = lsn_to_page_off(log, lsn) + log->record_header_len; log->record_header_len (and log->data_off, used for the following pages) comes verbatim from the on-disk restart area and is only checked for 8-byte alignment in is_rst_area_valid(), so off can exceed log->page_size. \"tail = log->page_size - off\" then underflows and memcpy() reads past the page_size-sized buffer returned by read_log_page(), spilling adjacent slab memory into the replay buffer. This is reachable by mounting a crafted NTFS image: BUG: KASAN: slab-out-of-bounds in read_log_rec_buf+0x216/0x580 Read of size 64 at addr ffff88800a877ff8 by task exploit/127 read_log_rec_buf fs/ntfs3/fslog.c:2299 log_replay fs/ntfs3/fslog.c:4216 ntfs_loadlog_and_replay fs/ntfs3/fsntfs.c:324 ntfs_fill_super fs/ntfs3/super.c:1392 get_tree_bdev_flags fs/super.c:1694 __x64_sys_mount fs/namespace.c:4360 The buggy address is located 4088 bytes to the right of the 4096-byte region [ffff88800a876000, ffff88800a877000) Reject an in-page offset outside the current page before the copy. [almaz.alexandrovich@paragon-software.com: replaced the >= sign with >]", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90140", "url": "https://ubuntu.com/security/CVE-2026-90140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cuse: wait for pending RCU callbacks on module exit Since commit 053fc4f755ad (\"fuse: fix UAF in rcu pathwalks\"), fuse_conn_put() frees the fuse_conn through call_rcu() rather than synchronously. For cuse, fc->release is cuse_fc_release(), which lives in the cuse module. If the module is removed before the RCU grace period ends, the callback jumps into freed module memory: userspace / module unload | RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ close(/dev/cuse) | cuse_channel_release() | fuse_dev_release() | fuse_conn_put(fch->conn) | call_rcu(delayed_release) ------+---> callback queued | rmmod cuse | cuse_exit() | cuse_channel_destroy() | ... | return | | | | rcu_do_batch() | delayed_release() | fc->release() | -> cuse_fc_release() | ^^^ freed text! The freed module text is unmapped by vfree(), so the jump into the stale callback triggers a page-fault Oops. If the virtual address is subsequently reused, the callback could execute unrelated code (undefined behaviour). Fix this by calling rcu_barrier() in cuse_exit() so that any pending fuse_conn release callback completes before the module is removed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89776", "url": "https://ubuntu.com/security/CVE-2026-89776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: vnifilter: enforce exact length of GROUP/GROUP6 attributes The VXLAN VNI filter entry policy declares the GROUP/GROUP6 address attributes as NLA_BINARY with only a maximum length, so validate_nla() accepts a payload shorter than the address. The GROUP consumer reads it with nla_get_in_addr(), an unconditional 4-byte load, so a short attribute over-reads up to 3 bytes of uninitialised slab data, which are stored into remote_ip and echoed back via RTM_GETTUNNEL, disclosing kernel memory. Switch both entries to NLA_POLICY_EXACT_LEN() so the validator rejects any GROUP/GROUP6 that is not exactly 4 / 16 bytes; a valid address is always sent at full width.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90141", "url": "https://ubuntu.com/security/CVE-2026-90141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix integer overflow in ftp helper port/address parsing ip_vs_ftp_get_addrport() accumulates decimal digits into a __u16 (hport) and into unsigned char (p[]) without checking for overflow. A crafted FTP PASV/EPSV response with an over-long port or address octet wraps the value, so the helper configures the data connection with a truncated port/address. The netfilter conntrack FTP helper had the same defect, fixed in commit 2b413fc689ba (\"netfilter: nf_conntrack_ftp: avoid u16 overflows\"). Apply the equivalent fix here: widen the port accumulator to u32 and reject values above 65535, and reject address octets above 255.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90143", "url": "https://ubuntu.com/security/CVE-2026-90143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: kcm: Hold RCU read lock while running BPF parser kcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which prevents CPU migration, but does not establish an RCU read-side critical section. Consequently, BPF map operations can trigger WARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser program. Hold the RCU read lock while running the program.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90145", "url": "https://ubuntu.com/security/CVE-2026-90145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hinic3: Fix skb linearization mismatch and drop skb when skb_checksum_help() failed Previously, hinic3_send_one_skb() cached the skb fragment count before calling hinic3_tx_offload(). If hinic3_tx_csum() falls back to skb_checksum_help() for unsupported tunnel packets, the skb may be linearized. Continuing to build the TX descriptor with the stale fragment count leads to a descriptor mismatch, which can trigger out-of-bounds DMA reads or IOMMU faults. Furthermore, the old code ignored the return value of skb_checksum_help(), transmitting corrupted packets with incomplete checksums upon failure. Fix this by: 1. Moving the hinic3_tx_offload() call before calculating 'num_sge' to ensure the correct fragment count is used if the SKB is linearized. 2. Propagating skb_checksum_help() errors and returning HINIC3_TX_OFFLOAD_INVALID to properly drop the skb.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90146", "url": "https://ubuntu.com/security/CVE-2026-90146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, xdp: move offload check into dev_xdp_install() bpf_xdp_link_update() calls dev_xdp_install() directly and skips dev_xdp_attach(), so the checks in dev_xdp_attach() do not run. A user can make an XDP link with a normal program and then swap in an offloaded or device-bound program with BPF_LINK_UPDATE, which puts it on the software path. dev_xdp_install() is the one place all three paths go through: \"ip link set xdp\" and BPF_LINK_CREATE reach it via dev_xdp_attach(), and BPF_LINK_UPDATE calls it directly. So move the program checks (offloaded, bound to another device, device-bound in generic mode, native vs generic, DEVMAP and CPUMAP) there, and keep only the netlink-flag check (XDP_FLAGS_UPDATE_IF_NOEXIST) in dev_xdp_attach().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90147", "url": "https://ubuntu.com/security/CVE-2026-90147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: devres: fix cleanup in devm_clk_get_optional_enabled_with_rate() devm_clk_get_optional_enabled_with_rate() registers its cleanup action before setting the clock rate. If setting the rate fails, it attempts to disable and unprepare a clock that was never enabled. This issue was spotted while reviewing \"rust: clk: add devres-managed clks\" [1]. Register the cleanup action only after successfully preparing and enabling the clock. [1]: https://lore.kernel.org/rust-for-linux/20260706-clk-type-state-v5-3-67c5f326a16c@collabora.com", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90148", "url": "https://ubuntu.com/security/CVE-2026-90148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Fix incorrect argument passed to nfs4_delete_lease() in nfs4_add_lease() When nfs4_add_lease() races with a delegation return, it calls nfs4_delete_lease() to clean up. Previously, it passed priv, which can legitimately be NULL. Passing a NULL priv eventually leads to a NULL pointer dereference in generic_setlease().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90149", "url": "https://ubuntu.com/security/CVE-2026-90149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/flexfiles: fix NULL dereference for NFSv4.0 data servers flexfiles accepts NFSv4.0 data servers, but two NFSv4 code paths assume the data server client has a session. Unlike NFSv4.1+, an NFSv4.0 client has no session (clp->cl_session is NULL; it uses clp->cl_slot_tbl), so I/O to a v4.0 flexfiles DS oopses: - nfs4_init_ds_session() dereferences clp->cl_session->session_state while seeding the DS lease. It also only seeds cl_lease_time when NFS4_SESSION_INITING is set; without a session that never happens, so cl_lease_time stays 0 and nfs4_renew_state() busy-loops, requeuing every 5 seconds. Seed the lease whenever there is no session and return before touching session state. - ff_layout_async_handle_error_v4() dereferences clp->cl_session->fc_slot_table on every DS I/O error. Fall back to the v4.0 transport slot table (clp->cl_slot_tbl) when there is no session.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90150", "url": "https://ubuntu.com/security/CVE-2026-90150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pnfs/blocklayout: Fix device leaks on parse failure bl_parse_concat() and bl_parse_stripe() allocate a child device array and then parse each child in turn. If parsing a child fails, the failed child is not counted in nr_children and the parent may be left with a children array that bl_free_device() will not release when nr_children is zero. Release the failed child and the already parsed children before returning the error. Also make bl_free_device() release the child array whenever the children pointer is set, so that partially initialised concat or stripe devices are cleaned up correctly. bl_parse_scsi() can also fail after assigning d->bdev_file and dropping the file reference. Clear the pointer after fput() so that an outer cleanup path does not put it again.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90151", "url": "https://ubuntu.com/security/CVE-2026-90151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: remove callback IDR entry on client allocation failure nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfs_client directly with nfs_free_client(). That bypasses nfs_put_client(), which is where the callback IDR entry is removed during normal teardown. A failed allocation can therefore leave cb_ident_idr pointing at a freed nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the stale pointer and take a reference to it. Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client. This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90152", "url": "https://ubuntu.com/security/CVE-2026-90152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix session leak in ksmbd_session_register() See the procedure below: smb2_sess_setup ksmbd_smb2_session_create __session_create atomic_set(&sess->refcnt, 2) hash_add(sessions_table, &sess->hlist, sess->id) ksmbd_session_register xa_store(&conn->sessions, sess->id, sess) // fail ksmbd_user_session_put atomic_dec(&sess->refcnt) // refcnt is 1, session is not freed Remove the session from sessions_table and drop its table reference if xa_store() fails.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90153", "url": "https://ubuntu.com/security/CVE-2026-90153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound smb_check_perm_dacl() ACE walks by DACL size smb_check_perm_dacl() validates that the DACL fits inside the NT security descriptor, but then bounds its two ACE walks by the remaining NTSD length (acl_size) rather than the DACL's declared size (pdacl_size). When pdacl->size is smaller than the trailing NTSD buffer, bytes after the declared DACL boundary - still inside the stored security descriptor - are parsed as ACEs during access checks. A crafted DACL can place an access-granting ACE beyond pdacl->size, and the current code accepts it during SMB2_CREATE access validation, while parse_dacl() and smb_inherit_dacl() stop at pdacl_size. Bound both ACE walks by pdacl_size to match the DACL boundary semantics used elsewhere in the server. Validation: - semantic KUnit harness shows the post-boundary ACE is selected before the fix and rejected (EACCES) after it - linux master (7.2-rc6), x86_64", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90157", "url": "https://ubuntu.com/security/CVE-2026-90157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative optlen in cgroup getsockopt hook A cgroup getsockopt BPF program can shrink ctx->optlen after the kernel getsockopt handler has run. The kernel-buffer variant, used by TCP_ZEROCOPY_RECEIVE, only rejects values larger than the original length. If BPF writes a negative optlen, that value is accepted and propagated back to the TCP getsockopt code. It can then be passed to copy_to_sockptr() as a size_t and trigger the hardened usercopy bytes > INT_MAX warning. Reject negative ctx.optlen in __cgroup_bpf_run_filter_getsockopt_kern(), matching the lower-bound validation already present in the sockptr-based getsockopt hook.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90158", "url": "https://ubuntu.com/security/CVE-2026-90158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: m68k: nfcon: Do not call console_is_registered() in nfcon_device() Since 7c2af0f634f1 (\"tty: tty_io: use console_list_lock for list synchronization\") show_cons_active() calls the .device() method under the console_list_lock, but console_is_registered() tries to acquire console_list_lock as well, causing a deadlock. It should not be necessary to check console_is_registered() here since the function should not be called in the fist place when the console is not registered.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90159", "url": "https://ubuntu.com/security/CVE-2026-90159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disallow bpf_{g,s}etsockopt() in cgroup UNIX getname hooks _bpf_setsockopt() and _bpf_getsockopt() call sock_owned_by_me() for full sockets, so these helpers expect the socket lock to be held. BPF_CGROUP_UNIX_GETPEERNAME and BPF_CGROUP_UNIX_GETSOCKNAME run BPF programs without acquiring the socket lock. A program attached to either hook can therefore trigger the sock_owned_by_me() warning by calling bpf_setsockopt() or bpf_getsockopt(). Disallow bpf_setsockopt() and bpf_getsockopt() for CGROUP_UNIX_GETPEERNAME and CGROUP_UNIX_GETSOCKNAME.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90160", "url": "https://ubuntu.com/security/CVE-2026-90160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lwt_bpf: Restore reserved headroom after xmit program ip_finish_output2() expands an skb to LL_RESERVED_SPACE(dev) before LWT xmit. An LWT_XMIT BPF program can then modify the skb head and still return BPF_OK, so bpf_xmit() rechecks the remaining headroom before the skb continues to neighbour output. That recheck uses dst->dev->hard_header_len. This is not enough for the neighbour cached-header path: neigh_hh_output() copies the cached hardware header using the aligned hh_cache size, HH_DATA_MOD for short headers or HH_DATA_ALIGN(hh_len) otherwise. On Ethernet, hard_header_len is 14 but the cached copy needs 16 bytes. If an LWT_XMIT BPF program calls bpf_skb_change_head(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neigh_hh_output() hits its headroom warning and drops the skb. Use LL_RESERVED_SPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90161", "url": "https://ubuntu.com/security/CVE-2026-90161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix interlaced ztailpacking pclusters On-disk sizes of interlaced pclusters should be block-aligned, and ztailpacking interlaced pclusters should be invalid at all. Currently, mkfs.erofs won't generate any interlaced pcluster with ztailpacking enabled, so this doesn't affect any existing valid filesystems. However, crafted images can contain invalid interlaced ztailpacking pclusters, resulting in an out-of-bounds read from a kmap'd page and copying irrelevant kernel memory into userspace-visible page cache.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90165", "url": "https://ubuntu.com/security/CVE-2026-90165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix invalid pointer dereference in ksmbd_stop_durable_scavenger() See the procedure below: ksmbd_launch_ksmbd_durable_scavenger durable_scavenger_running = true server_conf.dh_task = kthread_run() // fail, dh_task is an ERR_PTR() server_ctrl_handle_reset ksmbd_stop_durable_scavenger kthread_stop(server_conf.dh_task) // invalid pointer", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90166", "url": "https://ubuntu.com/security/CVE-2026-90166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix null-ptr-deref in ksmbd_ipc_tree_connect_request() See the procedure below: ksmbd_tree_conn_connect ksmbd_share_config_get share->name = kstrdup() // fail if (!test_share_config_flag(share, KSMBD_SHARE_FLAG_PIPE)) // false // do not check `share->name` ksmbd_ipc_tree_connect_request strlen(share->name) // null-ptr-deref", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90169", "url": "https://ubuntu.com/security/CVE-2026-90169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: free preauth sessions on connection teardown SMB3.1.1 multichannel binding preserves the preauthentication hash in a preauth_session between the NTLM negotiate and authenticate requests. The binding NTLM negotiate allocates this object and returns STATUS_MORE_PROCESSING_REQUIRED. If the client disconnects before it sends the authenticate request, neither the authenticate nor error cleanup paths free the object. Release any remaining preauthentication sessions when tearing down the connection. Initialize the list when allocating the connection so that this cleanup is safe regardless of the negotiated dialect.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90170", "url": "https://ubuntu.com/security/CVE-2026-90170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ipc response length before dereferencing its fields ipc_validate_msg() computes the expected message size by reading length fields out of the response buffer supplied by the userspace ksmbd daemon (payload_sz, session_key_len, ngroups, ...). Those fields are read before the buffer is verified to be large enough to contain the struct they belong to, so a short response makes the read land past the end of the allocation. handle_response() sizes entry->response purely from the netlink attribute length (nla_len()) and only guards the leading handle read, so the daemon can install a response as small as the kmalloc-8 object seen below. When ipc_msg_send_request() then calls ipc_validate_msg() for a KSMBD_EVENT_RPC_REQUEST, the cast to struct ksmbd_rpc_command reads resp->payload_sz at offset 8 of an 8-byte allocation: [ 3697.841381] ================================================================== [ 3697.844099] BUG: KASAN: slab-out-of-bounds in ipc_msg_send_request+0x763/0x800 [ 3697.846604] Read of size 4 at addr ffff888105f95910 by task kworker/4:3/20682 [ 3697.849061] [ 3697.849801] CPU: 4 UID: 0 PID: 20682 Comm: kworker/4:3 Not tainted 7.2.0-rc3-next-20260717-virtme #117 PREEMPT(lazy) [ 3697.850077] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3697.850303] Workqueue: ksmbd-io handle_ksmbd_work [ 3697.850592] Call Trace: [ 3697.850794] [ 3697.850952] __dump_stack+0x21/0x60 [ 3697.851239] dump_stack_lvl+0xc2/0x100 [ 3697.851528] print_address_description+0x77/0x200 [ 3697.851816] ? ipc_msg_send_request+0x763/0x800 [ 3697.852024] print_report+0x58/0x70 [ 3697.852316] kasan_report+0x117/0x150 [ 3697.852585] ? down_write+0x146/0x1f0 [ 3697.852809] ? ipc_msg_send_request+0x763/0x800 [ 3697.853082] ipc_msg_send_request+0x763/0x800 [ 3697.853385] ? __pfx_ipc_msg_send_request+0x10/0x10 [ 3697.853604] ? kasan_unpoison+0x48/0x70 [ 3697.853936] ? __pfx___up_read+0x10/0x10 [ 3697.854221] ksmbd_rpc_ioctl+0x380/0x520 [ 3697.854542] ? __pfx_ksmbd_rpc_ioctl+0x10/0x10 [ 3697.854757] ? kasan_unpoison+0x48/0x70 [ 3697.854962] ? copy_from_kernel_nofault+0x32c/0x4e0 [ 3697.855166] ? kasan_unpoison+0x48/0x70 [ 3697.855416] fsctl_pipe_transceive+0x139/0x7a0 [ 3697.855705] ? __pfx_copy_from_kernel_nofault+0x10/0x10 [ 3697.855937] ? __pfx_fsctl_pipe_transceive+0x10/0x10 [ 3697.856388] ? __sanitizer_cov_trace_switch+0x7b/0x140 [ 3697.856620] smb2_ioctl+0x1141/0x3420 [ 3697.856994] ? __pfx_smb2_ioctl+0x10/0x10 [ 3697.857182] ? get_smb2_cmd_val+0xe3/0x1c0 [ 3697.857655] handle_ksmbd_work+0x9ad/0x15e0 [ 3697.858034] ? __pfx_handle_ksmbd_work+0x10/0x10 [ 3697.858251] ? lock_release+0xf7/0x360 [ 3697.858466] ? process_scheduled_works+0x954/0x1600 [ 3697.858698] ? process_scheduled_works+0x954/0x1600 [ 3697.858905] process_scheduled_works+0xc22/0x1600 [ 3697.859368] ? __pfx_process_scheduled_works+0x10/0x10 [ 3697.859637] ? __pfx_assign_work+0x10/0x10 [ 3697.859896] ? lock_is_held_type+0x7b/0x110 [ 3697.860146] worker_thread+0x975/0xee0 [ 3697.860524] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 3697.860830] ? __kthread_parkme+0x21e/0x260 [ 3697.861105] kthread+0x3a6/0x490 [ 3697.861423] ? __pfx_worker_thread+0x10/0x10 [ 3697.861643] ? __pfx_kthread+0x10/0x10 [ 3697.861878] ret_from_fork+0x55a/0xa20 [ 3697.862194] ? __pfx_ret_from_fork+0x10/0x10 [ 3697.862480] ? __pfx_kthread+0x10/0x10 [ 3697.862714] ret_from_fork_asm+0x1a/0x30 [ 3697.862965] [ 3697.863039] [ 3697.938882] Allocated by task 20761: [ 3697.940257] kasan_save_track+0x3e/0x80 [ 3697.941782] __kasan_kmalloc+0x72/0x90 [ 3697.943228] __kvmalloc_node_noprof+0x3e9/0x6a0 [ 3697.944948] handle_generic_event+0x59b/0x750 [ 3697.946592] genl_family_rcv_msg_doit+0x3d6/0x560 [ 3697.946977] genl_rcv_msg+0x67c/0x900 [ 3697.947224] netlink_rcv_skb+0x286/0x580 [ 3697.947488] genl_rcv+0x2d/0x80 [ 3 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90175", "url": "https://ubuntu.com/security/CVE-2026-90175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak of ksmbd_ipc_login_request_ext() returned buffer Free it unconditionally after ksmbd_alloc_user() calls. kmemleak splat: unreferenced object 0xffff888103b83540 (size 192): comm \"pool-0\", pid 16970, jiffies 4377290937 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 408ccc66): __kvmalloc_node_noprof+0x730/0x920 handle_generic_event+0xec/0x1a0 [ksmbd] genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x181/0x290 netlink_rcv_skb+0x4f/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x1e6/0x2c0 netlink_sendmsg+0x20a/0x450 ____sys_sendmsg+0x2e8/0x310 ___sys_sendmsg+0x78/0xc0 __sys_sendmsg+0x63/0xc0 do_syscall_64+0xa1/0x670 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90176", "url": "https://ubuntu.com/security/CVE-2026-90176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Do not skip lock checks for single-byte ranges check_lock_range() uses inclusive ranges. Its callers pass the end offset as start + length - 1, so start == end represents a valid single-byte range rather than an empty range. The start == end shortcut therefore skips mandatory byte-range lock checks for one-byte reads, writes, copychunk operations and one-byte truncate ranges. A conflicting lock covering that byte is not checked and the operation is allowed to proceed. Remove the shortcut. The truncate size == inode->i_size case is already handled by only calling check_lock_range() when the new size differs from the current file size.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90178", "url": "https://ubuntu.com/security/CVE-2026-90178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix core_data leak on CPUs without PTS pdata->core_data is allocated in init_temp_data() when the first core temp_data of a package is created, but it is only released from destroy_temp_data(), and only in the branch that handles the package temp_data. Package temp_data is created solely when the CPU supports X86_FEATURE_PTS. On a CPU without it, coretemp_cpu_online() never calls coretemp_add_core() with pkg_flag set, so pdata->pkg_data stays NULL. coretemp_cpu_offline() then skips the removal of the package interface, destroy_temp_data() is never called for package data, and the array is still allocated when coretemp_device_remove() frees the platform data that pointed at it. Release the array in coretemp_device_remove(). destroy_temp_data() sets pdata->core_data to NULL when it frees it, so the added kfree() is a no-op on CPUs that do have PTS. Tested on an Intel Core i5-1135G7. The driver was instrumented to log every allocation and release of pdata->core_data, and the PTS check in coretemp_cpu_online() was patched out to emulate a CPU without package thermal support. Without this change the array was allocated and never released, and coretemp_device_remove() still saw a non-NULL pointer. With it the array is released and the pointer accounting balances. On an unmodified build the release still happens via the package temp_data and the added kfree() sees NULL, with no slab warnings over repeated module load and unload cycles.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90179", "url": "https://ubuntu.com/security/CVE-2026-90179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix deadlock in complain-mode change_hat The use of change_hat when in complain mode can cause a deadlock when the hat doesn't exist and a new learning profile is created for the missing profile. This is because change_hat() has taken the lock to search the hat list and creating the new learning profile needs to take the lock to add it to the list. From the bug report: Originally found in 7.0.0 in LTS ubuntu 26.04 with pam_apparmor + su in complain mode set to change hats. Then verified in newest available vanilla kernel I've compiled to see if still present: 7.2-rc7 vanilla -> affected checked also some other kernels: 6.18.44 vanilla -> affected 6.12.95 with debian patches -> unaffected On systems without bug (for example 6.12.95 debian) it just prints: aa_change_hat rc=0 On systems with bug, the executable always hangs, prints nothing and becomes unkillable. (And once stuck this way, it will cause any further hat changes to also cause the changing process to get stuck) Then in syslog you can find hint about cause: kernel: INFO: task hat:3409 blocked for more than 483 seconds. kernel: Not tainted 7.2.0-rc7 #1 kernel: \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. kernel: task:hat state:D stack:0 pid:3409 tgid:3409 ppid:2605 task_flags:0x400000 flags:0x00080800 kernel: Call Trace: kernel: kernel: __schedule+0x48f/0xfe0 kernel: schedule+0x27/0xa0 kernel: schedule_preempt_disabled+0x15/0x30 kernel: __mutex_lock.constprop.0+0x569/0xa10 kernel: aa_new_learning_profile+0x15f/0x210 kernel: build_change_hat+0x19f/0x3b0 kernel: change_hat.isra.0+0x5dd/0xd60 kernel: aa_change_hat+0x2f3/0x710 kernel: aa_setprocattr_changehat+0x121/0x1f0 kernel: do_setattr+0x28c/0x340 kernel: apparmor_setselfattr+0x20/0x50 kernel: security_setselfattr+0xf6/0x110 kernel: __x64_sys_lsm_set_self_attr+0x53/0x90 kernel: do_syscall_64+0xdd/0x5e0 kernel: ? __mod_memcg_lruvec_state+0xfd/0x260 kernel: ? lruvec_stat_mod_folio+0x8d/0xd0 kernel: ? __folio_mod_stat+0x2d/0x90 kernel: ? map_anon_folio_pte_nopf+0xd1/0x1f0 kernel: ? do_anonymous_page+0x184/0xa10 kernel: ? __handle_mm_fault+0x805/0x870 kernel: ? count_memcg_events+0xef/0x230 kernel: ? handle_mm_fault+0x1f0/0x2f0 kernel: ? do_user_addr_fault+0x2bb/0x7b0 kernel: ? do_syscall_64+0x94/0x5e0 kernel: ? exc_page_fault+0x75/0x160 kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e kernel: RIP: 0033:0x7f815e134c8d kernel: RSP: 002b:00007fff6df94ea8 EFLAGS: 00000246 ORIG_RAX: 00000000000001cc kernel: RAX: ffffffffffffffda RBX: 0000556d8c81d040 RCX: 00007f815e134c8d kernel: RDX: 0000000000000046 RSI: 0000556d8c81d040 RDI: 0000000000000064 kernel: RBP: 00007fff6df94ef0 R08: 00007f815e212ac8 R09: 000000000000000c kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000556d8c81d010 kernel: R13: 0000000000000026 R14: 0000000000000046 R15: 0000000000000064 kernel: kernel: INFO: task hat:3409 is blocked on a mutex likely owned by task hat:3409. To fix the issue, lift the locking out of the core of aa_new_learning_profile(), introduce a wrapper function that takes the lock where needed, and have build_change_hat() call the core function that no longer takes the lock. In addition fix 4 other issues introduced by commit 32e92764d6f8d (\"apparmor: grab ns lock and refresh when looking up changehat child profiles\") - aa_get_profile_rcu() was replaced-by: aa_get_profile without the accompanying rcu_dereference_protected() - an extra aa_get_label(label) was introduced at the start of change_hat() without an accompanying aa_put_label() causing a reference count leak. - a reference count leak was introduced in the label_is_stale(label) case, where the newest profile would be leaked instead of the label passed to the function. - a potential UAF when the lookup walks up the tree with new_ns != ns the new label refere ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90180", "url": "https://ubuntu.com/security/CVE-2026-90180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: mtip32xx: synchronize ioctls with device removal The ioctl handlers only test REMOVE_PENDING before entering mtip_hw_ioctl(). Removal can set that bit immediately afterwards and free dd->port in mtip_hw_exit() while an ioctl still dereferences it. An already open block device can reach the handlers while del_gendisk() is in progress. Serialize both native and compat ioctls with removal. Set REMOVE_PENDING before taking the mutex so new callers fail after an in-flight ioctl has drained, and hold the mutex until the port has been torn down.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90184", "url": "https://ubuntu.com/security/CVE-2026-90184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: serialize configfs attribute updates with device setup The attribute store methods generated with NULLB_DEVICE_ATTR() refuse to change the configuration of a live device by testing NULLB_DEV_FL_CONFIGURED, but that flag is only set by nullb_device_power_store() after null_add_dev() has returned, and the store methods take no lock at all. configfs only serializes writes to the same open file (buffer->mutex), so a write to any attribute can run concurrently with null_add_dev() and change the device configuration while it is being used. null_add_dev() reads the configuration several times, e.g. dev->zoned is read once to set up the queue limits and once to initialize the zone resources: CPU0: echo 1 > nullb0/power CPU1: echo 1 > nullb0/zoned nullb_device_power_store() mutex_lock(&lock) null_add_dev() if (dev->zoned) -> false /* no BLK_FEAT_ZONED */ nullb_device_zoned_store() test_bit(FL_CONFIGURED) -> 0 dev->zoned = true blk_mq_alloc_disk() /* queue is not zoned */ if (nullb->dev->zoned) -> true null_register_zoned_dev() blk_revalidate_disk_zones() blk_revalidate_disk_zones() is then called for a queue that does not have BLK_FEAT_ZONED set, which triggers its WARN_ON_ONCE() and fails the device setup with -EIO: WARNING: CPU: 2 PID: 322 at block/blk-zoned.c:2357 blk_revalidate_disk_zones+0x4c/0x560 Clearing dev->zoned in the same window is worse: the queue is created with BLK_FEAT_ZONED but the zone resources are never initialized, so add_disk() succeeds for a zoned disk that has no zones. And a store that lands after the last dev->zoned test leaves dev->zoned set while dev->zones is still NULL, which null_process_zoned_cmd() dereferences on the first write. Fix this by taking the global lock, which nullb_device_power_store() already holds across null_add_dev() and null_del_dev(), around both the NULLB_DEV_FL_CONFIGURED test and the update of the device configuration. The submit_queues and poll_queues apply callbacks are now called with that lock held, so remove the locking they did themselves. Since the store methods can run as soon as configfs_register_subsystem() returns, that is, before null_init() gets to mutex_init(&lock), also initialize the lock statically with DEFINE_MUTEX().", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90185", "url": "https://ubuntu.com/security/CVE-2026-90185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: serialize configfs attribute stores with the lock The NULLB_DEVICE_ATTR _store takes no lock: apply_fn attributes (submit_queues, poll_queues) get dev->NAME written again after apply_fn returns, outside its lock; APPLY=NULL attributes are entirely lockless. configfs only serializes stores per-open-file, so concurrent stores on separate fds race. For apply_fn attributes, once one store's apply_fn has reconfigured the hardware, a second (losing) store can still overwrite dev->NAME afterwards. This leaves dev->submit_queues out of sync with the live queue count, which is later caught by the WARN_ON_ONCE() in null_map_queues(). For !apply_fn attributes, power_store()'s null_add_dev() validates and builds the device under \"lock\" but only sets CONFIGURED afterwards. A store slipping in during this window can change a field mid-setup -- for example, zone_nr_conv can be pushed above nr_zones after it has already been clamped, leading to an out-of-bounds dev->zones[] access. Take \"lock\" in the macro around the apply_fn call, the CONFIGURED test and the field write, and move it out of nullb_apply_submit_queues()/ nullb_apply_poll_queues() so both paths are covered once. This serializes stores with power_store's setup and with each other.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90186", "url": "https://ubuntu.com/security/CVE-2026-90186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: reject per-device queue resize for shared tag set When shared_tags is enabled, null_setup_tagset() makes the device use the global tag_set, whose driver_data stays NULL. null_map_queues() therefore falls back to the module-wide g_submit_queues/g_poll_queues instead of any per-device value. Resizing submit_queues or poll_queues via configfs on such a device calls blk_mq_update_nr_hw_queues() on the shared set, shrinking set->nr_hw_queues. __blk_mq_realloc_hw_ctxs() only grows the q->queue_hw_ctx[] allocation, so on shrink it merely exits and NULLs the now-excess hctx slots. null_map_queues(), however, keeps mapping CPUs with the unchanged g_submit_queues/g_poll_queues, so mq_map[] ends up pointing at those NULLed hctx slots. blk_mq_map_swqueue() then dereferences the NULL hctx (hctx->cpumask), crashing the kernel: [ 460.218374] KASAN: null-ptr-deref in range [0x0000000000000098-0x000000000000009f] [ 460.219003] CPU: 24 UID: 0 PID: 1492 Comm: sh Not tainted 7.2.0-rc2+ #67 PREEMPT(full) [ 460.219792] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 [ 460.220452] RIP: 0010:blk_mq_map_swqueue+0x4db/0x1430 ...... [ 460.228977] Call Trace: [ 460.229175] [ 460.229354] blk_mq_update_nr_hw_queues+0xd49/0x11c0 [ 460.229779] ? __pfx_blk_mq_update_nr_hw_queues+0x10/0x10 [ 460.230200] nullb_update_nr_hw_queues+0x1a9/0x370 [null_blk] [ 460.230694] nullb_device_submit_queues_store+0xd9/0x170 [null_blk] [ 460.231190] ? __pfx_nullb_device_submit_queues_store+0x10/0x10 [null_blk] [ 460.231776] ? configfs_write_iter+0x35c/0x4e0 [ 460.232122] configfs_write_iter+0x286/0x4e0 [ 460.232460] vfs_write+0x52d/0xd00 [ 460.232779] ? __x64_sys_openat+0x108/0x1d0 [ 460.233106] ? __pfx_vfs_write+0x10/0x10 [ 460.233413] ? fdget_pos+0x1cf/0x4c0 [ 460.233745] ? fput_close+0x133/0x190 [ 460.234038] ? __pfx_expand_files+0x10/0x10 [ 460.234368] ksys_write+0xfc/0x1d0 Reproducer: modprobe null_blk shared_tags=1 submit_queues=64 poll_queues=1 mkdir /sys/kernel/config/nullb/dev echo 1 > /sys/kernel/config/nullb/dev/power echo 1 > /sys/kernel/config/nullb/dev/submit_queues A per-device resize of a shared tag set is meaningless anyway, so reject it with -EINVAL in nullb_update_nr_hw_queues() when the device is bound to the global tag_set.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90187", "url": "https://ubuntu.com/security/CVE-2026-90187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: free zones array on device power-off null_init_zoned_dev() allocates dev->zones when a zoned device is powered on, but null_del_dev() never frees it on power-off; dev->zones is only freed later in null_free_dev(), when the configfs directory is removed. If the device is powered off and then on again, null_init_zoned_dev() allocates a new array and overwrites the dev->zones pointer, leaking the previous allocation each power cycle. Free dev->zones in null_del_dev() via null_free_zoned_dev() to solve it. And calling null_free_zoned_dev() in null_free_dev() is no longer necessary because every caller already invokes null_del_dev() first: via nullb_group_drop_item() before nullb_device_release(), in the null_add_dev() error path of null_create_dev(), and in null_destroy_dev(). Remove the redundant call. And take &lock around zone_cond_store() in the two store wrappers to serialize dev->zones check-and-deref against its alloc/free, which already run under &lock. The reason there was no problem before is that only nullb_device_release() or null_exit() frees the dev->zones, which guarantees that subsequent users won't access the configfs interface.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90188", "url": "https://ubuntu.com/security/CVE-2026-90188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: free global tag_set on init error path If shared_tags is enabled, null_setup_tagset() allocates the global tag_set via null_init_global_tag_set(). If device creation later fails, err_dev destroys the default devices and calls unregister_blkdev(), but never frees the global tag_set. Since module init failed, null_exit() is never invoked, so the global tag_set's tags and maps are permanently leaked. Free the global tag_set in err_dev, matching null_exit() which does if (tag_set.ops) blk_mq_free_tag_set(&tag_set).", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90189", "url": "https://ubuntu.com/security/CVE-2026-90189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: register configfs subsystem after creating default devices In null_init(), configfs_register_subsystem() currently runs before register_blkdev(), so when null_blk is built as a module, a racing mkdir() + poweron from userspace can reach null_add_dev() while null_major is still 0. __add_disk() then hits WARN_ON(disk->minors) (major=0 with minors!=0) and fails: [root@fedora ~]# [ 2366.521436] WARNING: block/genhd.c:476 at __add_disk+0x8a7/0xde0, [ 2366.523552] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib [ 2366.529081] CPU: 26 UID: 0 PID: 1600 Comm: sh Not tainted 7.2.0-rc1+ #66 PREEMPT(full) ...... [ 2366.547251] Call Trace: [ 2366.547575] [ 2366.547831] ? _raw_spin_lock+0x84/0xe0 [ 2366.548260] add_disk_fwnode+0x114/0x560 [ 2366.548739] null_add_dev+0x102d/0x1b80 [null_blk] [ 2366.549310] ? __pfx_null_add_dev+0x10/0x10 [null_blk] [ 2366.549906] ? mutex_lock+0xde/0x1c0 [ 2366.550361] ? __pfx_mutex_lock+0x10/0x10 [ 2366.550827] nullb_device_power_store+0x1e7/0x280 [null_blk] [ 2366.551499] ? __pfx_nullb_device_power_store+0x10/0x10 [null_blk] [ 2366.552177] ? __kmalloc_cache_noprof+0x1f5/0x470 [ 2366.552748] ? configfs_write_iter+0x35c/0x4e0 [ 2366.553242] configfs_write_iter+0x286/0x4e0 [ 2366.553787] vfs_write+0x52d/0xd00 [ 2366.554169] ? __pfx_vfs_write+0x10/0x10 [ 2366.554679] ? __pfx___css_rstat_updated+0x10/0x10 [ 2366.555196] ? fdget_pos+0x1cf/0x4c0 [ 2366.555649] ksys_write+0xfc/0x1d0 ...... Additionally, the err_dev path destroys all devices on nullb_list while configfs is still registered. If a racing mkdir() + poweron puts a user device on the list, null_destroy_dev()->null_free_dev() kfrees the user device's nullb_device but /sys/kernel/config/nullb/ is still reachable. Any userspace access to the item will trigger a UAF. For simplicity, move configfs_register_subsystem() to the end to solve the problems above.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90190", "url": "https://ubuntu.com/security/CVE-2026-90190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: use DEFINE_MUTEX for the file-scope mutex In null_init(), mutex_init(&lock) currently happens after configfs_register_subsystem(), which exposes the nullb subsystem to userspace. A racing mkdir() into /sys/kernel/config/nullb/ can reach null_find_dev_by_name() -> mutex_lock(&lock) before the mutex is initialized, trigger warning: [ 123.137788] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 123.137796] WARNING: kernel/locking/mutex.c:159 at mutex_lock+0x171/0x1c0, CPU#13: mkdir/1301 [ 123.140090] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 ...... [ 123.154926] Call Trace: [ 123.155172] [ 123.155419] ? __pfx_mutex_lock+0x10/0x10 [ 123.156181] ? __pfx__raw_spin_lock+0x10/0x10 [ 123.156571] nullb_group_make_group+0x20/0x100 [null_blk] [ 123.157011] configfs_mkdir+0x47b/0xc70 [ 123.157337] ? __pfx_configfs_mkdir+0x10/0x10 [ 123.157719] ? may_create_dentry+0x242/0x2e0 [ 123.158061] vfs_mkdir+0x2a9/0x6c0 [ 123.158352] filename_mkdirat+0x3dc/0x500 [ 123.158710] ? __pfx_filename_mkdirat+0x10/0x10 [ 123.159070] ? strncpy_from_user+0x3a/0x1d0 [ 123.159413] __x64_sys_mkdir+0x6b/0x90 [ 123.159760] do_syscall_64+0xea/0x600 Replace the runtime mutex_init(&lock) with a static DEFINE_MUTEX(lock) declaration to fix this issue.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90191", "url": "https://ubuntu.com/security/CVE-2026-90191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: riscv-sbi-mpxy: validate RPMI notification lengths The SBI return value controls how many bytes are copied from shared memory into the RPMI notification buffer. It is not validated against the negotiated shared-memory size before that copy. The event walker also uses a reversed loop condition and can inspect a short event record. Validate the complete notification length before copying it, iterate only while a full event header remains, and stop when a declared event payload extends beyond the copied notification data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90192", "url": "https://ubuntu.com/security/CVE-2026-90192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: qcom-cpucp: handle NULL data in send_data callback mailbox_clear_channel() calls mbox_send_message() with NULL data to notify the remote side that the RX channel has been cleared. qcom_cpucp_mbox_send_data() blindly dereferenced the data pointer, causing a NULL pointer dereference kernel panic when invoked from this path under PREEMPT_RT. Add an explicit NULL check and return early without writing to the TX register, which is the correct behaviour for a channel-clear notification.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90193", "url": "https://ubuntu.com/security/CVE-2026-90193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: qcom-cpucp: fix PREEMPT_RT self-deadlock in IRQ handler qcom_cpucp_mbox_irq_fn() calls mbox_chan_received_data() while holding chan->lock. Under PREEMPT_RT, spin_lock_irqsave() is converted to an rt_spinlock (rtmutex-based), which tracks ownership and can sleep. The callback chain triggered by mbox_chan_received_data() eventually reaches mailbox_clear_channel() -> mbox_send_message() -> add_to_rbuf(), which attempts to re-acquire the same chan->lock. Since rtmutex detects the re-entrant lock attempt by the same owner, the thread blocks waiting for a lock it already holds, causing a permanent deadlock. This deadlock manifests as 'irq/N-apss_cpucp_mbox' stuck in D state with the following call trace: rt_spin_lock -> mbox_send_message -> mailbox_clear_channel -> scmi_rx_callback -> mbox_chan_received_data [<- held chan->lock here] Fix by saving chan->cl locally and clearing the HW interrupt register inside the lock, then invoking mbox_chan_received_data() after releasing the lock. This preserves the mutual exclusion for chan->cl access while avoiding the lock re-entrancy that causes the PREEMPT_RT deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90194", "url": "https://ubuntu.com/security/CVE-2026-90194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: scan: fix bus ID cleanup on device_add() failures When device_add() fails after acpi_device_set_name() has allocated an instance ID and a new acpi_device_bus_id has been linked into acpi_bus_id_list, the rollback path only removes wakeup_list and detaches the ACPI handle data. That leaves the bus-ID bookkeeping behind and keeps the allocated instance number consumed. Move the bus-ID cleanup and wakeup-list removal into a single helper. Use it from both the normal device teardown path and the device_add() rollback path. The wakeup list node is initialized before registration, so it can be deleted without checking whether the device is wakeup- capable like in the original teardown path. [ rjw: Rename acpi_device_del_list() to acpi_device_cleanup() ] [ rjw: Subject and changelog edits ]", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90195", "url": "https://ubuntu.com/security/CVE-2026-90195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Fix missing sign-ext for signed 1-byte and 2-byte kfunc args On RV64, the ABI requires sign-extension for signed 1-byte and 2-byte kfunc args. However, the RV64 JIT currently does not perform sign-extension for such kfunc args. Before commit 7ce090afbf72 (\"bpf: Infer zext_dst based on static register liveness analysis\"), state pruning could potentially omit zero-extension of 32-bit subregisters, which inadvertently masked the above issue by making the args appear as if they had been properly sign-extended. After that commit, the problem is exposed, causing the kfunc_call/kfunc_call_test4 selftest to fail. Fix this by extending the existing sign-extension logic to handle signed 1-byte and 2-byte kfunc args as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90196", "url": "https://ubuntu.com/security/CVE-2026-90196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: validate topology volume range before allocation SOF treats the topology mixer min and max values as non-negative indices into its volume table. It stores them in signed fields, allocates max + 1 entries through an int argument, and later indexes the table with the stored range. An inverted range is invalid, while a maximum at or above INT_MAX cannot be represented safely after the increment or in the signed fields. Validate the complete range before storing it or allocating the table.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90197", "url": "https://ubuntu.com/security/CVE-2026-90197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: haptic: don't write an uninitialized value to unhandled usages fill_effect_buf() initializes value only for the four haptic usages handled by its switch, but writes it to field->value[] for every usage. An unhandled usage can therefore receive either an uninitialized value or one left over from the previous usage. hid_output_report() then serializes that value into the effect's report buffer. Skip unhandled usages instead. This also matches switch_mode(), which only updates fields it recognizes. Found with Clang's -Wconditional-uninitialized.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90198", "url": "https://ubuntu.com/security/CVE-2026-90198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix use-after-free in snd_card_do_free() A use-after-free was detected in snd_card_do_free() when a sound card managed by devres is unbound while a user-space application still holds an open file descriptor. For managed cards, the memory is allocated using devres_alloc(), and its release function is set to __snd_card_release(), which calls snd_card_free(). When the device is unbound, the unbind thread calls snd_card_free(), which drops a reference to the card's device. If the user thread still has an open file descriptor, the reference count does not reach zero, and the unbind thread blocks on wait_for_completion(&released). When the user thread closes the file descriptor, it drops the final reference, invoking the device release callback release_card_device(), which calls snd_card_do_free(). snd_card_do_free() performs cleanup and calls complete(card->release_completion). This wakes up the unbind thread, which returns from snd_card_free() and __snd_card_release(). The devres core then immediately frees the memory block containing the snd_card structure. Meanwhile, the user thread continues execution in snd_card_do_free() and evaluates `if (!card->managed)`. It reads the `managed` boolean from the snd_card structure that was just freed by the unbind thread, triggering a KASAN use-after-free. Fix this by caching the value of card->managed in a local variable before calling complete(). This ensures that the card pointer is not dereferenced after the unbind thread has been woken up and potentially freed the card. BUG: KASAN: use-after-free in snd_card_do_free sound/core/init.c:604 [inline] BUG: KASAN: use-after-free in release_card_device+0x1ab/0x1b0 sound/core/init.c:153 Read of size 1 at addr ffff8881912ec909 by task syz-executor130/5857 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description+0x55/0x1e0 mm/kasan/report.c:378 print_report+0x58/0x70 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 snd_card_do_free sound/core/init.c:604 [inline] release_card_device+0x1ab/0x1b0 sound/core/init.c:153 device_release+0xc4/0x1f0 drivers/base/core.c:-1 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x222/0x550 lib/kobject.c:737 snd_card_file_remove+0x331/0x390 sound/core/init.c:1125 snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c:2986 __fput+0x418/0xa50 fs/file_table.c:512 fput_close_sync+0x11f/0x240 fs/file_table.c:617 __do_sys_close fs/open.c:1511 [inline] __se_sys_close fs/open.c:1496 [inline] __x64_sys_close+0x7e/0x110 fs/open.c:1496 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90199", "url": "https://ubuntu.com/security/CVE-2026-90199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject out-of-range evcn in mi_enum_attr() In mi_enum_attr(), the start/end VCN validation for non-resident attributes is: \tif (svcn > evcn + 1) goto out; When evcn is U64_MAX the \"evcn + 1\" expression wraps to 0 and any svcn passes the check. For evcn values close to U64_MAX (but not equal to it) the right-hand side is still a meaningless near-wrap upper bound, so a malformed on-disk attribute with svcn == 0 and evcn near U64_MAX can pass mi_enum_attr() unrejected. VCN (virtual cluster number) is a cluster index, so any valid evcn is bounded by the volume's total cluster count, which ntfs3 holds in sbi->used.bitmap.nbits (set up in ntfs_init_from_boot() before any caller of mi_enum_attr() runs). Reject evcn values that fall outside this range. However, an empty non-resident attribute (no allocated clusters) is legitimately encoded with svcn == 0 and evcn == -1 (U64_MAX), e.g. via attr->nres.evcn = cpu_to_le64((u64)vcn - 1) with vcn == 0. That sentinel must keep passing, so exclude evcn == U64_MAX from the range check. The existing \"svcn > evcn + 1\" test still tolerates the sentinel (\"0 > 0\" is false) and continues to require svcn == 0 for it, while the range check rejects every other out-of-range evcn and thereby also defuses the \"evcn + 1\" wraparound. svcn does not need its own bound: once evcn < nbits, \"svcn > evcn + 1\" implies svcn <= nbits. [almaz.alexandrovich@paragon-software.com: fixed evcn check]", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90200", "url": "https://ubuntu.com/security/CVE-2026-90200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix integer overflow in MFT cluster validation In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are validated against the volume size with: \tif (mlcn * sct_per_clst >= sectors || \t mlcn2 * sct_per_clst >= sectors) \t\tgoto out; mlcn and mlcn2 are u64 fields read directly from the boot sector. sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus the is_power_of_2() check below it), but the multiplication is done in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn near 2^62 with sct_per_clst == 4 wraps to 0, which compares below any non-zero 'sectors', so the check is bypassed and the malformed record is accepted. The accepted mlcn is then used unchanged in \tsbi->mft.lbo = mlcn << cluster_bits; In practice the resulting reads fail at the block layer (sb_bread() returns NULL via grow_buffers()'s check_mul_overflow() guard), so today this manifests as mount failing in odd places rather than as something more dangerous, but the validation step is still wrong and there is no reason for callers to rely on the block layer to catch a value that should never have been accepted in the first place. Use check_mul_overflow() to compute the two sector positions and fail the mount if either multiplication wraps; this preserves the existing semantics (mlcn * sct_per_clst >= sectors) instead of switching to division (mlcn >= sectors / sct_per_clst), which would tighten the check at edge cases where 'sectors' is not a multiple of sct_per_clst. The check_*_overflow() style is the one ntfs3 already uses for similar on-disk arithmetic in fs/ntfs3/run.c.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90201", "url": "https://ubuntu.com/security/CVE-2026-90201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: page_pool: fix UAF in __page_pool_release_netmem_dma on xa_cmpxchg race This bug was discovered while testing the hns3 driver under channel reconfiguration (`ethtool -L` / `ethtool -G`) with iperf3 traffic on arm64. The race is intermittently triggered when page_pool_destroy() runs page_pool_scrub() concurrently with page return via page_pool_put_netmem() on a different CPU. A WARN in page_pool_clear_pp_info() surfaced the dangling DMA index bits left by the cmpxchg loser, which led to the investigation. page_pool_scrub() iterates pool->dma_mapped via xa_for_each() with no page ref held. __page_pool_release_netmem_dma() currently reads and writes netmem fields (dma_addr, DMA index bits in pp_magic) after xa_cmpxchg() returns. The unref path calls put_page() unconditionally regardless of the cmpxchg outcome; when it loses the cmpxchg, it still frees the page before the scrub winner finishes these netmem accesses, so scrub touches a freed page -- a Use-After-Free. Fix this by splitting the DMA release into two functions: 1. __page_pool_unmap_netmem_dma() caches dma_addr before xa_cmpxchg(), does the cmpxchg to remove the DMA mapping, and calls dma_unmap on the cached address. It never touches netmem fields after the cmpxchg, making it safe for the scrub path which holds no page ref. 2. __page_pool_release_netmem_dma() wraps the above and additionally clears dma_addr and DMA index bits in netmem fields. This is safe only when the caller holds a page ref, so it is used by the return path (page_pool_return_netmem). The scrub path calls __page_pool_unmap_netmem_dma() directly; the return path calls __page_pool_release_netmem_dma().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90202", "url": "https://ubuntu.com/security/CVE-2026-90202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers _base_release_memory_pools() unconditionally frees every ioc->pcie_sg_lookup[] entry, including ones the setup loop never allocated after a partial failure, causing a \"bad dma\" warning on debug kernels or a NULL pointer dereference otherwise.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90203", "url": "https://ubuntu.com/security/CVE-2026-90203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check block offset is not negative If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfs_copy_data() to perform an out of bounds access. Fix by checking if offset is negative, and returning 0. This matches existing behaviour where an offset beyond the block returns 0 bytes copied. To trigger this out of bounds access requires a crafted Squashfs filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be able to mount such a filesystem, but once mounted, an unprivileged user can trigger the out of bounds access by reading the crafted file with the negative offset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90204", "url": "https://ubuntu.com/security/CVE-2026-90204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate DIO orphan slot during inode read [BUG] A corrupted append-DIO dinode (high byte at offset 0xa1 corrupted from 0 to 1) can carry an i_dio_orphaned_slot outside the mounted filesystem slot range and trigger a use-after-free error: BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85 Call Trace: ... ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840 ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline] ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295 evict+0x38e/0x8f0 fs/inode.c:810 iput_final fs/inode.c:1914 [inline] iput fs/inode.c:1966 [inline] iput+0x55b/0x8b0 fs/inode.c:1926 ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374 ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373 ... [CAUSE] ocfs2_del_inode_from_orphan() uses i_dio_orphaned_slot to index the slot-local system inode cache. The dinode validator does not check this active slot, so an out-of-range value produces an invalid cache entry pointer that is dereferenced as an inode pointer. [FIX] Reject an active i_dio_orphaned_slot outside the slot range during dinode validation, before DIO orphan recovery can consume it.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90205", "url": "https://ubuntu.com/security/CVE-2026-90205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate orphan slot during inode read Patch series \"ocfs2: validate active orphan slots during inode read\". OCFS2 trusts active ordinary and append-DIO orphan slots read from dinodes. A corrupted slot can therefore index osb_orphan_wipes or the slot-local system-inode cache outside their allocations before the corruption is reported. Patch 1 validates the ordinary orphan slot used by inode wipe processing. Patch 2 validates the append-DIO orphan slot used by DIO completion and orphan recovery. Both checks reject corrupt metadata at the existing inode validation boundary. This patch (of 2): [BUG] A corrupted dinode with OCFS2_ORPHANED_FL can carry an i_orphaned_slot outside the mounted filesystem slot range. ocfs2_wipe_inode() uses it to index osb_orphan_wipes before looking up the orphan directory, causing an out-of-bounds memory access. BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85 Call Trace: ... ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840 ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline] ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295 evict+0x38e/0x8f0 fs/inode.c:810 iput_final fs/inode.c:1914 [inline] iput fs/inode.c:1966 [inline] iput+0x55b/0x8b0 fs/inode.c:1926 ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374 ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373 ... [CAUSE] ocfs2_validate_inode_block() validates i_suballoc_slot but leaves the active ordinary orphan slot unchecked. Downstream consumers assume that the value is smaller than osb->max_slots. [FIX] Reject an active i_orphaned_slot outside the slot range during dinode validation, before the inode reaches orphan wipe processing.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90207", "url": "https://ubuntu.com/security/CVE-2026-90207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: midi: Serialize input teardown with event_input snd_midi_input_event() must not be running while a rawmidi substream is closing, since this can lead to the trigger state becoming out-of-step through this sequence in snd_rawmidi_input_trigger(): \tsnd_rawmidi_input_trigger(up=0) \t\t\t\t\tsnd_midi_input_event() \t\t\t\t\t -> snd_rawmidi_kernel_read() \t\t\t\t\t -> snd_rawmidi_input_trigger(up=1) \t -> cancel_work_sync() which ends with the underlying device being active unexpectedly. When this is called from close_substream(), further input can re-trigger the input event leaving it running after rawmidi_release_priv() has set rfile->rmidi to NULL which leads to: \tUnable to handle kernel NULL pointer dereference at virtual address 00000000000000b0 \tCall trace: \t snd_midi_input_event+0x3c/0x134 [snd_seq_midi] (P) \t snd_rawmidi_input_event_work+0x1c/0x2c \t process_one_work+0x150/0x3a4 \t worker_thread+0x190/0x318 Apply a similar approach to commit ef7607ab1c8ad (\"ALSA: seq: midi: Serialize output teardown with event_input\") which fixed the same issue in the output direction, but updated to use RCU following Takashi Iwai's proposed follow-on patch [1]. With this change in place, midisynth_unsubscribe() clears the input file so snd_midi_input_event() will not re-trigger the stream and will be quiesced by the cancel_work_sync() in snd_rawmidi_input_trigger(). [1] https://lore.kernel.org/linux-sound/20260813144224.753399-1-tiwai@suse.de/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90209", "url": "https://ubuntu.com/security/CVE-2026-90209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/debug: Fix deadlock during unregister Unregistering an s390dbf debug area while one of the associated debugfs files is being written to can cause a deadlock: $ echo >.../vmur/level $ rmmod vmur =================================================== debugfs write debugfs_file_get() debug_unregister() mutex_lock(debug_mutex) debugfs_remove() wait for debugfs_file_put() debug_file_ops.write() debug_input() mutex_lock(debug_mutex) ==> DEADLOCK Fix this by splitting debug_unregister() into an s390dbf and debugfs part, and running only the s390dbf part with debug_mutex locked.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90213", "url": "https://ubuntu.com/security/CVE-2026-90213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: core: fix memory leak in error path of build_tree() In the error path of build_tree(), node instances can remain in the local linked list when the function returns. Whenever an invalid value is detected in the self ID sequence, each allocated node instance is either an entry in the linked list or an entry in the ports array of its parent node. Therefore, the allocate node instances can be safely released by traversing the linked list from its head. Release the remaining node instances with for_each_fw_node() before returning to the caller.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90214", "url": "https://ubuntu.com/security/CVE-2026-90214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: xilinx: formatter_pcm: fix stream_data leak on open error In xlnx_formatter_pcm_open(), stream_data is allocated and adata->play_stream or adata->capture_stream is assigned early. If a later step, such as snd_pcm_hw_constraint_step() or snd_pcm_hw_constraint_integer(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so stream_data is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call snd_pcm_period_elapsed() on the freed substream. Free stream_data and clear the stream pointer on the error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90215", "url": "https://ubuntu.com/security/CVE-2026-90215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: ubi: Release device reference on busy detach ubi_detach_mtd_dev() obtains a device reference through ubi_get_device() before checking whether the UBI device is busy. The busy return path drops ubi->ref_count but leaves the device reference held, so the device object cannot be released after a later detach. Drop the device reference before returning -EBUSY.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90216", "url": "https://ubuntu.com/security/CVE-2026-90216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubi: Fix rollback for explicit UBI device numbers ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90218", "url": "https://ubuntu.com/security/CVE-2026-90218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix WARNING in res_to_rt syzbot reported a WARN_ON(!res->dev) in res_to_rt() triggered via addr_handler() during asynchronous address resolution: \" WARNING: drivers/infiniband/core/restrack.c:138 at res_to_rt+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ib_addr process_one_req RIP: 0010:res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: rdma_restrack_add+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addr_handler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 process_one_req+0x2eb/0x540 drivers/infiniband/core/addr.c:624 process_one_work kernel/workqueue.c:3375 [inline] process_scheduled_works+0xc4e/0x1630 kernel/workqueue.c:3458 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 \" In addr_handler(), cma_acquire_dev_by_src_ip() is called to populate id_priv->cma_dev and bind the associated ib_device to id_priv->id.device. If cma_acquire_dev_by_src_ip() returns an error (non-zero status), the ID remains unassociated with any RDMA device. Previously, rdma_restrack_add(&id_priv->res) was invoked unconditionally even when cma_acquire_dev_by_src_ip() failed, passing a resource with a NULL dev pointer and triggering the WARN_ON assertion in res_to_rt(). Fix this by only adding the resource to restrack when acquiring the device succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90219", "url": "https://ubuntu.com/security/CVE-2026-90219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Free debugfs on registration failure c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via setup_debugfs()), but it is removed only in c4iw_remove(), not in c4iw_dealloc(). When RDMA device registration fails, the registration worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing c4iw_remove(), so the debugfs dentries leak and outlive the freed c4iw_dev. Move debugfs_remove_recursive() into c4iw_dealloc() so every path that frees ctx->dev also removes its debugfs tree.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90220", "url": "https://ubuntu.com/security/CVE-2026-90220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Don't leak the extension cell pointer in the bounce payload The bounce_error_event() embeds the failed event in the bounce payload by pointing data.ext.ptr at it. When that event is a queued variable-length event, its own data.ext.ptr holds the address of its first extension cell, put there by snd_seq_event_dup(). The payload goes out verbatim through snd_seq_expand_var_event(), so the address reaches userspace. That is the same address commit 705dd6dcbc0e (\"ALSA: seq: Clear variable event pointer on read\") removed from the event header. The read path still clears it there, just above the call that expands the payload. Embed a sanitised copy instead, treated exactly as snd_seq_read() treats the header. A stack copy is enough because delivery is synchronous and snd_seq_event_dup() copies before returning. An unprivileged client reaches this by setting SNDRV_SEQ_FILTER_BOUNCE, queueing a variable-length event to a port that does not exist and reading the bounce back. Eight bytes on 64-bit, from its own pool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90221", "url": "https://ubuntu.com/security/CVE-2026-90221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing nci_core_init_rsp_packet_v1() and nci_core_init_rsp_packet_v2() parse the CORE_INIT_RSP packet without validating that the skb contains enough data. A malformed response (e.g. injected via virtual_ncidev) can declare a large num_supported_rf_interfaces while providing insufficient data, causing reads of uninitialized slab memory. This is later used in nci_init_complete_req(), triggering a KMSAN uninit-value warning. Add skb length checks before accessing packet fields: - Validate the skb has at least 1 byte for the status field. - Validate the skb can hold the fixed-size header before parsing. - In v2, bounds-check each variable-length rf_interface entry and its extension parameters within the parsing loop. - In v1, verify the skb is large enough for both the variable-length rf_interfaces array and the trailing rsp_2 structure.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90222", "url": "https://ubuntu.com/security/CVE-2026-90222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: hold a reference to the request skb during send_frame __pn533_send_async() publishes the command and then calls dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame can be matched to this command: the I2C threaded IRQ runs pn533_recv_frame(), which queues cmd_complete_work, and pn533_send_async_complete() frees cmd->req with consume_skb(). On the I2C transport, pn533_i2c_send_frame() still dereferences the same skb after i2c_master_send() returns, so a completion that races the send can free the skb while the transport is still using it. The request skb is owned by the command object and may be freed by command completion at any time after dev->cmd is published, so the transport send path must not assume it stays alive. Hold a temporary reference to the request skb across the send_frame() call so the transport always sees a live skb even if completion races the send. Add a pn533_send_cmd_frame() helper and use it from all three send paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90223", "url": "https://ubuntu.com/security/CVE-2026-90223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound SNL TLV parsing to the skb and add length checks nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed: - For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made \"service_name_len = length - 1\" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3] without a length check. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Walk the TLV list by pointer, bounded by skb_tail_pointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90224", "url": "https://ubuntu.com/security/CVE-2026-90224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix double completion race in nci_data_exchange_complete nci_close_device() and nci_rx_work can both call nci_data_exchange_complete() concurrently. After commit 4527025d440ce8 (\"nfc: nci: fix circular locking dependency in nci_close_device\") moved flush_workqueue(ndev->rx_wq) after mutex_unlock(&ndev->req_lock), rx_work is no longer serialized with the explicit completion call in the close path. Both callers read the non-NULL callback pointer and invoke rawsock_data_exchange_complete(), which calls sock_put() -- but only one sock_hold() was taken, so the second sock_put() underflows the refcount and frees the socket while it is still in use. Replace the bare clear_bit(NCI_DATA_EXCHANGE) with test_and_clear_bit() so that only the first caller proceeds to invoke the callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90225", "url": "https://ubuntu.com/security/CVE-2026-90225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: read llcp_sock->local under the socket lock in getsockopt nfc_llcp_getsockopt() read llcp_sock->local before lock_sock(sk) and then dereferenced the cached pointer inside the locked region. llcp_sock_bind() assigns and clears llcp_sock->local under the same socket lock, dropping the last reference on its error path. A getsockopt() racing an in-flight bind() can observe the pointer, block on lock_sock(), and then dereference a freed nfc_llcp_local once bind() has unwound. Move the llcp_sock->local read and the NULL check inside the lock_sock(sk) region so bind() cannot mutate or free the pointer between the load and the use.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90226", "url": "https://ubuntu.com/security/CVE-2026-90226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: avoid userspace overflow on invalid optlen nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90227", "url": "https://ubuntu.com/security/CVE-2026-90227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme/ioctl: check SUBMIT_IO with nvme_cmd_allowed() Unlike IO_CMD / IO64_CMD, NVME_IOCTL_SUBMIT_IO never calls nvme_cmd_allowed(). Unprivileged callers can thus issue I/O on a partition device or write through a read-only file descriptor. Pass flags and open_for_write through and reject disallowed commands with -EACCES.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90228", "url": "https://ubuntu.com/security/CVE-2026-90228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns() When a host issues an Identify command with CNS 05h (I/O Command Set specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed namespace has no block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The I/O command set is selected by the host-supplied CSI field and the command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled, independent of the namespace backing type, so any file-backed namespace is exposed. Reject the command with Invalid Field when the namespace is not backed by a block device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90229", "url": "https://ubuntu.com/security/CVE-2026-90229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-apple: Destroy the admin queue on removal The admin queue is allocated with blk_mq_alloc_queue() but never destroyed. nvme_free_ctrl() only drops the last reference and blk_mq_exit_queue() and blk_sync_queue() never run: the hctx is never moved to q->unused_hctx_list and the timeout timer and work stay armed on a queue that is about to be freed which will eventually oops inside blk_mq_timeout_work(). This can only be triggered when the controller fails to come up and is then immediately torn down again which is why no one ever ran into this before. Let's just copy what the pcie driver does: unquiesce and destroy the admin queue before nvme_uninit_ctrl(). With this the following WARN followed by a panic no longer happens: WARNING: block/blk-mq.c:4390 at blk_mq_release+0x194/0x238, CPU#4: kworker/u34:4/119 CPU: 4 UID: 0 PID: 119 Comm: kworker/u34:4 Not tainted 7.2.0-rc1-dirty #248 PREEMPT Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: nvme-wq apple_nvme_remove_dead_ctrl_work pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : blk_mq_release+0x194/0x238 lr : blk_mq_release+0x58/0x238 sp : ffffc000833a3b50 x29: ffffc000833a3b50 x28: ffff80001d0450f8 x27: ffff800020c95200 x26: 0000000000000088 x25: 0000000000000000 x24: ffff800020f36805 x23: 0000000000000000 x22: ffffc00081a86878 x21: ffff800020be9c60 x20: 0000000000000000 x19: ffff800022501698 x18: 000000000000000a x17: 7365757165722066 x16: 666f7265776f7020 x15: 0000000000000000 x14: 0000000000000028 x13: 0000000000004def x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000805b4fc8 x8 : ffffc00081915820 x7 : ffffc00081c4f3c8 x6 : 0000000000000001 x5 : 0000000000000004 x4 : ffff800022498d80 x3 : ffffc000833a3b14 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800022501698 Call trace: blk_mq_release+0x194/0x238 (P) blk_put_queue+0x8c/0xf0 nvme_free_ctrl+0x4c/0x260 device_release+0x44/0x128 kobject_put+0xa0/0x120 put_device+0x1c/0x40 nvme_uninit_ctrl+0x48/0x60 apple_nvme_remove+0x54/0xb0 platform_remove+0x28/0x40 device_remove+0x54/0x98 device_release_driver_internal+ device_release_driver+0x20/0x38 apple_nvme_remove_dead_ctrl_wor process_one_work+0x1f4/0x770 worker_thread+0x1b8/0x360 kthread+0x140/0x160 ret_from_fork+0x10/0x20 irq event stamp: 448 hardirqs last enabled at (447):in_unlock_irqrestore+0x74/0x80 hardirqs last disabled at (448): [] el1_brk64+0x20/0x60 softirqs last enabled at (0): [ess+0xb28/0x2698 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 0000000000000000 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagA GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [0000000000000000] user address Internal error: Oops: 0000000096000005 [#1] SMP CPU: 7 UID: 0 PID: 54 Comm: kwor 7.2.0-rc1-dirty #248PREEMPT Tainted: [W]=WARN Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: kblockd blk_mq_timeou pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : percpu_ref_tryget_many.cons lr : percpu_ref_tryget_many.constprop.0+0xc0/0x168 sp : ffffc000829cbce0 x29: ffffc000829cbce0 x28: ffff800020be9f48 x27: ffff800013e503c0 x26: 0000000000000108 x25: 000009c05 x23: 0000000000000000 x22: ffffc000819f5000 x21: ffff800020be9f48 x20: ffff8001deda4808 x19: ffff8000a x17: 00000000580e1fac x16: ffffc00082bbbb7c x15: 0000000000000000 x14: 0000000000000028 x13: 000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000829cbc20 x8 : ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90230", "url": "https://ubuntu.com/security/CVE-2026-90230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix heap out-of-bounds read in nvmet_auth_negotiate() nvmet_execute_auth_send() allocates the DH-HMAC-CHAP message buffer with the host-supplied transfer length (tl) and hands it to nvmet_auth_negotiate() without passing tl along. nvmet_auth_negotiate() then reads the negotiate header and, for each of the halen hash identifiers and dhlen DH group identifiers, indexes into the fixed idlist[60] array (hashes at idlist[0..halen), groups at idlist[30..]). Neither the transfer length nor halen/dhlen is validated. A malicious or non-conformant host can report a tl smaller than the negotiate structure, or a halen/dhlen larger than the array (both are u8, up to 255), making the loops read past the end of the allocated buffer (heap out-of-bounds read). The sibling nvmet_auth_reply() already validates tl against the structure size; the negotiate path did not. Pass tl into nvmet_auth_negotiate(), reject a tl that does not cover the negotiate data plus one full protocol descriptor, and reject halen/dhlen larger than NVME_AUTH_DHCHAP_MAX_DH_IDS.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90232", "url": "https://ubuntu.com/security/CVE-2026-90232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: Don't support cross-netns setup. When a lower device is unregistered, amt_device_event() tries to unregister its upper AMT device, but it has two problems. 1. amt_lookup_upper_dev() looks up an upper device in the lower device's netns only 2. amt_device_event() unregisters a single upper device only If AMT device is created on a lower device in another netns, removing the lower device triggers the splat below and gets stuck until all upper devices are removed. [0] The cross-netns setup seems unintentional considering 1. and the following points: * amt_link_setup() sets dev->netns_immutable to true * skb_scrub_packet() is not called in the fast path * iproute2 binary fails to find cross-netns lower device via link-netns: # ip -n ns1 link add amt0 link-netns ns2 type amt dev veth1 Cannot find device \"veth1\" Instead of supporting it properly and preparing for per-netns netdev unreg, let's forbid cross-netns setup. Note that the problem 2. needs a separate fix. [0]: WARNING: net/core/dev.c:12518 at unregister_netdevice_many_notify+0x1cce/0x2250, CPU#48: ip/2031 Modules linked in: CPU: 48 UID: 0 PID: 2031 Comm: ip Not tainted 7.2.0-rc5+ #27 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:unregister_netdevice_many_notify (net/core/dev.c:12518) Code: 89 ef e8 d5 52 ae fe e9 d0 f4 ff ff 48 8d 3d f9 3b 9c 02 48 c7 c6 c0 0b 63 84 ba ab 1f 00 00 67 48 0f b9 3a e9 65 ff ff ff 90 <0f> 0b 90 eb 81 48 8d 3d f6 3b 9c 02 48 c7 c6 c0 0b 63 84 ba e2 1f RSP: 0018:ffffc90004abf160 EFLAGS: 00010212 RAX: ffff888104d38260 RBX: ffff88800b0911b8 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff85b9f880 RBP: ffffc90004abf2d0 R08: ffffffff85b9f887 R09: 1ffffffff0b73f10 R10: dffffc0000000000 R11: fffffbfff0b73f11 R12: ffff88800b091d08 R13: ffff88800b091178 R14: dffffc0000000000 R15: ffff88800b091000 FS: 00007f555b86c600(0000) GS:ffff8881942a0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562107d489c0 CR3: 0000000109a40002 CR4: 0000000000372ef0 Call Trace: rtnl_dellink (net/core/rtnetlink.c:3632 net/core/rtnetlink.c:3674) rtnetlink_rcv_msg (net/core/rtnetlink.c:7112) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1319) netlink_sendmsg (net/netlink/af_netlink.c:1900) ____sys_sendmsg (net/socket.c:775) __sys_sendmsg (net/socket.c:2738) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... unregister_netdevice: waiting for veth0 to become free. Usage count = 7 ref_tracker: netdev@ffff88800d7496d8 has 3/3 users at __netdev_adjacent_dev_insert (./include/linux/netdevice.h:4525 ./include/linux/netdevice.h:4554 net/core/dev.c:8791) __netdev_upper_dev_link (net/core/dev.c:8879 net/core/dev.c:8963) netdev_upper_dev_link (net/core/dev.c:9009) amt_newlink (drivers/net/amt.c:3321)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90233", "url": "https://ubuntu.com/security/CVE-2026-90233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-pci: release descriptor pools on probe failure The per-NUMA-node descriptor DMA pools are created lazily from nvme_init_hctx_common() once the admin tag set is allocated, but they are only destroyed in nvme_remove() via nvme_release_descriptor_pools(). Any probe failure after the admin tag set has been allocated unwinds through the out_disable label and nvme_pci_free_ctrl(), neither of which releases the pools, leaking the dma_pool objects. Release the descriptor pools in the out_disable error path. It must not be added to nvme_pci_free_ctrl(), as that would double-free against nvme_remove() on the normal teardown path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90235", "url": "https://ubuntu.com/security/CVE-2026-90235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: xprtsock: annotate shared socket callbacks with READ_ONCE/WRITE_ONCE xprtsock replaces and restores sk->sk_data_ready and sk->sk_write_space on live sockets with plain stores, and xs_udp_do_set_buffer_size() invokes sk->sk_write_space via a plain load. These callback pointers are shared with generic socket and protocol paths that may read or invoke them concurrently, so xprtsock needs the same READ_ONCE()/WRITE_ONCE() callback visibility contract that the validated 4022 family applied elsewhere. When SUNRPC takes over an AF_LOCAL, UDP, or TCP socket and later restores the lower-socket callbacks during teardown, another CPU may still hold an earlier callback snapshot. The plain replace/restore pattern leaves the same visibility hole as the validated 4022 family, so a stale snapshot can still invoke xs_data_ready() or xs_udp_write_space() after the live callback fields have already been restored to the lower-socket handlers. Use WRITE_ONCE() for the shared sk_data_ready and sk_write_space stores in xs_local_finish_connecting(), xs_udp_finish_connecting(), xs_tcp_finish_connecting(), and xs_restore_old_callbacks(). Use READ_ONCE() for the direct sk_write_space invocation in xs_udp_do_set_buffer_size(). This matches the required callback visibility contract while leaving adjacent sk_state_change and sk_error_report handling unchanged.", "cve_priority": "negligible", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89784", "url": "https://ubuntu.com/security/CVE-2026-89784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6 rpcb_register_inet4() and rpcb_register_inet6() store the result of rpc_sockaddr2uaddr() into map->r_addr without checking it for NULL. rpc_sockaddr2uaddr() returns NULL when its final kstrdup() fails, and the unchecked NULL is then carried into the synchronous RPCBPROC_SET encode path: rpcb_register_call() -> rpc_call_sync() -> rpcb_enc_getaddr() -> encode_rpcb_string(), whose first statement is strlen(string), dereferencing NULL and oopsing the kernel. The crash reproduces under failslab on v6.12; with KASAN the NULL dereference surfaces as a fault on the shadow of address zero: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 [#1] PREEMPT SMP KASAN RIP: 0010:strlen (lib/string.c:409) Call Trace: encode_rpcb_string (net/sunrpc/rpcb_clnt.c:890) rpcb_enc_getaddr (net/sunrpc/rpcb_clnt.c:910) rpcauth_wrap_req_encode (net/sunrpc/auth.c:745) call_encode (net/sunrpc/clnt.c:1966) __rpc_execute (net/sunrpc/sched.c:952) rpc_run_task (net/sunrpc/clnt.c:1243) rpc_call_sync (net/sunrpc/clnt.c:1272) rpcb_v4_register (net/sunrpc/rpcb_clnt.c:500) svc_generic_rpcbind_set nfsd_rpcbind_set svc_register svc_setup_socket svc_addsock write_ports nfsctl_transaction_write vfs_write The crash is reachable when an in-kernel RPC service (nfsd, lockd, nfs-callback) registers with the local rpcbind under enough memory pressure for the small GFP_KERNEL kstrdup() in rpc_sockaddr2uaddr() to fail. The asynchronous getport path already handles this exact failure mode by returning -ENOMEM; only the two register helpers omit the check. Mirror that handling: bail out with -ENOMEM when rpc_sockaddr2uaddr() returns NULL, before the address is fed into the encoder.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90240", "url": "https://ubuntu.com/security/CVE-2026-90240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush context cache with correct SID when tearing down aliases domain_context_clear_one() and device_pasid_table_teardown() are both invoked once per DMA alias of a device. Each function locates the context entry using the bus/devfn pair provided by the pci_for_each_dma_alias() callback, then calls intel_context_flush_no_pasid(), which constructs a device-selective context-cache invalidation from info->bus and info->devfn (that is, always the requester ID of the device itself). As a result, for every alias other than the device’s own RID, the context entry that was just cleared in memory is never invalidated in the context cache. Hardware may continue using that stale cached entry. In the scalable-mode teardown path, intel_pasid_free_table() can then free the PASID directory still referenced by that stale entry, allowing the IOMMU to walk freed memory. Fix this by passing the source ID of the entry being torn down to intel_context_flush_no_pasid(), instead of deriving it from @info.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90241", "url": "https://ubuntu.com/security/CVE-2026-90241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Tear down scalable-mode context on probe failure intel_pasid_setup_sm_context() walks a PCI device’s DMA aliases via pci_for_each_dma_alias() and programs a scalable-mode context entry for each RID. For a device with a dma_alias_mask, the callback is invoked once for the device’s own RID and once for each alias bit, all with the same pci_dev, so device_pasid_table_setup() runs for multiple RIDs. pci_for_each_dma_alias() stops at the first callback error. Therefore, a failure partway through the walk can leave context entries for already processed RIDs present and still pointing to the device’s PASID table. On this error path, intel_iommu_probe_device() currently jumps directly to intel_pasid_free_table(), which frees the PASID table without first tearing down those context entries. The IOMMU may then walk a present context entry whose PASID table pointer references freed memory. intel_iommu_release_device() already performs teardown before freeing the table. Apply the same ordering on the probe failure path. device_pasid_table_teardown() safely handles RIDs that were never programmed: iommu_context_addr() returns NULL when no context table has been allocated, and clearing the Present bit of an already non-present entry is a no-op. So unwind is safe for both the alias that failed and any aliases not yet reached.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90243", "url": "https://ubuntu.com/security/CVE-2026-90243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down copied context entry copied_context_tear_down() zeroes the 128-bit context entry with context_clear_entry() while the Present bit is still set, and only then issues the context-cache and IOTLB invalidations. This leaves a window in which hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behaviour or spurious faults. While x86 provides strong write ordering, the compiler may reorder the writes to the two 64-bit halves of the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. There is no cacheline flush before the invalidation either, so on an IOMMU without coherent access to the context table the zeroed entry may not be visible to hardware at the point the invalidation is submitted. Apply the same ownership handshake described in the VT-d spec, Section 6.5.3.3 (\"Guidance to Software for Invalidations\"): clear only the Present bit, flush it out to the IOMMU, perform the invalidations, and only then zero the remainder of the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90244", "url": "https://ubuntu.com/security/CVE-2026-90244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Restore locking around msi_page_list Unlike a group's default domain, which is always freshly allocated and privately owned (iommu_group_alloc_default_domain()), VFIO type1's legacy container merges any newly attached group into an existing domain whenever their iommu_ops and cache-coherency enforcement match. iommu_dma_get_msi_page() only asserts the caller's own group mutex is held (iommu_group_mutex_assert()). On an IOMMU that publishes IOMMU_RESV_SW_MSI, e.g. ARM SMMU, a VM with two such devices assigned through the legacy container can have their guest drivers probe and allocate MSIs in parallel; each host-side VFIO_DEVICE_SET_IRQS lands on a different device fd and group mutex, but both devices' domains are the same merged domain, so both can enter iommu_dma_get_msi_page() concurrently and corrupt msi_page_list. commit 288683c92b1a (\"iommu: Make iommu_dma_prepare_msi() into a generic operation\") dropped the prior msi_prepare_lock on the reasoning that \"each iommu_domain is unique to a group,\" which holds for default domains but not this VFIO type1 case. Restore the static lock, since it's only guarding a corner case and will likely never be contended. iommufd avoids the equivalent problem by having its own callers (iommufd_sw_map_msi()) take a ctx-wide sw_msi_lock before ever reaching the shared list. VFIO type1 can't mirror that since it dispatches to iommu_dma_sw_msi() which is outside VFIO's jurisdiction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90245", "url": "https://ubuntu.com/security/CVE-2026-90245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: kyro: Validate overlay viewport coordinates The overlay viewport end coordinates are computed from the viewport origin and dimensions using 32-bit unsigned arithmetic. Large input values can cause these calculations to wrap around before the resulting coordinates are passed to SetOverlayViewPort(). SetOverlayViewPort() packs the viewport coordinates into 16-bit register fields. The X coordinates are additionally adjusted by +2 and +1 before being written. Validate the coordinate calculations for 32-bit wraparound and ensure that the adjusted coordinates fit within their 16-bit register fields before calling SetOverlayViewPort(). Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90247", "url": "https://ubuntu.com/security/CVE-2026-90247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix mmap_lock leak in irq_work path stack_map_get_build_id_offset() introduced a per-CPU irq_work to defer mmap_read_unlock() from NMI context, and bpf_find_vma() later reused the same mmap_unlock_work. Both callers only check whether the work is busy before taking mmap_lock, so a nested caller can reuse the slot before the first caller queues it. Two read locks may then be acquired while only one deferred unlock runs, leaking a read lock and blocking exit_mmap(). Reserve the per-CPU slot before mmap_read_trylock(). Use the same wrapper in stackmap and bpf_find_vma() so both callers release the reservation on trylock failure. Keep rejecting the slot while the irq_work remains busy. Release it after the irq_work callback unlocks the mm.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90248", "url": "https://ubuntu.com/security/CVE-2026-90248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: fix teardown of an adopted proto on insert-race loss In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER. Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly: - TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy) Both errout reactions are single expressions derived from the state. This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race. [1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90249", "url": "https://ubuntu.com/security/CVE-2026-90249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes The IIO core does not filter duplicate writes to the event enable attribute, so writing the same value twice invokes write_event_config() twice. Enabling twice leaks a runtime PM reference, preventing the device from ever suspending again; disabling twice underflows the usage count and triggers a \"Runtime PM usage count underflow\" warning. Bail out early when the requested state matches the current state. While at it, switch to pm_runtime_resume_and_get() so a failed resume is propagated to userspace instead of silently marking the event enabled.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90250", "url": "https://ubuntu.com/security/CVE-2026-90250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, cgroup: Fix storage null-ptr-deref after replacing prog Syzkaller reported a storage null-ptr-deref issue after replacing prog. This occurs in the following scenario: 1. prog A, an empty prog, is attached to a cgrp. 2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the bpf_get_local_storage helper. 3. link_update is called to replace prog A with prog B. The reason is that __cgroup_bpf_replace fails to alloc and assign the required cgrp storage for the incoming replacement prog. Consequently, the new prog inherits an uninit storage, leading to null-ptr-deref panic when kick the new prog. Fix this by rejecting a link update if new_prog's cgroup storage is incompatible with link->prog.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90251", "url": "https://ubuntu.com/security/CVE-2026-90251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MSFT: validate evt_prefix_len against the response length read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: \tif (skb->len < sizeof(*rp)) { \t\tbt_dev_err(hdev, \"MSFT supported features length mismatch\"); \t\tgoto failed; \t} evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so \tmsft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, \t\t\t\t GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes (\"skb->len=11 evt_prefix_len=255\", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with \"MSFT event prefix length mismatch\" and msft->evt_prefix is left unset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90252", "url": "https://ubuntu.com/security/CVE-2026-90252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: free the HCI command when it is cancelled mgmt_hci_cmd_sync() queues the pending command with a NULL destroy callback, so it is only freed if send_hci_cmd_sync() runs. A cancelled entry is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Nothing else reclaims it either: mgmt_pending_new() does not put the command on hdev->mgmt_pending. The leak also pins the socket reference taken by mgmt_pending_new(), so the mgmt socket is never released. Free the command from a destroy callback. The now-empty done label is replaced by a direct return.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90253", "url": "https://ubuntu.com/security/CVE-2026-90253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: free the mesh send cancel command when it is cancelled mesh_send_cancel() queues the pending command with a NULL destroy callback, so it is only freed if send_cancel() runs. A cancelled entry is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Nothing else reclaims it either: mgmt_pending_new() does not put the command on hdev->mgmt_pending. The leak also pins the socket reference taken by mgmt_pending_new(), so the mgmt socket is never released. Free the command from a destroy callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90254", "url": "https://ubuntu.com/security/CVE-2026-90254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: free the advertising instance on the failure and cancel paths adv_timeout_expire() hands a kmalloc()ed instance byte to hci_cmd_sync_queue() with a NULL destroy callback, and only adv_timeout_expire_sync() frees it. That leaks on two paths: - the return value is not checked, and hci_cmd_sync_queue() does not take ownership when it fails (-ENETDOWN, -ENODEV, -ENOMEM); - a cancelled entry is not released, as _hci_cmd_sync_cancel_entry() does not free entry->data when there is no destroy callback. hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Free the buffer from a destroy callback, and in the caller when the entry could not be queued at all.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90255", "url": "https://ubuntu.com/security/CVE-2026-90255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fix the SCO setup context lifetime hci_setup_sync() queues a conn_handle_t with a NULL destroy callback, so the context is only freed if hci_enhanced_setup_sync() actually runs. An entry that is cancelled instead is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. The context also stores a bare hci_conn pointer, so the connection can be freed while the work is queued. The dequeue in hci_conn_del() does not cover it either, as it matches on entry->data == conn and entry->data is the wrapper here. Same problem as commit 2f5d635ad590 (\"Bluetooth: hci_sync: hold conn in hci_connect_acl/le_sync() callbacks\"). Hold the connection and release both from a destroy callback. The submission failure path drops both, since hci_cmd_sync_submit() does not call the destroy callback when it fails to queue.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90257", "url": "https://ubuntu.com/security/CVE-2026-90257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: avoid OOB read of build info string The virtbt_setup_zephyr() sends the Zephyr vendor command 0xfc08 (Read Build Information) and hands the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length. A backend that answers with status only leaves that pointer past the end of the received data, so the walk reads adjacent slab memory until it meets a NUL. Those bytes reach the kernel log and the firmware-info debugfs file. To fix this, print the string with a bounded \"%.*s\" limited to skb->len - 1. A short or unterminated response then prints as much as arrived instead of failing setup. This mirrors commit dd068ef04412 (\"Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()\"), which fixed the identical pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90258", "url": "https://ubuntu.com/security/CVE-2026-90258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: airoha: add missed IRQ resource helpers Without hooking .irq_request_resources, gpiolib cannot set GPIOD_FLAG_USED_AS_IRQ. This breaks pin direction locking and can allow userspace or another driver to reconfigure an active IRQ pin as an output", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90259", "url": "https://ubuntu.com/security/CVE-2026-90259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix a wrong length calculation in qgroup_free_reserved_data() In that function, we round down the start position and round up the ending position. But during the calculation of @len, we use \"round_up(start + len, sectorsize)\", which is the rounded up end position, not the rounded up length. Which results a much larger length, and later we are still using \"start + len\", which is completely incorrect. Fix it by declaring a local @aligned_start and @aligned_len and use them instead.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90260", "url": "https://ubuntu.com/security/CVE-2026-90260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: don't clobber the extent buffer when zeroing it out On a zoned filesystem a freed-but-still-dirty tree block is written out as zeros (EXTENT_BUFFER_ZONED_ZEROOUT) only to keep the zone write pointer advancing. btree_csum_one_bio() implemented this by memzeroing the extent buffer's own folios before submission. That destroys the in-memory buffer while it may still be referenced. In particular btrfs_free_tree_block() can run on it afterwards and reads the header to add a delayed reference; once the header has been zeroed it frees bytenr 0 and corrupts the extent tree (the btrfs_header_bytenr(buf) != 0 ASSERT in btrfs_free_tree_block(), or an \"unable to find ref\" abort). It is flaky and reproduces under fsstress, e.g. generic/461 and generic/013. Write the zeros to disk from the shared zero page instead and leave the extent buffer content untouched, so any later reference - including the delayed reference from btrfs_free_tree_block() - still sees a valid header. end_bbio_meta_write() now clears writeback on the buffer's own folios, as the bio no longer carries them.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90262", "url": "https://ubuntu.com/security/CVE-2026-90262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: retry verity reads for not-uptodate Merkle folios btrfs_read_merkle_tree_page() can find a folio in the mapping that is not uptodate. After taking the folio lock, the current code treats that state as a read error and returns -EIO. That can make a previous transient read failure sticky. If the failed read left a not-uptodate folio in the mapping, later callers find that folio and fail instead of retrying the read. Keep the existing page-cache insertion and locking order, but retry the Merkle item read when a not-uptodate folio is found in the mapping. Also unlock the folio when read_key_bytes() fails so that a later caller can lock it and retry the read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90264", "url": "https://ubuntu.com/security/CVE-2026-90264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: always wait for ordered extents to avoid OE races [BUG] Syzbot reported a bug that there can be conflicting OEs for the same range: BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object alrea[ 179.162726][ T6897] BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object already exists) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ordered-data.c:264! Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026 RIP: 0010:btrfs_alloc_ordered_extent+0x943/0xad0 Call Trace: cow_file_range+0x744/0x12a0 fallback_to_cow+0x5ea/0xa00 run_delalloc_nocow+0x110c/0x17a0 btrfs_run_delalloc_range+0xbe4/0x1c20 writepage_delalloc+0x104d/0x1ba0 btrfs_writepages+0x1667/0x28b0 do_writepages+0x338/0x560 filemap_fdatawrite_range+0x1f2/0x300 btrfs_fdatawrite_range+0x54/0xf0 btrfs_direct_write+0x6a0/0xc30 btrfs_do_write_iter+0x329/0x790 do_iter_readv_writev+0x624/0x8d0 vfs_writev+0x34c/0x990 __se_sys_pwritev2+0x17a/0x2a0 do_syscall_64+0x174/0x580 entry_SYSCALL_64_after_hwframe+0x77/0x7f ---[ end trace 0000000000000000 ]--- [CAUSE] Since commit ff66fe666233 (\"btrfs: fix incorrect buffered IO fallback for append direct writes\"), if the direct IO finished short, we will revert the isize back to the original one, so that append writes can be respected during the buffered fallback. Normally we rely on lock_and_cleanup_extent_if_need() function during buffered writeback to wait for any existing ordered extents. But that ordered extent waiting only happens if the start_pos is inside the isize. Since we have reverted the isize during failed direct IO, we will not wait for any ordered extents. This means we can have a race where the direct IO OE is still in the tree, finished but not yet removed, then we're inserting the OE for the buffered write, causing the above crash. [FIX] Make the OE wait to be unconditional, to handle the reverted isize situation. And since lock_and_cleanup_extent_if_need() now either lock the extents or return -EAGAIN, also remove the branches that handles no-extent-locked cases, and rename it to remove the \"_if_need\" suffix. The following micro benchmark shows the runtime difference for btrfs_buffered_write(), doing `xfs_io -f -c \"pwrite 0 1m\"` workload, all values are the average runtime in nano seconds. function runtime | before | after -----------------------------------+-------------+--------------- lock_and_cleanup_extent_if_need() | 58.2 | 183.0 btrfs_buffered_write() | 2115.6 | 2973.3 The overall runtime of btrfs_buffered_write() is still pretty tiny (still less than 3 micro seconds), I'd say the extra cost is still acceptable. An alternative to fix this problem is to wait ordered extents during iomap_end() where the isize revert is done. But that solution will break nowait requirement, as if a nowait direct IO finished short, we have to wait for the OEs unconditionally or the next append buffered IO can still hit the same problem. So here we have to move the wait cost to buffered write, but at least the code is slightly more streamline.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90265", "url": "https://ubuntu.com/security/CVE-2026-90265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: defrag: fix deadlock between defrag and delalloc space reservation While running fsstress with autodefrag and flushoncommit, hit a deadlock due to the fact that defrag reserves delalloc space while it's holding dirty and locked folios, besides the extent range lock. The stack traces are the following: [958.624] task:kworker/u50:3 state:D stack:0 pid:20365 tgid:20365 ppid:2 task_flags:0x4208060 flags:0x00080000 [958.626] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs] [958.627] Call Trace: [958.628] [958.628] __schedule+0x4be/0x10f0 [958.629] ? preempt_count_add+0x69/0xa0 [958.630] schedule+0x26/0xd0 [958.631] wait_current_trans+0x102/0x160 [btrfs] [958.632] ? __pfx_autoremove_wake_function+0x10/0x10 [958.633] start_transaction+0x374/0x900 [btrfs] [958.634] btrfs_commit_current_transaction+0x1d/0x70 [btrfs] [958.635] flush_space+0xca/0x5e0 [btrfs] [958.636] ? _raw_spin_unlock+0x15/0x30 [958.637] ? btrfs_reduce_alloc_profile+0x8c/0x190 [btrfs] [958.639] ? _raw_spin_unlock+0x15/0x30 [958.640] ? calc_available_free_space.isra.0+0x6f/0x110 [btrfs] [958.641] do_async_reclaim_metadata_space+0x84/0x190 [btrfs] [958.642] btrfs_async_reclaim_metadata_space+0x64/0x80 [btrfs] [958.644] process_one_work+0x19d/0x3a0 [958.644] worker_thread+0x1c4/0x330 [958.645] ? __pfx_worker_thread+0x10/0x10 [958.646] kthread+0xfc/0x130 [958.647] ? __pfx_kthread+0x10/0x10 [958.648] ret_from_fork+0x1f7/0x2c0 [958.648] ? __pfx_kthread+0x10/0x10 [958.649] ret_from_fork_asm+0x1a/0x30 [958.650] [958.651] task:kworker/u49:7 state:D stack:0 pid:52990 tgid:52990 ppid:2 task_flags:0x4208060 flags:0x00080000 [958.653] Workqueue: writeback wb_workfn (flush-btrfs-334) [958.655] Call Trace: [958.655] [958.656] __schedule+0x4be/0x10f0 [958.657] ? __blk_flush_plug+0xe9/0x140 [958.658] schedule+0x26/0xd0 [958.658] io_schedule+0x42/0x70 [958.659] folio_wait_bit_common+0x12b/0x330 [958.660] ? folio_wait_bit_common+0x100/0x330 [958.662] ? __pfx_wake_page_function+0x10/0x10 [958.663] extent_write_cache_pages+0x599/0x830 [btrfs] [958.664] ? acpi_fwnode_get_reference_args+0x1fa/0x270 [958.665] btrfs_writepages+0x77/0x130 [btrfs] [958.666] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] [958.667] do_writepages+0xc6/0x160 [958.668] __writeback_single_inode+0x42/0x310 [958.669] writeback_sb_inodes+0x231/0x570 [958.670] wb_writeback+0x8a/0x340 [958.671] wb_workfn+0xbf/0x450 [958.672] ? finish_task_switch.isra.0+0xc1/0x350 [958.673] process_one_work+0x19d/0x3a0 [958.673] worker_thread+0x1c4/0x330 [958.674] ? __pfx_worker_thread+0x10/0x10 [958.675] kthread+0xfc/0x130 [958.676] ? __pfx_kthread+0x10/0x10 [958.676] ret_from_fork+0x1f7/0x2c0 [958.677] ? __pfx_kthread+0x10/0x10 [958.678] ret_from_fork_asm+0x1a/0x30 [958.679] [958.679] task:btrfs-cleaner state:D stack:0 pid:296750 tgid:296750 ppid:2 task_flags:0x208040 flags:0x00080000 [958.681] Call Trace: [958.682] [958.682] __schedule+0x4be/0x10f0 [958.683] schedule+0x26/0xd0 [958.684] handle_reserve_ticket+0x1b9/0x2c0 [btrfs] [958.685] ? __pfx_autoremove_wake_function+0x10/0x10 [958.686] reserve_bytes+0x283/0x4c0 [btrfs] [958.687] btrfs_reserve_metadata_bytes+0x18/0xb0 [btrfs] [958.688] btrfs_delalloc_reserve_metadata+0x121/0x320 [btrfs] [958.690] btrfs_delalloc_reserve_space+0x46/0xb0 [btrfs] [958.691] btrfs_defrag_file+0x903/0x1110 [btrfs] [958.692] btrfs_run_defrag_inodes+0x334/0x430 [btrfs] [958.694] cleaner_kthread+0x97/0x1c0 [btrfs] [958.694] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] [958.696] kthread+0xfc/0x130 [958.696] ? __pfx_kthread+0x10/0x10 [958.697] ret_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90269", "url": "https://ubuntu.com/security/CVE-2026-90269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject load-acquire from pointers requiring fault protection A BPF_LOAD_ACQ is not rewritten to a BPF_PROBE_MEM load by the verifier, unlike a regular BPF_LDX, so the JIT emits a plain load with no exception table entry and a fault panics the kernel instead of being handled. Reject the source pointer types that a BPF_LDX would have had that fault protection applied to, i.e. the ones bpf_convert_ctx_accesses() turns into BPF_PROBE_MEM: a bare PTR_TO_BTF_ID, PTR_TO_BTF_ID | PTR_UNTRUSTED, PTR_TO_BTF_ID | MEM_ALLOC | PTR_UNTRUSTED and PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED. This is reachable e.g. by loading ->mm out of a trusted task_struct yields an untrusted pointer to mm_struct, and it is NULL for a kernel thread: [...] SEC(\"tp_btf/sched_switch\") int BPF_PROG(demo, bool preempt, struct task_struct *prev, struct task_struct *next) { struct mm_struct *mm = next->mm; /* untrusted */ out_ldx = (__u64)mm->pgd; /* BPF_LDX */ out_acq = load_acquire(&mm->pgd); /* BPF_LOAD_ACQ */ return 0; } [...] Both dereference the same pointer, but only the BPF_LDX is protected (x86-64 JIT, jump targets shown prog-relative): [...] ; out_ldx = (__u64)mm->pgd; 17: movq $-10485760, %r10 1e: movq %rsi, %r11 21: addq $184, %r11 28: subq %r10, %r11 2b: movabsq $140737498841088, %r10 35: cmpq %r10, %r11 38: ja 0x3e <-- kernel addr? 3a: xorl %edi, %edi <-- no: dst = 0, skip the load 3c: jmp 0x45 3e: movq 184(%rsi), %rdi <-- yes: load + extable entry [...] ; load_acquire(&mm->pgd) 53:\tmovq %rsi, %rdi 56:\tmovq 184(%rdi), %rax <-- no check, no extable entry [...] Note that BPF_PROBE_MEM is not visible in a bpftool xlated dump, as bpf_insn_prepare_dump() rewrites it back to BPF_MEM. A PTR_TRUSTED pointer is deliberately not on the list. Such a load is not converted either, but it does not need to be, since the pointer is guaranteed live, so load-acquire from it stays allowed. The check is gated on BPF_LOAD_ACQ so that atomic RMW and store-release error messages are unchanged; writes (RMW / store-release) to such pointers are already rejected elsewhere, so only load-acquire needs this.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90272", "url": "https://ubuntu.com/security/CVE-2026-90272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: arm_pmuv3: Zero initialize hw_id branch stack field PERF_SAMPLE_BRANCH_HW_INDEX is supported by BRBE so hw_id is passed to userspace, but it's never set by the BRBE driver. Zero initialize it as it should be according to the docs: * For the architectures whose raw branch records are * already stored in age order, the hw_idx should be 0. It's probably too risky to remove PERF_SAMPLE_BRANCH_HW_INDEX from BRBE now in case anyone is setting it and reading the value, but zero initializing the whole struct also protects against the same issue with new fields that are added in the future.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90274", "url": "https://ubuntu.com/security/CVE-2026-90274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: etm4x: fix underflow for usage of (nrseqstate - 1) According to IHI006H Embedded Trace Macrocell Architecture Specification[0], TRCSEQEVR is implemented only when TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2; otherwise, TRCIDR5.NUMSEQSTATE is 0b000. IOW, the number of usage in the initialisation or setting TRCSEQEVR with drvdata->nrseqstate - 1 in the loop could make underflow issue when TRCIDR5.NUMSEQSTATE is 0b000. Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate. As part of this introduce ETM_MAX_SEQ_TRANSITIONS macro and apply nr_seq_ctrls and above macro to TRCSEQEVR relevant fields setup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90275", "url": "https://ubuntu.com/security/CVE-2026-90275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid1: don't set array_frozen in raid1_takeover() raid1_takeover() sets conf->array_frozen = 1 on the newly-allocated r1conf and nothing ever clears it, so every I/O to the array stalls permanently once _wait_barrier() sees it stuck at 1. This used to be harmless: level_store() called mddev_resume() right after pers->run(), which called raid1_quiesce(mddev, 0) and cleared array_frozen back to 0 regardless of what raid1_takeover() set. Commit b39f35ebe86d (\"md: don't quiesce in mddev_suspend()\") removed that quiesce(mddev, 0) call, so the pre-set now sticks. setup_conf() already zero-initializes the new r1conf via kzalloc, so just don't set array_frozen here. Same class of bug as commit 892da88d1cd9 (\"md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()\"), also triggered by b39f35ebe86d.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90276", "url": "https://ubuntu.com/security/CVE-2026-90276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: stop daemon timer rearm on destroy llbitmap_destroy() deletes pending_timer before flushing md_llbitmap_io_wq. However, daemon_work can still be queued or running after the timer has been deleted, and the daemon path can arm pending_timer again when it finds dirty chunks that are not ready to flush yet. If that happens during teardown, pending_timer can remain armed after llbitmap is freed and later dereference freed memory. Add a BITMAP_SHUTDOWN bit to llbitmap->flags, set it before deleting the timer, and make the timer and daemon paths stop queueing or rearming work once teardown starts. Cancel daemon_work before flushing the shared workqueue so no already queued daemon instance can race with the free. Use timer_shutdown_sync() so a daemon instance that passed the shutdown check before teardown cannot rearm the timer afterward. BITMAP_SHUTDOWN is a runtime-only state. Mask it out when reading and updating the llbitmap superblock so the shutdown state is never loaded from disk or persisted to disk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90277", "url": "https://ubuntu.com/security/CVE-2026-90277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: prevent create failure bitmap UAF llbitmap_create() publishes mddev->bitmap before reading the bitmap superblock. This is needed because llbitmap_read_sb() can initialize a new bitmap and flush it through helpers that use mddev->bitmap. If llbitmap_read_sb() fails, the old cleanup dropped bitmap_info.mutex and freed llbitmap before clearing mddev->bitmap. Readers such as /proc/mdstat rely on bitmap_info.mutex to keep the bitmap pointer stable while collecting bitmap stats, so they could observe the stale pointer after the failed create path released the mutex. Clear mddev->bitmap while still holding bitmap_info.mutex, then free the failed llbitmap after dropping the mutex. This makes mutex-protected readers see either a live bitmap or no bitmap.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90278", "url": "https://ubuntu.com/security/CVE-2026-90278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: wait for behind writes before destroying bitmap __md_stop() destroyed the bitmap before calling mddev_detach(). That made mddev_detach() skip bitmap_ops->wait_behind_writes(), because the bitmap was already disconnected from mddev. This was still safe for the legacy bitmap because bitmap_destroy() waits for behind writes itself. llbitmap keeps that wait in its ->wait_behind_writes() operation instead, while ->destroy() tears down the llbitmap storage. With the old ordering, RAID1 behind-write completions could still run after llbitmap storage had been freed. Call mddev_detach() before md_bitmap_destroy() so the common detach path can wait for behind writes while the bitmap is still alive. Only destroy the bitmap after those users are gone.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90279", "url": "https://ubuntu.com/security/CVE-2026-90279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: round bitmap stripes with sector division raid5_bitmap_sector_map() aligns the array range to full RAID5 stripe widths before converting it to component sectors. That width is chunk_sectors multiplied by the number of data disks, and it is not always a power of two. Reproduce with a 4-disk RAID5, 1024-sector chunks, and three data disks. The full-stripe width is 3072 sectors. For a one-sector write at array sector 3072, correct rounding gives array range [3072, 6144), which maps to component range [1024, 2048). The old round_down()/round_up() logic instead gives [1024, 4096), which maps to [0, 1024). Use sector_div() based arithmetic so the rounded range is aligned to the actual RAID5 stripe width. The deterministic mapper test now reports the fixed component range as [1024, 2048), while the old mask-based range was [0, 1024).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90280", "url": "https://ubuntu.com/security/CVE-2026-90280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: Fix possible NULL-deref on early runtime suspend There is a small window where the runtime suspend callback may run after pm_runtime_enable() and before pm_runtime_forbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: `if (!qmp->phy->init_count) {` This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized. Similarly to other qcom phy drivers, introduce a qmp->phy_initialized variable that can be used to avoid relying on the possibly uninitialized phy pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90281", "url": "https://ubuntu.com/security/CVE-2026-90281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend Runtime PM must be enabled before creating the PHY, since phy_create() only enables runtime PM on the PHY device if it is already enabled on this parent device. However, the runtime PM callbacks dereference the hsphy instance, which is not yet ready, leaving a window where a suspend callback may trigger a NULL pointer dereference. Take a runtime PM usage reference with pm_runtime_get_noresume() before enabling runtime PM and release it once the PHY has been created, so that no runtime suspend can run before the PHY is ready. This also prevents a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90282", "url": "https://ubuntu.com/security/CVE-2026-90282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend There is a small window where the runtime suspend callback may run after pm_runtime_enable() and before pm_runtime_forbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: `if (!qmp->phy->init_count) {` This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized. Similarly to other qcom phy drivers, introduce a qmp->phy_initialized variable that can be used to avoid relying on the possibly uninitialized phy pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90283", "url": "https://ubuntu.com/security/CVE-2026-90283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: release subpool on fill_super failure hugetlbfs_fill_super() allocates a hugepage subpool when size or min_size mount options are specified. hugepage_new_subpool() may also reserve huge pages for min_size. If root dentry creation fails after the subpool is created, the failure path frees the subpool with kfree(). This bypasses hugepage_put_subpool() and can leave min_size reservations charged. Use hugepage_put_subpool() on the failure path, matching the normal put_super path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90284", "url": "https://ubuntu.com/security/CVE-2026-90284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: do not queue completed sysfs fallback requests fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to pending_fw_head. device_add() publishes the fallback loading interface, so a userspace helper which discovers the device by scanning sysfs can write 0 to the loading attribute and complete the request before it is queued as pending. In that interleaving firmware_loading_store() calls fw_state_done() while pending_list still points to itself, so it cannot remove an entry from pending_fw_head. The subsequent unconditional list_add() then queues an already-completed fw_priv. Once the request is released, pending_fw_head can retain a pointer to freed memory and the next fallback request can fault while validating the list. Only in-flight fallback requests need suspend or reboot abort handling. If the request is already DONE after device_add(), return success from the fallback path without sending another uevent, waiting again, or queueing it as pending. This preserves the invariant that pending_fw_head contains only active fallback requests.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90285", "url": "https://ubuntu.com/security/CVE-2026-90285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path qla2x00_sysfs_read_vpd() called ha->isp_ops->read_optrom() a second time after releasing optrom_mutex. The repeated read is redundant and, unlike the first, runs without optrom_mutex held, exposing flash access to concurrent optrom operations. Drop the duplicate call.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90286", "url": "https://ubuntu.com/security/CVE-2026-90286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx6: Use PFP on the compute queues too On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.) This means that we have to take into consideration that the PFP also exists on compute queues on GFX6: Use PFP for register writes on both graphics and compute queues. In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission. After a VM flush, emit PFP_SYNC_ME on compute queues as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90287", "url": "https://ubuntu.com/security/CVE-2026-90287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: sunplus: fix error handling in sp_uphy_init() Fix the error paths of sp_uphy_init() to undo exactly what each stage did: return directly if clk_prepare_enable() fails, release only the clock if reset_control_deassert() fails, and jump to err_reset if update_disc_vol() fails so the clock and reset are not leaked.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90290", "url": "https://ubuntu.com/security/CVE-2026-90290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Restore DAIF state on error Sashiko AI has reported that if swsusp_mte_save_tags() for some reason fails we return from swsusp_arch_suspend() with DAIF being masked - that is not what we'd expect. Restore the saved DAIF state before returning from the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90291", "url": "https://ubuntu.com/security/CVE-2026-90291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: module/dups: Fix use-after-free in kmod_dup_req lifetime handling The kmod dups code uses RCU to ensure that a kmod_dup_req instance is freed only after it is no longer referenced. When releasing an instance, the kmod_dup_request_delete() function removes the kmod_dup_req from the dup_kmod_reqs list, waits via synchronize_rcu() and finally frees it. However, this doesn't work correctly because parallel users referencing the instance in kmod_dup_request_exists_wait() don't enter an RCU read-side critical section. This can result in a use-after-free. The kmod_dup_request_exists_wait() function may need to hold a valid reference to a kmod_dup_req instance across a blocking wait until the corresponding modprobe command completes. This makes it unsuitable for RCU. Fix the issue by changing the lifecycle management of kmod_dup_req to use reference counting.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90292", "url": "https://ubuntu.com/security/CVE-2026-90292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix use-after-free in siw_accept() siw_accept() looks up the QP supplied by userspace. If that QP is already in RTS, the function jumps to error cleanup before associating the incoming CEP with it. The cleanup tests whether qp->cep is non-NULL and assumes the current call installed the association. However, qp->cep can point to the CEP of an existing connection. The cleanup then drops a reference from the incoming cep, not qp->cep. Once the incoming endpoint loses its remaining references, this can free it before the subsequent cep->qp store, causing a use-after-free. It also clears the existing QP association. Only release the association reference when qp->cep is the incoming CEP. This preserves an existing association and avoids accessing the freed endpoint.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90293", "url": "https://ubuntu.com/security/CVE-2026-90293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: post the full-feature receive buffers after session registration isert_put_login_tx() posts the full-feature receive buffers before __transport_register_session() runs, so an initiator that does not wait for the final Login Response can still have a SCSI command executed against an se_session whose se_tpg is NULL - the same oops as the previous patch, at target_submit+0xbe. Post them from isert_get_rx_pdu(), which the previous patch already uses to send that response, and post them before that send: the receive queue is filled at the moment the initiator is told it may use it. Allocating there keeps the existing property that a memory allocation failure cannot happen once the final Login Response is on the wire. The receive queue is already empty between the final Login Request and isert_post_recvm(); this moves the second point later, from a median of 92 us to 172 us over 1200 logins. Only an initiator that sends before it has been told to can reach that window, and on IB and RoCE its send is retried there until the buffers appear - isert_rdma_accept() asks for rnr_retry_count = 7. iWARP has no RNR flow control, so there the same send terminates the connection instead. Measured over rxe, 400 login cycles per run, with an initiator that does not wait: an instrumented build counted no entries to isert_recv_done() before the buffers are posted in 10 runs, where that initiator oopsed 8 of 10 unpatched runs and 5 of 10 with only the previous patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90294", "url": "https://ubuntu.com/security/CVE-2026-90294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: delay the final Login Response until the session is registered isert_put_login_tx() puts the final Login Response on the wire before __transport_register_session(), which iscsi_post_login_handler() reaches only after iscsi_target_do_login() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses on the NULL dereference. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ib-comp-wq ib_cq_poll_work RIP: 0010:target_submit+0xbe/0x390 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363 RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078 RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52 R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000 R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044 FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? __pfx__raw_spin_lock_bh+0x10/0x10 ? __pfx_target_submit+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ? __pfx_isert_recv_done+0x10/0x10 ? rxe_poll_cq+0x253/0x3d0 ? finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Delay the final Login Response instead. isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn->rx_login_comp, completed by iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP and cxgbit already take PDUs from that thread, isert alone does not. The buffers are still posted first, so the initiator's first command does not meet an empty receive queue and nothing depends on RNR flow control, and the header and payload live in isert_conn, not in the struct iscsi_login that iscsi_target_nego_release() frees first. Over rxe, 400 login cycles per run, the oops appeared in 10 of 20 unpatched runs and in none of 20 runs with this patch. An initiator that never waits is handled by the next patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90295", "url": "https://ubuntu.com/security/CVE-2026-90295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix out-of-bounds write when probed more than once imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: \timx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), \t\t\t\t GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90296", "url": "https://ubuntu.com/security/CVE-2026-90296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix devres accumulation across driver rebind imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev is the CPU device from get_cpu_device(0). That device is never unbound, so its devres list is never released, and imx6q_cpufreq_remove() does not free the array either. Every probe therefore adds an allocation that stays for the lifetime of the system. Allocate against the platform device instead. Its devres is released when the driver is unbound, which is exactly the lifetime the array wants: imx6q_set_target() reads it, and nothing may reach that after cpufreq_unregister_driver(). That makes the array actually go away on unbind, so also clear the file-scope pointer in remove and on the failed-probe path, rather than leave it pointing at memory devres is about to release. Tested by rebinding the driver on qemu's mcimx6ul-evk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90297", "url": "https://ubuntu.com/security/CVE-2026-90297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: crtc: Propagate layer initialization error sun4i_crtc_init() returns plain NULL when layer initialization fails, while all its other error paths return an error pointer. The only caller, sun4i_tcon_bind(), checks the result with IS_ERR() and happily continues with tcon->crtc set to NULL. sun4i_rgb_init() and sun4i_lvds_init() then dereference it in drm_crtc_mask(), which oopses. Return the error pointer instead.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90298", "url": "https://ubuntu.com/security/CVE-2026-90298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: tcon: Drop TCON TOP device reference of_find_device_by_node() takes a device reference. Drop it after mux configuration succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90302", "url": "https://ubuntu.com/security/CVE-2026-90302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: synchronize heartbeat callbacks with o2net teardown Patch series \"ocfs2: harden heartbeat teardown races\". This series fixes two OCFS2 heartbeat/o2net teardown races found by KASAN. This patch (of 2): Heartbeat callbacks stay registered while configfs local-node teardown enters o2net_stop_listening(). A node-down event can still run through o2net_disconnect_node() and o2net_set_nn_state() while teardown is destroying o2net_wq, so the later queue/flush operations can hit a dead workqueue. KASAN has caught this as a slab-use-after-free in __queue_work() with the call chain: KASAN slab-use-after-free in __queue_work+0x56/0xa90 Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __queue_work+0x56/0xa90 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __queue_delayed_work+0x58/0x1e0 queue_delayed_work_on+0xb4/0xc0 o2net_set_nn_state+0x467/0x840 o2net_disconnect_node+0x7b/0xe0 o2net_hb_node_down_cb+0x54/0x60 o2hb_run_event_list+0x236/0x2d0 o2hb_check_slot+0xad4/0xbc0 lock_release+0xc8/0x290 o2hb_check_slot+0x9ea/0xbc0 trace_hardirqs_on+0x18/0x130 o2hb_do_disk_heartbeat+0x646/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) __lock_acquire+0x466/0x2260 lockdep_hardirqs_on_prepare+0xea/0x1a0 ktime_get_with_offset+0xe9/0x230 o2hb_thread+0x14e/0x770 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 __switch_to+0x2e9/0x730 ret_from_fork_asm+0x1a/0x30 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x292/0x760 __alloc_workqueue+0x736/0xc60 alloc_workqueue_noprof+0xb1/0x110 o2net_start_listening+0xe5/0x430 o2nm_node_local_store+0x184/0x310 configfs_write_iter+0x18a/0x210 vfs_write+0x469/0x810 ksys_write+0xd2/0x170 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 rcu_core+0x4f4/0x1320 handle_softirqs+0x156/0x660 queue_delayed_work_on o2net_set_nn_state o2net_disconnect_node o2net_hb_node_down_cb o2hb_run_event_list Keep heartbeat callbacks registered so quorum state still tracks node state, but stop them from driving o2net reconnect/disconnect work once local teardown starts. Mark the transport offline before destroying o2net_wq, wait for any in-flight heartbeat callback to finish, and delay bring-up replay until the new local node is published through o2nm_this_node(). The replay also has to stay serialized with heartbeat callback delivery. Otherwise a live-node snapshot can be copied, a real hb_down callback can install -ENOTCONN for a peer, and the stale replay can call o2net_hb_node_up() for that same peer and queue reconnect work even though heartbeat is already down. The buggy scenario involves two paths, with each column showing the order within that path: local-node teardown: heartbeat node-down callback: 1. configfs local-off enters 1. o2hb_run_event_list() invokes o2net_stop_listening(). o2net_hb_node_down_cb(). 2. teardown heads for 2. the callback reaches destroy_workqueue(o2net_wq). o2net_disconnect_node() and o2net_set_nn_state(). 3. teardown destroys and NULLs 3. the callback flushes or queues o2net_wq. work through o2net_wq.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90303", "url": "https://ubuntu.com/security/CVE-2026-90303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults When CONFIG_DEBUG_USER=y, and cmdline \"user_debug=31\" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte(). If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running. Acquire mmap_write_lock() around show_pte() for user faults to fix the contention. For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr < TASK_SIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications. Keep everything unchanged for kernel faults, because the kernel is already in the \"oops\" state, acquiring a lock may risk a deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90306", "url": "https://ubuntu.com/security/CVE-2026-90306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9481/2: breakpoint: CFI breakpoints only on demand This removes the stub hw_breakpoint_cfi_handler() from ARM, making it not steal breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) unless CFI is actively used in the kernel. When not instrumenting with CFI, or when a breakpoint is issued in userspace, we fall through to return 1 from hw_breakpoint_pending() \"unhandled fault\" so userspace can make use of this breakpoint. Tested with LKDTM and this command line: echo CFI_FORWARD_PROTO > /sys/kernel/debug/provoke-crash/DIRECT still works as expected.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90307", "url": "https://ubuntu.com/security/CVE-2026-90307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes nothing to srp_process_cred_req() and srp_process_aer_req(), which read fixed-size fields from the receive buffer without checking that those fields were received. The buffer size is max_ti_iu_len, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent back, so those bytes reach the target. SRP_AER_REQ behaves the same way and also reads req->lun. The leak is 8 bytes per response. max_ti_iu_len also decides which slab cache the buffer comes from. With 8 the buffer is a kmalloc-8 object and the read is entirely outside it: BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8) Without KASAN the returned bytes are whatever is next in the slab. One run returned \".strtab\". rsp->data[3] in srp_process_rsp() has the same problem: only resp_data_len is checked before it is read. Drop a request that is shorter than the structure being parsed, and check byte_len before the tsk_mgmt read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90308", "url": "https://ubuntu.com/security/CVE-2026-90308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: Hold QP references for AE and CM processing AE QP fatal events and iWARP CM paths load QPs from dev->qp_xa and then use or reference them outside the xarray lock. erdma_destroy_qp() can drop the destroy-path reference and free QP resources while such a lookup is in flight. Add erdma_qp_get_by_qpn() to acquire a kref under the xarray lock with kref_get_unless_zero(). Remove the QP from the xarray before dropping the destroy-path reference so no new lookup can acquire it while destruction waits for existing users.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90309", "url": "https://ubuntu.com/security/CVE-2026-90309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: Hold CQ references when processing EQ events EQ handlers look up CQs from dev->cq_xa and invoke CQ completion or error callbacks outside the xarray lock. erdma_destroy_cq() can erase the CQ from the xarray and free its queue buffer and doorbell record while a previously scheduled EQ handler is still using the CQ. Add a CQ refcount and take a reference under the xarray lock with refcount_inc_not_zero(). Remove the CQ from the xarray before dropping the destroy-path reference, then wait for in-flight EQ users before releasing CQ resources.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90312", "url": "https://ubuntu.com/security/CVE-2026-90312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check load-acquire src ptr type before the load check_atomic_load() calls check_load_mem() before atomic_ptr_type_ok(). For a load-acquire that fetches into its own source register (dst_reg == src_reg), check_load_mem() overwrites src_reg's type with the type of the loaded value, so the subsequent atomic_ptr_type_ok() no longer sees the source pointer and fails to reject the disallowed types (ctx, pkt, flow_keys, sock). Since bpf_convert_ctx_accesses() does not rewrite atomic loads, the raw access to the underlying kernel object is left in place. The destination type is taken from the ctx access itself, so a load-acquire of the sk field of struct __sk_buff for example leaves the register typed as PTR_TO_SOCK_COMMON_OR_NULL, which type_is_sk_pointer() does not match either, while it actually holds unconverted struct sk_buff bytes. Once the NULL check has passed this is a type confusion, not just a leak of kernel data. Validate src_reg with check_reg_arg() and check the source pointer type with atomic_ptr_type_ok() before the load again, mirroring check_atomic_rmw(). Out-of-range register numbers are already rejected earlier by check_and_resolve_insns() (commit 503d21ef8eac (\"bpf: Do register range validation early\")), and the only exemption there, is_stack_arg_ldx(), requires BPF_LDX | BPF_MEM | BPF_DW and thus never matches a BPF_ATOMIC insn. atomic_ptr_type_ok() can therefore not dereference register state out of bounds, that is, the out-of-bounds read addressed by the Fixes commit below does not reappear (as proven also via selftest).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90313", "url": "https://ubuntu.com/security/CVE-2026-90313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed A potential invalid storage access issue can occur after replacing a cgroup bpf prog. This occurs in the following scenario: 1. prog1 with storage is attached to a cgroup in multi-attach mode. 2. prog1 is replaced with prog2 using BPF_F_REPLACE in multi-attach mode, but fails midway (e.g. in bpf_trampoline_link_cgroup_shim or update_effective_progs). 3. A new prog3 is attached to the cgroup in multi-attach mode. The reason is that __cgroup_bpf_attach overwrites pl->storage with the new storage prior to attachment completion. When attachment fails midway, the cleanup path calls bpf_cgroup_storages_free(new_storage) to free the newly allocated storage, but fails to restore pl->storage back to old_storage. Consequently, the still-active prog1 holds invalid or dangling storage pointers, leading to an invalid memory access when prog1 executes and calls bpf_get_local_storage. Additionally, original pl->flags and cgrp->bpf.flags[atype] are left unrestored. Fix this by saving old_pl_flags, old_storage, and old_flags prior to the update, and properly restoring all of them in the cleanup path on error.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90314", "url": "https://ubuntu.com/security/CVE-2026-90314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression \"table_sz - offset - sizeof(*hdr)\", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90316", "url": "https://ubuntu.com/security/CVE-2026-90316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/omap: dsi: Do not copy isr table To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90318", "url": "https://ubuntu.com/security/CVE-2026-90318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: release buffer head after rebuilding parent fat_scan_logstart() leaves the matching directory entry's buffer head in sinfo.bh for the caller to release, just like fat_scan(). fat_rebuild_parent() uses the directory entry to rebuild the parent inode for the nostale_ro NFS export path, but does not release sinfo.bh after a successful scan. Release it once fat_build_inode() has consumed the directory entry data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90319", "url": "https://ubuntu.com/security/CVE-2026-90319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: clear mport->net when rio_add_net() fails rio_alloc_net() stores the newly allocated rio_net in mport->net before rio_scan_alloc_net() registers the device. If rio_add_net() fails, rio_scan_alloc_net() drops the device reference with put_device(), which releases the rio_net through the device release callback. However, mport->net is left pointing at the freed object. A later mport unregister path can then dereference the dangling mport->net pointer and may try to free the same rio_net again. Clear mport->net in the rio_add_net() failure path, matching the cleanup done for the destID table allocation failure path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90322", "url": "https://ubuntu.com/security/CVE-2026-90322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2/cluster: keep heartbeat local node stable o2nm_node_local_store() handles local=0 by stopping o2net and setting cl_local_node to O2NM_INVALID_NODE_NUM, but it leaves cl_has_local set. That stale state makes o2nm_this_node() return 255, blocks a later local=1 attempt with -EBUSY, and can feed 255 to heartbeat users that call o2nm_this_node() dynamically. Clearing cl_has_local is required when the local node is reset. But heartbeat threads can still be running at that point. They pin the local node config item at startup, yet o2hb_do_disk_heartbeat() and thread teardown re-read o2nm_this_node() for the local slot and for o2nm_undepend_this_node(). Once local=0 has cleared the live local-node state, those dynamic reads return O2NM_MAX_NODES, which is also the invalid node number 255. Store the local node number in the heartbeat region when the region starts. Use that stable node for heartbeat slot writes/checks, negotiation messages, and the final configfs undepend. Stop the heartbeat loop when the current local node no longer matches the stored node, and clear cl_has_local together with cl_local_node in the local=0 path so nodemanager state matches node removal. Validation reproduced this kernel report: KASAN slab-out-of-bounds in o2hb_do_disk_heartbeat+0x372/0xb30 RIP: 0010:memset+0xf/0x20 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xd0/0x630 o2hb_do_disk_heartbeat+0x372/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x188/0x2f0 kasan_report+0xe4/0x120 o2hb_do_disk_heartbeat+0x5/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) o2hb_thread+0x14e/0x770 kthread_affine_node+0x139/0x180 lockdep_hardirqs_on_prepare+0xda/0x190 trace_hardirqs_on+0x18/0x130 kthread+0x19d/0x1e0 ret_from_fork+0x37a/0x4d0 __switch_to+0x2d5/0x6f0 ret_from_fork_asm+0x1a/0x30", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90324", "url": "https://ubuntu.com/security/CVE-2026-90324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: check import_ubuf() return value import_ubuf() can fail if the address range (provided by the userspace ublk server) is outside the allowed user address space. Return that 0 bytes were copied if import_ubuf() fails rather than passing an uninitialized struct iov_iter to ublk_copy_user_pages().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90325", "url": "https://ubuntu.com/security/CVE-2026-90325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: skip dying blkg in blkcg_activate_policy() When switching IO schedulers on a block device, blkcg_activate_policy() can race with concurrent blkcg deletion, leading to a use-after-free in rcu_accelerate_cbs. T1: T2: blkg_destroy kill(&blkg->refcnt) // blkg->refcnt=1->0 blkg_release // call_rcu(__blkg_release) ... blkg_free_workfn ->pd_free_fn(pd) elv_iosched_store elevator_switch ... iterate blkg list blkg_get(blkg) // blkg->refcnt=0->1 list_del_init(&blkg->q_node) blkg_put(pinned_blkg) // blkg->refcnt=1->0 blkg_release // call_rcu again rcu_accelerate_cbs // uaf Fix this by checking hlist_unhashed(&blkg->blkcg_node) before getting a reference to the blkg. This is the same check used in blkg_destroy() to detect if a blkg has already been destroyed. If the blkg is already unhashed, skip processing it since it's being destroyed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90326", "url": "https://ubuntu.com/security/CVE-2026-90326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix race between policy activation and blkg destruction When switching an IO scheduler on a block device, blkcg_activate_policy() allocates blkg_policy_data (pd) for all blkgs attached to the queue. However, blkcg_activate_policy() may race with concurrent blkcg deletion, leading to use-after-free and memory leak issues. The use-after-free occurs in the following race: T1 (blkcg_activate_policy): - Successfully allocates pd for blkg1 (loop0->queue, blkcgA) - Fails to allocate pd for blkg2 (loop0->queue, blkcgB) - Enters the enomem rollback path to release blkg1 resources T2 (blkcg deletion): - blkcgA is deleted concurrently - blkg1 is freed via blkg_free_workfn() - blkg1->pd is freed T1 (continued): - Rollback path accesses blkg1->pd->online after pd is freed - Triggers use-after-free In addition, blkg_free_workfn() frees pd before removing the blkg from q->blkg_list. This allows blkcg_activate_policy() to allocate a new pd for a blkg that is being destroyed, leaving the newly allocated pd unreachable when the blkg is finally freed. Fix these races by extending blkcg_mutex coverage to serialize blkcg_activate_policy() rollback and blkg destruction, ensuring pd lifecycle is synchronized with blkg list visibility.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90327", "url": "https://ubuntu.com/security/CVE-2026-90327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: do not write beyond optlen in getsockopt pep_getsockopt() clamps the reported length to the caller's buffer with min_t(), but then stores the value with put_user(val, (int __user *) optval), which always writes sizeof(int) bytes. A getsockopt() call with an optlen smaller than sizeof(int) thus reports the clamped length yet writes a full int, one to three bytes past the user buffer. Write the value with copy_to_user() bounded by len, so at most optlen bytes are copied, matching the length reported back to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90328", "url": "https://ubuntu.com/security/CVE-2026-90328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: steam: Reject short reads Steam Controller FEATURE reports encode the size of the message in the message itself. Previously we were trusting that the size reported matched the size we actually read, leading to a potential issue with short reads. Instead, we should actually verify the length of the read.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90329", "url": "https://ubuntu.com/security/CVE-2026-90329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: synchronize input before cleaning up a failed probe hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90333", "url": "https://ubuntu.com/security/CVE-2026-90333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-integrity: replace forgeable discard filler with a keyed sector marker The discard-block check in dm_integrity_rw_tag() treats a stored tag of all 0xf6 bytes (DISCARD_FILLER) as proof a block was discarded and skips HMAC verification. allow_discards is only accepted in dm-integrity's standalone mode. An attacker with raw write access to the backing device, but without the integrity key, can stamp any block with an all-0xf6 tag and have it served as authentic. Add a new \"allow_discards_keyed\" target argument that marks discarded blocks with a keyed checksum of (salt || sector) instead, computed by integrity_discard_checksum().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90334", "url": "https://ubuntu.com/security/CVE-2026-90334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: clear cdev pointer after cdev_add() failure tty_cdev_add() drops the cdev reference when cdev_add() fails, but leaves driver->cdevs[index] pointing to freed memory. tty_unregister_device() later passes that stale pointer to cdev_del(), causing a use-after-free. Clear the slot after dropping the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90338", "url": "https://ubuntu.com/security/CVE-2026-90338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: amba-pl011: keep console clock enabled for atomic writes pl011_console_write_atomic() runs from nbcon atomic context, where sleeping is not allowed. It calls clk_enable(), which takes the common-clk enable_lock. Under PREEMPT_RT that is a sleeping lock: clk_enable_lock() first tries spin_trylock_irqsave(), but on contention falls back to spin_lock_irqsave(). Therefore, an atomic-context printk on an RT kernel with a clk-backed pl011 can trip: BUG: sleeping function called from invalid context at spinlock_rt.c:48 __might_resched from rt_spin_lock rt_spin_lock from clk_enable_lock clk_enable_lock from clk_enable clk_enable from pl011_console_write_atomic ... from vprintk_emit This was found and reproduced on PREEMPT_RT. Arm32 and arm64 DT SoCs are affected; arm64 SBSA/ACPI has no clk, so clk_enable(NULL) short-circuits before the lock. In addition, write_atomic() may be invoked from NMI context and is documented to avoid locking. Removing clk_enable() from the callback also avoids a potentially unsafe NMI acquisition of the common-clock enable_lock. An nbcon atomic-capable console must be printable from any context, so the clock cannot be gated between writes. Enable the clock while the console is available for output: use clk_prepare_enable() in pl011_console_setup(), release it via clk_disable_unprepare() in the console .exit() callback, and drop the per-write clk_enable()/clk_disable() pairs from write_atomic() and write_thread(). When printk suspends consoles, drop the reference after uart_suspend_port() stops console access and restore it before uart_resume_port() -- but only if suspend actually marked the port suspended (a wake-capable tty stays running and must keep its clock), and keep it when console_suspend_enabled is false so no_console_suspend works. The active power cost of keeping the clock enabled is platform-dependent: none where the UART clock is a fixed always-on oscillator, real where it is a gateable clock branch, which then cannot be gated (nor possibly can its parent clocks) while the console is available for output. When serial core actually suspends the port, the reference is released so the clock provider can gate the clock tree.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90341", "url": "https://ubuntu.com/security/CVE-2026-90341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: coreboot: Validate table bounds The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table. A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header. Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90343", "url": "https://ubuntu.com/security/CVE-2026-90343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: stop PMSR before P2P and NAN teardown PMSR request teardown must abort active measurements while the wireless_dev is still present in the driver. cfg80211_leave_locked() and cfg80211_stop_pd() already do this before invoking the driver's stop callback, but cfg80211_stop_p2p_device() and cfg80211_stop_nan() do not. Those helpers are also called directly by nl80211, rfkill shutdown, and wireless_dev unregister paths. If one of these paths stops a P2P device or NAN interface with a pending request, it removes the mac80211 subinterface from the driver first. Subsequent request cleanup cannot reach the lower driver's abort callback, but cfg80211 frees the request regardless. Driver state can then retain a stale request and use it when it later reports a result. Call cfg80211_pmsr_wdev_down() before stopping the P2P device or NAN interface. This keeps lower-driver request state and cfg80211 request ownership in sync for all of the helpers' callers.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90344", "url": "https://ubuntu.com/security/CVE-2026-90344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: disconnect on CSA to channel 0 The refactor for the CSA parsing erroneously equates channel zero and no information present, leading it to ignore a CSA on an AP that advertises a switch to that (invalid) channel. This leads to not disconnecting, which we should. For Intel devices, this can lead to a firmware crash. Fix this by using an int type for the channel number as well as the opclass, and using a (negative) value that cannot be encoded in the element to indicate it's not present.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90348", "url": "https://ubuntu.com/security/CVE-2026-90348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90349", "url": "https://ubuntu.com/security/CVE-2026-90349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix out-of-bounds link array access in mt7996_tx() When mac80211 leaves the link unspecified, mt7996_tx() substitutes the primary link id of the station or vif. That value is IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added, and it is then used unchecked to index vif->link_conf[], mvif->mt76.link[] and sta->link[], all of which hold IEEE80211_MLD_MAX_NUM_LINKS (15) entries. Clamp the primary link id to the default link before using it, and use the clamped value for the link_sta fallback as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90350", "url": "https://ubuntu.com/security/CVE-2026-90350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: reject out-of-range link ids in mt76_vif_link() mt76_vif_link() indexes mvif->link[] without validating link_id, but callers pass mvif->deflink_id / msta->deflink_id, which hold IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added. Since IEEE80211_MLD_MAX_NUM_LINKS is 15, that reads one element past the end of the array, aliasing mt76_vif_data.offchannel_link. Reachable via mt7996_set_tsf()/mt7996_offset_tsf() and mt7996_net_fill_forward_path(). Bounds check link_id and return NULL, matching mt7996_sta_link() and mt7996_sta_link_protected().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90351", "url": "https://ubuntu.com/security/CVE-2026-90351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: do not attach hif2 WED when the main WED attach failed If the WED attach for the primary PCIe function fails, the probe path still attached wed_hif2 for the secondary function, leaving the device in an inconsistent half-WED configuration that crashes later. The hif2 call also re-enabled hwrro_mode, which the failed primary attach had just turned off. Skip the hif2 WED setup when the primary WED device is not active.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90352", "url": "https://ubuntu.com/security/CVE-2026-90352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: release hif2 reference on probe IRQ failure The hif2 reference obtained by mt7915_pci_init_hif2() is only released on error paths that key off dev->hif2, which is not assigned until after the IRQ setup. If pci_alloc_irq_vectors() or the primary devm_request_irq() fails, the reference leaks. Drop it explicitly on those paths via mt7915_put_hif2().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90353", "url": "https://ubuntu.com/security/CVE-2026-90353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix ext PHY use-after-free on register error path After mt7915_register_ext_phy() succeeded, a failure of the main PHY mt7915_init_debugfs() or mt7915_coredump_register() unwound through free_phy2, which called ieee80211_free_hw() on the ext PHY hw while it was still registered with mac80211, since mt76_unregister_device() only unregisters the main hw. Unregister the ext PHY (thermal + phy + hw) first and skip the redundant free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90354", "url": "https://ubuntu.com/security/CVE-2026-90354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix double hif2 init on the non-WED path mt7915_pci_init_hif2() was called unconditionally and again inside the WED-inactive branch. The helper increments the global hif_idx, writes the PCIe RECOG_ID register and takes a get_device() reference via mt7915_pci_get_hif2(), while removal only drops one reference. On non-WED dual-hif hardware this double-incremented hif_idx, wrote RECOG_ID twice and leaked a device reference. Only the call inside the WED-inactive branch is correct; drop the unconditional one. hif2 is already initialised to NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90356", "url": "https://ubuntu.com/security/CVE-2026-90356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: free vif links after clearing wcid entries on full reset mt7996_mac_reset_vif_iter() queues non-default vif links for kfree_rcu while dev->wcid[] still holds pointers to the wcid embedded in each freed link; mt76_reset_device() then dereferences those entries and runs mt76_wcid_cleanup() on them. If a grace period elapses in between, the cleanup operates on freed memory. Run mt76_reset_device() first, so the wcid entries are cleaned up and cleared while the links are still valid.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90357", "url": "https://ubuntu.com/security/CVE-2026-90357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: unlink TWT flow if the MCU rejects the agreement The flow is added to dev->twt_list before sending the agreement to the firmware, but the error path leaves it linked while flowid_mask is never set. The flow slot can then be reused and memset while still on the list, corrupting twt_list, and station removal leaves a dangling entry behind that mt7915_mac_twt_sched_list_add() later walks.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90358", "url": "https://ubuntu.com/security/CVE-2026-90358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, x86: Fix trampoline stack size for 128-bit arguments btf_distill_func_proto() accepts a function argument up to 16 bytes, so a 128-bit scalar such as __int128 reaches the x86 trampoline with arg_size == 16. But the current implementation assumes an __int128 argument only needs one register, so the register save area is under-allocated and save_args() overwrites adjacent stack slots. Compute the register count from arg_size for all arguments to fix it.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90360", "url": "https://ubuntu.com/security/CVE-2026-90360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: use system_freezable_wq for init complete work schedule_delayed_work() uses system_wq, which is non-freezable, allowing regulator_init_complete_work to run concurrently with system suspend. This work fires ~30s after boot to disable unused regulators via I2C. When it races with PM suspend, the I2C adapter may already be suspended, triggering a -ESHUTDOWN warning in __i2c_transfer(): WARNING: ... at __i2c_transfer+0x36c/0x3c8 Call trace: __i2c_transfer i2c_transfer regmap_i2c_write _regmap_update_bits regulator_disable_regmap _regulator_do_disable regulator_late_cleanup regulator_init_complete_work_function process_one_work Switch to system_freezable_wq so the work is frozen before any device is suspended, eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90361", "url": "https://ubuntu.com/security/CVE-2026-90361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix leak in ath11k_service_ready_ext_event() Currently, during ath11k_service_ready_ext_event() processing, svc_rdy_ext.mac_phy_caps can be allocated during TLV parsing. This is a temporary allocation that is freed on the success path, but not on the error path. If parsing succeeds far enough to allocate mac_phy_caps and then fails on a later TLV, the allocation leaks. So free the allocation on the error path. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90362", "url": "https://ubuntu.com/security/CVE-2026-90362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Drop dev_pm_opp_set_rate(0) dev_pm_opp_set_rate(0) removes the vote specified in required-opps but does not actually park the clock, making it run without the necessary power backing. Drop the explicit call to it. Every call site of ops->link_clk_disable() is followed by pm_runtime_put(), so the power vote will be rescinded if deemed safe. Patchwork: https://patchwork.freedesktop.org/patch/742783/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90363", "url": "https://ubuntu.com/security/CVE-2026-90363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: don't tear down KMS twice when KMS init fails When priv->kms_init() (mdp4_kms_init() / mdp5_kms_init()) fails partway through, both display drivers already tear their KMS state down via mdp4_destroy() / mdp5_kms_destroy() before returning the error. The common error path in msm_drm_init() then runs msm_drm_uninit() -> msm_drm_kms_uninit(), which tries to destroy the very same KMS a second time, which causes a use-after-free crash. Bring MDP4/MDP5 in line with the DPU driver whose dpu_kms_init() doesn't perform error cleanup on the failure. Let the common path own the cleanup, instead of freeing the KMS from their error paths. The crash trace for the reference: __lock_acquire from lock_acquire (kernel/locking/lockdep.c:5906 kernel/locking/lockdep.c:5863) lock_acquire from touch_wq_lockdep_map (kernel/workqueue.c:4094 (discriminator 1)) touch_wq_lockdep_map from __flush_workqueue (kernel/workqueue.c:4136) __flush_workqueue from msm_drm_kms_uninit (drivers/gpu/drm/msm/msm_kms.c:243 (discriminator 33)) msm_drm_kms_uninit from msm_drm_uninit (drivers/gpu/drm/msm/msm_drv.c:93) msm_drm_uninit from msm_drm_init (drivers/gpu/drm/msm/msm_drv.c:184) msm_drm_init from try_to_bring_up_aggregate_device (drivers/base/component.c:249 drivers/base/component.c:227) try_to_bring_up_aggregate_device from __component_add (drivers/base/component.c:269 drivers/base/component.c:748) __component_add from dsi_host_attach (drivers/gpu/drm/msm/dsi/dsi_host.c:1739) dsi_host_attach from mipi_dsi_attach (drivers/gpu/drm/drm_mipi_dsi.c:383) mipi_dsi_attach from sharp_nt_panel_probe (drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c:247) Patchwork: https://patchwork.freedesktop.org/patch/742068/", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90364", "url": "https://ubuntu.com/security/CVE-2026-90364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Unregister cpufreq notifier on init failure acpi_processor_driver_init() registers the cpufreq policy notifier before registering the ACPI processor driver and setting up CPU hotplug state. If driver_register() or cpuhp_setup_state() fails, the error path only unregisters the ACPI processor driver and the idle driver. The cpufreq notifier remains registered even though initialization failed. Mirror the module exit path on the init failure path and unregister the cpufreq notifier when it has been registered.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90366", "url": "https://ubuntu.com/security/CVE-2026-90366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: reserve space for the CSA-abort countdown TLV When a CSA countdown is active, mt7996_mcu_beacon_cntdwn() emits two bss_bcn_cntdwn_tlv entries (the CSA countdown and the CCA-abort BCC), but MT7996_BEACON_UPDATE_SIZE only reserved one. With MBSSID enabled and a near-maximum beacon template the extra 8 bytes could push the offload command past MT7996_MAX_BSS_OFFLOAD_SIZE and trigger skb_over_panic(). Reserve room for both countdown TLVs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90367", "url": "https://ubuntu.com/security/CVE-2026-90367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: hold dev->mt76.mutex while disabling tx worker in SER mt7996_mac_reset_work() parked the tx worker and disabled the RX/TX NAPIs before taking dev->mt76.mutex. mt76_worker_disable()/_enable() are plain kthread park/unpark, not refcounted, and __mt76_set_channel() toggles the same worker and the MT76_RESET bit under the mutex. An L1 SER racing a channel switch could therefore have the worker unparked and MT76_RESET cleared while the reset path resets the DMA rings, corrupting descriptors or tokens. Take the mutex before disabling the worker, as mt7915 does.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90368", "url": "https://ubuntu.com/security/CVE-2026-90368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: unwind state on add_interface failure When mt76_wcid_alloc() fails, mt7915_add_interface() returned without clearing the vif_mask/omac_mask bits it had already set, without removing the firmware dev info added earlier, and without clearing a monitor_vif pointer to the vif mac80211 is about to free. mac80211 does not call remove_interface() for a failed add, so the indices and firmware dev entry leaked permanently and testmode could dereference the stale monitor_vif. Add a proper error unwind.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90370", "url": "https://ubuntu.com/security/CVE-2026-90370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: bound TLV walk in mt7996_mcu_get_chip_config The response TLV loop advanced by tlv->len without a minimum, so a theoretical firmware response containing a zero-length TLV could spin forever, hanging the CPU during device probe. The u32 payload was also read without bounds checking. Reject a short fixed field, stop on a TLV whose length underruns the header or overruns the skb.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90371", "url": "https://ubuntu.com/security/CVE-2026-90371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix RXDMAD_C buffer recycling race The RXDMAD_C buffers come from the RRO data queues' page pools, which are bound to a different NAPI, so the direct page-pool recycle used here could race the owning NAPI; take the non-direct path as is already done for WED RX queues.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90372", "url": "https://ubuntu.com/security/CVE-2026-90372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss If a peer's VHT/HE MCS map has no supported spatial stream (all fields 0x3), the loop exits with nss == 0 and the function returned (u8)-1 (255), which was then written into the firmware sta_rec_bf beamforming fields. Clamp the result to 0.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90373", "url": "https://ubuntu.com/security/CVE-2026-90373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: clear wcid mask under mutex after RCU pointer clear mt7915_remove_interface() cleared the wcid mask bit with no lock held and before clearing the RCU wcid pointer. The mask is a non-atomic RMW shared with the allocators, which all run under dev->mt76.mutex; on DBDC the two wiphys share one mt76_dev, so this raced add_interface/sta_add on the other band and could leak or double-hand-out a wcid. Clearing the bit before the RCU pointer also let a concurrent allocation reuse the index and publish its wcid, which the subsequent NULL assignment then wiped. Move the clear into the existing mutex section, after the RCU pointer is cleared.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90374", "url": "https://ubuntu.com/security/CVE-2026-90374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: validate RX band_idx before dereferencing phys[] band_idx comes from a 2-bit descriptor field (0-3) and was used directly to index dev->mt76.phys[] (size __MT_MAX_BAND == 3) and dereference the result. A corrupt or reserved descriptor value could index out of bounds or hit a NULL phy on parts with fewer bands. Reject invalid band indices, mirroring mt7996_rx_get_wcid().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90375", "url": "https://ubuntu.com/security/CVE-2026-90375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix non-AQL packet accounting for MLO stations __mt76_tx_queue_skb() overrides the wcid passed by the driver with sta->drv_priv, so the wcid might incorrectly be changed after TX, causing wcid->non_aql_packets to be counted on the wrong wcid. For example, on the AP side, if a station's setup link is the 5G link and the station uses 2G to transmit a frame, the value of non_aql_packets is increased on the 5G wcid but decreased on the 2G wcid. Once the inflated counter exceeds MT_MAX_NON_AQL_PKT, the TX scheduler permanently refuses to service the station. Drop the reassignment and account on the wcid used for transmission. This also records the actual wcid in the queue entry.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90376", "url": "https://ubuntu.com/security/CVE-2026-90376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix MLD ID in MAC TXD and HIF TXP Problem: MCU command timeout while the firmware state is normal, and the firmware keeps showing the error log \"ERROR!! NO PAUSE...\". Root cause: If the MLD_ID field in the TXD is neither the primary link id nor the secondary link id, it may lead to a firmware busy loop when the third link is in power saving mode. Remap frames directed to a third link to the primary link wcid. Since TX status events and txfree completions carry the wcid the firmware saw, use the remapped wcid for packet id tracking and non-AQL packet accounting as well, while the frame keeps its original link context for addressing, band and OMAC selection.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90377", "url": "https://ubuntu.com/security/CVE-2026-90377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix RX data queuing of RRO 3.0 For RRO 3.0, RX data released from a RRO data queue should be put to the indicator queue. The frames are processed and completed in the context of the indicator queue NAPI, which only polls skbs queued on the MT_RXQ_RRO_IND list; frames queued under the data queue id are left sitting on that list until the data queue NAPI happens to run, stalling and reordering RX data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90378", "url": "https://ubuntu.com/security/CVE-2026-90378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt792x: Fix memory leak in SDIO TX path When tx_prepare_skb() returns an error in the SDIO TX path, the skb is not freed, leading to a memory leak. This can occur when zero-length frames (such as WNM NULL frames) are dropped to prevent potential hardware TX hangs. Fix this by properly releasing the skb with ieee80211_tx_status_ext() when tx_prepare_skb() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90379", "url": "https://ubuntu.com/security/CVE-2026-90379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash When an AER error occurs and the bus is hung, the register reads return 0xFFFFFFFF, causing the DMA queue state to be corrupted and resulting in an invalid memory access when accessing q->desc[] or q->entry[]. Unable to handle kernel paging request at virtual address ffffffc01099eac0 pc : mt76_dma_add_buf+0x124/0x188 [mt76] lr : mt76_dma_rx_fill+0x11c/0x1d8 [mt76] sp : ffffffc016d9bbf0 x29: ffffffc016d9bc10 x28: 0000000000000000 x27: 0000000000000000 x26: ffffffb7855e50b8 x25: ffffffb80d04f000 x24: 0000000000000000 x23: 0000000000000ec0 x22: ffffffb796803648 x21: ffffffb796801f80 x20: ffffffb7968035f8 x19: 0000000000000ec0 x18: 0000000000000000 x17: 000000004ec00000 x16: 000000000ec00000 x15: ffffffc01099eac0 x14: 000000004ec00000 x13: 00000000ffc5a000 x12: ffffffc016d9bc32 x11: 00000000ffffffff x10: 0000000000000002 x9 : 0000000000000000 x8 : 000000000000b4ac x7 : 0000000000000a20 x6 : ffffffb6c1806400 x5 : 0000000000000000 x4 : ffffffb80d04f000 x3 : 0000000000000000 x2 : 0000000000000001 x1 : 000000000ec04000 x0 : ffffffb7968035f8 Call trace: mt76_dma_add_buf+0x124/0x188 [mt76 (HASH:1029 4)] mt76_dma_rx_reset+0xe8/0xfc [mt76 (HASH:1029 4)] mt7921_wpdma_reset+0x188/0x1b0 [mt7921e (HASH:ee48 5)] mt7921e_mac_reset+0x128/0x418 [mt7921e (HASH:ee48 5)] mt7921_mac_reset_work+0xac/0x1a8 [mt7921_common (HASH:f721 6)] process_one_work+0x188/0x514 worker_thread+0x12c/0x300 kthread+0x140/0x1fc ret_from_fork+0x10/0x30 Fix the invalid memory access by validating the DMA index read from the hardware before it is used as a queue index. An out-of-range value, such as the 0xFFFFFFFF returned while the bus is hung, is now clamped so it can no longer corrupt q->head or q->tail. In addition, check the bus_hung flag in mt7921_mac_reset_work() before attempting the reset sequence, reject MCU messages while the bus is hung, and install no-op bus operations when an unrecoverable AER error is detected, preventing further invalid hardware accesses. Due to hardware limitations - such as the lack of a connected hardware reset pin or the absence of host re-probe functionality - affected Wi-Fi devices may not fully recover to a normal operational state after certain errors, even with AER enabled.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90382", "url": "https://ubuntu.com/security/CVE-2026-90382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARN_ON_ONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when panic_on_warn is set. Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf (\"mt76x2: remove some harmless WARN_ONs in tx status and rx path\") did for the neighboring rx and tx status paths. Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90383", "url": "https://ubuntu.com/security/CVE-2026-90383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: sgi-gru: remove interrupt-context page-table walks The GRU TLB miss handler walks a process's page tables without holding page-table locks or a reference to the mapped page. It also uses a kernel page-table accessor on user page tables and supports only PMD-level large mappings on x86-64. Remove the direct walker. Send interrupt faults directly to user polling mode so the existing call-OS fallback retries them in process context. Remove the mmap-lock failure statistic that can no longer be incremented.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90385", "url": "https://ubuntu.com/security/CVE-2026-90385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid1: create serial pool adding rdev to array with serialize_policy=1 The following bug has been observed with kernel 7.1.3 after adding a new rdev to an existing RAID1 array with serialize_policy enabled: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 19639 Comm: ext4lazyinit Not tainted 7.1.3-1-default RIP: _raw_spin_lock_irqsave+0x27/0x50 CR2: 0000000000004960 Call Trace: wait_for_serialization+0xb9/0x260 [raid1] raid1_make_request+0x762/0xaff [raid1] md_handle_request+0x1c9/0x2e0 [md_mod] The raid1.c code calls wait_for_serialization() if the MD_SERIALIZE_POLICY is set, and wait_for_serialization assumes that rdev->serial is initialized. Normally this will be the case for arrays that have the serialize_policy sysfs attribute set to 1. But when a new rdev is added to an existing array in bind_rdev_to_array(), the condition at mddev_create_serial_pool() causes creation of rdev->serial to be skipped. Fix it.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90386", "url": "https://ubuntu.com/security/CVE-2026-90386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90387", "url": "https://ubuntu.com/security/CVE-2026-90387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: swiotlb: Preserve allocation virtual address for dynamic pools swiotlb_alloc_tlb() can allocate from the DMA atomic pool when a decrypted pool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP, the atomic pool is backed by remapped virtual addresses, which are not the same as the direct-map addresses returned by phys_to_virt(). swiotlb_init_io_tlb_pool() currently reconstructs the pool virtual address from the physical start address. For atomic-pool backed allocations this stores the wrong address in pool->vaddr. Later, swiotlb_free_tlb() passes that address to dma_free_from_pool(), which will fail to recognize the chunk Pass the virtual address returned by the allocation path into swiotlb_init_io_tlb_pool(), and store that address in pool->vaddr. This keeps the pool free path using the same virtual address as the allocator.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90388", "url": "https://ubuntu.com/security/CVE-2026-90388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Check atomic pool allocation result directly The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90389", "url": "https://ubuntu.com/security/CVE-2026-90389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: scope memalloc_noio to allocation critical sections Storing a memalloc_noio_save() token in mddev->noio_flags lets one task save the token and another task restore it. With concurrent suspend sysfs writes, task A can enter PF_MEMALLOC_NOIO, return to userspace still in that scope, and later task B can restore A's saved token. Avoid tying the token lifetime to mddev. Keep mddev_suspend() and mddev_resume() only responsible for array suspension, and enter PF_MEMALLOC_NOIO only in the MD paths that allocate memory after the array has been suspended. Restore the token before resuming the array. A reproducer repeatedly writes suspend_lo and suspend_hi from concurrent workers and checks each worker's /proc/self/stat flags before and after the sysfs write.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90390", "url": "https://ubuntu.com/security/CVE-2026-90390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/bitmap: resume array on backlog_store() error path backlog_store() suspends the array before checking whether a write-mostly device exists. If no such device exists, the error path only unlocks reconfig_mutex and leaves the array suspended, blocking subsequent I/O. Use mddev_unlock_and_resume() to release both states.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90391", "url": "https://ubuntu.com/security/CVE-2026-90391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone dmirror_fault() is called from the dmirror_read() and dmirror_write() retry loops after dmirror_do_read() or dmirror_do_write() finds a missing device page table entry. If the mirrored mm has already exited, mmget_not_zero() fails. The current code returns 0 in that case, which tells the caller that faulting succeeded even though no page was faulted and no device page table entry was installed. The caller then retries the same address, hits -ENOENT again, and can loop forever without making progress. Return -EFAULT instead, so the ioctl fails when the mirrored mm is no longer faultable.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90392", "url": "https://ubuntu.com/security/CVE-2026-90392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF when reading bpf link info In bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is accessed without holding any locks. If the prog is concurrently replaced via bpf_link_update, the old prog can be freed, leading to a potential UAF issue. Fix this by accessing link->prog under RCU protection to safely fetch the pointer and guarantee its lifetime while reading its fields.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90393", "url": "https://ubuntu.com/security/CVE-2026-90393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF in bpf_netns_link_update_prog In bpf_netns_link_update_prog, the checks for old_prog and prog type are currently performed locklessly before acquiring netns_bpf_mutex. This creates a race condition that can lead to a UAF issue. If two threads concurrently execute BPF_LINK_UPDATE on the same netns link, the following execution path can trigger a UAF: CPU0 CPU1 bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) return -EPERM; bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) ... old_prog = xchg(&link->prog, new_prog); bpf_prog_put(old_prog); if (new_prog->type != link->prog->type) <-- trigger UAF Fix this by moving the old_prog and prog->type checks inside the netns_bpf_mutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90394", "url": "https://ubuntu.com/security/CVE-2026-90394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sc2731_charger: cancel work on remove The USB notifier and initial charger detection can schedule info->work. The remove path unregisters the notifier, but does not cancel queued or running work before the devm-allocated driver data is released. Set the platform drvdata used by remove, then cancel the work after unregistering the notifier. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90395", "url": "https://ubuntu.com/security/CVE-2026-90395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: isp1704_charger: cancel work on remove The USB notifier and initial VBUS detection can schedule isp->work. The remove path unregisters the notifier and power supply, but does not wait for queued or running work before tearing down the power supply state. Cancel the work after unregistering the notifier. Do this before unregistering the power supply. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90396", "url": "https://ubuntu.com/security/CVE-2026-90396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix dio leak on metadata mapping error A failed integrity mapping holds a dio reference, so we need to go through the full bio ending in case there were previously submitted bio's in the sequence.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90397", "url": "https://ubuntu.com/security/CVE-2026-90397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published In qcom_scm_probe(), devm_request_threaded_irq() is called before smp_store_release(&__scm, scm). Two paths can dereference __scm before it is published, both causing a NULL pointer dereference. The IRQ handler receives scm via its data argument but passes only wq_ctx to qcom_scm_waitq_wakeup() and qcom_scm_get_completion(), which then dereference __scm directly. Thread scm through both functions so the IRQ handler path never touches __scm. Non-atomic SMC calls made during probe (e.g. from qcom_tzmem_init via qcom_scm_shm_bridge_enable) can return WAITQ_SLEEP, causing qcom_scm_wait_for_wq_completion() to run before __scm is published and dereference it. Add platform_set_drvdata(pdev, scm) early in probe and change qcom_scm_wait_for_wq_completion() to take the device pointer and use dev_get_drvdata() to reach scm, removing any dependency on __scm.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90398", "url": "https://ubuntu.com/security/CVE-2026-90398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix stride mismatch in mac_phy_caps_parse() Currently, in ath11k_wmi_tlv_mac_phy_caps_parse(), kcalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct wmi_mac_phy_capabilities)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation. The reader in ath11k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride. Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides. Compile tested only.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90399", "url": "https://ubuntu.com/security/CVE-2026-90399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix stride mismatch in mac_phy_caps_parse() Currently, in ath12k_wmi_mac_phy_caps_parse(), kzalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct ath12k_wmi_mac_phy_caps_params)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation. The reader in ath12k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride. Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90400", "url": "https://ubuntu.com/security/CVE-2026-90400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: recheck spare changes before starting sync remove_spares() and remove_and_add_spares() modify the array's rdev configuration. These operations are only safe after the array has been suspended. md_start_sync() checks whether spare configuration changes are needed before taking reconfig_mutex. However, the rdev state can change before the mutex is acquired, so the initial check can become stale. In that case, md_choose_sync_action() may remove or replace rdevs while normal I/O is still accessing them. The race can occur as follows: raid10d Worker Normal IO ____________ _______________________ ______________________ raid10_write_request() wait_blocked_dev() set Blocked set Faulty Skip Faulty rdev rrdev->nr_pending++ .repl_bio = bio removeable_rdev = false . array not suspended . lock mddev goto err_handle lock mddev (wait) . update sb . clear Blocked . . unlock mddev . lock mddev (acquires) remove_spares() removeable_rdev = true raid10_remove_disk() rdev = replacement replacement = NULL rdev_dec_pending(NULL) unlock mddev (NULL)->nr_pending-- In this case, rdev_dec_pending() is called with a NULL pointer, resulting in a NULL pointer dereference when attempting to decrement nr_pending. Fix this by suspending the array when spare configuration changes are needed, including for non-read-write arrays, and checking again after taking reconfig_mutex. If the array was not already suspended and a change is now needed, release the mutex, suspend the array, and reacquire the mutex before continuing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90402", "url": "https://ubuntu.com/security/CVE-2026-90402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Fix controller cleanup on EDL sysfs failure mhi_register_controller() adds the controller device before creating the optional trigger_edl sysfs file. If sysfs_create_file() fails, the error path only drops the device reference and leaves the device registered. Hence, call device_del() in the error path before put_device().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90403", "url": "https://ubuntu.com/security/CVE-2026-90403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix error path in rtl_pci_probe() In the last error path in rtl_pci_probe(), the cleanup functions are skipped due to a wrong goto label. Moreover, the successful call to rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to be reverted. Fix this issue by updating the labels and adding the relevant cleanup functions to the last error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90404", "url": "https://ubuntu.com/security/CVE-2026-90404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_debugfs: Unregister panic notifier cros_ec_debugfs_probe() registers notifier_panic with the EC panic notifier chain. The remove path tears down debugfs and the console log, but leaves the notifier registered. A later panic notification can call back into the removed instance and queue work that accesses released data. Unregister the panic notifier before tearing down the debugfs and console log state. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90406", "url": "https://ubuntu.com/security/CVE-2026-90406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: qcom: iris: handle runtime PM resume failure in core deinit Check the return value of pm_runtime_resume_and_get() in iris_core_deinit(). If runtime PM resume fails, skip hardware power-off operations but still perform software teardown and state transition. Also skip the corresponding pm_runtime_put_sync() call to avoid unbalanced runtime PM references.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90407", "url": "https://ubuntu.com/security/CVE-2026-90407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix overreads in ath11k_wmi_process_csa_switch_count_event() There is no policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, so the parse infrastructure does not enforce a minimum length for the event struct. Additionally, the num_vdevs field is taken directly from firmware and used as a loop bound over the vdev_ids array without checking that it fits within the TLV payload. Either condition can cause an out-of-bounds read. Add a TLV policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT so the parse infrastructure enforces a minimum length for the fixed-size event struct. Add a helper ath11k_wmi_tlv_data_len() to recover the payload length of a parsed TLV from the header preceding its data pointer. Use it in ath11k_wmi_process_csa_switch_count_event() to bound num_vdevs before the loop. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90410", "url": "https://ubuntu.com/security/CVE-2026-90410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: davinci: switch to managed controller allocation The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_threaded_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded davinci_spi devdata, which is the IRQ handler's dev_id. The devm_request_threaded_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach davinci_spi_irq() and dereference already-freed memory. Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns. The clock is acquired with devm_clk_get_enabled(), which is registered after the IRQ and thus released before it by the devres LIFO order. Drain the interrupt explicitly with devm_free_irq() before disabling the controller so that a late interrupt cannot access the registers of a clock-gated controller. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90411", "url": "https://ubuntu.com/security/CVE-2026-90411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request __nvme_fc_init_request() maps cmd_iu and then rsp_iu for DMA. If the rsp_iu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmd_iu unmapped and still marked the op as FCPOP_STATE_IDLE before returning. Since blk-mq does not call .exit_request() when .init_request() fails, the cmd_iu mapping is leaked for every op whose rsp_iu mapping fails. Jump to an error path on rsp_iu mapping failure that unmaps cmd_iu and returns the error without marking the op idle, so it stays in the FCPOP_STATE_UNINIT state set by the initial memset().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90413", "url": "https://ubuntu.com/security/CVE-2026-90413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject login PDUs declaring more data than was received isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(), \tpayload_length = ntoh24(login_req->dlength); \ttmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90414", "url": "https://ubuntu.com/security/CVE-2026-90414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject PDUs declaring more data than was received isert_recv_done() hands each received PDU to the opcode handlers without ever looking at wc->byte_len, the number of bytes the HCA actually placed in the receive descriptor. The handlers then copy that many bytes - the data-segment length the initiator declared in the BHS (ntoh24(hdr->dlength), via the derived unsol_data_len / imm_data_len) - out of the fixed-size descriptor: isert_handle_iscsi_dataout(): sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc), unsol_data_len); isert_handle_scsi_cmd(): sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents, isert_get_data(rx_desc), imm_data_len); Because the declared length is never checked against wc->byte_len, an initiator can declare a data segment larger than the bytes it actually sent (and larger than the descriptor) and cause an out-of-bounds read of the receive buffer. Nothing upstream of isert closes this door: - __iscsit_check_dataout_hdr() bounds the inbound payload against conn_ops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter, used here for the inbound check. - iscsi_set_connection_parameters() sets ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in iscsi_check_acceptor_state(), so the value the initiator declares is adopted verbatim (type range 512..16777215). The initiator effectively raises its own ceiling. - isert never clamps the negotiated value to its own fixed receive descriptor (ISER_RX_SIZE, 9216 bytes), so the target core's bound and the descriptor size are unrelated. The imm_data_len == data_len path is more than an over-read: it aliases the receive descriptor via sg_set_buf() and passes it to the backend as the data source for the SCSI WRITE, so an over-declared length causes heap contents past the descriptor to be written through the backend to the backing store. The backend is the victim of the oversized scatterlist isert hands it, not the cause; no read-back of the written bytes was demonstrated. Trigger: after login completes (full feature phase), an initiator that has declared a large TargetRecvDataSegmentLength and a FirstBurstLength that permits unsolicited/immediate data sends a PDU whose declared data-segment length exceeds what was received. With KASAN: BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ib_cq_poll_work Call Trace: sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 isert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout() (ib_isert.c:1160), inlined through isert_rx_opcode(). Validate wc->byte_len against the framing in isert_recv_done() before the PDU reaches any handler, and reinstate the connection if it is short. Because the test compares without subtracting the header length, it also rejects PDUs shorter than the iSER and iSCSI headers, which would otherwise be parsed out of stale descriptor contents. The login handler rejects PDUs shorter than ISER_HEADERS_LEN (commit 29e7b925ae6d (\"IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN\")) but does not bound the declared length either; that is fixed in the next patch. The data handlers had no length check at all. isert reads the data segment from a fixed offset: isert_get_data() returns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for an AHS. The bytes the handlers touch are therefore exactly [ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum against wc->byte_len bounds precisely the region that is read. An AHS term would only make the test stricter without bounding anything furth ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90415", "url": "https://ubuntu.com/security/CVE-2026-90415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: free STAG index when TPT entry write fails write_tpt_entry() allocates a new STAG index with c4iw_get_resource() and bumps stats.stag.cur before programming the entry. When write_adapter_mem() fails, it returns the error without releasing the index or reversing the statistic. No MR is inserted into rhp->mrs, so deregistration never reclaims it, leaking the index until device teardown. Record whether this call allocated the index and, on a failed write, return it to tpt_table and decrement stats.stag.cur. Key the rollback on both the write error and that flag, not the error alone: a non-reset update carries a caller-owned STAG that this call did not allocate and must not free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90416", "url": "https://ubuntu.com/security/CVE-2026-90416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs get_param() reads a congestion parameter as a u32 but formats it with the signed \"%d\" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as \"-2147483648\\n\" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with \"%u\" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90418", "url": "https://ubuntu.com/security/CVE-2026-90418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix BUG in nilfs_copy_dirty_pages() on dirty state mismatch Syzbot reported a kernel BUG triggered within nilfs_copy_dirty_pages(), which copies dirty DAT file folios/pages to its shadow page cache. The BUG occurs when a retrieved dirty folio/page unexpectedly loses its 'dirty' status. This issue arises because, since the commit referenced below, the 'dirty' flag of a folio/page can be cleared asynchronously after the filesystem detects metadata corruption and transitions to read-only mode. Resolve the issue by returning an -EROFS error if the filesystem has transitioned to read-only mode. Also change the behavior to issue a kernel warning only once instead of triggering a kernel BUG when this unexpected 'dirty' state is detected while the filesystem is not in read-only mode.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90419", "url": "https://ubuntu.com/security/CVE-2026-90419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent out-of-bounds read in super root block parsing super-root inode metadata size is trusted before nilfs_read_inode_common(). Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfs_read_inode_common() read past the end of the super-root block. [ryusuke: clarify the commit title]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90420", "url": "https://ubuntu.com/security/CVE-2026-90420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix infinite loop in nilfs_clean_segments() syzbot reported a hung task in nilfs_transaction_begin(). This occurs because the cleaner ioctl falls into an infinite loop if nilfs_segctor_construct() repeatedly returns -EROFS (e.g. the device is remounted as read-only after an I/O error). Currently in nilfs_clean_segments(), if err is non-zero, it logs the error and sleeps but doesn't abort when it encounters a terminal error like -EROFS. This causes the thread to loop forever. Fix this by breaking out of the loop if nilfs_segctor_construct() returns -EROFS. This matches the behaviour in nilfs_segctor_write_out(), which also handles -EROFS.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90422", "url": "https://ubuntu.com/security/CVE-2026-90422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: pllfh: Fix IO remapping leak in register_pllfhs error path When mtk_clk_register_pllfhs function fails to register a PLL, it unregisters all PLLs and cleans up itself in its error path before returning, so the function callers don't need to do it. But contrary to mtk_clk_unregister_pllfhs function, that does almost the same sequence, it does not free the IO memory mapped on fhctl node, leading to a leak. Fix this leak by factorizing the cleanup sequence in a new private function and use it both mtk_clk_register_pllfhs and mtk_clk_unregister_pllfhs functions. Also, change the loop index start value to avoid the -1 operation on index at each loop.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90423", "url": "https://ubuntu.com/security/CVE-2026-90423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix UAF in ODP init error-handling path rxe_odp_mr_init_user() stores &umem_odp->umem in mr->umem before calling rxe_odp_init_pages(). If rxe_odp_init_pages() fails, rxe_odp_mr_init_user() releases umem_odp and returns an error. rxe_reg_user_mr() then unwinds the error through rxe_cleanup(), rxe_mr_cleanup(), ib_umem_release(mr->umem). There is an IS_ERR_OR_NULL(umem) check at the start of ib_umem_release(). But since mr->umem is NOT reset to NULL in the error handling path of rxe_odp_mr_init_user(), the check passes and it reads already-freed fields like umem->is_dmabuf, causing UAF. Fix the UAF by clearing mr->umem after releasing the failed ODP umem so the MR cleanup path does not release it again.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90424", "url": "https://ubuntu.com/security/CVE-2026-90424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Fix VINTF0 leak on the init-failure path tegra241_cmdqv_init_structures() allocates VINTF0 with kzalloc_obj(), inits it, and preallocates its logical VCMDQs. Two of its error paths leak. When tegra241_cmdqv_init_vintf() fails it returns before VINTF0 reaches the cmdqv->vintfs[] array, so the devres unwind on probe failure cannot reach it; free it directly there. A later VCMDQ preallocation failure instead leaves VINTF0 published, and so this time the unwind does reach tegra241_cmdqv_remove_vintf(), which then frees it from vintf->hyp_own. But tegra241_vintf_hw_init() sets that flag only afterward, from a HW read-back, so the still-uninited VINTF0 reads as guest-owned and leaks, with mutex_destroy() and ida_destroy() run on fields it never set up. Decide ownership from vintf->idx instead, the index assigned when its id is allocated: idx 0 is the kernel-owned VINTF0, while idx >= 1 marks a guest VINTF. So the in-kernel free decision in tegra241_cmdqv_remove_vintf() and tegra241_vintf_free_lvcmdq() now keys on idx too, and hyp_own stays a pure HW-readback state.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90425", "url": "https://ubuntu.com/security/CVE-2026-90425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Require exactly one Stream ID for a vSID tegra241_vintf_init_vsid() maps a guest vSID to a single physical Stream ID taken from master->streams[0], and only warns when the device does not have exactly one stream. A device with several streams gets only its first one mapped, so a guest vSID invalidation cannot reach the others' ATC and IOTLB entries; a device with none makes master->streams a ZERO_SIZE_PTR, read out of bounds. Reject the mapping with -EOPNOTSUPP if master->num_streams is not one.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90426", "url": "https://ubuntu.com/security/CVE-2026-90426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Free the error IRQ before tearing down VINTFs tegra241_cmdqv_remove() tears each VINTF down first, then calls free_irq(). Tearing a VINTF down frees vintf0 and clears cmdqv->vintfs[0]. An error in that window makes tegra241_cmdqv_isr() read the stale slot and hand it to tegra241_vintf0_handle_error(), which dereferences a NULL or freed pointer. Free the IRQ before tearing the VINTFs down. free_irq() waits for in-flight handlers to finish and blocks new ones, so no ISR can observe a VINTF as it is torn down. Note: a user-owned VINTF (viommu) could outlive this teardown, which unmaps cmdqv->base and frees cmdqv->vintfs, so a later viommu close then touches freed memory. This is neither introduced nor fixed here: a physical IOMMU is not a pluggable device, so iommufd by design holds no reference on the one behind a viommu, and this teardown is not expected while that viommu is still alive.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90428", "url": "https://ubuntu.com/security/CVE-2026-90428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Don't run the error ISR before probe sets up vintfs __tegra241_cmdqv_probe() requests the error IRQ before it has allocated the cmdqv->vintfs array and set cmdqv->num_vintfs. A CMDQV left enabled with a latched error across a kexec fires the IRQ as soon as it is requested, and tegra241_cmdqv_isr() then walks the uninitialized cmdqv->vintfs array. Request the IRQ only after cmdqv->vintfs is allocated and zeroed, so that a latched interrupt firing early runs the ISR against a valid array of NULL slots that it safely skips.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90429", "url": "https://ubuntu.com/security/CVE-2026-90429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Synchronize the error ISR against VINTF (de)init A user VINTF is torn down by tegra241_cmdqv_deinit_vintf(), which runs from the destroy callback and from the init-failure unwind in the alloc handler. It clears the cmdqv->vintfs[] slot and lets the iommufd core free it, but nothing serializes that against the error interrupt: tegra241_cmdqv_isr() reads cmdqv->vintfs[idx] and dereferences the vintf. A concurrent error can make the ISR read a slot mid-clear (a NULL deref) or use a vintf which is about to be freed (a use-after-free). deinit_vintf() also returns idx to the IDA before clearing the slot, so a concurrent create that reuses idx can publish its new vintf into the slot, only for this teardown to erase it again with the stale NULL store. On the other end, tegra241_cmdqv_init_vintf() publishes a new vintf with a plain store to the cmdqv->vintfs[] slot, and the ISR dereferences fields of a published vintf such as vintf->base. A plain store gives no ordering on a weakly-ordered CPU, and a stale VINTF_ERR_MAP bit on a reused idx can make the ISR pick a vintf the moment it is published, before its fields are set or tegra241_vintf_hw_init() runs. The cmdqv->vintfs[0] slot stays NULL until tegra241_cmdqv_init_structures() first creates VINTF0, so the slot 0 read needs the same NULL check. Publish every slot with an smp_store_release(), and read each slot in the ISR with an smp_load_acquire() under a NULL check, so the ISR always sees a fully built vintf or NULL. Also make deinit_vintf() clear the slot, and synchronize_irq() prior to returning idx to the IDA, so no vintf is freed under a running handler and no reused idx is clobbered.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90430", "url": "https://ubuntu.com/security/CVE-2026-90430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Publish an LVCMDQ only after it is fully initialized tegra241_vintf_init_lvcmdq() stores the freshly allocated vcmdq pointer to the vintf->lvcmdqs[] array, before tegra241_vcmdq_alloc_smmu_cmdq() builds the vcmdq->cmdq. The error ISR dereferences that cmdq, so a latched LVCMDQ error (e.g. one inherited across a kexec) firing in this window would make tegra241_vintf0_handle_error() pass the still-zeroed arm_smmu_cmdq down to __arm_smmu_cmdq_skip_err(), dereferencing NULL queue register pointers. Drop the store from tegra241_vintf_init_lvcmdq() and publish the vcmdq at the end of the allocation instead, with an smp_store_release() that pairs with an smp_load_acquire() in the ISR, which can see a fully built LVCMDQ or NULL. The user-owned LVCMDQ allocation moves accordingly, publishing the vcmdq once tegra241_vcmdq_hw_init_user() succeeds, using a plain store since a user VINTF's lvcmdqs[] has no lockless reader -- the error ISR only walks the VINTF0 array.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89782", "url": "https://ubuntu.com/security/CVE-2026-89782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject restart table growth beyond U16_MAX entries During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index. alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl(): \trt = init_rsttbl(esize, used + add); used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image. BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90431", "url": "https://ubuntu.com/security/CVE-2026-90431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: Prevent crash handling to race with rproc_del() There's no synchronization between rproc_crash_handler_work() and rproc_del(), as such it's possible for a driver to be removed while crash-handler work is scheduled, or even executing - resulting in use-after-free issues. To avoid this the scheduled work need to be cancelled and synchronized against before the removal proceeds. In order to ensure that this doesn't race with the reporting, and thereby scheduling new work, a \"deleting\" flag is introduced. This is similar to the RPROC_DELETE state that was introduced to ensure that \"start\" didn't race with rproc_del(), but the existing mechanism can not be used as it's valid to call rproc_report_crash() in atomic context - and the \"state\" is protected by a mutex. In the event that work is cancelled the pm_stay_awake() is left unbalanced and need to be unrolled. The blocking and cancelling of crash-handler work prior to the actual rproc_shutdown() call does have the explicit side-effect that crashes resulting from the shutdown process will not enter the crash-handling path, and as such will not generate devcoredumps etc. Due to the existing mutual exclusion between these code paths there's no concrete reduction in functionality, but further work would be needed to handle this case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90433", "url": "https://ubuntu.com/security/CVE-2026-90433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: oc-tiny: switch to managed controller allocation The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded driver-private devdata, which is the IRQ handler's dev_id. The devm_request_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach tiny_spi_irq() and dereference already-freed memory (e.g. hw->base). Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90434", "url": "https://ubuntu.com/security/CVE-2026-90434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: release zisofs block pointer buffer head zisofs_fill_pages() reads the compressed block pointer table. The error paths release the current buffer_head, the loop also releases the old buffer_head when it advances. However, the success path leaves the last buffer_head referenced. Release it before returning success.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90435", "url": "https://ubuntu.com/security/CVE-2026-90435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix integer overflow of user QP buffer size set_user_buf_size() computes the QP buffer size by left-shifting the user-supplied rq.wqe_cnt and rq.wqe_shift values as signed integers. A sufficiently large rq.wqe_cnt causes signed integer overflow, which is undefined behavior, and yields a small or negative buf_size, causing ib_umem_get() to map a buffer smaller than the hardware will actually write into. Replace the shifts and addition with check_shl_overflow() and check_add_overflow(), rejecting invalid user inputs. Moreover, guard the identical shift computing qp->sq.offset in _create_user_qp() before set_user_buf_size() is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92476", "url": "https://ubuntu.com/security/CVE-2026-92476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Initialize completion before requesting IRQ kmb_ocs_aes_probe() requests the device IRQ before initializing irq_completion. Once the handler is registered it can run immediately, and ocs_aes_irq_handler() unconditionally calls complete(). An interrupt in this window would therefore use an uninitialized completion. Initialize the completion before requesting the IRQ, as the sibling OCS HCU and ECC drivers already do.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92477", "url": "https://ubuntu.com/security/CVE-2026-92477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: debugfs: Reserve space for a string terminator ufs_saved_err_write() copies user input into a zero-initialized stack buffer and passes it to kstrtoint(). A write that fills the entire buffer overwrites its only terminator. Reject an input whose length leaves no room for the trailing NUL.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92481", "url": "https://ubuntu.com/security/CVE-2026-92481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: free EINT resources on unbind mtk_eint_do_init() creates an IRQ domain, populates it with a mapping for every EINT line and installs a chained handler on the parent interrupt, but none of these are ever released. This was harmless while the drivers were built-in, but now that they can be built as modules and unbound/rmmod'd it leaves behind a dangling IRQ domain, interrupt mappings whose chip data points at freed memory, and a chained handler that keeps firing into that freed data. The plain allocations in mtk_eint_do_init() already use the device-managed devm_*() helpers, so tear the remaining resources down the same way: register a devm action that detaches the chained handler, waits for any in-flight handler to finish, disposes of the per-line mappings and removes the IRQ domain. This mirrors the device-managed lifecycle adopted for the GPIO chip and keeps the whole EINT setup self-cleaning on unbind.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92484", "url": "https://ubuntu.com/security/CVE-2026-92484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fix use-after-free in find_pos_and_ways() error path The error path releases its reference to a switch decoder before logging an error that includes the decoder name. If the released reference is the last one, the decoder can be freed before the error message accesses its name. Drop the reference after the error is reported.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92486", "url": "https://ubuntu.com/security/CVE-2026-92486", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix CFI mismatch in task work callback BPF subprograms use the bpf_callback_t ABI, but task work invokes the callback through a three-argument function pointer. This trips kCFI. Store and invoke the callback as bpf_callback_t.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89785", "url": "https://ubuntu.com/security/CVE-2026-89785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92488", "url": "https://ubuntu.com/security/CVE-2026-92488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: complete object teardown when the destroy command fails erdma_destroy_qp(), erdma_destroy_cq(), erdma_dereg_mr(), and erdma_destroy_ah() returned early when erdma_post_cmd_wait() failed, leaking the queue buffers, MTTs, doorbells and the STAG, QPN, CQN and AHN identifiers. A command timeout clears ERDMA_CMDQ_STATE_OK_BIT and permanently disables the command queue, so no retry can succeed; the RDMA core keeps the object after a failed destructor and forced uverbs cleanup then nulls the pointers, making the resources unreachable. Warn on failure but release every software-owned resource and return success, since during terminal destruction the hardware command result is only diagnostic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92489", "url": "https://ubuntu.com/security/CVE-2026-92489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix skb double-free in xfrm_dev_direct_output() A return value other than 1 from local_out() means that the skb has been consumed or its ownership was transferred. xfrm_dev_direct_output() nevertheless frees the skb on this path, causing a double-free when netfilter drops the packet and invalidating any other owner. Return the local_out() result directly, matching the ownership handling in xfrm_output_resume().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92490", "url": "https://ubuntu.com/security/CVE-2026-92490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unrequest devices if driver registration fails scmi_driver_register() requests protocol devices before registering the driver. If driver_register() fails, those requests remain in the global IDR and retain pointers to the module's ID table. Once the failed module load releases that storage, later request matching or SCMI device creation can dereference the stale pointers. Unrequest the complete protocol table before returning the registration failure. At this point table registration succeeded, so every entry is owned by the current registration attempt.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92491", "url": "https://ubuntu.com/security/CVE-2026-92491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Roll back partial protocol table registration scmi_protocol_table_register() can leave earlier requests registered when a later entry in the same ID table fails. Each request retains a pointer to the driver's ID table, so a failed module load can leave a dangling pointer after the module storage is released. Unrequest only the successfully registered prefix, in reverse order, before returning the failure. Leave the failed entry and the remaining entries untouched because matching requests can be owned by another driver.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92493", "url": "https://ubuntu.com/security/CVE-2026-92493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate-ut: Skip tests when amd-pstate driver is not active The crash issue may occur when modprobe amd_pstate_ut on intel platform. amd_pstate_ut: 1 amd_pstate_ut_acpi_cpc_valid success! amd_pstate_ut: 2 amd_pstate_ut_check_enabled success! BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 20300 Comm: modprobe Kdump: loaded Tainted: G O 6.6.0-0010.rc1.ctl4.x86_64 #1 Hardware name: FiberHome R2200 V5/Xeon Boards, BIOS 3.1a 02/24/2020 RIP: 0010:amd_pstate_ut_check_perf+0x141/0x280 [amd_pstate_ut] Call Trace: amd_pstate_ut_init+0x1b/0xff0 [amd_pstate_ut] ? __pfx_amd_pstate_ut_init+0x10/0x10 [amd_pstate_ut] do_one_initcall+0x42/0x2e0 ? kmalloc_trace+0x26/0x90 do_init_module+0x60/0x240 __se_sys_init_module+0x185/0x1c0 do_syscall_64+0x62/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e Add state detection to amd pstate driver to prevent amd_pstate_ut driver from testing on non-AMD platforms. (ML: adjust title)", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89787", "url": "https://ubuntu.com/security/CVE-2026-89787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check dir entry fits before reading the hash trailer in ext4_search_dir() For casefolded encrypted directories ext4 stores an 8-byte hash trailer after the name (EXT4_DIRENT_HASHES()), at an offset derived from de->name_len. On the sb_no_casefold_compat_fallback() path ext4_match() reads that trailer, but ext4_search_dir()'s by-hand pre-check only tests de->name + de->name_len <= dlimit, which proves the name fits, not the rounded trailer. A crafted entry whose name ends at the block boundary passes the check while EXT4_DIRENT_HASHES(de) lands past the block end, so ext4_match() reads out of bounds on an ordinary lookup. KASAN reports it as a use-after-free when the page after the directory block holds a freed object: BUG: KASAN: use-after-free in ext4_match (fs/ext4/namei.c:1435) Read of size 4 at addr ffff888010458000 by task exploit Call Trace: ext4_match (fs/ext4/namei.c:1435) ext4_search_dir (fs/ext4/namei.c:1470) __ext4_find_entry (fs/ext4/namei.c:1268 fs/ext4/namei.c:1632) ext4_lookup (fs/ext4/namei.c:1703 fs/ext4/namei.c:1769) ... filename_lookup (fs/namei.c:2842) vfs_statx (fs/stat.c:353) __do_sys_newfstatat (fs/stat.c:538) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Require, for hash-in-dirent directories, that the whole entry including the rounded trailer fits before calling ext4_match(). This is the same bound ext4_check_dir_entry() already enforces via ext4_dir_rec_len(), so no well-formed entry is rejected. The other caller, ext4_find_dest_de(), runs ext4_check_dir_entry() first and is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92494", "url": "https://ubuntu.com/security/CVE-2026-92494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix buffer_head leak in ext4_init_orphan_info ext4_init_orphan_info() reads orphan file blocks with ext4_bread() and stores the returned buffer_head in oi->of_binfo[i].ob_bh. If ext4_bread() succeeds but the orphan block magic or checksum validation fails, the function jumps to out_free. However, the old out_free loop starts releasing buffers from i - 1, so the current buffer_head at index i is skipped. This leaks the buffer_head reference obtained by ext4_bread() on the bad magic and bad checksum error paths. Fix this by tracking the number of successfully read buffer_heads and releasing exactly those buffer_heads on the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92495", "url": "https://ubuntu.com/security/CVE-2026-92495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Clear VM_MAYWRITE on DBR/toggle page mmap bnxt_re_mmap() rejects VM_WRITE for the DBR_PAGE and TOGGLE_PAGE mmap flags, but a read-only mapping can still retain VM_MAYWRITE. nd later be upgraded with mprotect(PROT_WRITE). This can bypass the write check that only runs at mmap time. Clear VM_MAYWRITE before vm_insert_page() in the shared DBR/toggle-page branch, matching the existing policy that userspace writes are not expected for these pages.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92496", "url": "https://ubuntu.com/security/CVE-2026-92496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx() Currently, in ath11k_wmi_tlv_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Add an upfront length check before dereferencing skb->data as a wmi_cmd_hdr. The check is placed before the trace_ath11k_wmi_event() call to preserve the existing trace semantics (tracing the full raw WMI event including the header), unlike the analogous ath12k fix which could use skb_pull_data() directly. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92497", "url": "https://ubuntu.com/security/CVE-2026-92497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Avoid buffer overread in ath12k_wmi_op_rx() Currently, in ath12k_wmi_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Update the logic to verify the buffer contains at least enough data to hold a wmi_cmd_hdr before reading from the buffer. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92498", "url": "https://ubuntu.com/security/CVE-2026-92498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: avoid buffer overreads in WMI event handlers The following WMI event handlers currently read from the event buffer without first verifying that the message was large enough to hold the expected event: ath6kl_wmi_scan_complete_rx() ath6kl_wmi_addba_req_event_rx() ath6kl_wmi_delba_req_event_rx() Add length checks to prevent overread.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92499", "url": "https://ubuntu.com/security/CVE-2026-92499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: validate readdir offset before accessing dirent A corrupted directory can trigger the following KASAN report when ext4_readdir() resumes from an invalid position: BUG: KASAN: use-after-free in __ext4_check_dir_entry+0x5ef/0x820 Read of size 2 at addr ffff88810a646000 by task repro_linear/509 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 kasan_report+0xce/0x100 __ext4_check_dir_entry+0x5ef/0x820 ext4_readdir+0xcde/0x2b70 iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x12b/0x220 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f KASAN reports use-after-free because the out-of-bounds access lands in an adjacent freed page. The directory buffer itself is still referenced. ext4_dir_llseek() invalidates the directory cookie so that ext4_readdir() rescans directory entries from the start of the block. The rescan checks only the lower bound of rec_len before advancing. A corrupted rec_len can therefore place the offset where the block has insufficient space for a complete directory entry. The rescan itself may dereference that truncated entry, or the main loop may pass it to __ext4_check_dir_entry(). The latter reads de->rec_len before validating the range. For example: block offset 0 4092 4096 |---- de1.rec_len = 4092 -----|----| de2.inode | de2.rec_len ^ OOB, reported as UAF de2 starts at offset 4092 in this 4 KiB block. Its four-byte inode fits in the block, but its rec_len starts at offset 4096 and crosses the boundary. The minimum safe length is inode-dependent. Encrypted and casefolded directory entries need eight additional hash bytes, while a valid metadata checksum tail is only 12 bytes. Cache the metadata checksum feature state and derive the minimum directory entry length from the on-disk format. Use it to bound both the rescan and the offset passed to the main loop. Report an offset in a truncated block tail and skip the remainder of the block, while continuing to accept an offset exactly at the block boundary.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92500", "url": "https://ubuntu.com/security/CVE-2026-92500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: use fsdata to track inline data write state and fix race Instead of checking the live inode state (ext4_has_inline_data(inode) and ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) in the write_end handlers, use the fsdata parameter of the address space operations to explicitly pass down the state in which write_begin prepared the write. A concurrent thread (such as ext4_page_mkwrite()) can convert the inline data to an extent between write_begin and write_end. If this happens, the write_end handlers would previously miss the inline write_end path and fall through to extent-based write_end logic. However, since block buffers were never allocated in write_begin, this resulted in NULL pointer dereferences or data loss because folio_buffers(folio) was NULL. Define EXT4_WRITE_DATA_INLINE (4) as a bit flag (Bit 2), treating fsdata as bitwise flags rather than mutually exclusive enums to keep states of the write path independent. Communicate this state via fsdata: 1) ext4_write_begin() and ext4_da_write_begin() set the EXT4_WRITE_DATA_INLINE bit in *fsdata via bitwise OR when an inline write is successfully prepared. 2) On entry, ext4_write_begin() clears the EXT4_WRITE_DATA_INLINE bit to safely handle VFS retries (where generic_perform_write() bypasses the fsdata initialization on its retry jump). 3) The write_end handlers perform a bitwise AND to check if the EXT4_WRITE_DATA_INLINE bit is set and invoke the inline write_end helper accordingly. Furthermore, during a buffered write, ext4_write_inline_data_end() acquires the xattr lock after preparing the write. If a concurrent page fault (ext4_page_mkwrite()) converts the inline data to an extent after the write_end handlers check the state but before ext4_write_inline_data_end() acquires the xattr write lock, the subsequent check will trigger a kernel panic via BUG_ON(!ext4_has_inline_data(inode)). To keep git history working and bisectability clean, replace the BUG_ON check in ext4_write_inline_data_end() with a graceful error- handling retry path in this same commit. If the inline data is cleared after locking the xattr, we safely release all resources (releasing iloc.bh, unlocking/putting the folio, stopping the active journal transaction handle) and return 0 (VFS retry) to let the generic write path retry the operation safely.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92501", "url": "https://ubuntu.com/security/CVE-2026-92501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drain in-flight DIO before buffered write fallback generic/746 started failing intermittently on ext3 (no-extent inodes). The test triggers 'Page cache invalidation failure on direct I/O' warnings and subsequent fsync returns -EIO. Adding a 50ms delay between ext4_buffered_write_iter() and filemap_write_and_wait_range() in ext4_dio_write_iter() makes the race almost always reproducible. On no-extent inodes, DIO writes to holes cannot use unwritten extents, so ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0. The iomap layer then returns -ENOTBLK, causing fallback to buffered I/O. The fallback path in ext4_dio_write_iter() calls ext4_buffered_write_iter() which dirties pages, then does flush and invalidate. However, there's an unprotected window between ext4_buffered_write_iter() returning (with inode lock released) and the subsequent flush+invalidate. Concurrent async DIO completions from other threads can run kiocb_invalidate_post_direct_write() during this window. If pages have been re-dirtied, post-invalidation finds dirty pages and triggers the warning, setting -EIO in the error sequence. Consider a file with two 4k extents: [hole][written]. Thread A does DIO to the written extent, while thread B does DIO spanning both: kworker A (4k DIO, allocated block) kworker B (8k DIO, fallback) ----------------------------------- ---------------------------- inode_lock_shared() inode_lock_shared() iomap_dio_rw(): iomap_dio_rw(): kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio (async) dio->size = 0 inode_unlock_shared() inode_unlock_shared() [bio pending in block layer] /* fallback: lock released */ ext4_buffered_write_iter() inode_lock(exclusive) generic_perform_write() -> dirty pages [0, 8k] inode_unlock(exclusive) /* pages dirty, no lock */ [bio completes] filemap_write_and_wait_range() iomap_dio_complete() -> flush dirty pages kiocb_invalidate_post_direct_write() invalidate_mapping_pages() invalidate_inode_pages2_range() -> finds dirty page! -> dio_warn_stale_pagecache() -> errseq_set(-EIO) This issue can be triggered through normal I/O paths, not just intentionally overlapping DIO writes from userspace. For example, generic/746 uses a loop device where multiple kworkers issue concurrent I/O to the backing file. Additionally, when block_size < folio_size, non-overlapping DIO writes that share a large folio can also trigger the race. Add inode_dio_wait() in ext4_buffered_write_iter() before ext4_write_checks() to drain all in-flight DIO. This ensures that all DIO clears existing pages before submitting IO (via kiocb_invalidate_pages()), all BIO waits for all DIO to complete (via inode_dio_wait()), and ext4_write_checks() observes the inode size after all completed DIO so that ext4_block_zero_eof() does not race with in-flight DIO, thus eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92504", "url": "https://ubuntu.com/security/CVE-2026-92504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int3400: clean up ODVP on probe failures evaluate_odvp() creates per-ODVP sysfs files before the thermal zone and later probe resources are registered. The current unwind path only calls cleanup_odvp() from the late sysfs failure path, so failures after evaluate_odvp() but before that label, including thermal_tripless_zone_device_register() failures, leave the ODVP files and storage behind. Move the ODVP cleanup to the common ART/TRT unwind path so every failure after evaluate_odvp() releases the ODVP state. Also clear the cached ODVP pointers in cleanup_odvp(), because evaluate_odvp() can already call it for partial setup failures while probe continues.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92505", "url": "https://ubuntu.com/security/CVE-2026-92505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix undefined behavior in devid_write debugfs function When for_each_pci_segment() loop completes without finding a matching segment, the pci_seg pointer is not NULL but points to an invalid memory location (the list head). Accessing pci_seg->id after the loop causes undefined behavior. Fix this by handling the successful case inside the loop and returning -EINVAL after the loop if no matching segment is found.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92506", "url": "https://ubuntu.com/security/CVE-2026-92506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix requested device removal race scmi_protocol_device_unrequest() drops scmi_requested_devices_mtx while notifying listeners but continues to retain the per-protocol list head. When two SCMI drivers for the same protocol unregister concurrently, one thread can remove the final request and free the list head while the other is running its notifier. The latter then dereferences the freed list head after reacquiring the mutex and can free it a second time. Complete the list and IDR updates, including freeing an empty list head, before dropping the mutex. Keep the blocking notifier outside the critical section and retain only the detached request across the callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92507", "url": "https://ubuntu.com/security/CVE-2026-92507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_dealloc_pd_user() When accessing a PD via the netlink path the only synchronization mechanism for the said PD is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_dealloc_pd_user(), which is too late, since by that point vendor-specific resources associated with the PD might already be freed. This can leave a short window where the PD remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_dealloc_pd_user(), ensuring that the PD is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a PD that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92508", "url": "https://ubuntu.com/security/CVE-2026-92508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_free_cq() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_free_cq(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92509", "url": "https://ubuntu.com/security/CVE-2026-92509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in counter_release() When accessing a counter via the netlink path the only synchronization mechanism for the said counter is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of counter_release(), which is too late, since by that point vendor-specific resources associated with the counter might already be freed. This can leave a short window where the counter remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources, ensuring that the counter is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a counter that is in the process of destruction.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92510", "url": "https://ubuntu.com/security/CVE-2026-92510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_destroy_srq_user() When accessing a SRQ via the netlink path the only synchronization mechanism for the said SRQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_srq_user(), which is too late, since by that point vendor-specific resources associated with the SRQ might already be freed. This can leave a short window where the SRQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_srq_user(), ensuring that the SRQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a SRQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92511", "url": "https://ubuntu.com/security/CVE-2026-92511", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_destroy_cq_user() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_cq_user(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_cq_user(), ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92512", "url": "https://ubuntu.com/security/CVE-2026-92512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix use after free in ib_query_qp() When querying a QP via the netlink flow the only synchronization mechanism for the said QP is rdma_restrack_get(), meanwhile during the QP destroy path rdma_restrack_del() is called at the end of the ib_destroy_qp_user() function which is too late, since by then the vendor specific resources for said QP would already be destroyed, and till the rdma_restrack_del() is called this QP can still be accessed, which could cause the use after free below. Fix this by moving the rdma_restrack_begin_del() to the start of the ib_destroy_qp_user(), which in turn waits for all usages of the QP to be done then removes it from the database to prevent access to it while it is being destroyed. RIP: 0010:ib_query_qp+0x15/0x50 [ib_core] Code: 48 83 05 5d 8e b9 ff 01 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 c7 46 40 00 00 00 00 48 c7 46 78 00 00 00 00 <48> 8b 07 48 8b 80 88 01 00 00 48 85 c0 74 1a 48 83 05 54 91 b9 ff RSP: 0018:ff11000108a8f2f0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ff11000108a8f370 RCX: ff11000108a8f370 RDX: 0000000000000000 RSI: ff11000108a8f3d8 RDI: 0000000000000000 RBP: ff1100010de5a000 R08: 0000000000000e80 R09: 0000000000000004 R10: ff110001057a604c R11: 0000000000000000 R12: ff11000108a8f370 R13: ff110001090e8000 R14: 0000000000000000 R15: ff110001057a602c FS: 00007f2ffd8db6c0(0000) GS:ff110008dc90b000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010b9a7004 CR4: 0000000000373eb0 Call Trace: mlx5_ib_gsi_query_qp+0x21/0x50 [mlx5_ib] mlx5_ib_query_qp+0x689/0x9d0 [mlx5_ib] ib_query_qp+0x35/0x50 [ib_core] fill_res_qp_entry_query.isra.0+0x47/0x280 [ib_core] ? __wake_up+0x40/0x50 ? netlink_broadcast_filtered+0x15a/0x550 ? kobject_uevent_env+0x562/0x710 ? ep_poll_callback+0x242/0x270 ? __nla_put+0xc/0x20 ? nla_put+0x28/0x40 ? nla_put_string+0x2e/0x40 [ib_core] fill_res_qp_entry+0x138/0x190 [ib_core] res_get_common_dumpit+0x4a5/0x800 [ib_core] ? fill_res_qp_entry_query.isra.0+0x280/0x280 [ib_core] nldev_res_get_qp_dumpit+0x1e/0x30 [ib_core] netlink_dump+0x16f/0x450 __netlink_dump_start+0x1ce/0x2e0 rdma_nl_rcv_msg+0x1d3/0x330 [ib_core] ? nldev_res_get_qp_raw_dumpit+0x30/0x30 [ib_core] rdma_nl_rcv_skb.constprop.0.isra.0+0x108/0x180 [ib_core] rdma_nl_rcv+0x12/0x20 [ib_core] netlink_unicast+0x255/0x380 ? __alloc_skb+0xfa/0x1e0 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x230 ? copy_msghdr_from_user+0xea/0x170 ___sys_sendmsg+0x7c/0xb0 ? __futex_wait+0x95/0xf0 ? __futex_wake_mark+0x40/0x40 ? futex_wait+0x67/0x100 ? futex_wake+0xac/0x1b0 __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xb90 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92513", "url": "https://ubuntu.com/security/CVE-2026-92513", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mana_ib: drain QP references after partial table insertion mana_table_store_ud_qp() publishes a QP at its send-queue id before inserting the receive-queue id, dropping the XArray lock between the two xa_insert_irq() calls. A concurrent completion handler can look up the QP and take a transient reference. When the second insertion fails, the rollback erased only the send-queue entry and returned, leaving both the initial table reference and the transient reference outstanding while RDMA core frees the QP, causing a use-after-free. Drain the reference as normal destruction does: drop the initial reference and wait for qp->free, releasing the QP only after every concurrent lookup returns its reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92514", "url": "https://ubuntu.com/security/CVE-2026-92514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: Fix CEQ tasklet use-after-free on removal Each CEQ interrupt handler only schedules eqc->tasklet. The tasklet calls erdma_ceq_completion_handler(), which reads the DMA-coherent EQ ring through get_next_valid_eqe() and updates eq->dbrec through notify_eq(). erdma_ceqs_uninit() frees each CEQ IRQ and then destroys its EQ. free_irq() prevents another hard IRQ and waits for an in-flight handler, but it does not drain a tasklet that the handler already scheduled. The tasklet can therefore access eq->qbuf or eq->dbrec after erdma_eq_destroy() frees them. Clearing ceq_cb->ready does not synchronize with a tasklet that already passed the check at the start of erdma_ceq_completion_handler(). Kill the tasklet after free_irq(), when no handler can schedule it again, and before erdma_ceq_uninit_one() releases the EQ buffers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92515", "url": "https://ubuntu.com/security/CVE-2026-92515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve unique-field state across nested structs btf_find_struct_field() initializes a fresh seen mask for every recursive descent. Unique special fields in different levels of the same aggregate therefore do not see one another. The duplicate fields can reach btf_parse_fields(), where they trigger an invariant WARN_ON_ONCE(). A crafted user BTF can consequently trigger the warning before map creation checks capabilities. Initialize the seen mask once in btf_find_field() and pass the same pointer through struct, datasec, and nested-struct walks. This gives the entire field traversal one shared uniqueness state.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92516", "url": "https://ubuntu.com/security/CVE-2026-92516", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix offset warn check for bpf_res_spin_lock Sashiko pointed out correctly that the case statement for BPF_RES_SPIN_LOCK incorrectly checks offset for BPF_SPIN_LOCK. Fix it by checking res_spin_lock_off instead.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92517", "url": "https://ubuntu.com/security/CVE-2026-92517", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, riscv: Fix extable handling for arena load_acquire emit_atomic_ld_st() returns 1 to have build_body() skip the zext after a sub-word load_acquire. The caller does \"ret = ret ?: add_exception_handler(...)\", which skips add_exception_handler() on any non-zero ret, so the extable entry is missing and a faulting PROBE_ATOMIC load_acquire oopses. REG_DONT_CLEAR_MARKER leaves rd stale on fault, and the verifier still thinks the load overwrote it, so a program can leak it through a map. Check ret >= 0 before calling add_exception_handler(), and pass rd for LOAD_ACQ so the fault zeroes rd like a PROBE_MEM load. Return ret unchanged for the zext skip.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92518", "url": "https://ubuntu.com/security/CVE-2026-92518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Fix kernel stack corruption in tailcall with CFI When CONFIG_CFI_CLANG is enabled, prog->bpf_func already skips the kcfi instruction during setup. Including it again in the tailcall jump offset causes it to jump over an extra 4 bytes, skipping the stack pointer adjustment, which will result in kernel stack corruption.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92519", "url": "https://ubuntu.com/security/CVE-2026-92519", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Fix memory leak in bpf_jit_free When bpf_int_jit_compile() is called for subprograms, it returns early during the first pass (!prog->is_func || extra_pass is false), keeping ctx->offset alive for the subsequent extra pass. If JIT compilation fails for a later subprogram, the BPF core aborts and calls bpf_jit_free() to clean up the first subprogram. However, bpf_jit_free() fails to free jit_data->ctx.offset, which causes a memory leak of the JIT context offsets array. Fix this by adding the missing kfree(jit_data->ctx.offset) in bpf_jit_free().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92520", "url": "https://ubuntu.com/security/CVE-2026-92520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero queue and stack outputs on lock failure Queue and stack pop/peek helpers accept an uninitialized output buffer because the verifier expects the helper to initialize it. The empty-map error path clears the buffer, but a failed lock acquisition returns -EBUSY without writing it. Clear the output before returning -EBUSY so BPF programs cannot observe uninitialized stack contents after a failed helper call.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89786", "url": "https://ubuntu.com/security/CVE-2026-89786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bounds read in ext4_read_inline_dir() ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64(): BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir The dirent payload lives in a buffer of exactly inline_size bytes: \tdir_buf = kmalloc(inline_size, GFP_NOFS); but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic \".\" and \"..\" land at their block-dir offsets. A dirent is formed at \"dir_buf + pos - extra_offset\", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected. Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and main loops, and pass inline_size rather than extra_size to ext4_check_dir_entry() so the length check matches the physical buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92521", "url": "https://ubuntu.com/security/CVE-2026-92521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first. When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer. acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed. Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92522", "url": "https://ubuntu.com/security/CVE-2026-92522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: validate MADT IOAPIC entry bounds The IOAPIC hotplug lookup parses both MADT and _MAT records directly. The MADT walk previously used a subtable's declared length to advance the cursor after only locating a generic header. The _MAT path likewise passed a generic header to the IOAPIC helper. Validate that a current record has a complete generic header, that its declared length is contained in the available record range, and that a typed IOAPIC record contains the full fixed IOAPIC body before reading its fields. Use the same relation for both MADT and _MAT provider paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92523", "url": "https://ubuntu.com/security/CVE-2026-92523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/nldev: validate dynamic counter attribute length RDMA_NLDEV_ATTR_STAT_HWCOUNTERS is a nested attribute whose children are consumed directly with nla_get_u32(). The top-level policy validates only the container, so it does not establish the fixed shape of each child. Require every child payload to be exactly one u32 before reading it.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92524", "url": "https://ubuntu.com/security/CVE-2026-92524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc() When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92525", "url": "https://ubuntu.com/security/CVE-2026-92525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[] For a user QP, qp->sq.queue is a ring the application writes directly, so rxe_post_send() takes the is_user branch and only schedules send_task without validating the WQE. rxe_requester() consumes it in place via req_next_wqe() and calls copy_data(), which indexes &wqe->dma.sge[cur_sge] with the attacker-controlled num_sge/cur_sge. Only the kernel path bounds num_sge (validate_send_wr()); the user WQE is never checked, so a local unprivileged user can post a WQE with an out-of-range cur_sge or oversized num_sge and force an out-of-bounds read of the per-WQE sge array in copy_data() (vmalloc OOB read, local DoS). Bound num_sge to qp->sq.max_sge in rxe_requester() before use, the way get_srq_wqe() already guards SRQ entries, and bound cur_sge only when the WQE carries payload (dma.resid): copy_data() returns early on a zero-length copy before touching dma->sge[], so a zero-payload WQE -- the only kind a max_sge == 0 QP can post -- stays valid. Reproduced under KASAN; the vmalloc-out-of-bounds in copy_data() is gone.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93037", "url": "https://ubuntu.com/security/CVE-2026-93037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Propagate sdma_txinit_ahg() errors set_txreq_header_ahg() ignores the return value of sdma_txinit_ahg(). If sdma_txinit_ahg() fails, it returns before initializing tx->txreq. However, set_txreq_header_ahg() ignores the error and returns the AHG change count, causing the caller to continue processing the request as though initialization had succeeded. Propagate sdma_txinit_ahg() failures to the caller and abort request processing when initialization fails. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93039", "url": "https://ubuntu.com/security/CVE-2026-93039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: Keep link pointers valid on realloc failure meson_card_reallocate_links() grows the DAI link and private data arrays with two consecutive krealloc() calls and updates the owner pointers only after both calls have succeeded. A successful krealloc() may move the data: it frees the old block and returns a new one. When that happens for the link array and the second krealloc() then fails, card->dai_link still points to the block that krealloc() already freed, and the error path frees the new block too. The probe error path then calls meson_card_clean_references(), which dereferences card->dai_link and kfree()s it again, resulting in a use-after-free and a double free. Commit card->dai_link and card->num_links right after the first krealloc() succeeds, so the pointer always refers to a valid allocation that meson_card_clean_references() can walk and free. krealloc() with __GFP_ZERO zero-initializes the added entries, so walking them on the error path is safe. With both failure paths reduced to a plain return, drop the goto labels and the error message.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93040", "url": "https://ubuntu.com/security/CVE-2026-93040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize channel state checks pause() and resume() read and update channel state without holding vc.lock, while the interrupt handlers update the same state under it. Take the same lock around those state checks so that request, status, and configured stay consistent. For example, pause() can observe EDMA_ST_BUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issue_pending() requires EDMA_REQ_NONE, the channel is wedged for good: terminate_all() leaves the stale request behind, so even reconfiguring the channel does not recover it. issue_pending() already runs under vc.lock, but it tests configured before taking it. Move that test under the lock as well, so configured, request, and status are evaluated as one channel-state snapshot.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93041", "url": "https://ubuntu.com/security/CVE-2026-93041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize abort state updates dw_edma_abort_interrupt() drops vc.lock before changing request and status. issue_pending() can acquire the lock in that small window, observe the old busy state, and skip starting queued descriptors. Then the abort handler overwrites the channel status as idle, leaving the new descriptors stranded for good. Keep descriptor completion and the state transition in the same critical section.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93042", "url": "https://ubuntu.com/security/CVE-2026-93042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Terminate all descriptors without callbacks The DMA Engine client documentation says in the \"Terminate APIs\" section of Documentation/driver-api/dmaengine/client.rst: \"No callback functions will be called for any incomplete transfers.\" dw-edma instead calls vchan_cookie_complete() when a deferred STOP reaches the interrupt handler. This schedules a callback for the active descriptor and leaves other issued or submitted descriptors queued. A late callback after dmaengine_terminate_sync() can dereference client state that has already been freed, while leftover descriptors may later restart into reused buffers or leak. Move all issued and submitted descriptors to the terminated list whenever termination completes. For a pending STOP, do this from both the DONE and ABORT paths. Complete their cookies in order without scheduling callbacks. A STOP can remain pending until the running transfer raises an interrupt. Make device_synchronize() wait for such a pending STOP to complete before releasing terminated descriptors. Reuse it from free_chan_resources(), then release the remaining virt-dma resources. Sleep instead of busy-polling while waiting, and warn if the existing timeout expires.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93045", "url": "https://ubuntu.com/security/CVE-2026-93045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject arena frees below the arena base bpf_arena_free_pages() accepts scalar arena addresses. The runtime masks the address to the low 32 bits and reconstructs a full user address from the arena base before returning the range to the arena free tree. When the scalar value is below the low 32 bits of the arena base, full_uaddr falls below user_vm_start. The existing upper-end clipping then turns this into an out-of-range free-tree offset. A later allocation can reuse that offset and return an address below the arena mapping. Reject such frees before computing the clipped range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93046", "url": "https://ubuntu.com/security/CVE-2026-93046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: software node: Fix software_node_get_reference_args() with index -1 The bounds check for the index passed to software_node_get_reference_args() was failing when passed UINT_MAX, this in turn would lead to an out of bound access in the property array. Fix the bound check to also cover the UINT_MAX case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93048", "url": "https://ubuntu.com/security/CVE-2026-93048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition() mtd_add_partition() does not reject the special offset value MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in add_mtd_device() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on cur_offset being the end of the previous partition, but in the dynamic partition path cur_offset equals the offset argument itself, causing undefined behavior. Commit 5daa7b21496a (\"mtd: prepare partition add and del functions for ioctl requests\") introduced mtd_add_partition() and correctly rejected MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2), since those special offsets rely on cur_offset tracking the previous partition's end. However, commit 1a31368bf92e (\"mtd: add a flags for partitions which should just leave smth. after them\") later added MTDPART_OFS_RETAIN (-3) for the static partition table path without updating mtd_add_partition() to also reject this value. With offset=-3 passed via BLKPG, the RETAIN size calculation in allocate_partition() underflows (parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3). If the underflow result does not appear to leave enough space, allocate_partition() jumps to out_register via goto, skipping erasesize initialization. This results in erasesize=0, which triggers: WARN_ON((!mtd->erasesize || !master->_erase) && \t\t!(mtd->flags & MTD_NO_ERASE)) in add_mtd_device(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the \"out of reach\" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error. Fix this by adding MTDPART_OFS_RETAIN to the rejection list in mtd_add_partition(), consistent with the existing handling of APPEND and NXTBLK.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93049", "url": "https://ubuntu.com/security/CVE-2026-93049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdswap: Avoid freeing registered blktrans device twice In mtdswap_add_mtd(), debugfs setup failure after successful blktrans registration can free mbd_dev twice. add_mtd_blktrans_dev() initializes the blktrans device reference and publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the disk down and drops the blktrans reference; when that reference reaches zero, blktrans_dev_release() frees the mtd_blktrans_dev. The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell through the common cleanup label and called kfree(mbd_dev) again. Clear the local pointer after deregistration so the common cleanup can still release the mtdswap state without freeing the blktrans object twice. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89777", "url": "https://ubuntu.com/security/CVE-2026-89777", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: clear vdev->msi_perm after freeing it on init failure vfio_msi_cap_len() lazily allocates the per-device MSI permission table: \tvdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); \tif (!vdev->msi_perm) \t\treturn -ENOMEM; \tret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); \tif (ret) { \t\tkfree(vdev->msi_perm); \t\treturn ret;\t\t/* vdev->msi_perm left dangling */ \t} When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at \"if (vdev->msi_perm) return len;\" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93050", "url": "https://ubuntu.com/security/CVE-2026-93050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipack: ipoctal: fix UAF, null-ptr-deref, and use-after-free in cleanup on remove Three issues arise when the device is removed while a tty session is still active: 1. UAF of struct ipoctal: the remove callback frees ipoctal via kfree() while tty ops may still access it. Fix by introducing kref-based lifetime management — kref is taken in install() when a tty is opened and released in cleanup() when the tty is finally destroyed; remove() uses kref_put() instead of kfree(). 2. NULL dereference in ipoctal_write_tty(): __ipoctal_remove() frees xmit_buf via tty_port_free_xmit_buf() while a userspace process may still hold the tty fd and call write(). Fix by checking for NULL xmit_buf in ipoctal_write_tty(). 3. UAF in ipoctal_cleanup(): ipack_put_carrier(ipoctal->dev) dereferences ipoctal->dev after the ipack_device has been freed by ipack_device_del(). Fix by caching ipoctal->carrier_owner during probe() and calling module_put() on the cached pointer directly in cleanup(), avoiding any access to ipoctal->dev. Also introduce a \"removed\" flag in struct ipoctal, set at the start of __ipoctal_remove(), and checked in every tty op that accesses hardware resources (port_activate, write_tty, set_termios, hangup, shutdown). This prevents page faults when devm_ioremap() regions are unmapped after remove() returns.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93051", "url": "https://ubuntu.com/security/CVE-2026-93051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ad525x_dpot: use driver core groups for sysfs files ad_dpot_probe() creates per-RDAC sysfs files manually and then optionally creates the command sysfs group. This leaves probe responsible for rolling back partial sysfs state and makes remove responsible for matching every file that probe created. Move the device attributes into driver core dev_groups for the I2C and SPI drivers and use an is_visible() callback to expose only the attributes supported by the probed device. With this shape, the driver core creates the sysfs files only after probe succeeds and removes them before the remove callback frees the driver data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93052", "url": "https://ubuntu.com/security/CVE-2026-93052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: bcm-vk: Use acquire/release for msgq_inited bcm_vk_sync_msgq() fills the message queue information and then sets msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the message queues and their cached queue information. atomic_set()/atomic_read() do not order those accesses. A reader can see msgq_inited set while still seeing stale queue information. Use release when publishing the initialized queues and acquire when checking the gate. Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the gate and does not publish queue state to readers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93053", "url": "https://ubuntu.com/security/CVE-2026-93053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: speakup: keyhelp: guard letter_offsets possible out-of-range indexing help_init() builds letter_offsets[] by using the first byte of each function name as an index via `(start & 31) - 1`. If function_names are overridden from sysfs (root) with a name starting outside [a–z], the index underflows or exceeds the array, leading to OOB write. Function names can be overridden with the following commands as root: modprobe speakup_soft echo \"0 _bad\" > /sys/accessibility/speakup/i18n/function_names # then press Insert+2 on /dev/tty This fix checks the first letter in help_init(), and if it is not in the [a–z] range the function returns an error to the caller. Eventually this error is propagated to drivers/accessibility/speakup/main.c:2217, which causes a bleep sound.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93054", "url": "https://ubuntu.com/security/CVE-2026-93054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uio: Fix stale info pointer in failed registration path After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same \"device gone\" state as normal uio_unregister_device().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93055", "url": "https://ubuntu.com/security/CVE-2026-93055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: UDF symlink pathComponent header OOB read udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93056", "url": "https://ubuntu.com/security/CVE-2026-93056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: remove broken string configfs attributes The UAC1_STR_ATTRIBUTE macro defines configfs show/store handlers for the fn_play, fn_cap, and fn_cntl string options. The store function contains an inverted null check on the kstrndup() return value. This means every write attempt returns -ENOMEM on success and dereferences a NULL pointer on allocation failure. The attributes have been broken and unused for many years. Remove the UAC1_STR_ATTRIBUTE macro and the three attributes it generated. The internal defaults (FILE_PCM_PLAYBACK, FILE_PCM_CAPTURE, FILE_CONTROL) set in f_audio_alloc_inst() are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93058", "url": "https://ubuntu.com/security/CVE-2026-93058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Only fini scheduler after successful init msm_ringbuffer_new() destroys a partially initialized ring through msm_ringbuffer_destroy() when an allocation or scheduler setup step fails. If drm_sched_init() fails before it finishes initializing the scheduler, the failure path still calls drm_sched_fini(). That teardown path assumes the scheduler work items, lists, and workqueue state were initialized. Track successful scheduler initialization and call drm_sched_fini() only after drm_sched_init() returned 0. This issue was found by a static analysis checker and confirmed by manual source review. Patchwork: https://patchwork.freedesktop.org/patch/738905/", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93059", "url": "https://ubuntu.com/security/CVE-2026-93059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix task_struct reference leak in recover_worker get_pid_task() increments the task reference count, but the corresponding put_task_struct() was missing in the else branch, leaking a reference on every GPU hang recovery. Patchwork: https://patchwork.freedesktop.org/patch/730662/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93061", "url": "https://ubuntu.com/security/CVE-2026-93061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Avoid stack over-read in debug output helpers host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93062", "url": "https://ubuntu.com/security/CVE-2026-93062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: guard against division by zero in iwl_dbg_tlv_alloc_fragments Make sure we don't end-up with a num_frags = 0 situation. For that, check that the required size is not 0 and put a checker on num_frags as well.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93063", "url": "https://ubuntu.com/security/CVE-2026-93063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mei: check SAP message length before reading it Verify the SAP message size is not larger than the local buffer before reading the message to avoid buffer overflow.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93064", "url": "https://ubuntu.com/security/CVE-2026-93064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix off-by-one in TXF key sanitiser iwl_mvm_frob_txf_key_iter() tracks the last matched byte position in loop variable 'i'. When a full key match is found (match == keylen), 'i' points at the last byte of the matched key. The memset start offset should therefore be i + 1 - keylen, not i - keylen; the current code zeroes one byte before the match and leaves the final key byte un-sanitised.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93065", "url": "https://ubuntu.com/security/CVE-2026-93065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix counter type in iwl_fwrt_dump_error_logs The loop counter 'count' was declared as u8 while num_pc is u32. If firmware advertises more than 255 PC entries the counter wraps back to zero and the loop never terminates potentially causing an infinite loop or reading past the allocated pc_data array. Change the declaration to u32 to match num_pc.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93066", "url": "https://ubuntu.com/security/CVE-2026-93066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: Take cpa_lock around large-page collapse Loading and unloading modules concurrently on several CPUs on a KASAN build, with a short delay injected at the CPA page-table lookup to widen the window, faults within minutes: BUG: KASAN: use-after-free in __change_page_attr+0x7cc/0x7e0 Write of size 8 at addr ffff888181139718 by task modprobe ... The buggy address belongs to the physical page: pfn:0x181139 ... page_type: f2(table) cpa_collapse_large_pages() rebuilds a leaf PMD from its 4K PTEs and frees the old PTE-table pages, while __change_page_attr() fetches a PTE pointer from a lockless lookup_address_in_pgd_attr() and writes it with set_pte_atomic() only later. When module text is served from a shared large ROX mapping the two run on the same PMD: CPU A (module load) CPU B (module finalize) ------------------- ----------------------- execmem_make_temp_rw set_memory_nx __change_page_attr split 2M -> 4K table P kpte = &P[i] (lockless) execmem_restore_rox set_memory_rox (CPA_COLLAPSE) cpa_collapse_large_pages rebuild leaf PMD flush_tlb_all pagetable_free(P) set_pte_atomic(kpte, ...) -> writes into freed P P is a page-table page (page_type: table), reused at once, so the write corrupts whatever got the page next: a bad-pte or bad-page splat, or a fatal fault once P has been turned into read-only text. The flush_tlb_all() before the free does not close this: its IPI only serializes against page-table walkers that run with interrupts off (e.g. GUP-fast); the walk in __change_page_attr() runs with interrupts on, so nothing stops it from holding a stale pointer into P. Serialize the collapse - the PMD rebuild, TLB flush and PTE-table free - under cpa_lock, the same lock __change_page_attr() now takes unconditionally since commit (\"x86/mm/pat: stop gating cpa_lock on debug_pagealloc_enabled()\"), so a concurrent walker can no longer hold a pointer into a table the collapse is about to free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93067", "url": "https://ubuntu.com/security/CVE-2026-93067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: clamp the reported AUX read size to the request tc_aux_transfer() clamps an AUX read to the payload limit: \tsize_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: \tif (size) \t\tsize = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 (\"drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer\").", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93068", "url": "https://ubuntu.com/security/CVE-2026-93068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix DM I2C teardown race DM I2C adapters can remain visible to userspace while DM teardown is already in progress. A concurrent i2c-dev transfer may then enter amdgpu_dm_i2c_xfer() after the backing DM state has been torn down, leading to a NULL pointer dereference. Create a devres group around the DM I2C adapter lifetime and release it at the start of dm_hw_fini(), before HPD, IRQ, and DM state are torn down. This removes the I2C adapters first and waits for in-flight users to drain before the structures used by amdgpu_dm_i2c_xfer() disappear. This fixes a teardown ordering race seen during device removal: BUG: kernel NULL pointer dereference RIP: amdgpu_dm_i2c_xfer+0x122/0x1c0 [amdgpu] Call Trace: __i2c_transfer i2c_transfer i2cdev_ioctl_rdwr", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93070", "url": "https://ubuntu.com/security/CVE-2026-93070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ipu6: Do not free aux device pdata after init ipu6_bus_initialize_device() stores the isys/psys pdata pointer in struct ipu6_bus_device and initializes the auxiliary device. After that point, error unwinding must drop the auxiliary device reference and let ipu6_bus_release() free both the bus device and adev->pdata. The isys and psys init paths already call put_device() when MMU initialization fails, and ipu6_bus_add_device() calls auxiliary_device_uninit() on auxiliary_device_add() failure. Both paths therefore run the bus release callback. The extra kfree(pdata) in the callers can release the same object a second time. Remove the manual pdata frees after the auxiliary device has been initialized. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93071", "url": "https://ubuntu.com/security/CVE-2026-93071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: bcm2835-unicam: Fix asc leaked in error/remove path v4l2_async_nf_add_fwnode_remote() allocates the asc, which is freed when v4l2_async_nf_cleanup() is called. Call v4l2_async_nf_cleanup() properly in the driver paths. Discovered with kmemleak after rmmod: unreferenced object 0xffff000084526b80 (size 64): comm \"modprobe\", pid 185, jiffies 4295013512 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 e8 0d ff bf 00 00 ff ff ................ 40 83 bc 84 00 00 ff ff 60 83 bc 84 00 00 ff ff @.......`....... backtrace (crc ac584083): [<00000000ffb081a7>] kmemleak_alloc+0x38/0x44 [<00000000d2fd9301>] __kmalloc+0x1b0/0x250 [<000000004dd5354d>] __v4l2_async_nf_add_fwnode+0x28/0x9c [<0000000067587657>] __v4l2_async_nf_add_fwnode_remote+0x3c/0x64", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93072", "url": "https://ubuntu.com/security/CVE-2026-93072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/renesas-irqc: Fix generic interrupt chip leak on remove The driver allocates domain generic chips probe. However, on driver removal, the generic chips are not automatically freed when the interrupt domain is removed because the domain flags do not include IRQ_DOMAIN_FLAG_DESTROY_GC. This causes both the domain generic chips structure and the associated generic chips to be leaked. Additionally, the generic chips remain on the global list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. Fix the resource leak by setting IRQ_DOMAIN_FLAG_DESTROY_GC on the interrupt domain; this lets the interrupt domain core automatically release all generic chips when irq_domain_remove() is invoked, removing the need for manual cleanup calls in error paths and remove callback.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93073", "url": "https://ubuntu.com/security/CVE-2026-93073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dax: read holder_ops once in dax_holder_notify_failure() dax_holder_notify_failure() reads dax_dev->holder_ops twice without READ_ONCE() -- once for the NULL check and once for the indirect notify_failure() call. A concurrent fs_put_dax() can clear holder_ops between the two reads, so the check can observe a non-NULL pointer while the call dereferences NULL. (kill_dax() also clears holder_ops, but only after synchronize_srcu(), so it cannot race a reader that is inside dax_read_lock(); fs_put_dax() does no such synchronization.) Fetch holder_ops once into a local with READ_ONCE() so the NULL check and the indirect call observe the same value.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93077", "url": "https://ubuntu.com/security/CVE-2026-93077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/features: Clamp Get Feature output size to the remaining buffer cxl_get_feature() reads a feature in a loop but passes a fixed size_out as the output capacity every iteration. On the last partial iteration the buffer has less room left, so a device that returns more than asked can overflow feat_out. Use the per-iter size data_to_rd_size, which already tracks the remaining room, as the output capacity.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93078", "url": "https://ubuntu.com/security/CVE-2026-93078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/features: Reject Set Features output buffer smaller than the header cxlctl_set_feature() sizes its output buffer from the user's fwctl_rpc.out_len but never checks it is large enough to hold even the fwctl_rpc_cxl_out header. With out_len == 0 , kvzalloc() returns ZERO_SIZE_PTR, which passes the !rpc_out check, the subsequent rpc_out->size = 0 then writes through the poison pointer. Reject requests whose output buffer can't hold the response header, before allocating. The Set Feature reply carries no payload, so the header is all that is required.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93079", "url": "https://ubuntu.com/security/CVE-2026-93079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/features: Reject Get Feature count larger than the output buffer cxlctl_get_feature() sizes its output buffer from the user's fwctl_rpc.out_len, but the device is told to write cxl_mbox_get_feat_in.count bytes into rpc_out->payload, which is a separate user-controlled value. Nothing bounds count against out_len, so a small out_len with a large count overflows the kvzalloc()'d buffer. A heap OOB write reachable from FWCTL_RPC. Reject requests where count exceeds the available payload room, before allocating.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93080", "url": "https://ubuntu.com/security/CVE-2026-93080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix transport device teardown lookup SCMI transport devices are deliberately excluded from normal SCMI bus matching so protocol drivers cannot bind to the internal transport children. However, scmi_device_destroy() uses the same protocol/name lookup to find devices that must be unregistered during channel teardown. Split the match helper so driver matching still skips transport devices, while explicit child lookup can find them for teardown. Use a shared transport-device name prefix macro for both matching and name generation. Since transport-device names are derived from direction and protocol ID, reject duplicate protocol channel setup before creating or finding a transport device. This prevents malformed firmware with duplicate protocol child nodes from reusing an existing transport device and then destroying it when the duplicate IDR insertion fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93082", "url": "https://ubuntu.com/security/CVE-2026-93082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unwind P2A receiver mailbox setup failure mailbox_chan_setup() can request an additional P2A receiver channel after successfully acquiring the primary P2A channel. If that later request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93083", "url": "https://ubuntu.com/security/CVE-2026-93083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unwind TX receiver mailbox setup failure mailbox_chan_setup() can request an additional unidirectional TX receiver channel after successfully acquiring the primary channel. If that second request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93084", "url": "https://ubuntu.com/security/CVE-2026-93084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Drop handle on protocol bind failures The SCMI bus notifier acquires an SCMI handle when the driver core emits BUS_NOTIFY_BIND_DRIVER, before invoking the protocol driver probe callback. The protocol probe path only checks whether sdev->handle is set. If device_link_add() fails after the handle has been acquired, the protocol device can still bind with a valid handle but without the dependency link to the SCMI parent. A concurrent parent unbind can then miss the child and tear down the SCMI instance while the child still holds a handle into it. If the protocol driver probe later fails, for example with -EPROBE_DEFER, the driver core emits BUS_NOTIFY_DRIVER_NOT_BOUND rather than BUS_NOTIFY_UNBOUND_DRIVER. The SCMI notifier only released the handle on BUS_NOTIFY_UNBOUND_DRIVER, so each failed protocol-device bind leaked the SCMI instance users refcount and left sdev->handle set after the failed probe. Make the link helper report failure and drop the acquired handle if the link cannot be created. Also handle BUS_NOTIFY_DRIVER_NOT_BOUND in the same cleanup path used for unbind so failed probes balance the earlier BUS_NOTIFY_BIND_DRIVER acquisition.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93085", "url": "https://ubuntu.com/security/CVE-2026-93085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Reject out of range DT protocol IDs SCMI protocol IDs carried in message headers are limited by MSG_PROTOCOL_ID_MASK. The DT parsing paths noticed protocol IDs outside that range, but only logged an error and then kept processing the invalid value. That lets a malformed 32-bit DT reg value reach helpers which take a u8 protocol ID, where it can be truncated and/or treated as a different protocol. For channel setup, two different out-of-range values can also be used as distinct IDR keys while aliasing the generated SCMI protocol identity. Skip DT protocol nodes whose reg value does not fit the SCMI protocol ID field before setting up channels or creating protocol devices.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93086", "url": "https://ubuntu.com/security/CVE-2026-93086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Avoid IDR updates while cleaning channels scmi_cleanup_channels() walks the TX/RX channel IDRs with idr_for_each() to free transport resources and destroy the dedicated transport devices before calling idr_destroy(). The destroy callback removed each entry from the same IDR being walked. That is not needed for this cleanup path, and it is unsafe because idr_for_each() has not advanced its radix-tree iterator while the callback is running. Removing the current entry from the callback can invalidate the iterator state. The callback also cannot be protected by rcu_read_lock(), because scmi_device_destroy() may sleep. Leave IDR teardown to the following idr_destroy() call and keep the callback limited to device destruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93089", "url": "https://ubuntu.com/security/CVE-2026-93089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Free transport channel on IDR failure If transport channel setup succeeds but the following IDR insertion fails, the error path destroys the transport device and frees the channel info without invoking the transport cleanup callback. Call chan_free() before destroying the device so transport specific resources such as IRQs, mailbox channels and mapped shared memory are released consistently with the normal teardown path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93090", "url": "https://ubuntu.com/security/CVE-2026-93090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Clean up channels on setup failure scmi_channels_setup() can fail after the common BASE channel or earlier protocol channels have already been registered in the TX/RX IDRs. Route this failure through the existing channel cleanup label so the transport channels, transport devices and IDR state created before the failure are released before the probe error path frees the SCMI instance ID.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93091", "url": "https://ubuntu.com/security/CVE-2026-93091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Quiesce notifications before teardown scmi_notification_exit() clears and releases the notification instance, but transport callbacks can still deliver incoming notifications until the TX/RX channels are freed. During remove, an RX interrupt in that window can enter scmi_notify() while notification state is being torn down and then dereference freed memory. The same ordering exists on the probe error path after notification initialization. The notification late-init worker has a separate lifetime issue: protocol event registration queues ni->init_work on the system workqueue, so destroying ni->notify_wq does not drain that work. If the devres group is released while init_work is still pending or running, the late-init worker can dereference the freed notification instance. Quiesce the notification core before TX/RX channels are torn down, then clean up the channels before releasing the notification core resources. Use disable_work_sync() so future late-init queueing is rejected and any already queued or running late-init work has completed before channel teardown starts.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93092", "url": "https://ubuntu.com/security/CVE-2026-93092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unregister device notifier before IDR teardown The requested-devices notifier looks up protocol fwnodes from the active_protocols IDR. During remove, unregister the notifier before releasing and destroying active_protocols so no notifier callback can race with the IDR teardown. Keep the bus notifier registered until after the protocol state is torn down, matching the existing remove ordering for SCMI bus users.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93093", "url": "https://ubuntu.com/security/CVE-2026-93093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Publish channel state before callbacks Transport setup can enable callbacks before the setup routine returns. mailbox_chan_setup() registers the mailbox client with mbox_request_channel(), and the mailbox controller startup path can enable interrupt delivery before SCMI mailbox channel state has been published. Similarly, smc_chan_setup() requests the optional A2P completion IRQ before the SMC transport has made its cinfo pointer visible. If a pending or spurious callback fires in those windows, the transport RX callback can dereference a NULL transport cinfo pointer. Publishing only the transport-private pointer is not sufficient either: an early callback can enter the SCMI core before scmi_chan_setup() has assigned cinfo->handle. The core derives scmi_info from cinfo->handle in the RX path, so a NULL handle can still fault even when the transport-private cinfo is valid. Assign cinfo->handle before invoking the transport setup callback. Publish the mailbox and SMC transport-private channel state before requesting the mailbox channels or IRQ, and clear the early-published pointers again on setup failure. Also unwind mailbox setup devres resources on failure so an optional RX setup error that is ignored by the core does not leave stale transport state behind.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93095", "url": "https://ubuntu.com/security/CVE-2026-93095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: validate thread record before delete key rebuild hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName. That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name. A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation. Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name. Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93097", "url": "https://ubuntu.com/security/CVE-2026-93097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/mbox: Break poison list loop on an empty payload A device that returns count == 0 with CXL_POISON_FLAG_MORE set on every iteration never advances nr_records, so the max_errors guard never trips and the do/while loops forever while holding poison.mutex. That hangs the sysfs-triggered scan thread and blocks all subsequent poison operations on the device. The existing \"Protect against an uncleared _FLAG_MORE\" guard was intended to bound a misbehaving device but does not cover the count == 0 case. Stop the loop on an empty payload so a malfunctioning or malicious device cannot wedge the poison scan.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93098", "url": "https://ubuntu.com/security/CVE-2026-93098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: glink: fix deadlock in endpoint destroy during driver detach During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414  <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0>] invoke_syscall+0x48/0x10c [<0>] el0_svc_common.constprop.0+0xc0/0xe0 [<0>] do_el0_svc+0x1c/0x28 [<0>] el0_svc+0x34/0x108 [<0>] el0t_64_sync_handler+0xa0/0xe4 [<0>] el0t_64_sync+0x198/0x19c The rpmsg device unregistration inside endpoint destroy is redundant. In both contexts where endpoint destruction is triggered: - Driver detach path: the driver core already tears down the rpmsg device. - Channel close path: the rpmsg device is already unregistered before endpoint destruction is reached. Remove the redundant unregistration to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93100", "url": "https://ubuntu.com/security/CVE-2026-93100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Prevent use-after-free in rdtgroup_kn_put() A struct rdtgroup is reference counted via rdtgroup::waitcount. Callers that need the structure to remain valid across a sleep (while waiting on acquiring rdtgroup_mutex) take a reference with rdtgroup_kn_get() and release it with rdtgroup_kn_put(). The release path is intended to serve as the fallback freer: if the count drops to zero and the group has already been marked RDT_DELETED, rdtgroup_kn_put() frees the structure. The bulk teardown paths free_all_child_rdtgrp() and rmdir_all_sub() resulting from a resctrl directory remove or resctrl fs unmount act as the primary freer: they hold rdtgroup_mutex and free each rdtgroup whose waitcount is zero, otherwise they set RDT_DELETED and leave the freeing to the last waiter. These two freers race. rdtgroup_kn_put() commits waitcount == 0 with atomic_dec_and_test() outside rdtgroup_mutex, then reads rdtgroup::flags. Between those two operations a concurrent caller of free_all_child_rdtgrp() or rmdir_all_sub() (which holds the mutex) can observe waitcount == 0 via atomic_read(), call rdtgroup_remove(), and kfree() the structure. The subsequent read of rdtgroup::flags in rdtgroup_kn_put() is then a use-after-free, and the structure may even be freed twice if the freed memory happens to satisfy the RDT_DELETED flag check. Replace the bare atomic_dec_and_test() with atomic_dec_and_mutex_lock() so that the decrement-to-zero takes rdtgroup_mutex before the count becomes globally visible. The inspection of rdtgroup::flags then runs under the same mutex held by the bulk freers, making the two paths mutually exclusive. The common case where the count does not reach zero remains lock-free. Defer kernfs_unbreak_active_protection() until after the mutex is dropped since kernfs active protections functionally wrap rdtgroup_mutex. Remove resource group, which in turn drops its kernfs reference, after kernfs protection is restored. [ bp: Split the commit messsages into smaller, easier-parseable paragraphs. ]", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93101", "url": "https://ubuntu.com/security/CVE-2026-93101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-async: Unregister sub-device if asc_list is empty When my em28xx USB device that uses the i2c tvp5150 driver is disconnected, it crashes. The cause is that the tvp5150 i2c module uses v4l2_async, but the em28xx driver does not since it predates v4l2_async. In that corner case sd->asc_list is empty, so v4l2_async_unregister_subdev() never calls v4l2_device_unregister_subdev(). Modify the code so that, if sd->asc_list is empty, v4l2_device_unregister_subdev() is still called.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89778", "url": "https://ubuntu.com/security/CVE-2026-89778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: fix out-of-bounds page array access on empty zisofs block zisofs_uncompress_block()'s empty-block fast path returns pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the decompression path which returns bytes produced relative to poffset. zisofs_fill_pages() uses that return to advance its page cursor, so when the zisofs block size is below PAGE_SIZE and a sub-page block leaves poffset partway into a page, a following empty block over-counts and advances pages[] one element past its end, after which \"if (poffset && *pages)\" reads pages[1] out of bounds. rock.c only rejects a block-size shift > 17, so a crafted \"ZF\" Rock Ridge record can set it below PAGE_SHIFT; the bug is reached by an ordinary read() of a compressed file on such a mounted ISO9660 image. Return the byte count relative to poffset and zero only [poffset, PAGE_SIZE) of the first page, matching the decompression path. The page-aligned case (poffset == 0) is unaffected. BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290) Read of size 8 at addr ffff88800f5eac48 by task exploit/142 zisofs_read_folio (fs/isofs/compress.c:290) read_pages (mm/readahead.c:184) ... filemap_read (mm/filemap.c:2814) vfs_read (fs/read_write.c:574) __x64_sys_pread64 (fs/read_write.c:769) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address is located 0 bytes to the right of the allocated 8-byte region in the kmalloc-8 cache", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93102", "url": "https://ubuntu.com/security/CVE-2026-93102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Free RX data on late probe failure hfi1_init_dd() allocates the shared AIP/VNIC RX support before returning. If hfi1_init() or hfi1_register_ib_device() later fails, init_one() tears down the device data without calling hfi1_free_rx(). This leaks netdev_rx and its dummy netdev. Free the RX support after IB unregistration and before postinit_cleanup(), as done on normal device removal.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93103", "url": "https://ubuntu.com/security/CVE-2026-93103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89783", "url": "https://ubuntu.com/security/CVE-2026-89783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full The depth check in xfrm6_input_addr() is off by one: if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; ... sp->xvec[sp->len++] = x; xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode receive path re-enters IPv6 input via xfrm_trans_reinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6_input_addr() is called with sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so sp->xvec[sp->len++] writes one slot past the 6-element xvec[]. The write stays within the sec_path allocation (invisible to KASAN); UBSAN_BOUNDS flags it and panics under panic_on_warn. Use \"sp->len >= XFRM_MAX_DEPTH\", matching xfrm_input(). This also restores one chain level the old check rejected at sp->len == 5. UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c:309:10 index 6 is out of range for type 'xfrm_state *[6]'", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93106", "url": "https://ubuntu.com/security/CVE-2026-93106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crash_dump: release keyring reference at the correct time restore_dm_crypt_keys_to_thread_keyring() gets a reference to the user keyring before restoring the saved dm-crypt keys. The same keyring reference is then passed to add_key_to_keyring() for each saved key, but add_key_to_keyring() drops that reference on every call. This is only balanced when exactly one key is restored. With multiple keys, the keyring reference is dropped too many times and may trigger a refcount underflow or use-after-free. When more than five keys are restored, a refcount underflow/use-after-free warning can be triggered. The early error paths after lookup_user_key() also return without dropping the keyring reference. Keep ownership of the keyring reference in restore_dm_crypt_keys_to_thread_keyring(), drop it once on all exit paths, and make add_key_to_keyring() only use the reference without consuming it.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93107", "url": "https://ubuntu.com/security/CVE-2026-93107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Avoid reprocessing the current packet after the QP enters the error state When do_complete() finds the QP in the error state it returns RESPST_CHK_RESOURCE. Before commit 49dc9c1f0c7e (\"RDMA/rxe: Cleanup reset state handling in rxe_resp.c\") this was the flush loop: check_resource() had an error-state branch that fetched each remaining recv WQE and completed it with IB_WC_WR_FLUSH_ERR, without touching the current packet. That commit removed the error-state branch from check_resource() (draining is now done at rxe_receiver() entry) but kept the do_complete() error-state return. As a result, when a QP moves to the error state while a packet is being completed - e.g. an rdma_cm disconnect racing with receive processing - the responder state machine loops back into the request processing chain with the already-completed packet still in hand: check_resource() fetches a fresh recv WQE, execute()/send_data_in() copies the same packet payload again, do_complete() posts another IB_WC_SUCCESS CQE (qp->resp.status is still 0), and control returns to the error-state check. The loop re-executes the same packet once per posted recv WQE (observed: ~1000 duplicate IB_WC_SUCCESS completions of one SEND, one per ~8us, matching the RQ occupancy) until the RQ is exhausted, after which qp->resp.wqe is NULL and send_data_in() dereferences it: BUG: kernel NULL pointer dereference, address: 0000000000000014 Workqueue: rxe_wq do_work RIP: copy_data+0x29/0x1f0 Call Trace: send_data_in+0x25/0x50 rxe_receiver+0xf36/0x1dd0 The duplicate completions are indistinguishable from real receives to the ULP. During an rds stress test, the message was accepted as new and delivered the same datagram to user space hundreds of times, corrupting the stream; any ULP that relies on RC exactly-once delivery is affected. A live packet reaching the error-state check in do_complete() has been executed and completed exactly once and must be consumed, not re-processed. Return RESPST_CLEANUP for it (dequeue and free); keep returning RESPST_CHK_RESOURCE for the pkt == NULL case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93108", "url": "https://ubuntu.com/security/CVE-2026-93108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ipoib: Drain RCU callbacks during module teardown IPoIB reclamation completions can be signaled from inside an RCU callback. Teardown can wake before the callback returns and unload ib_ipoib while its code is still executing. Client registration failure can also remove already-added devices and queue callbacks. Wait after client and workqueue teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93109", "url": "https://ubuntu.com/security/CVE-2026-93109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Drain RCU callbacks during module teardown devx_free_subscription() can remain queued after the last DevX event file drops its module reference or an auxiliary driver detaches its devices. mlx5_ib can then unload before the callback runs. Registration error unwind has the same risk because driver registration can attach existing devices before failing. Wait after all drivers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93110", "url": "https://ubuntu.com/security/CVE-2026-93110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Wait for RCU callbacks before unloading ib_core put_gid_ndev() is queued with call_rcu() and implemented in ib_core. Stopping the workqueues does not drain callbacks already queued, so RCU could invoke it after the module code has been unloaded. synchronize_rcu() does not wait for callbacks. Wait for them after all producers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93112", "url": "https://ubuntu.com/security/CVE-2026-93112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Require a BPF cpumask for bpf_cpumask_populate() bpf_cpumask_populate() writes to its destination with bitmap_copy(), but the destination is typed as struct cpumask *. That allows the verifier to accept borrowed cpumask pointers returned by read-only kfuncs, such as scx_bpf_get_online_cpumask(), as a writable destination. Make the destination a struct bpf_cpumask * so populate follows the same ownership rule as the other mutating cpumask kfuncs. Query kfuncs continue to accept const struct cpumask * inputs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93113", "url": "https://ubuntu.com/security/CVE-2026-93113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: camcc-sc8280xp: unregister CAMCC_GDSC_CLK With the introduction of sync_state support in the clk and pmdomain subsystems, the following warning happens when the unused clocks are shutdown in camcc-sc8280xp: [ 15.408367] titan_top_gdsc status stuck at 'on' [ 15.408429] WARNING: drivers/clk/qcom/gdsc.c:178 at gdsc_toggle_logic+0x14c/0x160, CPU#2: kworker/u32:1/14 [ 15.408462] Modules linked in: bnep vfat fat ath11k_pci(+) ath11k mac80211 cfg80211 mhi libarc4 snd_soc_wcd938x snd_soc_wcd938x_sdw snd_soc_wcd_classh hci_uart snd_soc_wcd_common snd_soc_sc8280xp soundwire_qcom snd_soc_wcd_mbhc snd_soc_qcom_sdw slimbus snd_soc_qcom_common regmap_sdw btqca btrtl qcom_camss soundwire_bus btbcm btintel snd_soc_sdca snd_soc_lpass_wsa_macro bluetooth snd_soc_lpass_tx_macro snd_soc_lpass_va_macro snd_soc_lpass_rx_macro snd_soc_hdmi_codec snd_soc_lpass_macro_common videobuf2_dma_sg ov5675 v4l2_fwnode videobuf2_memops qcom_spmi_adc5 snd_soc_core qcom_spmi_adc_tm5 videobuf2_v4l2 snd_seq snd_seq_device videobuf2_common v4l2_async qcom_vadc_common qcom_spmi_temp_alarm pm8941_pwrkey industrialio videodev snd_compress rfkill ac97_bus snd_pcm_dmaengine qcom_tsens mc qcom_edac snd_pcm pci_pwrctrl_pwrseq qcom_cpufreq_hw snd_timer snd qcomtee soundcore tee leds_gpio joydev binfmt_misc zram lz4hc_compress governor_simpleondemand panel_edp msm xhci_plat_hcd nvme nvme_core dwc3 qcom_pm8008_regulator [ 15.408688] ucsi_glink nvme_keyring nvme_auth pmic_glink_altmode udc_core typec_ucsi aux_hpd_bridge qcom_battmgr ulpi ubwc_config socinfo ocmem drm_gpuvm qcom_q6v5_pas drm_exec qcom_pil_info leds_qcom_lpg gpu_sched led_class_multicolor rtc_pm8xxx qcom_pbs qcom_common drm_display_helper qcom_pon qcom_glink_smem qcom_glink ghash_ce pwrseq_qcom_wcn gpio_sbu_mux qcom_stats phy_qcom_qmp_combo qcom_q6v5 gf128mul cec dispcc_sc8280xp phy_qcom_edp camcc_sc8280xp i2c_qcom_cci qcom_sysmon drm_dp_aux_bus mdt_loader aux_bridge qcom_pm8008 i2c_hid_of_elan dwc3_qcom_legacy llcc_qcom icc_bwmon gpi typec qcom_refgen_regulator phy_qcom_qmp_usb nvmem_qfprom qcom_ipcc phy_qcom_snps_femto_v2 gpucc_sc8280xp pinctrl_sc8280xp_lpass_lpi qcom_hwspinlock pinctrl_lpass_lpi lpasscc_sc8280xp qrtr qcom_aoss pmic_glink pdr_interface phy_qcom_qmp_pcie qcom_smd qcom_pdr_msg icc_osm_l3 qcom_wdt qmi_helpers qcom_rng smp2p rpmsg_core gpio_keys pwm_bl smem hid_multitouch fuse i2c_dev [ 15.408928] CPU: 2 UID: 0 PID: 14 Comm: kworker/u32:1 Not tainted 7.1.0+ #2 PREEMPT(lazy) [ 15.408937] Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET88W (1.60 ) 03/14/2024 [ 15.408942] Workqueue: pm pm_runtime_work [ 15.408959] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 15.408967] pc : gdsc_toggle_logic+0x14c/0x160 [ 15.408978] lr : gdsc_toggle_logic+0x14c/0x160 [ 15.408987] sp : ffff8000800f3b40 [ 15.408991] x29: ffff8000800f3b40 x28: 0000000000000000 x27: 0000000000000000 [ 15.409003] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 15.409014] x23: 0000000000000000 x22: 0000000000000001 x21: ffffa33f298fca88 [ 15.409024] x20: 0000000000000000 x19: ffffa33f298fc5b0 x18: 00cd15db75dacefd [ 15.409035] x17: 000000040044ffff x16: ffffa33f3b1a3d88 x15: 726f776b80000002 [ 15.409045] x14: ffffffffffffffff x13: 0000000000000028 x12: 0101010101010101 [ 15.409056] x11: 7f7f7f7f7f7f7f7f x10: fefeff3039313274 x9 : ffffa33f3a5edafc [ 15.409067] x8 : ffff8000800f3780 x7 : 0000000000000001 x6 : 0000000000000001 [ 15.409078] x5 : ffff000bf3ca1288 x4 : 0000000000000000 x3 : ffff5cccb6a3f000 [ 15.409088] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000080ae0000 [ 15.409098] Call trace: [ 15.409103] gdsc_toggle_logic+0x14c/0x160 (P) [ 15.409115] gdsc_disable+0x4c/0x190 [ 15.409126] _genp ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93114", "url": "https://ubuntu.com/security/CVE-2026-93114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/surface: acpi-notify: Check ACPI companion before use Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION(). Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 (\"ACPI: driver: Check ACPI_COMPANION() against NULL during probe\") does for the core ACPI platform drivers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93115", "url": "https://ubuntu.com/security/CVE-2026-93115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93117", "url": "https://ubuntu.com/security/CVE-2026-93117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: fix UAF when probe runs concurrent to dyn ID removal Dynamic IDs are only guaranteed to be valid when usb_dynids_lock is held, as remove_id_store can free the node. Thus, make a copy in usb_probe_interface. Clarify the documentation that the id parameter is only valid during the probe. USB serial has the same pattern, but it does not need fixing as the IDs cannot be removed via sysfs.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93118", "url": "https://ubuntu.com/security/CVE-2026-93118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed_udc: check endpoint DMA allocation ast_udc_probe() allocates a coherent DMA buffer used as the backing store for endpoint buffers. ast_udc_init_ep() derives per-endpoint buffer pointers from udc->ep0_buf, so a failed allocation is dereferenced during probe. Check the allocation before endpoint setup. The existing probe error path called ast_udc_remove(), which unregisters the gadget unconditionally and is not safe before usb_add_gadget_udc() succeeds. Add a local cleanup helper for probe failures so pre-registration failures only unwind the resources that were actually initialized. This was found by a local static analysis checker for unchecked allocator returns while scanning Linux 6.16. The change was checked by applying it to current mainline and by running checkpatch. I do not have access to Aspeed UDC hardware, so no runtime testing was performed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93119", "url": "https://ubuntu.com/security/CVE-2026-93119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: ljca: bound bank_num in ljca_enumerate_gpio() ljca_enumerate_gpio() reads desc->bank_num from the device and loops valid_pin[i] = get_unaligned_le32(...) for i < bank_num. valid_pin[] holds only LJCA_MAX_GPIO_NUM / 32 = 2 entries. Two checks run before the loop. The reply length must match struct_size(desc, bank_desc, bank_num). The product pins_per_bank * bank_num must not exceed LJCA_MAX_GPIO_NUM. Neither one bounds bank_num against the size of valid_pin[]. The reply is capped at LJCA_MAX_PAYLOAD_SIZE (60) bytes, so the struct_size check limits bank_num to 9. A device that reports bank_num 9 with pins_per_bank 7 still passes both checks. gpio_num is 63 and the reply is 56 bytes. The loop then writes nine u32 into the two entry array and overruns valid_pin[] on the stack. A broken or malicious LJCA device can therefore overflow the stack. Reject a bank_num that does not fit valid_pin[].", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93120", "url": "https://ubuntu.com/security/CVE-2026-93120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: fix out-of-bounds read of qw_sign os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93121", "url": "https://ubuntu.com/security/CVE-2026-93121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix fence cleanup in ffs_dmabuf_transfer() error paths The error paths for endpoint-disabled (ESHUTDOWN) and request-allocation failure (ENOMEM) in ffs_dmabuf_transfer() jump to err_fence_put which calls dma_fence_put() on the fence. However, at that point the fence has only been kmalloc'd — dma_fence_init() has not been called yet, so the refcount and the fence ops are uninitialized. Calling dma_fence_put() on such an object leads to undefined behavior. Use kfree() instead, since the fence is just a plain allocation at this stage, and rename the label to err_fence_free to reflect the actual cleanup action.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93123", "url": "https://ubuntu.com/security/CVE-2026-93123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom-geni: do not advance stale DMA completions The qcom GENI serial DMA TX completion path advances the transmit fifo by the number of bytes recorded in port->tx_remaining. If uart_flush_buffer() runs after the hardware has completed a DMA transfer but before the DMA completion interrupt has been handled, the serial core resets the transmit fifo while port->tx_remaining still describes the old DMA transfer. A previous fix avoided advancing an empty fifo by checking that the fifo length is at least tx_remaining. That still does not distinguish the old DMA payload from new bytes written after the flush. If userspace writes new data before the stale DMA completion interrupt is handled, the fifo can again contain at least tx_remaining bytes and the stale completion can advance and discard those new bytes. Mark an in-flight DMA transfer stale when the transmit fifo is flushed. The later completion still unprepares the original DMA mapping using the saved length, but it no longer advances the transmit fifo.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93126", "url": "https://ubuntu.com/security/CVE-2026-93126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: qcom_q6v5_adsp: Fix reference leak for device node When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In adsp_map_carveout, it does not release the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93128", "url": "https://ubuntu.com/security/CVE-2026-93128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: lg-laptop: Fix LED resource handling The event notification callback might access kbd_backlight even when it was not successfully registered with the LED subsystem. The same happens inside acpi_remove(), where the LED devices are unregistered unconditionally. Fix this by tracking the availability of the kbd_backlight LED device and use devm_led_classdev_register() to let devres take care of unregistering the LED devices during removal. For this the parent device of the LED devices is changed to the native platform device.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93130", "url": "https://ubuntu.com/security/CVE-2026-93130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-base: Fix resource leak on module load failure We need to properly clean up the SMBIOS request and the privacy driver when the module load fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93131", "url": "https://ubuntu.com/security/CVE-2026-93131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-privacy: Fix race condition Accessing priv->features_present needs to happen with the list mutex being held, otherwise priv can be freed at any moment.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93132", "url": "https://ubuntu.com/security/CVE-2026-93132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: RISC-V: Fix riscv_acpi_add_prt_dep() loop handling The loop in riscv_acpi_add_prt_dep() includes error conditions that are handled in a dubious - if not outright wrong - way, by continuining the loop (which skips and misses the entry pointer update to point to the next entry). Rewrite the loop as a for loop (that handles the continuation correctly) and wrap the condition and update statements using helper functions to make it cleaner.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93133", "url": "https://ubuntu.com/security/CVE-2026-93133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: RISC-V: Check acpi_get_handle() status in riscv_acpi_add_prt_dep() In riscv_acpi_add_prt_dep(), the acpi_get_handle() call can fail which would leave link_handle uninitialized. Fix it by checking the acpi_get_handle() return status and skip the entry if it fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93134", "url": "https://ubuntu.com/security/CVE-2026-93134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: printk: Fix possible console use-after-free When emitting a record via legacy printing, it is possible that a handover to another legacy printing context occurs. When a context has performed a handover, the console SRCU read lock is released and the pointer to the console struct might now be invalid. Therefore, after calling nbcon_legacy_emit_next_record() or console_emit_next_record(), it is necessary to check if a handover occurred _before_ further @con usage. Sashiko pointed out that console_flush_one_record() was not doing this. In console_flush_one_record(), after emitting a record, move the further usage of @con after the handover check.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93136", "url": "https://ubuntu.com/security/CVE-2026-93136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: mhi: ep: Fix device refcount leak in the error path of MHI device creation mhi_ep_create_device() takes one device reference for the UL channel and another for the DL channel after allocating the transfer device. These references are normally released by mhi_ep_destroy_device() before the device itself is removed. If dev_set_name() or device_add() fails, the error path currently drops only one reference. The remaining channel references keep the device from being released and leave the channels associated with a device that was never registered. Route both failures through a common unwind path that drops the DL channel reference, the UL channel reference, and the initial reference from device_initialize().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93137", "url": "https://ubuntu.com/security/CVE-2026-93137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free on mm_struct in bpf_find_vma() bpf_find_vma() reads task->mm and calls mmap_read_trylock(mm) without holding a reference on the mm. On a foreign task, a concurrent exit_mm() can free the mm_struct between the lockless read and the trylock, resulting in a use-after-free. mm_struct is not SLAB_TYPESAFE_BY_RCU. For the current task, task->mm is stable. For a foreign task, pin the mm under task->alloc_lock and release it with mmput_async(), mirroring commit d8e27d2d22b6 (\"bpf: fix mm lifecycle in open-coded task_vma iterator\"). Use spin_trylock() instead of get_task_mm() so BPF context does not block on alloc_lock. Reject irqs-disabled contexts and !CONFIG_MMU on the foreign-task path because dropping the mm reference is not safe there. Race: CPU0 (BPF program) CPU1 (exiting task) ============================ ========================== bpf_find_vma(foreign_task): mm = task->mm exit_mm(): task->mm = NULL mmput(mm) -> frees mm_struct mmap_read_trylock(mm) // UAF on mm", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93138", "url": "https://ubuntu.com/security/CVE-2026-93138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the bpf_verifier_lock, but publishes the result through a plain store and re-checks it through a plain lockless load. Nothing orders the stores initializing the struct btf inside btf_parse_vmlinux() against the store publishing the pointer: On a weakly ordered arch, a concurrent first-time caller taking the lockless fast path could in principle observe the pointer before the parsed contents are visible. The mutex_unlock() does not help such a reader given it only synchronizes with a later acquisition of the same lock. Thus, publish the pointer with smp_store_release() and read it on the fast path with smp_load_acquire(). Acquire semantics are needed rather than a dependency-ordered READ_ONCE(): btf_parse_vmlinux() also populates globals outside the returned object (e.g. bpf_ctx_convert.t). An address dependency would only order accesses performed through the pointer and not cover other globals.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93140", "url": "https://ubuntu.com/security/CVE-2026-93140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 (\"udf: Mark LVID buffer as uptodate before marking it dirty\"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 udf_reconfigure+0x336/0x540 fs/udf/super.c:679 reconfigure_super+0x232/0x8f0 fs/super.c:1080 vfs_cmd_reconfigure fs/fsopen.c:268 [inline] vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297 __do_sys_fsconfig fs/fsopen.c:463 [inline] __se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350 do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93141", "url": "https://ubuntu.com/security/CVE-2026-93141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: r8a66597: avoid double free of ep0_req in probe error path If usb_add_gadget_udc() fails, r8a66597_probe() jumps to err_add_udc and frees ep0_req, then falls through to clean_up2 where ep0_req is freed again when it is non-NULL. Remove the redundant free from err_add_udc and keep the cleanup in clean_up2 so the request is released exactly once. Issue found using a prototype static analysis tool and confirmed by code review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93142", "url": "https://ubuntu.com/security/CVE-2026-93142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/rcar: Fix error checking in probe() This code accidentally calls thermal_zone_device_enable() before checking whether thermal_zone_device_register_with_trips() failed. Move the call until later to avoid an error pointer dereference of \"priv->zone\". The driver works differently depending on if we are using OF thermal or not. We use thermal_add_hwmon_sysfs() if we are using OF thermal and call thermal_zone_device_enable() if not. We can share same error check for if either of these fail. Moving the thermal_zone_device_enable() call is a bit cleaner as well. The original code used a three step process to cleanup: 1. Call thermal_zone_device_unregister() to cleanup. 2. Set priv->zone to an error pointer to preserve the error code. 3. Set priv->zone to NULL to avoid a second call to thermal_zone_device_unregister() in the rcar_thermal_remove() function. Now we can just do a direct goto error_unregister and rcar_thermal_remove() handles the cleanup properly.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93143", "url": "https://ubuntu.com/security/CVE-2026-93143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: media: ipu7: fix pm_runtime refcount leak in ipu7_resume() ipu7_resume() calls pm_runtime_get_sync() before resuming the device. If the runtime PM resume fails, the usage count remains incremented, but the error path returns without dropping the reference. Use pm_runtime_resume_and_get() instead, which balances the usage count on failure and avoids the leak. Keep returning 0 on error, as resume callbacks should not propagate failures to the PM core, matching the behaviour of the ipu6 driver.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93145", "url": "https://ubuntu.com/security/CVE-2026-93145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister() gdsc_unregister() removes the OF provider entry and tears down the parent/subdomain wiring, but never calls pm_genpd_remove() on the individual generic_pm_domain structures registered by gdsc_init(): \tvoid gdsc_unregister(struct gdsc_desc *desc) \t{ \t\tstruct device *dev = desc->dev; \t\tsize_t num = desc->num; \t\tgdsc_pm_subdomain_remove(desc, num); \t\tof_genpd_del_provider(dev->of_node); \t} That leaves dangling entries on the global gpd_list. After a provider unbind/rebind cycle (deferred-probe replay during early boot, real module unload of a clk driver that owns GDSCs, or an OF-overlay tear- down) the next gdsc_init() will end up trying to re-register a name that is still in the list and pm_genpd_init() returns -EEXIST. While we are here, flip the order so the consumer-facing OF provider entry is the first thing removed -- otherwise a fresh of_genpd_get_from_provider() call racing with the teardown could attach to a domain that is mid-removal. Iterate the scs[] array and pm_genpd_remove() each registered domain after the subdomain links are torn down. The regulators stay devm- managed (devm_regulator_get_optional() in gdsc_register()), so the release happens automatically when the underlying device is unbound; just the genpd accounting needs to be undone explicitly.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93146", "url": "https://ubuntu.com/security/CVE-2026-93146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: time/namespace: Validate nanosecond field in proc_timens_set_offset() The function validates tv_sec to be within [-KTIME_SEC_MAX, KTIME_SEC_MAX] but never validates that tv_nsec is within the valid range of [0, NSEC_PER_SEC-1] before using it in timespec64_add(). timespec64_add() expects both timespec64 structures to have normalized values with tv_nsec in the range [0, 999999999]. If off->val.tv_nsec contains invalid values (negative or >= NSEC_PER_SEC), it could lead to incorrect calculations or unexpected behavior. Add validation to ensure tv_nsec is within the valid range before performing the addition.", "cve_priority": "negligible", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93149", "url": "https://ubuntu.com/security/CVE-2026-93149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: avoid NULL skb in stop queue drain mac80211_hwsim_stop() drops any frames left in data->pending. The loop currently checks skb_queue_empty() and then dequeues separately. That split is racy with TX status handling, which can remove a pending frame under the queue lock. If the last entry is removed after the empty check, skb_dequeue() returns NULL and the stop path passes that NULL skb to ieee80211_free_txskb(). Use skb_dequeue() as the loop condition instead. The dequeue result is the object that stop owns and frees, and a concurrent status completion that empties the queue simply makes the loop terminate.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93150", "url": "https://ubuntu.com/security/CVE-2026-93150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Make nr_deadline_tasks an atomic_t The nr_deadline_tasks variable in the cpuset structure was introduced by commit 6c24849f5515 (\"sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets\"). It is reported by sashiko [1] that nr_deadline_tasks can currently be modified by inc_dl_tasks_cs() under rq->lock and by cpuset_attach() under cpuset_mutex. So if both updates happen simultaneously, the nr_deadline_tasks variable can be corrupted leading to incorrect operations down the road. Fix that by changing its type to atomic_t so that nr_deadline_tasks are always atomically updated. This fix patch is a low hanging fruit. It can handle some of the races between a concurrent sched_setscheduler() and cpuset_can_attach()/cpuset_attach() calls, but not all of them like the other issue raised by sashiko [2]. This will be handled hopefully in a future follow up patch. [1] https://sashiko.dev/#/patchset/20260626181923.133658-1-longman%40redhat.com [2] https://sashiko.dev/#/patchset/20260630033344.352702-1-longman%40redhat.com", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93151", "url": "https://ubuntu.com/security/CVE-2026-93151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: fix response resource leak on queue teardown When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs. These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows: unreferenced object 0xffff88812bc490c0 (size 32): comm \"kworker/2:1H\", pid 409, jiffies 4307744490 backtrace (crc 89afd339): __kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 unreferenced object 0xffff88814bd05e80 (size 64): comm \"kworker/3:1H\", pid 148, jiffies 4295195428 backtrace (crc e35510cb): __kmalloc_noprof+0x5f9/0x890 rdma_rw_ctx_init+0x333/0x1fa0 [ib_core] nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmet_rdma_free_rsp_resources() that frees up the RDMA read/write context and the request SGLs of such responses.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93152", "url": "https://ubuntu.com/security/CVE-2026-93152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-apple: Use acquire/release for queue enabled state apple_nvme_init_queue() initializes queue state and then marks the queue enabled. The interrupt and request paths check enabled before using that queue state. The old wmb() after WRITE_ONCE(enabled, true) does not publish the earlier initialization before enabled becomes visible. Use a release store when enabling the queue and acquire loads when testing it. Although the shutdown-side enabled accesses are not used for publishing queue initialization, use helpers for them as well for consistency.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93154", "url": "https://ubuntu.com/security/CVE-2026-93154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Add refcounting to user ring MRs Prevent userspace from deregistering the MRs that back QP/CQ/SRQ rings by bumping the MR's refcount upon association.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93155", "url": "https://ubuntu.com/security/CVE-2026-93155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Fix AEAD unregister count in error path register_aes_algs() registers the AEAD algorithms before registering the skcipher algorithms. If skcipher registration fails, the function unwinds the earlier AEAD registration with crypto_engine_unregister_aeads(), but it passes ARRAY_SIZE(algs), which is the skcipher table size. Use ARRAY_SIZE(algs_aead) for the AEAD unwind path so the unregister helper iterates over the same table that was registered. Also clarify the nearby comment: the crypto registration helpers clean up algorithms registered within the same call, while this function must still unwind earlier successful registration steps.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93156", "url": "https://ubuntu.com/security/CVE-2026-93156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: rk3288 - fail ahash requests on HASH idle timeout rk_hash_run() waits for RK_CRYPTO_HASH_STS to become idle after the final DMA transfer, but ignores the poll result. If the hash engine never becomes idle, the driver still reads the digest registers and finalizes the request with the previous success value. Store the poll result and finalize the request with the timeout error before reading the digest registers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93157", "url": "https://ubuntu.com/security/CVE-2026-93157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwrng: xilinx-trng - propagate timeout before any data is read xtrng_readblock32() polls for 16-byte chunks but returns the number of bytes read even when the first poll times out. Its caller then treats a zero return as a short successful read, and partial reads for full 32-byte blocks can make the tail copy use a fixed block offset rather than the amount already produced. Return the poll error when no data has been read, preserve partial positive returns after some data is available, stop the generator on all collection exits, and append tail bytes at the current output count.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93158", "url": "https://ubuntu.com/security/CVE-2026-93158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sa2ul - stop probe if context pool creation fails sa_ul_probe() calls sa_init_mem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool. Stop probing when sa_init_mem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93159", "url": "https://ubuntu.com/security/CVE-2026-93159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure The nonblocking RNG path allocates a work_data structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes. If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated work_data is not usable for producing RNG output and must not remain associated with the hwrng state. Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data. Fix this by freeing the pending work_data. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93160", "url": "https://ubuntu.com/security/CVE-2026-93160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-ecc - reject hardware ECDH without a public key The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the private key stored in the device. However, the public key is cached only after atmel_ecdh_set_secret() successfully generated that private key for the current tfm. atmel_ecdh_generate_public_key() already rejects requests when no public key is cached. Add the same check to atmel_ecdh_compute_shared_secret() to prevent the device from using a private key that was not generated for the current tfm.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93161", "url": "https://ubuntu.com/security/CVE-2026-93161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - clear AES key schedule from stack qat_alg_xts_reverse_key() expands the forward XTS AES key on the stack. That schedule contains key material and can remain in the stack frame. Clear the temporary crypto_aes_ctx with memzero_explicit() after the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93162", "url": "https://ubuntu.com/security/CVE-2026-93162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - cancel work on re-enable SR-IOV timeout The QAT reset worker queues SR-IOV reenable work using a work_struct and completion embedded in an on-stack adf_sriov_dev_data. If the completion wait times out, the reset worker can return while device_sriov_wq still holds or executes the stack-backed work item. Cancel the work on the device_sriov_wq on timeout before the stack frame unwinds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93163", "url": "https://ubuntu.com/security/CVE-2026-93163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwrng: core - fix rng list on registration error hwrng_register(rng) does the following: 1. Checks if rng has name and read methods set 2. Checks if the name already exists 3. Adds rng to global rng_list 4. May try to set rng to current_rng If step 4 fails, it returns an error. However, it does not remove the rng from rng_list, causing a dangling reference which can result in use-after-free if the caller frees rng, since registration failed. Add a list_del_init() cleanup step.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93165", "url": "https://ubuntu.com/security/CVE-2026-93165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Fix memory overread in ring handler `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93167", "url": "https://ubuntu.com/security/CVE-2026-93167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: csky: Fix a4/a5 restoration in syscall trace path The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid. The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments. This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with: mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0) Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0. Fix the trace path by loading a4/a5 from pt_regs before changing sp. Tested on: ck860f, linux-4.19.15, C-SKY abiv2", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93169", "url": "https://ubuntu.com/security/CVE-2026-93169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: zynqmp_dma: fix race between runtime PM and device removal In zynqmp_dma_remove(), runtime PM was disabled only after checking state and doing a manual suspend. This can race with runtime PM in the remove/unbind (rmmod) path. Disable runtime PM first, then suspend only if the device is not already suspended. To prevent any further runtime PM transitions.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93170", "url": "https://ubuntu.com/security/CVE-2026-93170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed. The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinx_dma_complete_descriptor() moves completed descriptors to done_list. 4. Channel is marked idle and start_transfer() is called even though active_list still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions. Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93172", "url": "https://ubuntu.com/security/CVE-2026-93172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug We miss a failed allocation check for pgdat->per_cpu_nodestats, which results in a NULL deref when we offset into the per-cpu area. Propagate -ENOMEM up the stack and leave per_cpu_nodestats pointing at boot_nodestats so a later online can retry the allocation. hotadd_init_pgdat() returns NULL on failure, which __try_online_node() already maps to -ENOMEM. On failure nothing needs to be unwound: - the node is never marked online - per_cpu_nodestats is left pointing at boot_nodestats - __add_memory_resource() cleans up pending memblock resources - later online attempts retry the per_cpu_nodestats allocation", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93173", "url": "https://ubuntu.com/security/CVE-2026-93173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf,lsm: Drop bpf_prog_free from sleepable_lsm_hooks __bpf_prog_put_rcu() is the call_rcu() callback for non-sleepable programs. security_bpf_prog_free() called from there fires bpf_prog_free in softirq; if a sleepable LSM prog is attached to that hook, might_fault() BUGs: BUG: sleeping function called from invalid context in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 5038 preempt_count: 101, expected: 0 Call Trace: __bpf_prog_enter_sleepable+0x1cd/0x320 kernel/bpf/trampoline.c:1255 bpf_trampoline_6442549705+0x53/0xd7 security_bpf_prog_free+0xde/0x130 security/security.c:5465 __bpf_prog_put_rcu+0xab/0xd0 kernel/bpf/syscall.c:2365 rcu_do_batch kernel/rcu/tree.c:2617 [inline] handle_softirqs+0x236/0x800 kernel/softirq.c:622 The call_rcu/call_rcu_tasks_trace split reflects the freed program's sleepability, not that of any attached observer. security_bpf_prog_free() also frees prog->aux->security, which has to stay after the grace period, so drop bpf_prog_free from sleepable_lsm_hooks rather than move the call. Non-sleepable observers still run there.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93174", "url": "https://ubuntu.com/security/CVE-2026-93174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Copy per-CPU map value padding in copy_map_value_long() In kernel, per-CPU map elements are stored with round_up(map->value_size, 8) bytes. On UAPI lookup paths, it copies the rounded size for each CPU into a temporary buffer. However, copy_map_value_long() passes 'map->value_size' to bpf_obj_memcpy(). When the map has special fields, bpf_obj_memcpy() copies around those fields with memcpy(), and does not copy the tail padding between 'map->value_size' and round_up(map->value_size, 8). The temporary UAPI lookup buffers are allocated without __GFP_ZERO. As a result, when the per-CPU map's value size is not equal to round_up(map->value_size, 8), UAPI LOOKUP_ELEM and its variants can return stale heap contents from that padding to user space. The same issue applies to bpf_iter for per-CPU maps. Pass round_up(map->value_size, 8) to bpf_obj_memcpy() from copy_map_value_long(), so per-CPU maps both with and without special fields copy the entire per-CPU slot. Remove the now redundant round_up() from bpf_obj_memcpy()'s long_memcpy path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93177", "url": "https://ubuntu.com/security/CVE-2026-93177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup vddInd, vddciInd and mvddInd from VBIOS-parsed tables index into vddc, vddci and vddmem lookup tables without bounds checks across nine sites. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93178", "url": "https://ubuntu.com/security/CVE-2026-93178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup vddInd and vddcInd fields from VBIOS-parsed tables are used to index into voltage lookup tables without a bounds check. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93182", "url": "https://ubuntu.com/security/CVE-2026-93182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix overflow in update_tg_cfs_runnable() A divide-by-zero crash is observed when running hackbench: [14697.488452] CPU: 112 UID: 0 PID: 124791 Comm: hackbench Not tainted 7.1.0-rc2+ [14697.492627] RIP: 0010:propagate_entity_load_avg+0x35f/0x3e0 [14697.506799] [14697.507411] __dequeue_task+0x2b4/0xc70 [14697.508677] dequeue_task_fair+0x36/0x370 [14697.509047] dequeue_task+0x101/0x2f0 [14697.509426] __schedule+0x1b1/0x1a00 [14697.510868] anon_pipe_read+0x3da/0x450 [14697.511400] vfs_read+0x361/0x390 [14697.512053] __x64_sys_read+0x19/0x30 The divide-by-zero happens here: if (scale_load_down(gcfs_rq->load.weight)) { load_sum = div_u64(gcfs_rq->avg.load_sum, scale_load_down(gcfs_rq->load.weight)); } gcfs_rq->load.weight is an insane large value and is truncated to the lower 32 bits by div_u64, which happen to be 0. Using AI for investigation, the cause is a u32 overflow in update_tg_cfs_runnable(), and flat pickup became a victim when using tg_tasks(): u32 new_sum, divider; ... new_sum = se->avg.runnable_avg * divider; <-- boom The following sequence shows how this triggers the crash: propagate_entity_load_avg() update_tg_cfs_runnable() # u32 overflow corrupts runnable_sum __update_load_avg_cfs_rq() ___update_load_avg() # computes insane runnable_avg update_tg_load_avg() # propagates to tg->runnable_avg update_cfs_group() calc_concur_shares() tg_tasks() # long-to-int truncation, negative nr reweight_entity() # corrupted se->load.weight update_load_add() # corrupted cfs_rq->load.weight propagate_entity_load_avg() update_tg_cfs_load() div_u64() # divide-by-zero Fix by widening new_sum from u32 to u64 (no need to force tg_tasks() to return unsigned long after this fix)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93183", "url": "https://ubuntu.com/security/CVE-2026-93183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/lima: call drm_mm_init() with a valid allocation range lima_vm_create() is currently run before va_start and va_end are set up, meaning they are both 0. lima_vm_create() runs drm_mm_init() with them as arguments for the allocator, and if DRM_DEBUG_MM is enabled the DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on exynos4412-odroid-u2: [ 1.736297] ------------[ cut here ]------------ [ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931! [ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 1.750697] Modules linked in: [ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT [ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree) [ 1.769446] Workqueue: events_unbound deferred_probe_work_func [ 1.775261] PC is at drm_mm_init+0x9c/0xa4 [ 1.779339] LR is at lima_vm_create+0x144/0x17c [ ... ] Fix the issue by moving the lima_vm_create() call after va_start and va_end are set up.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93184", "url": "https://ubuntu.com/security/CVE-2026-93184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl_audmix: rework runtime PM handling in probe After pm_runtime_enable() the AUDMIX block is powered off and stays suspended until the first runtime resume. Register writes issued between probe() and the first resume (e.g. from DAPM or ALSA control paths) target unpowered hardware and cause a system hang. Fix this by calling pm_runtime_resume_and_get() immediately after pm_runtime_enable() to power the hardware up and enable its clocks. Release the reference afterwards with pm_runtime_put() to allow the runtime PM framework to suspend the device and switch the regmap to cache-only mode when idle. When CONFIG_PM is disabled or runtime PM is not enabled, pm_runtime_* calls are stubs that do not power up the hardware. Handle this case explicitly by calling fsl_audmix_runtime_resume() directly so the hardware is always initialised and its clocks are enabled, ensuring register accesses succeed regardless of PM configuration.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93185", "url": "https://ubuntu.com/security/CVE-2026-93185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rt700-sdw: always drain jack work on remove rt700_sdw_remove() drains jack_detect_work and jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status() when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as the remove-time guard for draining these work objects. The delayed works are initialized during rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove path should drain work based on whether the work object exists, not on a runtime hardware state bit that can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED, and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a reachable race on current systems.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93186", "url": "https://ubuntu.com/security/CVE-2026-93186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/mbox: Clamp mailbox output allocation to the payload size CXL_MEM_SEND_COMMAND bounds the user's in.size to the mailbox payload size but leaves out.size unbounded, then cxl_mbox_cmd_ctor() calls kvzalloc(out.size). A large out.size drives a huge allocation, above INT_MAX it WARNs and taints, and with panic_on_warn=1 it panics. The transport __cxl_pci_mbox_send_cmd() already clamps the response copy to min(out.size, payload_size, device len), so the output buffer is never written beyond payload_size. Clamp the allocation to payload_size too, matching the RAW path.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93188", "url": "https://ubuntu.com/security/CVE-2026-93188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: bound device-supplied profile index kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93189", "url": "https://ubuntu.com/security/CVE-2026-93189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: quiesce input in hid_hw_stop() to prevent use-after-free A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver. Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path (\"hwmon: prevent packets from going to driver for probe\", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93190", "url": "https://ubuntu.com/security/CVE-2026-93190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_typec: Reject out-of-bounds PD cap count cros_typec_register_partner_pdos() copies the partner PDOs from the EC TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array. \tmemcpy(caps_desc.pdo, resp->source_cap_pdos, \t sizeof(u32) * resp->source_cap_count); \t... \tmemcpy(caps_desc.pdo, resp->sink_cap_pdos, \t sizeof(u32) * resp->sink_cap_count); PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields from the EC. The only check is that they are not both zero. If either is larger than 7, the memcpy writes past the end of the array on the stack. A count of 255 overflows it by about 1 KB. The EC source arrays are only seven entries wide. A larger count reads past them too. The ChromeOS EC firmware caps these counts today, so a compliant setup does not hit this. The kernel should still validate these values rather than trust them. Validate the counts in cros_typec_register_partner_pdos() next to the memcpy. Skip the PDO registration if either count is above PDO_MAX_OBJECTS. The rest of cros_typec_handle_status() still runs so events are handled and cleared.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93191", "url": "https://ubuntu.com/security/CVE-2026-93191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix incorrect task context in smack_msg_queue_msgrcv The smack_msg_queue_msgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task. In the msgsnd() syscall path, if a receiver is already waiting, the pipelined_send() optimization is used to push the message directly to the receiver task: ipc/msg.c`pipelined_send(): ` smp_store_release(&msr->r_msg, msg) In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->r_tsk, passed as the 'target' parameter): ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, target := msr->r_tsk,,) However, smack_msg_queue_msgrcv() ignores the 'target' and checks 'current': smack_msg_queue_msgrcv(…) ` smk_curacc_msq(isp, MAY_READWRITE); // current task 'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy. Test: 1) create a sysv message queue with label “foo” 2) echo \"bar foo r\" >/smack/load2 3) msgrcv(,,,0,MSG_NOERROR) in \"bar\"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a \"foo\"-labeled task: \"bar\"-labeled task gets the message. This patch fixes the issue by checking permission on the 'target' task instead of 'current'. (2008-02-04, Casey Schaufler)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93192", "url": "https://ubuntu.com/security/CVE-2026-93192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Clear queue->active_job when v3d_fence_create() fails The run_job() callbacks for BIN, RENDER, TFU and CSD assign the incoming job to queue->active_job before calling v3d_fence_create(). If v3d_fence_create() fails, the callback returns NULL without clearing active_job, leaving a dangling pointer. Create a failure path in all run_job() callbacks that clears the active job before returning NULL. The BIN path takes queue->queue_lock around the clear as it races against v3d_overflow_mem_work(); RENDER, TFU and CSD paths have no concurrent reader, so the clear is lock-free.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93193", "url": "https://ubuntu.com/security/CVE-2026-93193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Fix OF node reference leak via auto cleanup Sashiko reported a reference leak in rockchip_dp_drm_encoder_enable(), the of_get_child_by_name() function does not call of_node_put() in a symmetrical way [1]. Fix the device node reference leak by using __free(device_node) to automatically manage of_node_put() for all device nodes.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93194", "url": "https://ubuntu.com/security/CVE-2026-93194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: dw_dp: Release core resources Core resources such as the DisplayPort AUX channel get initialized and registered during dw_dp_bind(), but are never unregistered, which may lead to memory leaks and/or use-after-free: [ 224.661371] BUG: KASAN: slab-use-after-free in device_is_dependent+0xe0/0x2b0 [ 224.662015] Read of size 8 at addr ffff00011aee8550 by task modprobe/658 [ 224.662612] [ 224.662752] CPU: 7 UID: 0 PID: 658 Comm: modprobe Not tainted 7.0.0-rc2-next-20260305 #14 PREEMPT [ 224.662759] Hardware name: Radxa ROCK 5B (DT) [ 224.662762] Call trace: [ 224.662764] show_stack+0x20/0x38 (C) [ 224.662772] dump_stack_lvl+0x6c/0x98 [ 224.662777] print_report+0x160/0x4b8 [ 224.662783] kasan_report+0xb4/0xe0 [ 224.662790] __asan_report_load8_noabort+0x20/0x30 [ 224.662796] device_is_dependent+0xe0/0x2b0 [ 224.662802] device_is_dependent+0x108/0x2b0 [ 224.662808] device_link_add+0x1f8/0x10b0 [ 224.662813] devm_of_phy_get_by_index+0x120/0x200 [ 224.662819] dw_dp_bind+0x34c/0xb10 [dw_dp] [ 224.662830] dw_dp_rockchip_bind+0x194/0x250 [rockchipdrm] [ 224.662864] component_bind_all+0x3a8/0x720 [ 224.662869] rockchip_drm_bind+0x120/0x390 [rockchipdrm] [ 224.662899] try_to_bring_up_aggregate_device+0x76c/0x838 [ 224.662904] component_master_add_with_match+0x1f4/0x230 [ 224.662909] rockchip_drm_platform_probe+0x420/0x538 [rockchipdrm] [ 224.662939] platform_probe+0xe8/0x168 [ 224.662945] really_probe+0x340/0x828 [ 224.662950] __driver_probe_device+0x2e0/0x350 [ 224.662954] driver_probe_device+0x80/0x140 [ 224.662959] __driver_attach+0x398/0x460 [ 224.662964] bus_for_each_dev+0xe0/0x198 [ 224.662968] driver_attach+0x50/0x68 [ 224.662972] bus_add_driver+0x2a0/0x4c0 [ 224.662977] driver_register+0x294/0x360 [ 224.662982] __platform_driver_register+0x7c/0x98 [ 224.662987] rockchip_drm_init+0xc4/0xff8 [rockchipdrm] Since a previous commit exported dw_dp_unbind() function in DW DP core library to take care of the necessary cleanup, use this in the component's unbind() callback, as well as in its bind() error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93195", "url": "https://ubuntu.com/security/CVE-2026-93195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: synopsys: dw-dp: Support unregistering the AUX channel The DisplayPort AUX channel gets initialized and registered during dw_dp_bind(), but it is never unregistered, which may lead to resource leaks and/or use-after-free. Add the missing dw_dp_unbind() function to allow the users of the library to handle the required cleanup, i.e. unregister the AUX adapter.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93198", "url": "https://ubuntu.com/security/CVE-2026-93198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-pcache: validate the persisted dirty_tail chain at load The writeback worker follows the persisted dirty_tail chain, which is decoded from the cache device independently of the key_tail chain that cache_replay() walks and bounds. A crafted image, whose on-media fields are authenticated only by a crc32c with a fixed seed, can aim dirty_tail at a chain of last ksets that never terminates, so cache_writeback_fn() re-arms itself with no delay forever. Walk the dirty_tail chain once at load with the same hop cap cache_replay() uses and fail the table load with -EIO if it does not reach an end within n_segs hops.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93200", "url": "https://ubuntu.com/security/CVE-2026-93200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix use-after-free of master->this sysfs attribute callbacks for the master controller device dereference master->this. However, master->this is freed in i3c_master_detach_free_devs() before the master device itself is released. As a result, sysfs accesses can dereference a freed master->this pointer, leading to a use-after-free. Keep master->this alive until i3c_masterdev_release(), which is called after the master device and its sysfs state are being torn down. Do not free master->this as part of the normal device detach path. On the error path in i3c_master_set_info(), reset master->this and bus.cur_master to NULL before freeing the allocated device.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93199", "url": "https://ubuntu.com/security/CVE-2026-93199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Do not treat master device as a duplicate target i3c_master_search_i3c_dev_duplicate() searches the bus for another I3C device with the same PID as the reference device. The search can match master->this, causing the controller itself to be returned as a duplicate. Since the controller is not a target device, it cannot be a duplicate of one. Exclude master->this from matching so that the function only returns real duplicate target devices.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93196", "url": "https://ubuntu.com/security/CVE-2026-93196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm: virtio_pmem: refcount requests for token lifetime KASAN reports slab-use-after-free in __wake_up_common(): BUG: KASAN: slab-use-after-free in __wake_up_common+0x114/0x160 Read of size 8 at addr ffff88810fdcb710 by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-next-20260220-00006-g1eae5f204ec3 #4 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Call Trace: dump_stack_lvl+0x6d/0xb0 print_report+0x170/0x4e2 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __virt_addr_valid+0x1dc/0x380 kasan_report+0xbc/0xf0 ? __wake_up_common+0x114/0x160 ? __wake_up_common+0x114/0x160 __wake_up_common+0x114/0x160 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 __wake_up+0x36/0x60 virtio_pmem_host_ack+0x11d/0x3b0 ? sched_balance_domains+0x29f/0xb00 ? __pfx_virtio_pmem_host_ack+0x10/0x10 ? _raw_spin_lock_irqsave+0x98/0x100 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 vring_interrupt+0x1c9/0x5e0 ? __pfx_vp_interrupt+0x10/0x10 vp_vring_interrupt+0x87/0x100 ? __pfx_vp_interrupt+0x10/0x10 __handle_irq_event_percpu+0x17f/0x550 ? __pfx__raw_spin_lock+0x10/0x10 handle_irq_event+0xab/0x1c0 handle_fasteoi_irq+0x276/0xae0 __common_interrupt+0x65/0x130 common_interrupt+0x78/0xa0 virtio_pmem_host_ack() wakes a request that has already been freed by the submitter. This happens when the request token is still reachable via the virtqueue, but virtio_pmem_flush() returns and frees it. Fix the token lifetime by refcounting struct virtio_pmem_request. virtio_pmem_flush() holds a submitter reference, and the virtqueue holds an extra reference once the request is queued. The completion path drops the virtqueue reference, and the submitter drops its reference before returning.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93202", "url": "https://ubuntu.com/security/CVE-2026-93202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix recursive locking during device registration i3c_master_register_new_i3c_devs() registers newly discovered devices while holding i3c_bus_normaluse_lock(), a down_read(). device_register() can immediately probe the device, and probe callbacks typically invoke I3C helpers that take i3c_bus_normaluse_lock() again, leading to a recursive acquisition of the same rwsem. rwsems do not support recursive read locking and can deadlock when a writer is waiting. See the \"Recursive read locks\" section of Documentation/locking/lockdep-design.rst. For example, with Intel LPSS I3C, LOCKDEP generates a WARNING like: # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/unbind # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/bind WARNING: possible recursive locking detected kworker/5:1/94 is trying to acquire lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_device_match_id+0x45/0x370 but task is already holding lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_master_reg_work_fn+0x21/0x5f0 Fix this by separating device creation from device registration. Populate desc->dev under the maintenance lock, collect the devices that still need registration into a local list, then release the lock before calling device_register(). Finally retake the lock and clean up any devices that failed to register. Use the maintenance lock rather than the normal-use lock while adding device objects. A write-side maintenance lock prevents readers from observing a partially initialized desc->dev during initial device population, or desc->dev disappearing if registration fails. The local list requires a list node, so add a list node member to struct i3c_device.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93203", "url": "https://ubuntu.com/security/CVE-2026-93203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: avoid CRC corruption due to parallel claim add batadv_bla_add_claim() is used to add claims and modify the backbone of claims for CLAIM frames from remote backbones and local packets. When it handles a claim, it needs to either * add the new claim's CRC to the backbone CRC * remove the already existing claim's CRC from the old backbone and add it to the new backbone But when the \"new\" claim code was running in parallel to the \"change backbone\" code, it can happen that the CRC was invalid because the backbone_gw of the claim was changed twice in the \"new\" claim code path: * CPU0 creates the claim for gateway A and publishes it in the claim hash. The crc16 of the address has not yet been added to A's crc at this point. * CPU1 processes a claim frame of gateway B for the same client, finds the just published claim, and performs the ownership change: it switches the pointer to B, removes the crc16 from A's crc - which never contained it - and adds it to B's crc. * CPU0 continues behind the creation branch, unconditionally switches the pointer back to A without compensating B's crc (its remove_crc is false for the creation path), and finally adds the crc16 to A's crc The CRC is then wrong for both: * claim belongs to A: but CRC is not part of backbone A's CRC * claim doesn't belong to B: CRC is still part of backbone B's CRC This wrong CRC is never recomputated from the stored claims. For local backbone claims, this can also not recovered using syncs. To avoid this, split the functionality in clear separate parts: * new claim which always adds claim CRC to the backbone CRC (but never changes the already set backbone_gw of the claim back) * update of existing claim which automatically changes the backbone_gw entry and only updates both backbone CRCs when there was an actual change", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93204", "url": "https://ubuntu.com/security/CVE-2026-93204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: atomically update mac addresses When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" } ], "log": [ "", " * resolute/linux: 7.0.0-41.41 -proposed tracker (LP: #2170001)", "", " * Fix SDCA jack detection race and reprobe issues on Dell Slate Max platform", " with CirrusLogic audio solution (LP: #2163215)", " - ASoC: Add a component fixup_controls callback", " - SAUCE: ASoC: SDCA: Bind jack interrupts to their control after card", " probe", " - SAUCE: ASoC: SDCA: Do not leak or reuse jack state across a card rebind", "", " * [SRU] Fix for storage corruption on 64 bit DMA on AMD platforms", " (LP: #2166838)", " - ata: Use named initializers for pci_device_id arrays", " - Revert \"ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585\"", "", " * Fix missing headset on Dell QCx1255 models (LP: #2169175)", " - ALSA: hda/realtek - Add headset mode for Dell Pro QC1255", "", " * RTC device disappears after updating to 7.0.0-39-generic (LP: #2169736)", " - ACPI: x86/rtc-cmos: Use platform device for driver binding", " - ACPI: PNP: Drop CMOS RTC PNP device support", " - rtc: cmos: Use platform_get_irq_optional() in cmos_platform_probe()", "", " * Resolute update: upstream stable patchset 2026-10-07 (LP: #2169900)", " - drm/amd/display: Atomize IRQ register read/modify/write ops", " - ALSA: hda/realtek: Limit Star Labs internal mic boost", " - ALSA: hda/realtek: Add StarFighter HDA SSID", " - remoteproc: qcom_q6v5_adsp: Fix iommu_unmap() usage", " - KVM: s390: Fix IRQ injection with SIGP Stop and Store Status", " - s390/uv: Fix loop condition in uv_find_secrets", " - s390/uv: Prevent potential out-of-bounds read", " - bpf: Fix bpf_skb_change_tail wrt csum partial skbs", " - bpf: Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL", " - selftests/ftrace: Fix unique symbol check in kprobe_non_uniq_symbol.tc", " - bpf: Fix divide-by-zero in btf_struct_walk()", " - bpf: Fix out-of-bounds read of sk_protocol in bpf_sock_destroy()", " - tcp: Skip cond_resched() in inet_csk_listen_stop() under BPF context", " - HID: multitouch: Add report ID mismatch quirk for ASUS ROG Z13 Folio", " - HID: elecom: fix bus type for M-XGL20DLBK", " - KVM: x86/pmu: Move Intel PMU global MSRs to intel_is_valid_msr()", " - bpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch()", " - bpf: Fix out-of-bounds read of rtt_min in sock_ops", " - bpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk", " - bpf, sockmap: Fix self-redirect copied_seq double-counting", " - bpf, arm64: set up the frame pointer for the exception callback", " - pinctrl: meson: Fix typo in s4 group name", " - HID: amd_sfh: Validate PCI BAR size before mapping", " - HID: bpf: fix __hid_bpf_hw_check_params report length", " - KVM: riscv: Fix NACL hfence entry update order", " - RISC-V: KVM: Preserve firmware counter value across stop/start", " - RISC-V: KVM: Report snapshot write failure to the guest", " - RISC-V: KVM: Fix perf-backed counter accounting across stop and read", " - KVM: arm64: vgic-its: Free the caches when GITS_BASER changes", " - KVM: arm64: vgic-its: Skip unreachable devices instead of failing the", " save", " - KVM: arm64: Validate the SVE vector length in pkvm_vcpu_init_sve()", " - KVM: arm64: Do not clear VM-wide SVE feature on vCPU init failure", " - KVM: arm64: Derive GUEST_HAS_SVE from the SVE feature bit at EL2", " - KVM: arm64: Return -EINVAL for an empty SMCCC filter range at base 0", " - KVM: arm64: Fix FGT mapping for HFGITR_EL2.nGCSEPP", " - squashfs: Add dictionary size range check to prevent shift-out-of-bounds", " - scsi: sd_zbc: Reject disks with too many zones", " - pinctrl: sunxi: A523: fix voltage withstand encoding", " - Bluetooth: SMP: reject Security Request over BR/EDR", " - Bluetooth: btnxpuart: Fix skb leak in nxp_process_fw_dump()", " - Bluetooth: mgmt: Dequeue pending mesh_send_sync entries on cancel", " - selftests: cgroup: give the O_TMPFILE open in get_temp_fd() a mode", " - scsi: megaraid_sas: Protect megasas_get_ctrl_info() in megasas_resume()", " - docs: s390/pci: Improve and update PCI documentation", " - s390/pci/docs: Fix sriov_numvfs attribute name", " - s390/cio: Fix cio_update_schib() to not cache invalid schib", " - s390/cio: Check pmcw.dnv before pmcw.ena in I/O entry points", " - s390/cio: Guard PMCW field accesses with dnv check", " - fs: avoid repeated scans in evict_inodes()", " - xsk: Use a 32-bit compare in xsk_map_gen_lookup", " - bpf: Skip unsettled links in link iterator", " - eth: fbnic: Fix payload page pool error cleanup", " - net/sched: cls_u32: fix manual hash table handle IDR aliasing", " - net: pcs: rzn1-miic: Fix config array initialization", " - octeontx2-af: use seq_file for rsrc_alloc debugfs", " - net/mlx5: devcom, Base component size on linked devices", " - bpf: Restrict CO-RE poisoning to relocatable instructions", " - libbpf: Reject truncated ldimm64 CO-RE relocations", " - ipv4: fib: fix data-race and stale genid check around nh->nh_saddr", " - netfilter: flowtable: publish HW_DEAD after worker is done", " - netfilter: nfnetlink_queue: hold nfnl mutex in event notifier", " - netfilter: nft_synproxy: use the family-aware checksum helper", " - ipvs: revalidate ihl before icmp_send", " - netfilter: ctnetlink: fix suspicious RCU usage in expect_iter_name", " - arm64: io: Reject non-user protection in ioremap_prot()", " - ocfs2: make ocfs2_calc_xattr_init() return void", " - drm/nouveau/clk: fix list cursor use after loop in", " nvkm_clk_ustate_update", " - drm/nouveau/clk: don't clobber reclock status when restoring volt/fan", " - drm/nouveau/disp: don't reject HDMI config on cards without SCDC", " - net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure", " - net: gue: reject invalid REMCSUM offsets", " - net: ethernet: mtk_eth_soc: unregister net_devices in case of probe", " failure", " - ip6_gre: Call ip6erspan_tunnel_unlink_md() in ip6erspan_changelink().", " - eth: fbnic: Handle maximum standalone channels", " - eth: fbnic: reset num_napi when the napi vectors are freed", " - eth: fbnic: Set AW_FLUSH_MODE alongside AW_FLUSH when flushing the", " mailbox", " - eth: fbnic: Handle FW mailbox completions flagged with an error", " - sctp: avoid livelock while updating retransmit path", " - bpf: Bound ownership depth through local kptrs and graph roots", " - net: usb: catc: bound the RX packet length in catc_rx_done()", " - bpf: Check params size before reading reserved fields", " - net/sched: sch_hfsc: bound the classify inner-filter walk with a drift", " budget", " - drm/virtio: fix object leak when drm_gem_handle_create() fails", " - drm/virtio: fix object leak in virtio_gpu_resource_create_ioctl()", " - drm/virtio: fix object leaks in virtio_gpu_resource_create_blob_ioctl()", " - drm/virtio: release the GEM object on virtio_gpu_vram_create() errors", " - Revert \"drm/virtio: Allow importing prime buffers when 3D is enabled\"", " - drm/virtio: sync shmem backing on guest-bound transfers", " - drm/bridge: samsung-dsim: fix TE GPIO lifetime for host attach", " - ovpn: preserve IPv6 scope id for netlink peer endpoints", " - ovpn: skip UDP source validation for unspecified addresses", " - ovpn: track UDP socket route key for peer dst cache", " - ovpn: validate peer state before caching UDP dst", " - ovpn: replace bind when learning local endpoint", " - ovpn: replace bind when clearing stale local source", " - ovpn: always unhash old VPN addresses before rehashing", " - ovpn: reject duplicate peer VPN addresses", " - ovpn: reject multipeer peers without VPN addresses", " - ovpn: reject invalid peer VPN addresses", " - Bluetooth: bnep: fix out-of-bounds reads on short RX/TX frames and", " control fallthrough", " - Bluetooth: btintel_pcie: validate device-supplied DMA indices", " - Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame()", " - octeontx2-af: Fix memory scaling limitation in SR-IOV mode", " - ipv6: Prevent rt6_insert_exception() for dying fib6_info.", " - dpll: use exact lookup for reference sync pin id", " - net: usb: sr9700: include receive overhead in the length check", " - ipv6: Fix dst leak for uncached routes.", " - udp: relocate a connected socket in the 4-tuple hash table on re-connect", " - udp: remove a disconnected socket from the 4-tuple hash table", " - tg3: clean up PHYLIB resources on probe failure", " - drm/i915/psr: Clear stale sel fetch enable bits on sel fetch disable", " - s390/debug: Do not register views for failed static debug areas", " - s390/debug: Fix NULL pointer dereference in debug_info_copy()", " - net: spacemit: clear TX descriptor on fragment mapping failure", " - net: ethernet: ti: netcp: fix pm_runtime usage counter leak on error", " - genetlink: report the real command id for dump-only ops in policy dumps", " - net: pcs: xpcs: fix clock reference leak on xpcs_init_clks failure", " - thermal: gov_step_wise: Fix stale mitigation vote with non-zero lower", " bounds", " - bpf: Fix bounds check for skb-backed dynptrs", " - bpf: Fix bpf_sock context code generation", " - bpf, sockmap: Reject max_entries > INT_MAX in sock_map_alloc", " - net/mlx5: Bridge, don't fail switchdev events of sibling eswitch ports", " - net/mlx5: Bridge, don't fail unlink of untracked/unsupported peer ports", " - sctp: hold asoc or transport before mod_timer() in timer handlers", " - net: stmmac: selftests: Support running selftests on DSA conduits", " - net: stmmac: selftests: Check the dev->features for S-TAG offload", " testing", " - net: stmmac: selftests: Capture all packets for vlan checks", " - net: stmmac: dwmac4: Use the correct bufzise when the len is exactly 8K", " - net: stmmac: selftests: Account for alignment shift on dwmac1000 for", " Jumbo test", " - eth: fbnic: Avoid rounding zero ring sizes", " - net/sched: fix potential stack infoleak in em_text_dump()", " - bpf: Reject dev-bound-only programs on other devices", " - nfc: nfcmrvl: validate helper command length before pull", " - nfc: st21nfca: validate received frame size", " - nfc: llcp: Fix list corruption / refcount desync in nfc_llcp_recv_dm()", " - selftests: nci: Correct pthread_create return value check", " - nfc: llcp: Fix race condition in accept_queue lifecycle", " - selftests: nci: Fix uninitialized family ID on missing attribute", " - selftests/nci: Fix out-of-bounds store on thread join", " - nfc: virtual_ncidev: Add missing ioctl compat handler", " - nfc: llcp: fix sdreq TLV list leak on parse/alloc/send failure", " - nfc: st21nfca: validate ISO15693 inventory length", " - nfc: llcp: fix -ENOMEM on connect with zero-length service name", " - nfc: llcp: fix WKS SAP hijacking via prefix match in nfc_llcp_wks_sap()", " - nfc: llcp: fix slab-out-of-bounds reads when logging service names", " - nfc: pn533: fix OOB read in pn533_acr122_is_rx_frame_valid()", " - net/sched: act_gate: budget the per-entry list in get_fill_size", " - net: bcmgenet: stop Tx NAPI before disabling the queues", " - veth: manage XDP program pointers during channel resize", " - net: skbuff: fix pull-bound underflow in skb_checksum_setup_ipv6()", " - vrf: Stop corrupting skb->csum when capturing CHECKSUM_COMPLETE packets", " - bpf: Fix immediate JMP JEQ/JNE on MIPS32", " - bpf: Fix BSWAP 32 and 16 on MIPS64", " - tg3: use random MAC address when tg3_get_device_address fails", " - net: stmmac: clear stale buf->page after recycling on skb build failure", " - net: bcmgenet: fix 64-bit RTNL stats reading in ethtool on 32-bit", " systems", " - net: bcmgenet: initialize u64 stats seq counter for all queues", " - net: bcmgenet: do not skip WoL power up on GENET V1", " - net: bcmgenet: validate Ethernet address in bcmgenet_set_mac_addr", " - net: bcmgenet: mask DMA_TIMEOUT_MASK when reading DMA_RING0_TIMEOUT", " - ip_gre: Reject enabling collect metadata through changelink", " - vxlan: use one headroom snapshot for neighbour replies", " - net: xps: reject an out of range traffic class", " - drm/imagination: clamp freelist reconstruction requests", " - bonding: crypto offload enabled, non-offload slave failover, rekey", " failed", " - macsec: initialize SecY before registering the netdevice", " - net: dsa: mt7530: fix NULL dereference on unbind of MT7531 and MT7621", " - net: dsa: mt7530: leave the MDIO IRQ mappings to regmap-irq", " - tcp: fix use-after-free of retransmit_skb_hint in tcp_send_synack()", " - net: phylink: record the PHY only once bringup cannot fail", " - nfp: hold IPsec RX state under the XArray lock", " - net/smc: fix UAF on lgr list traversal in smcr_port_err()", " - tipc: Fix a data race on mon->peer_cnt in mon_timeout()", " - net: ethernet: stmmac: dwmac-rk: fix bulk clock leak when the PHY clock", " fails", " - gve: Advertise NETIF_F_GRO_HW instead of NETIF_F_LRO", " - gve: Enable hw-gro by default if device supported", " - gve: add support for UDP GSO for DQO format", " - gve: DQO: fix header length used by gve_can_send_tso() for UDP GSO", " - gve: fix TX drop when GSO MSS is too small for hw", " - gve: DQO: reject TSO packets with an out of range MSS", " - llc: fix skb UAF and leaks on llc_mac_hdr_init() failure", " - bridge: check llc_mac_hdr_init() return value in br_send_bpdu()", " - net/sched: sch_teql: fix shadowed err in __teql_resolve()", " - vlan: ensure sufficient headroom in vlan_dev_hard_header()", " - autofs: fix sbi->pipe file reference leak in autofs_kill_sb()", " - perf/x86/intel: Ensure KVM guest PEBS path doesn't set unwanted", " PERF_GLOBAL_CTRL bits", " - perf/x86/intel: Don't write PEBS_ENABLED on host<=>guest xfers if CPU", " has PEBS isolation, to fix stuck PEBS_ENABLED", " - perf/x86/intel: Don't pointlessly context switch DS_AREA (and PEBS", " config) if PEBS is unused", " - perf/x86/intel: Make @data a mandatory param for intel_guest_get_msrs()", " - perf/core: Fix a refcount leak in attach_perf_ctx_data()", " - sched/core: Account PSI IRQ time to the execution context, not the", " scheduling context", " - mptcp: return sk_wait_data() errors from recvmsg()", " - x86/mce: Fix hardware debug register corruption on task migration", " - x86/PCI: Disable enhanced atomics on AMD NBIO 7.7 and 7.11", " - virtio_net: copy zerocopy frags in start_xmit without NAPI", " - tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers", " underflow", " - tcp: prevent collapsing skbs across boundary in rtx queue", " - sctp: discard the rest of the packet on a stale-cookie error", " - af_packet: fix integer overflow in prb_calc_retire_blk_tmo()", " - arm64/boot: Disable trapping of PMZR_EL0 writes to EL2", " - arm64: errata: match the target implementation CPU's own MIDR", " - ata: libata-scsi: bound the ATA passthru sense descriptor writes", " - bna: prevent IOC timer rearm during teardown", " - bpf: fs/xattr: don't assume the inode is locked in", " path_unlink/path_rmdir", " - crypto: s390/hmac - Generate intermediate CV for API partial block", " handling", " - cgroup/pids: Restore pids.events notifications in local mode", " - fou: reject omitted FOU_ATTR_IPPROTO on FOU_ENCAP_DIRECT", " - fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder", " syzbot's \"WARNING in do_new_mount\" saga", " - writeback: bound cleanup_offline_cgwb() rescans by rotating scanned", " inodes", " - workqueue: Fix NULL current_pwq deref in flush dependency check", " - writeback: report a Tasks-RCU quiescent state per cgwb drain pass", " - fsl/fman: Fix clk reference leak in read_dts_node()", " - ipe: fix use-after-free when auditing a newly loaded policy", " - ipe: protect the dm-verity root hash with RCU", " - ipv6: do not let ipv6_find_hdr() return an offset past the packet end", " - ipv6: sr: enforce exact attribute length for SEG6_ATTR_DST", " - gpio: arizona: Fix runtime PM leak in arizona_gpio_direction_out()", " - gpio: cdev: fix kernel stack leak to user-space in error path", " - gpio: zynq: fix runtime PM leak on request error path", " - llc: reserve device headroom for allocated frames", " - mctp: route: iterate socket tag list in mctp_lookup_prealloc_tag()", " - rds: ib: Clear the sg list when mapping an MR fails", " - drm/imagination: Propagate map failures correctly from pvr_mmu_map_sgl()", " - drm/imagination: Fix page count for page table for map() interface", " - drm/i915: fix incorrect RCU teardown order", " - drm/i915/dp_mst: Fix configuring FEC for a disconnected stream", " - drm/i915/dp_mst: Fix configuring TUs for a disconnected stream", " - drm/amd/display: Fix dc stream excess put in dm_update_crtc_state()", " - drm/amd/display: Bump frame warning limit for clang builds of dml", " - drm/amdgpu: Fix last_update fence leak in amdgpu_vm_init()", " - drm/amdgpu: Fix runtime PM leak in amdgpu_debugfs_test_ib_show()", " - drm/amdgpu: Fix vmid_wait fence leak in amdgpu_ring_init()", " - drm/nouveau/uvmm: fix UAF in nouveau_uvmm_sm when BO is in TTM_PL_SYSTEM", " - drm/nouveau: fix autosuspend cleanup during teardown", " - drm/nouveau: Fix bridge reference leak in nv1a_ram_new()", " - drm/nouveau: fix double-free in nvif_vmm_dtor", " - drm/nouveau: Fix gem reference leak in validate_init()", " - drm/nouveau: Fix runtime PM leak in nouveau_connector_detect()", " - drm/nouveau: RCU-free the scheduler-containing nouveau_sched", " - drm/nouveau: don't bump pin count on failed re-pin in", " nouveau_bo_pin_locked()", " - drm/xe/vm: nuke PTs only after unlinking contested VMAs", " - drm/xe: harden adjust_idledly() against divide-by-zero and overflow", " - drm/xe: Limit sg segment size to PAGE_SIZE on Xen PV", " - drm/xe: Keep walking on SVM eviction failure", " - drm/virtio: fix memory leak of fence event on execbuffer failure", " - drm/virtio: fix NULL pointer dereference on fence allocation failure", " - gpio: tps65219: Fix GPIO input value reads", " - gpio: tps65219: Use the variant-specific direction callback", " - gpio: tps65219: Fix TPS65214 GPIO direction programming", " - mm/hugetlb: preserve mremap address delta when skipping page tables", " - mm/damon/vaddr: avoid hw-driven pte updates during damon_hugetlb_mkold()", " - PCI: of_property: Omit bus properties without a subordinate bus", " - packet: use ubuf_info completion for TX_RING packets", " - HID: alps: fix use-after-free on input2 registration failure", " - HID: quirks: add ALWAYS_POLL quirk for SDINNOVATION gaming keyboard", " - HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()", " - net/mlx5: Fix rev_entry reference leak in", " mlx5_tc_ct_shared_counter_get()", " - net/mlx5e: advertise MACsec offload only when supported", " - net/mlx5e: fix swapped IPv6 IPsec policy masks", " - net/sched: reject IDR error pointers when deleting actions", " - net: airoha: npu: cancel wdt_work after releasing the WDT IRQ", " - net: arp: terminate device name before lookup", " - net: atl1: fix soft lockup on out-of-range cmb_tpd_next_to_clean read", " - net: hisilicon: hns_dsaf_mac: fix mdio device leak in", " hns_mac_register_phy()", " - net: openvswitch: conntrack: avoid modifying shared unconfirmed ct entry", " - net: openvswitch: conntrack: remove 'add_helper' dead code", " - net: openvswitch: conntrack: fix helper UAF due to extensions realloc", " - net: atl1c: fix soft lockup on out-of-range tpd_cons read", " - net: atl1e: fix soft lockup on out-of-range hw_next_to_clean read", " - net: bridge: mdb: restart port group walk after deletion", " - net: ena: fix PHC cleanup on probe failure", " - net: ena: fix MMIO read buffer leak on probe failure", " - net: phy: micrel: Advance register data pointer in write loop", " - net: txgbe: fix FDIR filter restore for VF rules", " - net: usb: cdc_mbim: add MeiG Smart SRM821 to ZLP whitelist", " - net: usb: lan78xx: Fix URB reference leak in", " lan78xx_submit_deferred_urbs()", " - netfilter: ip6t_rpfilter: reject routes without inet6_dev", " - netfilter: ip6t_rt: fix zero-address non-strict match out-of-bounds read", " - netfilter: nf_tables: skip expired catchall elements on insert and", " delete", " - nfc: fix use-after-free in nfc_get_local_general_bytes", " - nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc()", " - nfc: port100: reject frames whose declared length exceeds the received", " data", " - nfc: trf7970a: power down on startup RX gain failure", " - scsi: libiscsi_tcp: Check the data direction of a Data-In PDU", " - parisc: Increase kernel stack size to 32kb", " - perf/core: Fix NULL pmu_ctx passed to pmu->sched_task()", " - perf/core: Run sched_task() for PMUs with only CPU-wide events", " - pinctrl: single: free the IRQ on domain creation failure", " - pinctrl: sunxi: keep a shadow copy of the data register output latches", " - s390/cio: Fix NULL pointer dereference in ccw_device_get_util_str()", " - s390/cmf: Fix virtual vs physical address confusion", " - s390/pci: Fix leak of struct pci_dev reference in zpci_report_status()", " - s390/pci: Fix missing device lock in zpci_report_status()", " - s390/pci: Report SCLP status on error events when no pdev is associated", " - s390/pci: Don't report recovery success on skipped recovery", " - s390/vfio-ap: fix KVM GISC and page leak when queue removed from host", " config", " - KVM: Ensure memory attributes xarray nodes are accounted to the caller's", " memcg", " - KVM: Don't treat reserved xarray entries as having memory attributes", " - KVM: SEV: Free have_run_cpus during VM destruction even if VM is no", " longer SEV", " - KVM: SEV: Do cache maintenance on the source VM during intra-host", " migration", " - KVM: arm64: Fix AArch32 DBGBXVR handling", " - KVM: arm64: Fix spurious warning for benign stage 2 teardown race", " - KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, teardown race", " - KVM: arm64: Transfer the hyp stack pages out of the host stage-2", " - RISC-V: KVM: Synchronize hrtimer callback during teardown", " - RISC-V: KVM: Propagate interrupted G-stage faults", " - RISC-V: KVM: Fix HSM hart status error propagation", " - Bluetooth: hci_conn: fix CIS hold ownership on reuse", " - Bluetooth: hci_sock: validate event length before filtering", " - Bluetooth: hci_sock: reject out-of-range OCF values", " - Bluetooth: ISO: balance the parent hold in hci_bind_bis()", " - Bluetooth: ISO: release unused CIS holds after channel attach", " - Bluetooth: L2CAP: validate frame length before control and FCS access", " - Bluetooth: mgmt: fix race in read_unconf_index_list()", " - Bluetooth: RFCOMM: fix NULL dereference of dlc->session in", " RFCOMM_CONNINFO", " - smb: client: fix create context out-of-bounds reads", " - smb: client: clean up failed cached directory opens", " - smb: client: preserve create-context parsing errors", " - smb: client: validate POSIX create context length", " - xfs: don't assert when XFS_SCRUB_TYPE_HEALTHY scans return corruption", " - xfs: fix attr fork block count checks in xrep_inode_blockcounts", " - xfs: release orphanage dir inode if chown fails", " - xfs: use correct jiffies comparison function in xchk_maybe_relax", " - xfs: check padding field in xfs_ioc_commit_range", " - xfs: don't call xfs_exchange_range_finish for a dry run", " - xfs: use the correct reservations for rtrmap/refcount recovery", " - xfs: check di_forkoff correctly in scrub", " - xfs: fix rtgroup repair estimations", " - xfs: fix wild memcpy access when formatting ondisk rtrefcount btree", " roots", " - xfs: call xfs_dquot_set_prealloc_limits if we installed default rtb", " limits", " - xfs: don't let hidden_space go negative in xfs_metafile_resv_init", " - xfs: fix blockgc group quota scanning when usrquota isn't enforced", " - xfs: fix cursor and pointer handling when recovering iunlink buckets", " - net: tls: fix silent data drop under pipe back-pressure", " - cgroup/cpuset: Return PERR_NOCPUS in remote_partition_enable() on", " subpartitions_cpus conflict", " - vlan: require the MAC header to be present in __vlan_insert_inner_tag()", " - i2c: qcom-geni: Fix hardcoded clock index in SE_GENI_CLK_SEL", " - drm/i915/psr: Disable PSR2 on Xiaomi Book Pro 14 2026 as a quirk", " - drm/i915/quirks: Limit eDP rate to HBR2 on HP Pavilion Plus 14-ew1", " - drm/amdgpu: Fix acpi device leak in amdgpu_acpi_enumerate_xcc()", " - drm/client: fix restore of partially initialized client", " - mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma", " publish", " - mm/hugetlb: do not dissolve gigantic pages without runtime support", " - super: make iterate_supers_type() deletion-safe", " - PCI: Fix BAR resize for devices on a root bus", " - HID: alps: unregister DualPoint Stick input device on remove", " - net: macb: fix dma_alloc_coherent() leak on macb_alloc() error paths", " - net: ipconfig: bound DHCP option construction", " - perf/x86/intel: Update event constraints and cache_extra_regsfor ADL", " - perf/x86/intel: Fix GRT PEBS load/store direction for latency events, to", " fix sample classification", " - perf/x86/intel: Update event constraints and cache_extra_regsfor LNL", " - perf/x86/intel: Remove incorrect LionCove PEBS data-source constraints", " - x86/sev: Remove redundant ghcbs_initialized checks around", " __sev_{get,put}_ghcb()", " - x86/sev: Make vTPM SVSM calls preemption-safe", " - net/sched: act_ct: fix helper UAF due to extensions realloc", " - net/sched: act_ct: avoid modifying shared unconfirmed ct entry", " - RISC-V: KVM: Serialize IMSIC attributes with vCPU migration", " - Revert \"rust: net: phy: fix off-by-one bit positions in device status", " accessors\"", " - rust: net: phy: fix off-by-one bit positions in device status accessors", " - mm/damon/core: fix unconditionally skip last region", " - sched_ext: Derive SCX_RQ_IN_WAKEUP from the core enqueue flags", " - rose: keep the route needed for routing loop detection", " - rose: guard rose_transmit_link() against a NULL neighbour", " - rose: use timer_shutdown_sync() for t0timer teardown", " - rose: don't warn on stray CALL_ACCEPTED/CLEAR_CONFIRMATION in state 3", " - drm/amd/display: Remove sink usage from DPMS", " - KVM: s390: Fix _gaccess_shadow_fault()", " - KVM: s390: Add missing srcu in kvm_s390_set_irq_state()", " - KVM: s390: Properly handle NULL pointer in dat_cond_set_storage_key()", " - KVM: s390: Fix potential races in dat skey functions", " - KVM: s390: Fix race in _destroy_pages_crste()", " - bpf: Allow terminal gotox instructions", " - bpf: Fix u32 overflow issue in map batch operations", " - pinctrl: generic: serialise pinctrl_generic_dt_node_to_map()", " - RISC-V: KVM: Fix the conversion between vsip and hvip", " - KVM: arm64: Match hyp text by physical address in fix_host_ownership()", " - scsi: block: Fix zones_cond out-of-bounds write on zone report", " - block: Add bvec_folio()", " - netfs: Fix netfs_read_gaps() to use separate sink folios", " - netfs, afs: Fix symlink reading", " - net/mlx5: LAG, reload IB reps of LAG master before the rest", " - bpf: Make post-verification instruction rewrites killable", " - eth: fbnic: use the Rx queue napi pointer to find the napi vector", " - drm/xe/gt_throttle: Report power brake as a throttle reason on CRI", " - bpf: Reject non-negative offsets in stack_slot_obj_get_spi()", " - net: don't require the hwtstamp NDOs when a PHY provides timestamping", " - bpf: Reject pkt arguments in mutating subprogs", " - net: stmmac: selftests: Validate EEE based on the actual LPI timer value", " - net: stmmac: size the RX buffers from the frame length, not the MTU", " - net: dsa: mv88e6xxx: 88E6191X and 88E6193X have no PTP", " - net: ipv6: keep room for the mac header in dst_dev_overhead()", " - net/sched: act_ife: validate metadata length before decoding", " - bpf: Zero-fill other CPUs when BPF_F_CPU creates a per-cpu hash element", " - net: wangxun: implement soft quiesce for PCIe error recovery", " - net: libwx: fix races in Tx timestamp handling", " - net/rds: size a connection's path set by the transport it ends up with", " - net: flush skb_defer_nodes in dev_cpu_dead()", " - ovl: fix UAF in ovl_do_mkdir() debug print", " - perf/x86/intel: Delete dead NVL PEBS data-source initcall", " - perf/core: Fill branch entries with a single assignment", " - vsock: ignore empty child namespace mode writes", " - netfs: Fix missing alloc tagging of direct mempool allocations", " - kprobes: Fix permanent hang when flushing the kprobe optimizer", " - drm/amdgpu/userq: fix double jiffies conversion in hang detect timeout", " - drm/amdgpu/vcn4.0.3: fix video_timeout unit mismatch in jpeg reset wait", " - drm/amdgpu/vcn5.0.1: fix video_timeout unit mismatch in jpeg reset wait", " - drm/nouveau/dmem: pin VRAM for the whole registered range", " - mm/damon/ops-common: use a page-aligned address in damon_ptep_mkold()", " - mm/damon/core: allow esz to be set to zero", " - mm/damon/core: reset invalid quota->charge_target_from", " - net: phy: intel-xway: workaround 100BASE-TX Link-Up issue", " - scsi: ufs: core: Keep internal commands dispatchable during error", " handling", " - parisc: parse early parameters in setup_arch()", " - perf/x86/intel: Fix Panther Cove PEBS data-source snoop states", " - perf/x86/intel: Remove incorrect Panther Cove PEBS data-source", " constraints", " - perf/x86/intel: Constrain Panther Cove UOPS_DISPATCHED events to PMCs", " 0-3", " - pinctrl: mpfs-mssio: fix width of unused bank voltage setting", " - pinctrl: mpfs-mssio: use correct regmap function to set bank voltage", " - KVM: arm64: Don't WARN on an unknown VM ioctl in protected mode", " - RISC-V: KVM: Release unused page after MMU invalidation", " - smb: client: close handle after create-context parsing failure", " - smb: client: use finish_no_open() for non-regular inodes", " - smb: client: close completed creates on compound wait errors", " - smb: client: delete compound mids on send failure before unlock", " - xfs: don't let memory failures leak blocks and kill repairs", " - xfs: don't merge different file IO error types", " - xfs: drop dquot flush lock when we can't find a buffer to flush", " - drm/xe: Add wa_14025941587 to xe2, xe3 and xe3p platforms", " - i2c: qcom-geni: Isolate serial engine setup", " - soc: qcom: geni-se: Add geni_icc_set_bw_ab() function", " - soc: qcom: geni-se: Introduce helper API for resource initialization", " - i2c: qcom-geni: Move resource initialization to separate function", " - i2c: qcom-geni: Store of_device_id data in driver private struct", " - i2c: qcom-geni: Fix hardcoded clock index in SE_GENI_CLK_SEL", " - drm/amd/display: Relax DML frame limit with UBSAN", " - KVM: arm64: nv: Fix life cycle of the nested_mmus array", " - KVM: arm64: nv: Delay freeing of shadow S2 structures until VM", " destruction", " - KVM: x86: Reject nested CAP enablement if nested virtualization is", " disabled", " - accel/ivpu: Use threaded IRQ for IPC callback processing", " - accel/ivpu: Drop IRQF_ONESHOT to allow IPC IRQ threading on PREEMPT_RT", " - i2c: qcom-geni: release DMA channels on probe error", " - Upstream stable to v6.18.55, v7.2.9", "", " * Resolute update: upstream stable patchset 2026-10-06 (LP: #2169641)", " - landlock: Fix TCP Fast Open connection bypass", " - selftests/landlock: Add test for TCP fast open", " - selftests/landlock: Use an actual chardev for MAKE_CHAR audit test", " - selftests/landlock: Add tests for whiteout object creation", " - selftests/landlock: Add audit test for whiteout object creation", " - sunvdc: fix -EIO issue due to lack of retries", " - media: video-i2c: fix buffer queue ordering", " - ipv6: Select best matching nexthop object in fib6_table_lookup()", " - ipv6: Honor oif when choosing nexthop for locally generated traffic", " - xfrm: iptfs: fix stack OOB read in iptfs_skb_reset_frag_walk()", " - xfrm: iptfs: fix runt reassembly panic from short inner tot_len", " - xfrm: fix compat ALLOCSPI request use-after-free", " - xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for", " xfrm_trans_reinject()", " - esp: downgrade zerocopy managed frags before mutating skb frags", " - ARM: socfpga: select the PL310 erratum 753970 workaround", " - RDMA/siw: Clear association under lock if siw_qp_modify fails in", " siw_accept", " - RDMA/rxe: validate access flags before swapping the MR's PD", " - RDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB access", " - firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS", " - clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate", " - RDMA/rxe: Restore HMM_PFN_WRITE check in ODP write paths", " - RDMA/rxe: insert mcg into mcg_tree only after rxe_mcast_add() succeeds", " - RDMA/mlx5: Remove warn on missing representor in query_port_speed", " - RDMA/core: Reject unregistering netdevs in ib_get_eth_speed", " - power: sequencing: Fix build issue with COMPILE_TEST", " - arm64: dts: renesas: r9a09g057: Switch GBETH TX queue scheduling to WRR", " - arm64: dts: renesas: r9a09g056: Switch GBETH TX queue scheduling to WRR", " - arm64: dts: renesas: r9a09g047: Switch GBETH TX queue scheduling to WRR", " - IB/iser: reject a remote invalidation of an unregistered direction", " - IB/isert: wait for deferred control PDU completions before releasing the", " connection", " - RDMA/bnxt_re: check create_singlethread_workqueue() in DCB setup", " - RDMA/mad: Fix receive buffer leak when PKey enforcement fails", " - RDMA/irdma: Enforce local fence for IB_WR_REG_MR", " - RDMA/rtrs-clt: Fix CQ pool leak when connect is interrupted", " - dmaengine: sprd: Fix runtime PM reference leak in probe", " - wifi: mac80211: include TIM bitmap control for buffered S1G mcast", " traffic", " - wifi: virt_wifi: free skb when disconnected", " - wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path", " - wifi: brcmfmac: cyw: pass PMKID to firmware if present", " - wifi: libipw: reject too-short beacon and probe responses", " - wifi: libipw: reject too-short association responses", " - IB/IPoIB: Avoid restoring OPER_UP after multicast flush", " - wifi: cfg80211: don't get the radio mask for netdev-less wdevs", " - wifi: cfg80211: check IP header size in cfg80211_classify8021d()", " - soundwire: cadence_master: wait and cancel cdns->work before clock stop", " - MIPS: Octeon: apply USB FDT fixups also when USB is modular", " - dma-coherent: report a failed reserved memory assignment", " - dmaengine: Fix device kref underflow in dma_chan_put()", " - dmaengine: fix use-after-free in dma_chan_put() and", " dma_release_channel()", " - dmaengine: wait for RCU readers before releasing dma_device", " - wifi: cfg80211: don't free driver-owned scan requests", " - wifi: cfg80211: only group hidden BSSes with beacon entries", " - wifi: cfg80211: don't filter by BSS type when removing stale entries", " - wifi: mac80211: don't start a ROC while scanning", " - wifi: mac80211: don't warn when an IBSS has no channel to scan", " - wifi: mac80211: don't offload TC setup on AP_VLAN interfaces", " - wifi: mac80211: suppress chanctx warning for debugfs reset", " - wifi: mac80211: abort chanswitch when leaving a mesh", " - wifi: mac80211: reset state when starting AP fails", " - wifi: cfg80211: restore netns_immutable on failures", " - wifi: cfg80211: undo netns switch if renaming the wiphy fails", " - wifi: mac80211: unlist vifs when their netdev is unregistered", " - wifi: cfg80211: get the wiphy out of a dying network namespace", " - wifi: mac80211_hwsim: don't hand frames to mac80211 while stopping", " - wifi: mac80211: don't allow injecting frames wider than the chanctx", " - wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown", " - wifi: mac80211: require a peer station for TDLS setup confirm", " - wifi: mac80211: don't allow link changes when iface is down", " - wifi: mac80211: don't RCU-dereference the mesh CSA settings we just set", " - wifi: mac80211: don't access the TSF of a down interface", " - wifi: mac80211: add HE 6 GHz capability in the scan elems len", " - wifi: mac80211: mesh: reset the CSA state when leaving", " - wifi: mac80211: mesh: release the channel if start fails", " - wifi: mac80211: set up the TX info early to fix failure paths", " - mm: memblock: show all region flags in debugfs", " - scsi: qla2xxx: Fix the ql2xfc2target parameter description", " - dmaengine: xilinx_dma: Fix hardware buffer descriptor reuse order", " - dmaengine: xilinx_dma: Fix hardware buffer descriptor chain after cyclic", " DMA", " - RDMA/efa: Keep admin queues alive while IRQ is registered", " - RDMA/efa: Keep EQ resources alive while IRQ is registered", " - RDMA/siw: Bound fragmented header copies by the remaining length", " - drm/msm: Fix the separate_gpu_kms parameter description", " - drm/msm/adreno: Fix the skip_gpu parameter description", " - netfilter: nft_nat: fully initialise new_addr in netmap setup", " - netfilter: nf_tables: fix device name and prefix match in hook lookup", " - netfilter: nf_nat: unregister and release hooks on error", " - netfilter: flowtable: hold reference on ct until flow is released", " - perf/arm-cmn: Fix wp_dev_sel2 setting for multi-DTM configurations", " - arm64: hibernate: clone only the linear map that exists at runtime", " - drm: Fix drm_pending_vblank_event leak in error path for out_fence_ptr", " - keys: fix lost wakeup when reaping a dead key type", " - neighbour: Enforce min/max to NDTPA_INTERVAL_PROBE_TIME_MS.", " - neighbour: Add missing RCU annotation for neightbl_dump_info().", " - neighbour: Skip default parms when resumed in neightbl_dump_info().", " - ALSA: bcd2000: Fix race between rawmidi and disconnect", " - phy: mediatek: phy-mtk-hdmi-mt8195: Fix PLL calc divisor overflow", " - phy: mediatek: phy-mtk-hdmi-mt8195: Fix TMDS clk bit ratio setting", " - ALSA: pcm: set timer->private_data before registering the PCM timer", " - drm/msm/dp: skip PUSH_IDLE when the link was never enabled", " - drm/msm/dp: fix link bandwidth check when wide bus is enabled", " - ASoC: Rename snd_soc_dai_link_ch_map.ch_mask to cpu_ch_mask", " - ASoC: Add codec_ch_mask to snd_soc_dai_link_ch_map", " - ASoC: soc-pcm: Apply snd_soc_dai_link_ch_map.codec_ch_mask to codec", " params", " - spi: spi-qpic-snand: avoid writing QPIC_EBI2_ECC_BUF_CFG register", " - Input: trackpoint - fix the inertia attribute name in the ABI document", " - gpio: virtuser: skip free_irq when no IRQ is installed", " - ALSA: usb: 6fire: Avoid embedded URBs", " - ALSA: 6fire: fix OOB write from device-reported iso length", " - wifi: virt_wifi: don't transfer operstate before register", " - drm/xe/mmio_gem: forbid VMA split", " - drm/xe/mmio_gem: use write-back mapping for dummy page", " - drm/xe/mmio_gem: Revoke drm_vma_node on xe_mmio_gem destroy", " - drm/xe/shrinker: Return the freed page count through a parameter", " - drm/vc4: Use managed KMS polling to fix UAF on unbind", " - ALSA: hda: trace PCM open only after assigning a stream", " - wifi: ath11k: cleanup arsta in ath11k_mac_peer_cleanup_all()", " - btrfs: tree-checker: print dev extent offset in error message", " - drm/msm/dsi: round the byte clock rate after reparenting to the PHY PLL", " - seg6: set IPSKB_L3SLAVE from IP6SKB_L3SLAVE on IPIP decapsulation", " - net: bcmgenet: convert RX path to page_pool", " - net: bcmgenet: restore the hardware filters on open", " - ipv4: icmp: reject RTN_UNREACHABLE input routes in icmp_route_lookup", " - net: fddi: skfp: fix NULL deref when setting the MAC address while down", " - wifi: brcmfmac: fix lost 802.1x TX completion wakeup", " - net: bridge: mst: move switchdev call outside rcu", " - tcp: Don't call skb_clone_and_charge_r() for close()d listener in", " tcp_v6_do_rcv().", " - tcp: do not let tcp_rmem be set below 4096", " - ksmbd: return buffer overflow for partial filesystem info", " - ksmbd: fix partial file information responses", " - ksmbd: keep compound responses on query info errors", " - dmaengine: mmp_pdma: fix wrong sg length in mmp_pdma_prep_slave_sg()", " - Bluetooth: hci_core: Fix queuing tx_work after workqueue is drained", " - Bluetooth: btintel_pcie: validate TX skb length in send_sync", " - Bluetooth: coredump: Quiesce dump work on unregister", " - Bluetooth: qca: Refactor code on the basis of chipset names", " - Bluetooth: qca: enable pwrseq support for WCN39xx devices", " - Bluetooth: hci_qca: Do not write to the serial port after it is closed", " - Bluetooth: ISO: Fix parent socket leak in iso_conn_ready()", " - Bluetooth: ISO: set BT_LISTEN before requesting a BIG sync", " - Bluetooth: btmtk: fix wrong status for short WMT FUNC_CTRL events", " - Bluetooth: btmtksdio: Fix PM runtime reference leak in shutdown", " - Bluetooth: btintel_pcie: fix off-by-one bounds check in RX submit", " - Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup", " - af_unix: Unify scc_index when finalising SCC in __unix_walk_scc().", " - pppoatm: ensure a writable skb header and linear data", " - drop_monitor: synchronize tracepoint unregistration on error path", " - drop_monitor: use timer_shutdown_sync() to prevent timer rearming during", " teardown", " - drop_monitor: fix out-of-bounds write in reset_per_cpu_data()", " - net: stmmac: do not overwrite phc_index when no PTP clock is registered", " - KVM: PPC: Book3S HV: fix use-after-free in", " kvmhv_emulate_tlbie_all_lpid()", " - KVM: PPC: Book3S HV: fix secure device page leak on uv_page_in() failure", " - powerpc/iommu: Fix the overflow validation in iommu_tce_check_ioba", " - futex: Also allocate private hash on vfork()", " - btrfs: handle lack of space when cleaning up verity items", " - ASoC: ux500: Parenthesize MSP_{RX,TX}_CLKPOL_BIT() arguments", " - ASoC: hdmi-codec: Report a change when the channel status moves", " - ASoC: amd: acp: bounds-check SoundWire link ID in machine drivers", " - ASoC: sdw_utils: tidyup .count_sidecar", " - ASoC: sdw_utils: tidyup asoc_sdw_parse_sdw_endpoints()", " - ASoC: amd: acp: refactor codec config count in SOF SoundWire machine", " driver", " - ASoC: amd: acp: fix ffs() operator precedence for SoundWire link ID", " - net: netsec: fix device_node reference leak on phy_np", " - eth: fbnic: ring the doorbell if a burst ends in a drop", " - net: lock the socket in sock_gettstamp()", " - net: ethernet: cortina: Ack RX overrun interrupt correctly", " - net: stmmac: propagate FPE preemption-class mapping errors", " - net: psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb()", " - x86/kprobes: Fix crash when probing CS CALL instructions", " - net: macb: fix ordering around PTP timestamp read", " - net: mvpp2: prevent buffer overflow in page_pool allocation", " - net: skbuff: do not leave stale header offsets after pskb_carve()", " - drm/amdgpu: check ras and obj before dereference", " - btrfs: abort transaction on failure to update inode for hole punching", " and reflinking", " - btrfs: check if there is space for chunk item when validating sys chunk", " array", " - x86/fred: Reconstruct the #GP context for rejected INT instructions", " - Input: eeti_ts - publish the OF module alias", " - hwmon: (gpio-fan) return IRQ_HANDLED from the shared alarm IRQ handler", " - hwmon: (hp-wmi-sensors) Improve raw WMI string handling", " - watchdog: da9062: fix suspend/resume handling of HW_RUNNING watchdog", " - wifi: rtw88: TX QOS Null data the same way as Null data", " - Input: xpad - add support for Victrix Pro BFG Controller", " - Input: xpad - add support for Azeron devices", " - Input: xpad - fix PDP Marvel Xbox 360 controller", " - ALSA: core: Fix potential UAF after asynchronous card release", " - ALSA: virtio: reset device before deleting virtqueues", " - ASoC: codecs: rt712-sdca-dmic: fix uninitialized stream_config->type", " - ata: libahci: clear PxCLBU and PxFBU for AHCI_HFLAG_32BIT_ONLY", " - ata: libahci_platform: Fix device reference leak in", " ahci_platform_get_resources()", " - cifs: Fix server use-after-free in cifs_chan_skip_or_disable()", " - exec: Cleanup POSIX timers right after de_thread()", " - fs/dax: check zero or empty entry before converting xarray entry", " - phy: renesas: rcar-gen3-usb2: Avoid long delay in atomic context", " - posix-cpu-timers: Prevent freeing a timer which is queued on the expiry", " list", " - rds: ib: use rds_conn_drop() on protocol version mismatch", " - rust: net: phy: fix off-by-one bit positions in device status accessors", " - Revert \"nouveau/gsp: fix suspend/resume regression on r570 firmware\"", " - drm/nouveau/gsp: Increase delay for magic sleep in r535_gsp_fini()", " - drm/nouveau/gsp/r570: Set GcOff = 0 in fbsr", " - drm/nouveau/gsp/r570: Enable S/R Display workaround in GSP", " - x86/build/64: Prevent native builds from generating EGPR use", " - [Config] Add and enable config setting RUSTC_HAS_APXF", " - x86/microcode/intel: Reject problematic loading on Granite Rapids", " systems", " - tcp: exclude old ACKs from tcp fast path", " - swiotlb: use the adjusted address for the highmem page lookup", " - spi: fsl-qspi: Reprogram the clock rate when the operation frequency", " changes", " - spi: spi-zynqmp-gqspi: stop the controller on shutdown", " - spi: virtio: Use the per-transfer bits per word", " - RDMA/ucma: Serialize join and leave on copy_to_user failure", " - RDMA/core: fix refcount bug in iwpm_get_nlmsg_request()", " - openvswitch: avoid reallocating confirmed conntrack labels", " - net: xfrm: reject unrepresentable espintcp transport headers", " - HID: logitech-hidpp: fix race condition when accessing stale stack", " pointer", " - kselftest/arm64: Fix size of thread_data values for pthread_join()", " - arm64: hibernate: pass HVC_SET_VECTORS args to the resume hvc", " - arm64: dts: renesas: r8a779f0: Set UFS lane count", " - arm64: percpu: Fix this_cpu_write() casting", " - arm64: percpu: Fix this_cpu_and() mask generation", " - arm64: percpu: Fix LSE operations on {8,16}-bit types", " - Bluetooth: btusb: fix NXP IW610 composite device handling", " - Bluetooth: eir: validate service data length before reading UUID", " - Bluetooth: hci_codec: validate vendor codec count length", " - Bluetooth: hci_sync: Serialize local codec list cleanup", " - btrfs: take commit root semaphore when iterating in", " mark_block_group_to_copy()", " - btrfs: clear free space tree creation state on rebuild failure", " - dmaengine: sun6i: fix non-atomic read of DMA position registers", " - dmaengine: sun6i: fix undefined behaviour in sun6i_dma_tx_status", " - dmaengine: ti: k3-udma-glue: fix NULL dereference in", " k3_udma_glue_release_rx_chn()", " - ipv6: xfrm: use full sockets in local error paths", " - net: ip_tunnel: initialize `options_len` before referencing options", " - net: lan743x: fix RX checksum use-after-free", " - net: phy: mediatek: do not report link and per-speed LED rules together", " - net: wwan: t7xx: validate the netif index in t7xx_ccmni_recv_skb()", " - net: wwan: mhi_wwan_mbim: guard against a cyclic NDP chain", " - net: wwan: mhi_wwan_mbim: check skb_copy_bits() return value", " - net/sched: act_api: release tail references on DELACTION failure", " - net/sched: hhf: cap hh_flows_limit at change time", " - net/packet: clear RX owner on VNET header error", " - net/packet: avoid truncating TPACKET_V3 private size", " - scsi: core: Validate MODE SENSE lengths in scsi_cdl_enable()", " - xfrm: serialize state GC with device state flush", " - xfrm: use hlist_del_init_rcu for state_cache and state_cache_input", " - soc: samsung: exynos-pmu: fix use-after-free of interrupt generator node", " - memcg: avoid charging the root memcg from obj_cgroup_charge_pages()", " - memstick: ms_block: destroy io_queue workqueue on removal", " - mm, swap: fix SWAP_USAGE_OFFLIST_BIT collision with real usage count", " - mm/mlock: use the IRQ-safe accessor for NR_MLOCK in __munlock_folio()", " - mm/mremap: account mm->locked_vm correctly for MREMAP_DONTUNMAP", " - mm: filemap: retain mapped dropbehind folios", " - KEYS: encrypted: fix integer overflow of datablob_len", " - keys: translate request_key_auth pid for the reading procfs instance", " - KEYS: trusted: Fix tpm2_load_cmd() boundary check", " - i2c: at91: release DMA channels on remove and probe error", " - i2c: atr: fix dangling adapter pointer on add failure", " - i2c: qcom-cci: fix device_node refcount leak in cci_probe()/cci_remove()", " - i2c: imx: release DMA channels on probe error", " - i2c: imx: disable autosuspend on remove", " - IB/mlx4: Fix use-after-free on pkey sysfs registration failure", " - IB/hfi1: Resolve the credit-return buffer through the send context's", " node", " - IB/hfi1: Fix the PIO_CRED credit-return mmap", " - selinux: preserve user SID across nested backing files", " - selinux: recheck intermediate backing files on mprotect()", " - selinux: always fill AVC decision in avc_has_perm_noaudit()", " - power: sequencing: don't call .post_enable() if pwrseq_unit_enable()", " failed", " - power: sequencing: fix NULL-pointer dereference in pwrseq_unit_new()", " - power: sequencing: fix NULL-pointer dereference in", " pwrseq_device_register()", " - mmc: core: Cancel SDIO IRQ work before freeing host", " - mmc: core: Fix OF node reference leak on card add failure", " - mmc: hsq: Fix use-after-free in retry work", " - mmc: mmci: Fix use-after-free in busy-timeout work", " - mmc: mxcmmc: cancel data work and watchdog on remove", " - mmc: rtsx_pci_sdmmc: ignore broken write-protect on ThinkPad X260", " - mmc: sdhci-of-aspeed: Remove children before releasing SDC resources", " - mmc: sdio_uart: fix xmit_fifo leak when the port table is full", " - mmc: sh_mmcif: initialize IRQ-thread mutex before requesting interrupt", " - mmc: spi: reset bytes_xfered before retrying CRC failures", " - mmc: sdhci_am654: Move tuning_loop to local variable", " - mmc: sdhci_am654: Reset command and data lines on failed tuning", " - mmc: sdhci_am654: Clear ITAPDLY on tuning failure", " - mmc: sdhci_am654: Fallback to DT-provided itap delay on DDR50 tuning", " failure", " - Input: adp5588-keys - cache GPIO state before registering the gpiochip", " - Input: atkbd - skip deactivate for Xiaomi Redmi Book Pro 16 2026", " - Input: cyttsp5 - clamp the HID report size before memcpy", " - Input: evdev - zero absinfo before partial copy in EVIOCSABS", " - Input: hp_sdc - shut down kicker timer on module exit", " - Input: i8042 - add quirk for Acer Aspire Go 15 AG15-42P", " - Input: rmi_smbus - fix out-of-bounds read in rmi_smb_write_block()", " - Input: soc_button_array - fix MS Surface Pro 11 probe failure", " - Input: soc_button_array - check btns_desc->package.count", " - Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722)", " - Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound", " - Input: zero ff_effect before compat copy in input_ff_effect_from_user", " - hwmon: (hp-wmi-sensors) Fix use-after-free in fungible_show()", " - hwmon: (pmbus/core) increase number of phases and add new mask", " - hwmon: (pmbus/tps53679) Fix TPS53676 phase page decoding", " - hwmon: (pmbus/tps53679) Select page 0 for single-page TPS53676", " - hwmon: (pwm-fan) Stop RPM timer before freeing tach data", " - hwmon: (w83791d) remove fan/pwm 4-5 sysfs group on remove", " - hwmon: (w83793) release probe data through kref", " - hwmon: (cgbc-hwmon) Fix current sensors ID lookup", " - hwmon: (cgbc-hwmon) Add missing sensors", " - watchdog: da9063: fix suspend/resume handling of HW_RUNNING watchdog", " - watchdog: digicolor: Avoid division by zero", " - watchdog: msc313e: Fix premature reset during timeout update", " - watchdog: msc313e: Propagate error code in resume()", " - watchdog: rtd119x: Avoid division by zero", " - watchdog: rzv2h: Avoid division by zero", " - watchdog: sp5100_tco: Fix pci_dev reference leak in sp5100_tco_init()", " - watchdog: starfive-wdt: Fix runtime PM leak in starfive_wdt_pm_start()", " - wifi: brcmsmac: fix UAF in brcms_free_timer()", " - wifi: iwlegacy: fix broadcast stations deallocation", " - wifi: libertas_tf: fix UAF in lbtf_free_adapter()", " - wifi: rsi: fix heap OOB write on key removal", " - wifi: wcn36xx: Fix potential use-after-free in TX ack timer teardown", " - wifi: wlcore: release runtime PM ref on regdomain config failure", " - wifi: wilc1000: fix out-of-bounds read in P2P public action frames", " - wifi: wilc1000: fix RX buffer OOB-write in wilc_wlan_handle_isr_ext()", " - wifi: p54: validate curve data length in the calibration curve", " converters", " - wifi: p54: require a full exp_if record in PDR_INTERFACE_LIST", " - wifi: mwifiex: bound the pairwise-cipher OUI walk to the IE length", " - wifi: mwifiex: validate scan response extents", " - wifi: mwifiex: prevent authentication frame length truncation", " - wifi: mwifiex: validate action frame fixed fields", " - wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driver", " - drm/gud: fix out-of-bounds write in gud_plane_atomic_check()", " - drm/gud: Ignore damage clips in full update mode", " - drm/msm/adreno: fix autosuspend cleanup during teardown", " - drm/msm/dpu: clear pending peripheral flush state", " - drm/msm/hdmi_phy: fix runtime PM cleanup on probe failure", " - drm/msm: RCU-free the scheduler-containing ring and VM objects", " - drm/amdgpu: fix rmmio iounmap skipped on device removal", " - smb: client: cancel reconnect work in clean_demultiplex_info()", " - smb: client: fix rlist race and missing initialization", " - smb: client: fix use-after-free of iface in cifs_try_adding_channels()", " - smb: client: reject short Next offsets in parse_server_interfaces()", " - smb: client: fix smbd_connection leak on cifs_get_tcp_session() error", " - smb: client: fix unaligned access in WSL reparse point parser", " - smb: client: fix next_buffer UAF and NextCommand bounds in compound PDUs", " - smb: client: fix OOB struct field reads in move_smb2_ea_to_cifs()", " - smb: client: fix potential OOB read in smb3_enum_snapshots()", " - smb: client: fix server->total_read for compound encrypted PDUs", " - smb: client: fix missing lower-bound check on DFS referral string", " offsets", " - smb: client: fix missing iov bounds check in parse_posix_sids()", " - time/namespace: Export init_time_ns and do_timens_ktime_to_host()", " - ntsync: Honour caller's time namespace for absolute MONOTONIC timeouts", " - ntsync: reject wait ioctls with zero owner", " - ALSA: usb-audio: Clamp implicit feedback packet count to URB capacity", " - signal: Prevent exec() race", " - xfrm: save input state data before secpath resets", " - mm/huge_memory: bypass THP tuneables for huge pfnmap mappings", " - 9p: Fix v9fs_issue_write() to update i_size and remote_i_size", " - mm/vma: correctly unaccount on mmap_prepare() failure", " - wifi: mac80211: refuse to make a monitor active when it has no queue", " - scsi: fnic: Rename fnic_scsi_fcpio_reset()", " - scsi: fnic: Bump up version number", " - scsi: fnic: Make debug logging protocol independent", " - scsi: fnic: Bump up version number again", " - scsi: fnic: Fix missed link-up when critical IRQ targets offline CPU", " - xfs: add a xfs_rmap_inode_owner helper", " - xfs: convert xchk_inode_xref_set_corrupt to xchk_ip_xref_set_corrupt", " - xfs: remove the i_ino field in struct xfs_inode", " - drm/amdgpu: hold a runtime PM reference for P2P dma-buf attachments", " - wifi: ipw2x00: Rename michael_mic() to libipw_michael_mic()", " - wifi: mac80211, cfg80211: Export michael_mic() and move it to cfg80211", " - wifi: ipw2x00: Use michael_mic() from cfg80211", " - wifi: libipw: reject TKIP frames without a full MIC", " - smb: client: fix reparse buffer bounds in cifs_query_reparse_point()", " - ksmbd: fix partial normalized name responses", " - Revert \"ksmbd: Fix to handle removal of rfc1002 header from smb_hdr\"", " - smb/client: send lease break ACKs thru correct session for multiuser", " mounts", " - xfrm: hold net_device reference under RCU in bundle creation", " - clk: scpi: register scpi-cpufreq once and clear on failure", " - RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency", " - arm64: dts: renesas: r9a09g077: Switch GBETH TX queue scheduling to WRR", " - arm64: dts: renesas: r9a09g087: Switch GBETH TX queue scheduling to WRR", " - RDMA/rtrs: guard against null kobj name", " - RDMA/uverbs: Fix potential leak of resources->collection in", " flow_resources_alloc()", " - RDMA/erdma: Use IRQ-safe XArray helpers for QP and CQ tables", " - mips: econet: fix unmet dependencies for ECONET", " - dma-mapping: don't trace the DMA address when the allocation fails", " - wifi: cfg80211: ibss: ref BSS entry for joined event", " - wifi: mac80211: reset the LED state when ifup fails", " - wifi: mac80211: only operate on TDLS peers in the TDLS code", " - scsi: pm80xx: Fix the use_msix, use_tasklet and read_wwn parameter", " descriptions", " - dmaengine: pxa: fix double counting of the hw descriptors", " - x86/div64: Fix addition of large constants in mul_u64_add_u64_div_u64()", " - arm64: mte: Fix PTRACE_{PEEK,POKE}MTETAGS error documentation", " - smb: client: validate absolute native symlink targets before NT fixups", " - neighbour: Don't render blackhole_netdev via RTM_GETNEIGHTBL.", " - objtool: Validate disassembler headers in libopcodes probe", " - sysctl: Check range in proc_dointvec_ms_jiffies_minmax", " - Bluetooth: put the peer's on-air address on air when we cannot resolve", " - Bluetooth: btmtksdio, btmtkuart: validate WMT event length before struct", " access", " - net: stmmac: fix TSO header length truncation", " - drop_monitor: use raw_cpu_ptr() in tracepoint probes", " - net: bridge: vlan: fix bugs caused by switchdev deletion errors", " - netlink: do not free nlk->groups while lockless readers can use it", " - Revert \"drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disable\"", " - drm/xe/i2c: Disable IRQ on unbind", " - ASoC: cs-amp-lib: Prevent NULL pointer if efi variable is zero length", " - net/sched: codel: bound the dropping loop per dequeue call", " - net: do not advance stack index from dev_fwd_path()", " - net: airoha: Fix non-standard return value in airoha_ppe_get_wdma_info()", " - net: pass dst via net_device_path in dev_fill_forward_path()", " - net: pass net_device_path_ctx to dev_fill_forward_path()", " - net: remove WARN_ON_ONCE() from the dev_fill_forward_path() loop check", " - net: prevent torn reads in netdev_tc_txq", " - net: stmmac: preserve real_num_tx_queues on mqprio setup failure", " - drm/amd/display: fix MALL hysteresis timer underflow at high refresh", " rates", " - perf: Fix null pointer access in is_include_guest_event()", " - Bluetooth: keep dst_type with dst when reusing an LE connection", " - gpiolib: Put fwnode reference on failure", " - dma-buf: Fix silent overflow for phys vec to sgt", " - dma-buf: Split sgl by largest page-aligned chunk", " - mips: select CONFIG_WEAK_REORDERING_BEYOND_LLSC from CONFIG_EYEQ", " - drm/amdkfd: Avoid integer underflow in EOP ring size calculation.", " - drm/amdkfd: Avoid integer underflow with ffs in EOP ring size calc", " - drm/amdkfd: implement restore_mqd callbacks for GFX12/12.1", " - smb: client: fix WSL reparse point uid/gid override", " - smb: client: fix fattr leaking on wsl_to_fattr() failure", " - drm/ttm: fix swapped-out resources never leaving their bulk_move range", " - doc/netlink: netlink-raw: Add max check", " - selftests/bpf: Test bpf_cpumask_populate() rejects a borrowed cpumask", " - Upstream stable to v6.18.54, v7.2.8", "", " * Resolute update: upstream stable patchset 2026-10-06 (LP: #2169641) //", " CVE-2026-98163", " - cgroup: Avoid iteration of dying tasks with zero refcount", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638)", " - drm/amd/display: Fix backlight max_brightness to match exported range", " - drm/amd/display: Scale custom brightness curve from full range", " - i3c: master: Fix device_register() error path", " - tracing/probes: ignore id update from btf_type_skip_modifiers", " - udf: Move udf_map_block() up", " - nvdimm: preserve flush callback -ENOMEM", " - tracing/probes: Fix BTF kflag check for anonymous struct member access", " - udf: Fix data loss when converting inline inodes to out of line", " - futex: Optimize futex hash bucket access patterns", " - nvdimm: pmem: keep PREFLUSH before data writes", " - nvdimm: virtio_pmem: stop allocating child flush bio", " - nvdimm: virtio_pmem: always wake -ENOSPC waiters", " - nvdimm: virtio_pmem: use READ_ONCE()/WRITE_ONCE() for wait flags", " - clk: qcom: Fix test_ctl_hi field for DEFAULT_EVO PLLs", " - mm/mremap: reset unfaulted VMA page offset for MREMAP_DONTUNMAP", " - platform/x86: hp-wmi: Add support for OMEN MAX 16-ak0xxx (8DD6)", " - staging: sm750fb: fix mono image source stride mismatch in", " lynxfb_ops_imageblit()", " - dm-pcache: reject a kset that overruns its segment", " - dm-pcache: bound the logical key offset from persistent memory", " - KVM: x86: Disallow EFER.LME and EFER.LMA if long mode is not supported", " - KVM: x86: Extract REGS and SREGS runtime sync code to helpers", " - KVM: x86: Rename __{g,s}et_sregs2() =>", " kvm_vcpu_ioctl_x86_{g,s}et_sregs2()", " - KVM: x86: Move the bulk of register specific code from x86.c to regs.c", " - KVM: x86: Check EFER validity on KVM_SET_SREGS*", " - Smack: Fix error in capability bypass", " - drm: Remove unused header in drm_dumb_buffers.c", " - drm: lcdif: Wait for vblank before disabling DMA", " - drm/bridge: synopsys: dw-dp: Set pixel mode by platform data", " - drm/rockchip: dw_dp: Simplify error handling", " - drm/rockchip: dw_dp: Add missing newline in dev_err_probe() message", " - drm/rockchip: vop2: Fix wrong wait target in layer cfg done check", " - drm/rockchip: vop2: Wait for layer cfg done before switching", " LAYERSEL_REGDONE_SEL", " - drm/rockchip: analogix_dp: Enable hclk for RK3588", " - drm/bridge: display-connector: don't autoenable HPD IRQ", " - drm/bridge: display-connector: trigger initial HPD event for DP", " - drm/rockchip: vop2: Add RK3576 to the RG swap special case", " - drm/rockchip: vop2: Recognise 10-bit YUV422 as YUV format", " - drm/bridge: cdns-dsi: Return an error pointer on allocation failure", " - drm/bridge: cdns-mhdp8546: Return an error pointer on allocation failure", " - smack: simplify write handlers of sysfs entries", " - smack: deduplicate smackfs/{direct,mapped} file_operations", " - smack: restrict smackfs/{direct,mapped} values to 0-255", " - sched_ext/scx_flatcg: Fix cvtime_delta race and add hweight scaling to", " bypass charging", " - x86/cfi: Use symmetric SYM_START and SYM_END in __CFI_TYPE()", " - selftests: proc: include fcntl.h in proc-pidns", " - HID: nintendo: Fix imu_timestamp_us double increment per report", " - soc: samsung: exynos-pmu: fix of_node refcount leak in", " exynos_get_pmu_regmap()", " - media: cec-pin: Fix event FIFO ordering", " - cxl/pci: Remove incorrect mbox.valid check in", " cxl_pci_type3_init_mailbox()", " - clk: versaclock7: Fix APLL clock leak on probe failure", " - clk: moxart: remove unused variables, fix refcount leak", " - clk: nuvoton: ma35d1: fix ignored div_u64 return values in PLL freq", " calculation", " - clk: nuvoton: ma35d1: fix PLL_CTL1_FRAC bit field width and fractional", " calc", " - clk: nuvoton: ma35d1: fix ma35d1_clk_pll_determine_rate logic", " - clk: stm32: add missing bitfield.h header", " - clk: hisilicon: reset: Use devm_kzalloc to initialize", " hisi_reset_controller", " - ARM: imx: fix device_node refcount leak in imx_src_init()", " - ARM: imx: fix device_node refcount leaks in imx7_src_init()", " - arm64: dts: imx93-kontron: set memory node to 0x80000000/1GiB", " - clk: imx: scu: drop redundant init.ops variable assignment", " - mm/mm_init: fix incorrect node_spanned_pages", " - perf/x86/intel/uncore: Keep PCI PMUs working when MMIO/MSR setup fails", " - pinctrl: bcm2835: Don't remove an unregistered GPIO chip", " - riscv: kexec_file: Fix crashk_low_res not exclude bug", " - media: keymaps: Remove obsolete RC_MAP_RC5_TV keymap define", " - media: keymaps: Remove obsolete RC_MAP_HAUPPAUGE_NEW keymap define", " - wifi: ath12k: correct monitor destination ring size", " - perf test: Drain pipe after child finishes to avoid losing output", " - perf test: Refactor parallel poll loop to drain all pipes simultaneously", " - perf test: Show snippet failure output for verbose=1", " - perf test: Add summary reporting", " - perf test: Fix subtest status alignment for multi-digit indexes", " - perf test: Add -j/--junit option for JUnit XML test reports", " - perf test: Truncate printed test descriptions dynamically to avoid", " terminal wrapping", " - perf test: Truncate test description to fit terminal width", " - perf tests: Skip metrics validation if system-wide recording lacks", " permission", " - perf tests: Add robust record retry helper and use subsecond workloads", " - perf tests: Fix flakiness in trace record and replay test", " - perf test: Fix perf stat --bpf-counters on hybrid machines", " - perf tests: Fix flakiness in BPF counters test on hybrid systems", " - perf test: Fixes for check branch stack sampling", " - perf tests: Fix flakiness in branch stack sampling tests", " - regulator: tps6594: Fix device node reference leaks in multiphase loop", " - tools/bpf/bpftool: Reset vmlinux BTF after map commands", " - tools/bpf/bpftool: Reset vmlinux BTF after struct_ops commands", " - selftests/bpf: Mask socket type flags in mptcpify prog", " - mm: name the anonymous MMOP enum as enum mmop", " - dmaengine: mediatek: mtk-uart-apdma: Return -ENOMEM on memory allocation", " failure", " - dmaengine: hisilicon: Return -ENOMEM on dynamic memory allocation in", " probe", " - soundwire: qcom: Fix port exhaustion check in stream_alloc_ports", " - iio: orientation: hid-sensor-rotation: Avoid race between callback setup", " and device exposure", " - selftests/rseq: Replace glibc-specific __GNUC_PREREQ with portable check", " - wifi: rtw89: check return values in rtw89_ops_start_ap()", " - wifi: rtw89: fix HE extended capability length check", " - fanotify: initialize permission event watchdog state", " - tools/nolibc: mark arg1 operand in __nolibc_syscall0() as write-only", " - perf cs-etm: Fix thread leaks on trace queue init failure", " - perf/x86/amd/uncore: Add group validation", " - perf vendor events amd: Update Zen 5 core events", " - RDMA/irdma: Deduplicate the irdma_del_memlist logic", " - RDMA/irdma: Add a refcount to track user ring MR associations", " - RDMA/irdma: Add irdma_cq fields to track pbl allocations", " - arm64: dts: qcom: sm8750: wire UFS to ice instance", " - nvmet-rdma: factor out response resource cleanup", " - bus: ti-sysc: Fix /chosen node reference leak", " - PM: sleep: Fix off-by-one in wakelocks number limit check", " - arm64: dts: qcom: sc8280xp-blackrock: switch to uefi rtc offset", " - arm64: dts: qcom: sm7225-fairphone-fp4: Fix address in fb node name", " - arm64: dts: qcom: hamoa: Fix clocks for HSPHYs", " - clk: qcom: gcc-glymur: Move EVA clocks to critical clock list", " - bus: qcom-ebi2: Fix clock leak on probe failure", " - staging: greybus: audio: correct sscanf() return value check", " - staging: sm750fb: gate dualview dataflow using g_dualview", " - staging: sm750fb: Add missing Kconfig dependency", " - greybus: audio: bound the topology section sizes against the fetched", " size", " - staging: fbtft: Use sysfs_emit_at() to print to sysfs file", " - staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown", " - staging: octeon: fix free_irq dev_id mismatch in cvm_oct_rx_shutdown", " - staging: octeon: ethernet-mem: replace pr_warn with dev_warn in free", " functions", " - staging: octeon: replace pr_warn with dev_warn in fill and rx paths", " - staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown", " - staging: rtl8723bs: fix mismatched free of HalData in", " rtw_sdio_if1_init()", " - ALSA: via82xx: Remove unreachable branch in snd_via686_pcm_pointer()", " - selftests/bpf: Fix memory leak in msg_alloc_iov error path", " - selftests/bpf: Fix memory leak in msg_alloc_iov", " - selftests/lsm: Fix memory leak in attr_lsm_count", " - irqchip/gic-v3-its: Fix memleak in its_probe_one()", " - irqchip/gic-v3-its: Fix its node leak in gic_acpi_parse_madt_its()", " - selftests: timers: leap-a-day: Fix -w option and update usage comment", " - clocksource: Unregister subsystem on device registration failure", " - timekeeping: Unwind aux clock sysfs children on failure", " - timers/migration: Fix memory leak in tmigr_setup_groups() error path", " - vdso/timens: Move functions to new file", " - timens: Add a __free() wrapper for put_time_ns()", " - timens: Simplify some calls to put_time_ns()", " - y2038: uapi: Use 64-bit __kernel_old_timespec::tv_nsec on x32", " - timekeeping: Account for monotonicity adjustment in ntp_error", " - arm64: dts: qcom: Add #{address,size}-cells to Chromium-based /firmware", " - clk: qcom: gdsc: propagate gdsc_check_status() errors from", " gdsc_poll_status", " - clk: qcom: gdsc: propagate gdsc_enable() failure for ALWAYS_ON domains", " - arm64: dts: qcom: sc8280xp-arcata: Fix top USB-C DP alt mode", " - arm64: dts: qcom: sc8180x-primus: Rename regulator nodes", " - arm64: dts: qcom: sc8180x-primus: Describe the display power net", " - arm64: dts: qcom: sc8180x-lenovo-flex-5g: Rename regulator nodes", " - arm64: dts: qcom: sc8180x-lenovo-flex-5g: Describe the display power net", " - clk: qcom: gcc-qcs8300: Use retention for PCIe power domains", " - clk: qcom: gcc-qcs8300: Use retention for USB power domains", " - perf data convert json: Fix trace_seq memory leak in", " process_sample_event()", " - staging: media: ipu7: fix pm_runtime refcount leak in", " ipu7_init_fw_code_region_by_sys()", " - usb: typec: ucsi: unregister debugfs entries on teardown", " - bpftool: Check EVP_Digest when computing excl_prog_hash", " - perf vendor events amd: Reintroduce deprecated Zen 5 core events", " - perf dso: Fix kallsyms DSO detection with fallback logic", " - efi: fix stale reference to efi_recover_from_page_fault()", " - iommu/mediatek-v1: Fix off-by-one in MT2701_LARB_NR_MAX", " - bpf: Fix security_bpf_map_create error handling", " - iommu/msm: Return -ENOMEM on memory allocation failure in probe", " - iommu/amd: Prevent SB IOAPIC from overriding IVRS validation errors", " - iommu/amd: Add support for Hygon family 18h model 4h IOAPIC", " - iommu/amd: Fix false positive in SB IOAPIC IVRS validation", " - leds: pca9532: Fix inverted GPIO output polarity", " - leds: st1202: Stop pattern sequence before reprogramming", " - leds: st1202: Fix pattern duration prescaler and pattern_clear skip", " marker", " - leds: st1202: Fix spurious pattern sequence start in setup", " - leds: st1202: Set all pattern PWM slots to full after clearing pattern", " - leds: st1202: Fix brightness having no effect while pattern mode is", " active", " - leds: st1202: Disable channel when brightness is set to zero", " - leds: st1202: Validate LED reg property against channel count", " - ACPI: RISC-V: Fix riscv_acpi_irq_get_dep() loop termination", " - platform/x86: lg-laptop: Drop debug-only ACPI notify handler", " - platform/x86: lg-laptop: Convert ACPI driver to a platform one", " - hwspinlock: propagate errno when registering single lock", " - selftests/sched_ext: Fix bpf_link leak on early return in prog_run", " - perf capstone: Fix kernel map reference count leak", " - spi: qcom-geni: Fix missing error check on pm_runtime_get_sync()", " - serial: core: Add dedicated uart_port field for console flow", " - serial: Replace driver usage of UPF_CONS_FLOW", " - serial: 8250: Set cons_flow on port registration", " - serial: 8250: Add support for console flow control", " - serial: 8250: Clear CON_PRINTBUFFER on port re-registration", " - serial: ma35d1: Fix OF node reference leaks in console init", " - usb: mtu3: allow system suspend during active gadget connection", " - usb: renesas_usbhs: Fix power-off ordering on unbind", " - usb: ucsi: huawei_gaokun: support mode switching", " - usb: typec: ucsi: gaokun: unwind notifier on UCSI register failure", " - drm/panel: samsung-s6d16d0: Power off on prepare failure", " - perf metricgroup: Fix metric expression copy leaks", " - soc: qcom: rpmh-rsc: manage PM notifiers with devres", " - bus: qcom-ebi2: use managed resources for clocks and children", " - wifi: rtw89: mlo: rearrange MLSR link decision flow", " - wifi: rtw89: phy: support per PHY RX statistics", " - wifi: rtw89: 8852a: fix RSSI report when average beacon RSSI is not", " ready", " - iio: accel: dmard09: Implement IIO_CHAN_INFO_SCALE", " - drm/msm/dp: add missing drm_edid_connector_update() before add_modes on", " cached EDID", " - Revert \"drm/msm: dsi: fix PLL init in bonded mode\"", " - crypto: ccp - Fix memory leak in SEV INIT_EX path", " - hwrng: ks-sa - Fix runtime PM cleanup on registration failure", " - ALSA: hpi: Check transport errors during HPI6000 adapter initialization", " - pmdomain: bcm: bcm2835: handle genpd provider registration errors", " - misc: rtsx_usb: avoid USB I/O in runtime autosuspend", " - RDMA/hfi1: Stop flushing the global IB workqueue", " - RDMA/hfi1: Initialize debugfs after probe completes", " - ASoC: apple: mca: increase SERDES reset delay", " - iommufd/selftest: Avoid selftest dirty bitmap size wrap", " - perf zstd: Fix compression error path in", " zstd_compress_stream_to_records()", " - perf record: Return the written size from process_comp_header()", " - perf record: Fix multiple PERF_RECORD_COMPRESSED2 records per push", " - iommufd: Simplify iommufd_device_remove_vdev()", " - cxl/memdev: Fix firmware upload exact-fit handling", " - cxl/pci: Honor -EPROBE_DEFER from component register setup", " - cxl/port: Restart port enumeration when a sibling adds the dport first", " - wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate", " - x86/entry/fred: Encode frame pointer on entry", " - firmware: arm_scmi: Use channel ID for transport teardown", " - firmware: arm_scmi: Protect device request lookup with RCU", " - regulator: adp5055: Fix error code in adp5055_of_parse_cb()", " - tools/sched_ext: scx_qmap: Fix stale API name in comment", " - libnvdimm/labels: Bound the on-media label size before the shift", " - cpufreq: spear: Fix an IS_ERR() vs NULL bug in spear1340_set_cpu_rate()", " - PCI: xgene: Drop unnecessary OF node reference", " - media: i2c: rdacm21: Fix missing media_entity_cleanup()", " - drm/amd/display: Remove unused-but-set variable hubp from", " - cpufreq: intel_pstate: Fix setting minimum P-state at init time", " - cpufreq: schedutil: Fix self-contradictory comment in", " sugov_iowait_apply()", " - remoteproc: qcom: Fix glink->node reference leak in", " qcom_add_glink_subdev", " - perf: evsel: Fix error handling in tp_format lookup", " - arm64: dts: qcom: msm8996-xiaomi-gemini: Fix up ti,drv2604 enable GPIO", " - arm64: dts: qcom: sc8280xp-x13s: Fix the drive-strength of mclk pin", " - arm64: dts: qcom: ipq5018: Correct CMN PLL reference clock rate", " - arm64: qcom: ipq5018: Add GEPHY RX and TX clocks", " - arm64: dts: qcom: sm8250: sort out Iris power domains", " - arm64: dts: qcom: sm8250: correct frequencies in the Iris OPP table", " - perf jevents: Add more components to the metric sorting order", " - clk: qcom: gcc-glymur: Enable runtime PM", " - soc: renesas: r8a78000: Drop duplicate \"default ARCH_RENESAS\"", " - spi: geni-qcom: Fix sticky ret causing wrong return value on invalid", " proto", " - wifi: iwlwifi: mei: pass correct argument to function", " - gpu: host1x: Fix offset calculation in trace_write_gather", " - drm/msm/a6xx: Fix stale rpmh votes after suspend", " - drm/msm: Recover HW before retire hung submit", " - drm/msm/a6xx: Fix A663 GPUCC register list for state capture", " - drm/msm/a6xx: Fix A621 GPUCC register list for state capture", " - crypto: sl3516 - drop invalid sg_dma_len checks before DMA mapping", " - ACPI: processor: idle: Expand _LPI package sanity checks", " - tty: hvc: restrict HVC_DCC to ARMv6+ and ARM64", " - staging: rtl8723bs: remove multiple blank lines in core/", " - staging: rtl8723bs: fix xmit_frame/xmit_buf leaks on mgnt-frame error", " paths", " - gpib: Move stuck SRQ update under lock", " - accessibility: speakup: Fix incorrect string length computation in", " report_char_chartab_status()", " - misc: rtsx: add missing write register handling", " - misc: lan966x_pci: depopulate children on populate failure", " - cacheinfo: don't propagate DT/ACPI error when arch supplies info (arm64)", " - ppdev: prevent overflow when setting port timeout", " - char: xilinx_hwicap: unregister class on init errors", " - mtd: intel-dg: Fix runtime PM error path in probe", " - perf ui hists: Fix uninitialized stack memory free on pstack allocation", " failure", " - driver core: soc: Unregister bus on early device registration failure", " - drm/msm/a6xx: Fix RBBM_CLOCK_CNTL3_TP0 value in a730_hwcg", " - dmaengine: dw-edma: Clear stale requests on termination", " - phy: starfive: Fix runtime PM cleanup in JH7110 DPHY TX probe", " - phy: starfive: Fix runtime PM cleanup in JH7110 DPHY RX probe", " - arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to", " nand_all_pins", " - arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for", " PCIe", " - RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters", " - kcsan: avoid unintended access checking in NMIs", " - arm64: dts: imx8-ss-audio: Fix LPCG clock indices for ASRC0", " - x86/bugs: Don't use cpu-type matching in cpu_vuln_blacklist", " - selftests/bpf: Check malloc result with ASSERT_NEQ in test_sha256", " - selftests/bpf: Silence array bounds warning in global_map_resize", " - ACPI: EC: Avoid _REG disconnect on GPIO IRQ defer", " - ext4: fix circular lock dependency in ext4_ext_migrate", " - ext4: skip extra isize expansion during mount to prevent deadlock", " - platform/x86: acer-wmi: reject missing gaming WMI results", " - libbpf: Search /lib64 and /lib in resolve_full_path()", " - ACPI: battery: Adjust charging status validation check", " - virt: arm-cca-guest: use migrate_disable() for attestation token", " requests", " - bpf: Mark bpf_refcount field as unique", " - RDMA/srpt: Pass the mapped task attribute to target_init_cmd()", " - PCI: j721e: Fix incorrect max_lanes for J7200", " - RDMA/core: Add rdma_restrack_begin/abort/commit_del() operations", " - RDMA/core: Fix potential use after free in uverbs_free_dmah()", " - iommu/qcom: Remove sysfs device on probe failure path", " - iommu/qcom: Fix inverted fault report check in qcom_iommu_fault()", " - iommu/arm-smmu-v3: Declare eats_s1chk and eats_trans as host-endian u64", " - wifi: ath12k: switch to name-based reserved memory lookup", " - wifi: ath12k: refactor QMI memory assignment", " - wifi: ath12k: allocate HOST_DDR and BDF regions after Q6 RO region", " - wifi: ath12k: Correctly copy the hint BSSID in WMI scan request", " - wifi: ath11k: Correctly copy the hint BSSID in WMI scan request", " - ARM: dts: allwinner: a10: Fix PMU interrupt", " - amd-pstate: Make certain freq_attrs conditionally visible", " - cpufreq/amd-pstate: Add dynamic energy performance preference", " - cpufreq/amd-pstate: Add support for platform profile class", " - cpufreq/amd-pstate: Fix EPP return type and handle errors during", " initialization", " - cpufreq/amd-pstate: Toggle auto_sel in active mode on shared memory", " systems", " - riscv: dts: spacemit: k1: Split gmac_clk_ref into independent pinctrl", " groups", " - perf cs-etm: Flush thread stacks after decoder reset", " - perf cs-etm: Avoid truncating AUX buffer sizes to int", " - PM: hibernate: Fix memory leak in snapshot_write_next() error path", " - leds: pca9532: Fix phantom device registration on missing hardware", " - perf cap: Remove used_root parameter and simplify capability checks", " - drm/tve200: add OF module alias for autoloading", " - netfilter: nf_nat_sip: rewind offset when NAT shrinks the packet", " - drm/panthor: return PTR_ERR() from devm_drm_dev_alloc()", " - arm64: dts: rockchip: Add missing hclk for RK3588 eDP0", " - arm64: dts: rockchip: Add missing hclk for RK3588 eDP1", " - arm64: dts: rockchip: Fix Gru WLAN sideband interrupt", " - arm64: dts: rockchip: Fix rk3566-bigtreetech-cb2 touchscreen property", " - ARM: lpc32xx: only run SoC init on LPC32xx hardware", " - selftests/bpf: Fix incorrect error checking for pthread_create", " - selftests/bpf: Fix memory leak on subtest_states reallocation", " - tools/build: Allow versioning of all LLVM tools defined in", " Makefile.include", " - arm64: RSI: fix field-spanning write warning in attestation token init", " - power: supply: sbs-battery: Use a per-device serial number buffer", " - crypto: keembay - publish OF module alias for OCS AES/SM4", " - thermal/drivers/airoha: Fix copy paste error on clamp_t low temp", " - thermal/drivers/airoha: Fix copy paste error for sen internal", " - thermal/drivers/qcom-spmi-adc-tm5: Drop IIO_VAL_INT check in", " adc_tm5_get_temp", " - powercap: intel_rapl_tpmi: Handle PMU registration failure during probe", " - clk: mediatek: mt6735: Unregister PLLs on probe failure", " - w1: ds2482: Fix signedness bug in ds2482_w1_triplet()", " - cpufreq/amd-pstate: Set min_limit_freq based on bios_min_perf", " - remoteproc: Allow shutdown of crashed processors", " - remoteproc: core: Attach rproc asynchronously in rproc_add() path via", " schedule_work()", " - staging: rtl8723bs: use kfree_sensitive() for key material", " - RDMA/efa: Fix PBL chunk length computation", " - wifi: mac80211: fix per-STA profile length in cross-link CSA parsing", " - arm64: dts: allwinner: sun50i-a64-pinephone: Fix mpu6050 mount matrix", " - clk: tegra: tegra124-emc: put EMC node on register failure", " - clk: palmas: Manage external-control prepare with devm", " - clk/x86: pmc_atom: add kasprintf return value check", " - clk: mediatek: mt8135: Fix inverted gate control for devapc_ck", " - clk: rockchip: Fix the fractional part denominator on RK3588/RK3576 PLLs", " - scsi: smartpqi: Fix AIO retry marker cleared by SCSI core between", " dispatches.", " - RDMA/mlx5: Send cong param changes to the resolved port mdev", " - media: staging/ipu7: fix async notifier leak on init error", " - wifi: ath12k: validate TLV length in process_tpc_stats()", " - PCI: starfive: Fix Runtime PM handling and teardown ordering", " - PCI: starfive: Fix unchecked pm_runtime_get_sync() in probe", " - drm/msm: remove objects from evit list after pinning them", " - media: qcom: iris: Fix bitmask test in iris_allow_cmd()", " - platform/chrome: cros_ec_debugfs: Clean up console log on probe failure", " - bus: mhi: host: Flush the posted write after writing to", " MHI_SOC_RESET_REQ_OFFSET", " - md/raid5: protect bitmap batch counters aka seq_flush/seq_write", " consistency", " - md/raid5-ppl: fix use-after-free in ppl_do_flush()", " - md/raid5: protect lockless recovery_offset accesses during reshape", " - fanotify: stop permission watchdog when timeout is zero", " - tools/nolibc/powerpc: mark ctr and xer as clobbered by system call", " - selftests/zram: fix kernel_gte() for POSIX sh", " - Revert \"serial: 8250: Clear CON_PRINTBUFFER on port re-registration\"", " - md/raid10: consistently fail atomic writes that require splitting", " - rcu: Mark accesses to ->rcu_urgent_qs and ->rcu_need_heavy_qs", " - arm64: dts: qcom: msm8998: Don't pull-up I2C pins by default in sleep", " - arm64: dts: qcom: msm8976-longcheer-l9360: Fix accidental node override", " - arm64: dts: qcom: sdm632-motorola-ocean: Fix LED default trigger", " property", " - arm64: dts: qcom: qcs404: Fix DTBS Check errors in usb controller nodes", " - clk: qcom: gcc-qcm2290: don't park QUP RCGs upon registration", " - arm64: dts: qcom: sc8280xp-crd: Fix the pin index for misc_3p3_reg_en", " - firmware: qcom: scm: add trace events for the SMC call interface", " - firmware: qcom: scm: instrument SMC call path with tracepoints", " - firmware: qcom: scm: Fix reserved memory cleanup on probe failure", " - firmware: qcom: scm: Fix tzmem state on probe retry", " - block: don't set BIO_QUIET for BLK_STS_AGAIN", " - block: add a bio_endio_status helper", " - arm64: dts: qcom: sm8250-xiaomi-elish: correct the board ID", " - clk: qcom: gpucc-qcm2290: Park RCG's clk source at XO during disable", " - clk: qcom: Return expected ENOMEM error on dynamic allocation failure", " - md: remove unused mddev argument from export_rdev", " - md: skip redundant raid_disks update when value is unchanged", " - i3c: master: adi: add OF module alias for autoloading", " - fs: annotate inode timestamp accessors", " - locking/lockdep: Fix NULL pointer dereference in __lock_set_class()", " - powerpc: implement get_direction() in cpm2", " - powerpc/44x: Set GPIO chip parent", " - powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()", " - misc: vmc_vmci: Fix potential memory leak in vmci_event_subscribe()", " - fanotify: report full event length for FIONREAD", " - wifi: mt76: connac: add MT7991A (0x7991) to is_mt7996()", " - wifi: mt76: mt7915: fix net_fill_forward_path for non-DBDC mt7986", " - wifi: mt76: always enable RRO queues for non-MT7992 chipset", " - wifi: mt76: mt7925: update clc before setting sar power table", " - wifi: mt76: mt7925: fix msg len mismatch between driver and firmware", " - wifi: mt76: mt7996: fix EAPOL source BSS for non-MLD stations", " - wifi: mt76: mt7996: fix capability of EHT-MCS 15 in MRU", " - wifi: mt76: mt7996: set specific BSSINFO and STAREC commands after", " channel switch", " - wifi: mt76: mt7996: fix out-of-bounds array access during hardware", " restart", " - wifi: mt76: assign link_id when sending probe request during scan", " - wifi: mt76: mt7996: set MT76_MCU_RESET before waking MCU waiters on full", " reset", " - wifi: mt76: mt7996: don't report a zero TX bitrate", " - wifi: mt76: mt7915: write RX header translation bit to the correct", " register", " - wifi: mt76: fix stranded frames in mt76_txq_schedule_pending", " - wifi: mt76: fix uninitialised RXDMAD_C descriptor info", " - wifi: mt76: mt7915: poll the correct SLP CTRL register for the second", " adie", " - wifi: mt76: check txfree done event on the WED hw path", " - wifi: mt76: mt7996: don't leak MLD group index on remap alloc failure", " - wifi: mt76: mt7915: use little-endian for bss_info_ra wire fields", " - wifi: mt76: mt7996: add missing rdd_idx check when enabling background", " radar", " - wifi: mt76: only consume the WO drop bit on WED v2 devices", " - drm/msm/dp: reject YUV420-only modes without VSC SDP support", " - drm/msm/dp: do not reject wide-bus modes while a YUV420 mode is active", " - perf: arm_spe: Make wakeup range check overflow safe", " - drm/msm/dpu: Drop sneaky dev_pm_opp_set_rate(0)", " - drm/msm/dp: Drop dev_pm_opp_set_rate(0)", " - perf machine: Fix fd leak on bounds check in", " maps__set_modules_path_dir()", " - perf machine: Fix NULL parent dereference in fork event processing", " - perf machine: Guard against NULL strlist in machines__findnew()", " - perf machine: Check snprintf truncation in machines__findnew()", " - perf machine: Don't abort guest map creation on first inaccessible dir", " - perf machine: Reset errno before strtol in guest kernel map creation", " - perf machine: Free scandir entries in guest kernel map creation", " - perf machine: Check snprintf truncation for guest kallsyms path", " - wifi: mt76: mt7996: skip key upload when adding an offchannel link", " - wifi: mt76: mt7996: wake MCU waiters before aborting scan in L1 SER", " - wifi: mt76: mt7996: fix MIB TX aggregation counter registers for mt7990", " - wifi: mt76: mt7996: fix reg addr remap when addr is 0", " - wifi: mt76: mt7915: fix chainmask handling for non-dbdc phys on band 1", " - wifi: mt76: mt7915: report RX chain signal for all RX paths", " - wifi: mt76: fix queue assignment for disassoc packets", " - wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band", " - wifi: mt76: mt7925: Fix EHT Beamformee SS subfields to meet 802.11be", " minimum", " - wifi: mt76: mt7996: remove beacon_int_min_gcd from ADHOC interface", " combinations", " - arm64: smp: Fix IPI teardown for GICv5 flow", " - arm64/fpsimd: ptrace: Fix inactive SVE and SSVE regsets", " - kselftest/arm64: fp-ptrace: Fix checks for inactive SVE and SSVE regsets", " - kselftest/arm64: Don't write to P0 in irritator on SME only systems", " - iommu/arm-smmu-v3: Convert to use atomic poll timeout", " - perf/cxlpmu: Fix 64-bit write to 32-bit HDM filter register", " - wifi: mac80211: send TWT teardown to peer after setup TX failure", " - wifi: zd1211rw: reject secondary interfaces to prevent conflicts", " - wifi: mac80211: skip unused probe response countdown offsets", " - wifi: nl80211: refactor nl80211_parse_chandef", " - wifi: cfg80211: Add an API to configure local NAN schedule", " - firmware: google: Add bounds checks in coreboot_table_populate()", " - pinctrl: eswin: Fix Handling of PIN_CONFIG_PERSIST_STATE", " - pinctrl: spacemit: validate pins in pinconf callbacks", " - powerpc/smp: add NULL guard for cause_ipi in smp_muxed_ipi_message_pass", " - powerpc/irq: Fix missing r2 clobber in PCREL inline assembly", " - soc: fsl: qe: properly scan GPIO nodes at startup", " - soc: fsl: qe: implement get_direction()", " - MIPS: ptrace: Fix syscall skipping via PTRACE_SYSCALL", " - serial: amba-pl011: unprepare console clock on unregister", " - misc: pci_endpoint_test: Check SUCCESS bit for doorbell status", " - HID: i2c-hid: Refactor _DSM helper and add i2c-hid-acpi-prp0001 driver", " - HID: i2c-hid: Fix \"(null)\" output when reading report descriptor fails", " - HID: steam: Refactor and clean up report parsing", " - HID: steam: Rename some constants that got renamed upstream", " - HID: steam: Add support for sensor events on the Steam Controller (2015)", " - HID: steam: Improve logging and other cleanup", " - HID: i2c-hid: goodix: Disable VDD on VDDIO enable failure", " - HID: lg4ff: validate report length before fixed offsets", " - perf thread-stack: Fix heap buffer overflow on branch stack wrap copy", " - perf auxtrace: Fix queue grow overflow and old array leak", " - perf intel-pt: Fix off-by-one in auxtrace_info minimum size check", " - perf intel-bts: Fix off-by-one in auxtrace_info minimum size check", " - perf arm-spe: Reject zero nr_cpu in metadata to prevent division by zero", " - iio: light: tsl2772: fix ALS calibscale readback", " - iio: light: isl29028: return zero in write_raw() on success", " - iio: light: tsl2583: return zero in write_raw() on success", " - net: stmmac: Skip PHY attach if custom PCS is in use", " - block/blk-stat: drain per-cpu callback stats over possible CPUs", " - block/blk-iocost: collect per-cpu latency stats over possible CPUs", " - block/kyber-iosched: flush per-cpu latency buckets over possible CPUs", " - ublk: check for ublk_unmap_io() returning 0", " - lib/string: fix memchr_inv() for large ranges", " - pps: don't try to wait for negative timeouts in PPS_FETCH", " - pps: pps-gpio: split IRQ handler into hardirq timestamper + threaded", " handler", " - pps-gpio: remove dead capture_clear code", " - riscv: dts: sophgo: cv180x: Allow the DMA multiplexer to set channel", " number for DMA controller", " - arm64: dts: qcom: agatti: Add missing CX power domain to DISPCC", " - remoteproc: Move resource table data structure to its own header", " - remoteproc: use rsc_table_for_each_entry() in rproc_handle_resources()", " - selftests/mm: ksm_tests: use kselftest framework", " - selftests/mm: fix ksm NUMA merge test for systems with memoryless NUMA", " nodes", " - selftests/mm: fix ternary operator precedence in ksm_tests", " - arm64: dts: qcom: sc8280xp-blackrock: Fix swapped USB QMP PHY vdda-", " phy/vdda-pll supplies", " - arm64: dts: qcom: qcs8550-aim300: Fix swapped USB QMP PHY vdda-phy/vdda-", " pll supplies", " - arm64: dts: qcom: sm7225-fairphone-fp4: Fix swapped USB QMP PHY vdda-", " phy/vdda-pll supplies", " - arm64: dts: qcom: sar2130p: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - intel_idle: Avoid using deep idle states during initialization", " - scripts/tags.sh: Prevent binary files appearing in cscope.files", " - modpost: prevent leak when early return no suffix .o in read_symbols()", " - kbuild: fix modules.builtin(.modinfo) targets in the top-level Makefile", " - perf libbfd: Validate BPF prog info arrays before pointer cast", " - perf bpf: Add PROG_TAGS to required arrays in", " __bpf_event__print_bpf_prog_info()", " - perf libbfd: Fix memory leaks and NULL fclose in BPF disassembly", " - clk: rockchip: rk3576: fix source muxes for SPI0..SPI4", " - drm/sun4i: vi scaler: Fix coefficient selection", " - drm/sun4i: tcon: Set output mux for DSI and LVDS", " - drm/sun4i: hdmi: Don't leak sync polarity bits into packet control", " - drm/sun4i: tcon: Drop remote endpoint reference", " - drm/sun4i: dw-hdmi: Drop TCON TOP port reference", " - drm/sun4i: hdmi-phy: Fix H6 8-bit MPLL config at 594 MHz", " - rust: cpufreq: Add CPUFREQ_TABLE_END as last table entry in", " TableBuilder::to_table", " - rust: cpufreq: Fix temporary write in Registration::bios_limit_callback", " - module: use strscpy() to copy module names in stats and dup tracking", " - module/dups: Inform duplicate requests about the result directly", " - RDMA/erdma: restrict the driver to little-endian systems", " - [Config] Disable CONFIG_INFINIBAND_ERDMA on s390x", " - wifi: mac80211: skip default WMM setup for AP_VLAN links", " - arm64: hibernate: mask DAIF before restoring hibernated kernel", " - mfd: rave-sp: validate received frame payload lengths", " - mfd: iqs62x: Reject zero-length firmware records", " - mfd: macsmc: Fix key count endianness annotation", " - leds: gpio: Clear error pointers for skipped LEDs", " - drm/amdgpu/gfx6: Fixup emit_cntxcntl()", " - ext4: fix spurious message about orphan cleanup on RO fs", " - arm64: dts: ti: k3-am64: Fix MDIO clock reference for ICSSG0 node", " - phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for", " disabled VBUS regulator", " - phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table", " - perf trace-event: Fix buffer overflow in read_string()", " - drm/amdgpu/gfx6: Fixup emitting SWITCH_BUFFER packets", " - pinctrl: rockchip: Reset the pin count when recalculating SoC data", " - soc: fsl: qe: check platform_driver_register() in qe_ic_of_init()", " - phy: qcom-sgmii-eth: relax order of .power_on() vs .set_mode*()", " - phy: qcom: sgmii-eth: vote for both voltage rails with correct current", " loads", " - phy: qcom: qmp-pcie: Add pcs_lane1 offset to V5 offsets", " - md: avoid stale clone I/O accounting timestamps", " - coresight: etm4x: fix wrong check of etm4x_sspcicrn_present()", " - coresight: etm4x: fix leaked trace id", " - bpf, riscv: Add and use bpf_atomic_is_load_acq() helper", " - bpf, x86: Fix exception table metadata for arena load-acquire", " - bpf, arm64: Fix exception table metadata for arena load-acquire", " - regulator: qcom-rpmh: Fix PMIC5 BOB bypass mode handling", " - ACPI: video: Release PCI device reference after lookup", " - perf/x86/intel/pt: Factor out pt_config_enable()", " - perf/x86/intel/pt: Use bitwise access for PERF_HES_STOPPED", " - perf/x86/intel/pt: Fix stop/start with no update", " - sched/fair: Also gate overloaded status update for SD_ASYM_CPUCAPACITY", " - sched/fair: Check CPU capacity before comparing group types during load", " balance", " - Bluetooth: btqca: Fix qca_set_bdaddr() waiting for wrong HCI event", " - Bluetooth: btusb: Fix BD_ADDR byte order in btusb_set_bdaddr_wcn6855()", " - Bluetooth: btusb: refactor endpoint lookup", " - Bluetooth: btusb: Record matched usb_device_id into btusb_data", " - Bluetooth: btusb: QCA: Fix populating devcoredump fields on unenabled", " devices", " - perf trace-event: Fix integer truncation in do_read() and skip()", " - scsi: sd: Fix sd_done() sense handling condition", " - btrfs: use aligned range for locking in extent_fiemap()", " - btrfs: avoid GFP_ATOMIC allocations in qgroup free paths", " - pinctrl: airoha: fix mdio bitfield names", " - pinctrl: airoha: an7581: fix pinconf of i2c_scl/i2c_sda pins", " - pinctrl: airoha: an7583: fix I2C0_SDA_PD register bit order", " - pinctrl: airoha: an7581: fix mux/conf of pcie_reset pins", " - pinctrl: airoha: an7583: fix muxing of non-gpio default pins", " - pinctrl: airoha: an7583: fix spi group pins", " - pinctrl: airoha: add missed get_direction() function for gpio_chip", " - pinctrl: airoha: fix getting gpiochip/pinctrl pointers in the IRQ", " handling code", " - pinctrl: airoha: fix IRQ mask/unmask code", " - pinctrl: airoha: fix edge-triggered interrupts handling", " - Bluetooth: btintel: Fix diagnostics event detection", " - mmc: sdio: add MediaTek MT7902 SDIO device ID", " - Bluetooth: btmtk: add MT7902 MCU support", " - Bluetooth: btmtk: add MT7902 SDIO support", " - Bluetooth: btmtksdio: fix usage_count leak when autosuspend_delay is", " negative", " - iio: light: opt4060: Fix pointer type passed to div_u64_rem()", " - iio: light: gp2ap002: re-enable irq if runtime suspend fails", " - riscv: cpufeature: Clarify ISA spec version for canonical order", " - bpf: Factor out stack_map build ID helpers", " - bpf: Avoid faultable build ID reads under mm locks", " - i3c: renesas: Return immediately if there is no transfer", " - i3c: renesas: Follow a unified pattern for transfer and command", " initialization", " - i3c: renesas: Don't register devices when ENTDAA times out", " - arm64: dts: turris-mox: fix usb3 phys", " - ARM: dts: helios4: add vcc-supply to EEPROM", " - ARM: dts: helios4: add vcc-supply to GPIO expander", " - ARM: dts: helios4: add SATA regulator supplies", " - perf stat: Fix evsel_list leak in cmd_stat", " - perf synthetic-events: Fix uninitialized pthread_join", " - perf test: Support dynamic test suites with setup callback and private", " data", " - perf test: Fix skiplist leak in cmd_test", " - perf python: Check counts_values size in set_values", " - perf python: Handle Py_None for thread and cpu maps", " - perf python: Validate CPU and thread maps in pyrf_evsel__open", " - perf python: Fix memory leak in pyrf__metrics_cb", " - perf synthetic-events: Fix divide by zero in", " perf_event__synthesize_threads", " - fbdev: tdfxfb: fix PCI enable cleanup with pcim_enable_device()", " - fbdev: clps711x-fb: Remove unreachable unregister_framebuffer() call", " - iommu/vt-d: Fix UCTP context table slot when copying root entries", " - crypto: qat - use 2-arg strscpy where destination size is known", " - crypto: qat - remove dead ADF_HEX code", " - hwrng: imx-rngc - Disable clock on registration failure", " - m68k: Fix backtraces for non-running tasks", " - xdrgen: Do not declare union XDR functions in the definitions header", " - xdrgen: Fix opaque and string encoders for unbounded members", " - arm64: Disable KCSAN instrumentation in delay.o", " - hwmon: (cros_ec) Register the thermal devices after the hwmon ones", " - hwmon: (cros_ec) Store the hwmon device in cros_ec_hwmon_priv", " - hwmon: (cros_ec) Synchronize EC access from the thermal device callbacks", " - nvmet: fix Reservation Register Replace for unregistered host with IEKEY", " - nvmet: propagate percpu_ref_init() failure in nvmet_ns_enable()", " - cgroup/cpuset: Use WRITE_ONCE() for shared prs_err updates", " - selftests/sched_ext: Check skeleton open failure in exit test", " - powerpc/configs: enable CONFIG_RAS to fix EDAC support", " - iommu/amd: Fix incorrect device ID in invalid PASID error message", " - rust: uapi: replace direct asm-generic/ioctl.h include with", " linux/ioctl.h", " - phy: renesas: rcar-gen3-usb2: Ignore missing VBUS regulator", " - phy: qcom: qmp-combo: Correct pre-emphasis table for QMP v4 DP PHYs", " - phy: qcom: qmp-combo: Drop qmp_v4_calibrate_dp_phy", " - spi: sprd-adi: Fix probe succeeding without registering the controller", " - ASoC: qcom: q6apm: keep the graph start count in sync with the DSP", " - arm64: bti: Disable in-kernel BTI with recent versions of Clang", " - integrity: Make arch_ima_get_secureboot integrity-wide", " - s390: Drop unnecessary CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT", " - s390/irqflags: Add out-of-line definitions of arch_local_irq_*() for", " KMSAN", " - nvme: Add the DHCHAP maximum HD IDs", " - nvme-apple: Don't set a DMA direction for commands without a data", " transfer", " - nvme-apple: Never set the opcode in the NVMMU TCB", " - nvme: Add a quirk for page aligned admin queue buffers", " - nvme-apple: Require page aligned buffers on the admin queue", " - nvme-apple: Drop the PRP null check chicken bit", " - nvme: reject passthrough of driver-managed Set Features", " - nfc: digital: Do not dump a NULL response in command completion", " - dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal", " - ice: fall back to SBQ when LL PHY timer interface times out", " - ice: clear the default forwarding VSI rule when releasing a VSI", " - idpf: add missing cpu_to_le32 in idpf_tx_splitq_build_flow_desc", " - ASoC: pxa: Use devm_clk_get_optional() for extclk clock", " - ASoC: fsl-asoc-card: defer probe when the CPU DAI device is not ready", " - UBI: Preserve torture flag when rescheduling failed erasures", " - UBI: fastmap: Pass to_be_tortured when reusing old fastmap PEBs", " - UBI: fix two issues in the ubi.mtd MODULE_PARM_DESC", " - firewire: core: add KUnit test skeleton for node tree", " - firewire: core: add KUnit tests for successful tree building", " - firewire: core: add KUnit tests for failure of tree building", " - firewire: core: consolidate port counting in build_tree()", " - firewire: core: validate parent port count before allocating nodes in", " build_tree()", " - PCI/ASPM: Use pcie_capability_clear_and_set_word() for ASPM", " disable/restore", " - super: fix dying superblock warning messages", " - perf build: Remove leftover feature tests for removed cxx and clang", " support", " - kunit: tool: fix _list_tests filtering wrong variable when list has TAP", " prefix", " - selftests: harness: Restore order of test functions", " - selftests: harness: Mark test fixture objects __maybe_unused", " - selftests/bpf: vmtest.sh: Preserve command quoting when running in the", " VM", " - spi: img-spfi: don't disable runtime PM on DMA deferred probe", " - PCI/ASPM: Disable/restore ASPM on every function for multi-function", " devices", " - power: supply: bd99954: Drop bad register fields", " - power: supply: bq27xxx: bq27520g4: fix REG_TTES address", " - power: supply: bq27xxx: bq28z610: fix invalid AverageEnergy address", " - power: supply: bq27xxx: bq27z561: fix invalid AverageEnergy address", " - xenbus: Unregister reboot notifier on init failure", " - clocksource/drivers/clps711x: Do not unmap clocksource MMIO", " - clocksource/drivers/armada: Unwind timer clock on init failure", " - ALSA: seq: midi: Optimize event_input locking with RCU", " - selftests/cgroup: Preserve CPU hotplug write errors", " - x86/pkeys: Fix pkey_alloc() return value when pkeys are not supported", " - bpftool: Fix double close in map dump", " - ocfs2: fix circular locking dependency in ocfs2_init_acl()", " - selftests/bpf: Fix for veristat file/prog filters processing", " - scsi: ufs: core: Set task state before io_schedule_timeout()", " - bpf, arm64: Fix stack-passed arguments for indirect trampolines", " - tracing: Have trace_event_update_all() only handle module that is", " loading", " - HID: multitouch: reclassify HTIX5288 to WIN_8_FORCE_MULTI_INPUT_NSMU", " - selftests/bpf: Add tests to verify the fix of encapsulating VxLAN in lwt", " - selftests/bpf: Use ping_command() for IPv6 pings in lwt_ip_encap", " - ring-buffer: Remove trace_buffer::cpus", " - bpf: Fix pending_pos walk on 32-bit ring position wrap", " - selftests/sched_ext: Fix flaky ddsp failure tests on busy systems", " - crypto: hisilicon/sec2 - fix CCM algorithm long packet failure", " - crypto: lskcipher - propagate errors from unaligned crypt", " - sched_ext/scx_flatcg: Fix cvtime true-up on slice expiry", " - perf dso: Guard against errno==0 when dso__get_filename() returns NULL", " - perf dso: Guard close() against invalid fd in", " dso__decompress_kmodule_path()", " - perf dso: Use stored fd error instead of stale errno in file_read() and", " file_size()", " - perf dso: Guard against cache underflow on short reads in", " dso_cache__memcpy()", " - perf dso: Replace assert with runtime check in dso__read_symbol()", " - mailbox: rockchip: disable pclk on probe failure and unbind", " - mailbox: pcc: Fix command timeout due to missed interrupt", " - ublk: reject non-power-of-2 zone sizes in SET_PARAMS", " - hwmon: (emc1403) Drop hysteresis for low limit temperature", " - ksmbd: do not advertise unimplemented CA support", " - smb/server: preserve error status in smb2_handle_negotiate()", " - erofs: clean up encoded map flags", " - erofs: error out obviously illegal extents in advance", " - erofs: guard on-disk algorithm IDs against Z_EROFS_COMPRESSION_MAX", " - erofs: fix unused pcluster_pools for higher page sizes", " - ksmbd: disconnect on SMB3 decryption failure", " - nfs: replace atomic bitops sequence with clear_and_wake_up_bit helper", " - nfs: refactor pNFS functions using clear_and_wake_up_bit", " - nfs: fix ENXIO on O_CREAT open of existing symlink over NFSv3", " - clk: ti: mux: resolve parent clocks by DT index, not by name", " - octeontx2-af: initialize lmac_bmap in rvu_mcs_set_lmac_bmap()", " - drm/xe: tests: fix error message in xe_migrate_sanity_test()", " - ptp: netc: skip PEROUT disable if channel is not enabled", " - ionic: fix completion descriptor access with 2x desc size", " - net: dsa: b53: fix error propagation from b53_fdb_dump()", " - pppox: drain queued packets on channel handoff", " - net: hsr: free learned nodes on device setup failure", " - f2fs:Fix incomplete search range in f2fs_get_victim when", " f2fs_need_rand_seg is enabled", " - f2fs: cleanup w/ f2fs_need_rand_{blk, seg, seg_blk}", " - f2fs: fix to avoid pinfile fragment on fragment:{block, segment} mode", " - net: dsa: mv88e6xxx: Fix PCS link check on CMODE read error", " - tls: fix RX desync on overlapping skbs", " - net: bridge: vlan: fix inverted default vlan notification", " - soc: qcom: ubwc: Fix missing include", " - ALSA: hda: Fix connection list comparison in proc output", " - vxlan: mdb: Fix use-after-free in vxlan_mdb_flush()", " - 8139cp: fix Rx and Tx not being disabled in cp_suspend", " - net/smc: hash socket only after full initialisation in smc_sk_init()", " - platform/x86: dell-wmi-sysman: Fix instance ID bounds", " - vsock: avoid timeout for non-blocking accept() with empty backlog", " - vsock: use sock_error() to consume sk_err after a failed connect", " - mlxbf-bootctl: fix the build error with FIELD_PREP()", " - bonding: initialize err for empty target lists", " - virtio_balloon: disable indirect descriptors", " - virtio: add virtio_device_shutdown() helper", " - virtio_balloon: factor out virtballoon_quiesce()", " - vhost/net: fix clear_user start address in VHOST_GET_FEATURES_ARRAY", " - virtio_pci: fix wrong queue index for admin vq in intx path", " - rtc: spacemit: handle regmap_test_bits() error return", " - cifs: remove dead size-update blocks in cifs_setattr_unix/nounix", " - rtc: zynqmp: Return optional clock lookup errors", " - i2c: ocores: Disable clock on failed resume", " - rtc: gamecube: check return value of devm_rtc_register_device()", " - lib/interval_tree: fix allocation warning messages", " - prctl: fix PR_SET_MM_AUXV losing the forced AT_NULL terminator", " - clk: ti: Make sure clk_init_data is fully initialized", " - irqchip/gic-v5: Synchronize CPU interface disable", " - irqchip/gic-v5: Check for NULL LPI domain on domain teardown", " - irqchip/gic-v5: Fix gicv5_init_common() error paths", " - irqchip/gic-v5: Use logical cpu 0 irs_data for dynamic IST allocation", " - ALSA: core: Add scoped cleanup helper for card references", " - RDMA/ucma: Allow path records to exactly fit the output buffer", " - spi: amlogic-spisg: Make sure clk_init_data is fully initialized", " - smb: server: Remove obsolete \"select CRYPTO_LIB_DES\" from Kconfig file", " - smb: server: remove unused DES crypto header", " - irqchip/irq-realtek-rtl: Add/simplify register helpers", " - irqchip/irq-realtek-rtl: Add multicore support", " - irqchip/irq-realtek-rtl: Split out parent setup code", " - irqchip/irq-realtek-rtl: Add interrupt data structure", " - irqchip/irq-realtek-rtl: Add mask for interrupt handling", " - irqchip/irq-realtek-rtl: Use readl_be()/writel_be() instead of", " readl()/writel()", " - xsk: avoid double checking against rx queue being full", " - net/sched: add get_fill_size callbacks for actions missing them", " - net: thunderbolt: Count delivered packets in rx_packets and rx_bytes", " - net/mlx5: E-Switch, use state lock for vport state changes", " - net/mlx5: Move vport DOWN state check out of", " mlx5_query_vport_max_tx_speed()", " - net/mlx5: E-Switch, preserve max tx speed on vport state modification", " - forcedeth: stop the tx_timeout register dump past the requested window", " - net: ipa: balance runtime PM reference on remove error", " - net: add missing ref_tracker_dir_exit() to net_passive_dec()", " - ipmr: Move unregister_netdevice_many() out of mroute_clean_tables().", " - ipmr: Move unregister_netdevice_many() out of ipmr_free_table().", " - ipmr: Convert ipmr_net_exit_batch() to ->exit_rtnl().", " - ipmr: Remove RTNL in ipmr_rules_init() and ipmr_net_init().", " - net: change sock_queue_rcv_skb_reason() to return a drop_reason", " - ipmr: Free mr_table after RCU grace period.", " - ip6mr: plug drop_reason to ip6mr_cache_report()", " - net: tcp: block mixing readable and unreadable frags", " - rtc: pcf85363: Add error checking to regmap calls in probe()", " - bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check", " - net: wangxun: replace busy-wait reset flag with kernel mutex", " - net: wangxun: schedule hardware stats update in watchdog", " - net: wangxun: introduce WX_STATE_DOWN to serialize device shutdown state", " - net: txgbe: fix MISC interrupt unmasking in non-MSI-X mode and device", " shutdown", " - net: libwx: fix concurrent bitmap overwrite in PTP setup", " - net: page_pool: Remove zone/policy GFP flags when allocating XArray", " entries", " - net_sched: sch_fq: fix pacing delay underflow with pacing offload", " - scsi: qla2xxx: Fix an loop timeout test", " - erofs: Fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS default logic", " - arm64: ptdump: Make note_page_flush() range aware", " - Bluetooth: mgmt: fix 'hdev->discovery.uuids' NULL dereference", " - Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support", " - Bluetooth: btmtk: Do not report success when subsys reset fails", " - Bluetooth: btmtk: Do not discard the subsystem reset timeout", " - Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX", " - xsk: align TX metadata layout across ABIs", " - octeontx2-af: Fix TL3/TL2 link config ENA clearing", " - net: enetc: restore RX ring congestion mode after ring reconfiguration", " - net/sched: add qstats_cpu_drop_inc() helper", " - cifs: fix clearing stats for fastest execution of each smb2 command", " - selftests/mm: skip COW tmpfile cases when fallocate() is unsupported", " - maple_tree: catch race in mas_alloc_cyclic()", " - maple_tree: fix argument name in header", " - selftests/proc: make proc-maps-race work with READ_IMPLIES_EXEC", " - net: core: check skb_frags_readable before uncloning in skb_copy_ubufs", " - net/sched: sch_codel: clamp default mtu to avoid disabling CoDel", " - tpm: st33zp24: Validate locality read result", " - apparmor: policy_int make sure list heads are initialized before fail", " path", " - ceph: Fix ERR_PTR(0) in ceph_mkdir()", " - ceph: revalidate ki_pos for O_APPEND writes after cap acquisition", " - samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-modify", " - net: ethernet: sun4i-emac: Fix IRQ error handling", " - net: wangxun: use BIT_ULL() to prevent shift overflow on 32-bit archs", " - net: stmmac: selftests: Pass the IP proto mask in the TC selftest", " - drm/xe/xe_gt_idle: Add CCS to the powergating info print", " - netfilter: xt_HL: add pr_fmt and checkentry validation", " - netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited()", " - selftests/arm64: Print missing MTE TAP headers", " - selftests/arm64: Treat KSM merge_across_nodes as optional", " - selftests/arm64: Fix MTE prctl TAP plan", " - net: airoha: npu: fix missing streaming DMA mask", " - net: stmmac: selftests: Check multiple MMC counters", " - net: stmmac: dwmac1000: Account for the primary MAC address for UC", " filtering", " - net: stmmac: dwmac4: Account for the primary MAC address for UC", " filtering", " - net: stmmac: dwxgmac: Account for the primary MAC address for UC", " filtering", " - net: stmmac: selftests: Account for the UC filter list for filtering", " tests", " - dm-integrity: fix buffer overflow with keyed discard", " - mtd: rawnand: pl353: Fix debug prints", " - platform/x86: lg-laptop: Check ACPI_COMPANION() against NULL", " - serial: 8250: Ignore flow control on suspend/resume with", " no_console_suspend", " - usb: ucsi: huawei_gaokun: move typec_altmode off stack", " - cpufreq/amd-pstate: handle missing policy in dynamic EPP callbacks", " - cpufreq/amd-pstate: Reorder notifier unregistration and floor perf reset", " - cpufreq/amd-pstate: Return -ENOMEM on failure to allocate profile_name", " - cpufreq/amd-pstate: Grab \"amd_pstate_driver_lock\" when toggling", " dynamic_epp", " - cpufreq/amd-pstate: Add POWER_SUPPLY select for dynamic EPP", " - [Config] Make ACPI_PLATFORM_PROFILE built-in for amd64.", " - [Config] Add disable for X86_AMD_PSTATE_DYNAMIC_EPP", " - cpufreq/amd-pstate: Fix setting EPP in performance mode", " - wifi: nl80211: fix UHR capability validation", " - integrity: Eliminate weak definition of arch_get_secureboot()", " - [Config] Disable IMA_SECURE_AND_OR_TRUSTED boot for s390x", " - [Config] Enable new config HAVE_ARCH_GET_SECUREBOOT", " - block: save page offset gaps in cloned bio", " - erofs: relax sanity check for tail pclusters due to ztailpacking", " - erofs: fix EFSCORRUPTED on multi-algorithm images in", " z_erofs_map_sanity_check()", " - ipmr: Call ipmr_fib_lookup() under RCU.", " - ipmr: Add __rcu to netns_ipv4.mrt.", " - Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] array", " - net/sched: fq: clamp quantum and initial_quantum in change path", " - cpufreq/amd-pstate: Add support for raw EPP writes", " - cpufreq/amd-pstate: Use \"epp_default_dc\" as default when dynamic_epp is", " disabled", " - cpufreq/amd-pstate: Allow writes to dynamic_epp when state isn't", " modified", " - ACPI: processor: idle: Remove redundant cstate check in", " acpi_processor_power_init", " - ACPI: processor: idle: Move max_cstate update out of the loop", " - ACPI: processor: idle: Remove redundant static variable and rename", " cstate check function", " - drm/panel-edp: Add CSW PNB601LS1-2 and LGD LP116WHA-SPB1", " - drm/gem: Consider GEM object reclaimable if shrinking fails", " - bus: fsl-mc: wait for the MC firmware to complete its boot", " - drm/xe/guc: Add support for NO_RESPONSE_BUSY in CTB", " - drm: rz-du: Ensure correct suspend/resume ordering with VSP", " - drm: renesas: rzg2l_mipi_dsi: Fix deassert/assert of CMN_RSTB signal", " - drm/amd/display: Fix DPMS using partially updated pipe context", " - drm/panel: jadard-jd9365da-h3: set prepare_prev_first", " - drm/amd/pm: Check SMUv13.0.6/12 metrics integrity", " - wifi: ath9k: Obtain system GPIOS from descriptors", " - gfs2: fix quota init duplicate scan", " - gpio: usbio: Add ACPI device-id for NVL platforms", " - gfs2: move quota_init qc iterator increment", " - drm/xe: Fix null pointer dereference in devcoredump cleanup", " - driver core: Replace dev->can_match with dev_can_match()", " - iio: adc: rtq6056: add i2c_device_id support", " - pinctrl: renesas: rzg2l: Handle RZ/V2H(P) IOLH configuration in PM cache", " - ALSA: usb-audio: Propagate write errors in generic mixer put callbacks", " - pinctrl: renesas: rzg2l: Add SR register cache for PM suspend/resume", " - ima: return error early if file xattr cannot be changed", " - usb: gadget: udc: skip pullup() if already connected", " - tee: optee: Allow MT_NORMAL_TAGGED shared memory", " - tools/nolibc: avoid call to wcslen() in _start_c() inserted by clang", " - PCI: Stop setting cached power state to 'unknown' on unbind", " - wifi: cfg80211: reject duplicate wiphy cipher suite entries", " - hfsplus: fix issue of direct writes beyond end-of-file", " - wifi: nl80211: reject beacons with bad HE operation", " - wifi: nl80211: check link is beaconing for color change", " - wifi: mac80211: always allow transmitting null-data on TXQs", " - wifi: mac80211: use chandef in ieee80211_get_sta_bw()", " - clk: clk-axi-clkgen: Add support versal timings", " - wifi: rtw88: Add NULL check for chip->edcca_th in", " rtw_fw_adaptivity_result()", " - wifi: rtw89: suspend DIG when remain-on-channel", " - wifi: rtw89: disable HTC field in AP mode", " - wifi: rtw89: disable CSI STBC for VHT 160MHz", " - psp: validate IPv4 header fields in psp_dev_rcv()", " - i3c: master: svc: Prevent IRQ storm from false SLVSTART on NPCM845", " - ASoC: fsl-asoc-card: reduce WM8904 PLL ratio to meet frequency limit", " - kcsan: Silence -Wmaybe-uninitialized when calling __kcsan_check_access()", " - firmware: stratix10-svc: change get provision data to async SMC call", " - bridge: Do not suppress ARP probes and DAD NS unconditionally", " - soundwire: intel_auxdevice: Add cs42l43b to wake_capable_list", " - soundwire: validate DT compatible before parsing it", " - media: chips-media: wave5: Fix Reports from Kernel Lock Validator", " - media: chips-media: wave5: Release m2m_ctx after Instance Removed from", " List", " - dm-raid: only requeue bios when dm is suspending", " - spi: spi-qcom-qspi: Fix incomplete error handling in runtime PM", " - media: rc: mceusb: Add support for 04eb:e033", " - net: mana: hardening: Reject zero max_num_queues from", " MANA_QUERY_VPORT_CONFIG", " - s390/cio: Purge based on the cdev's online status", " - media: platform: cros-ec: Add Kulnex and Moxoe to the match table", " - wifi: mac80211: avoid out-of-bounds access in monitor", " - thunderbolt: Avoid reserved fields in path config space for USB4 routers", " - thunderbolt: Don't disable lane adapter if XDomain lane bonding isn't", " possible", " - thunderbolt: Release request if tb_cfg_request() fails in", " __tb_xdomain_response()", " - thunderbolt: Keep XDomain reference during the lifetime of a service", " - thunderbolt: Keep the domain reference while processing hotplug", " - thunderbolt: Set tb->root_switch to NULL when domain is stopped", " - thunderbolt: Don't create multiple DMA tunnels on firmware connection", " manager", " - drm/amd/display: Find link encoder for flexible DIG mapping cases", " - drm/amdgpu: Prefer ROM BAR for default VGA device", " - drm/panel: Enable GPIOLIB for panels which uses functions from it", " - media: dm1105: fix missing error check for dma_alloc_coherent", " - net: dsa: mv88e6xxx: fix number of g1 interrupts for 6320 family", " - PCI: switchtec: Add Gen6 Device IDs", " - net: dsa: mv88e6xxx: define .pot_clear() for 6321", " - media: v4l2-common: Always register clock with device-specific name", " - net: dsa: mv88e6xxx: enable .rmu_disable() for 6320 family", " - media: em28xx-video: fix missing res_free() on init_usb_xfer failure", " - wifi: mac80211: explicitly disable FTM responder on AP stop", " - rtase: Fix flow control configuration", " - crypto: ixp4xx - fix buffer chain unwind on allocation failure", " - crypto: omap - add omap_des_unregister_algs helper", " - clk: renesas: cpg-mssr: Add number of clock cells check", " - drm/bridge: tc358768: Set pre_enable_prev_first for reverse order", " - dlm: add usercopy whitelist to dlm_cb cache", " - PCI/sysfs: Add CAP_SYS_ADMIN check to __resource_resize_store()", " - media: qcom: camss: avoid format string warning", " - net/mlx5: Relax capability check for eswitch query paths", " - drm/panel-edp: Add AUO B140XTN07.5, AUO B140HAK03.5, AUO B116XTN02.3,", " AUO B140XTK02.4, AUO B140HAN07.7", " - drm/panel-edp: Add BOE NT140WHM-N4T, BOE NT140WHM-T05, BOE NV140FHM-N40", " - phy: qcom: m31-eusb2: Make USB repeater optional", " - ASoC: ti: omap3pandora: update board check to use DT compatible", " - watchdog: imx7ulp_wdt: Keep WDOG running until A55 enters WFI on i.MX94", " - net/mlx5: HWS, Check if device is down while polling for completion", " - net/mlx5: HWS, Handle destroying table that has a miss table", " - platform/chrome: Resolve kb_wake_angle visibility race", " - drm/panel/tdo-tl070wsh30: Use refcounted allocation in place of", " devm_kzalloc()", " - mmc: core: Add validation for host-provided max_segs", " - genirq/proc: Size interrupt directory names for 10-digit interrupt", " numbers", " - serial: 8250_port: recognize UPIO_AU", " - mmc: davinci: avoid NULL deref of host->data in IRQ handler", " - platform/x86: sel3350-platform: Retain LED state on load and unload", " - drm/amd/display: Fix CRC open failure during active rendering", " - pinctrl: mediatek: paris: bypass pinctrl GPIO layer in set GPIO", " direction", " - pinctrl: mediatek: common-v1: bypass pinctrl GPIO layer in set GPIO", " direction", " - drm/amd/ras: Fix CPER ring debugfs read overflow", " - hfsplus: rework hfsplus_readdir() logic", " - net: phy: motorcomm: use device properties for firmware tuning", " - drm/gud: Add RCade Display Adapter VID/PID pair", " - media: chips-media: wave5: Add range checks for dec_output_info", " - media: video-i2c: use vb2_video_unregister_device on driver removal", " - bus: mhi: host: pci_generic: Round up nr_irqs to power of two", " - drm/panel-edp: Add AUO B133HAN06.6 and BOE NV133FHM-N4F V8.0", " - HID: multitouch: Fix Yoga Book 9 14IAH10 touchscreen misclassification", " - wifi: rtw89: phy: check length before parsing PHY status IE", " - net: dsa: realtek: rtl8365mb: add support for RTL8367SB", " - integrity: Check for NULL returned by asymmetric_key_public_key", " - drivers/of: validate live-tree string properties before string use", " - drivers/of: validate status properties in reconfig state changes", " - soundwire: intel: Move suspend tracking from trigger to pm suspend", " - clk: samsung: exynos850: mark APM I3C clocks as critical", " - scsi: pm8001: Reject firmware update in fatal error state", " - scsi: pm8001: Reject non-fatal dump when controller is crashed", " - crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y", " - crypto: atmel-ecc - add support for atecc608b", " - net: airoha: Reserve RX headroom to avoid skb reallocation", " - clk: qcom: clk-rpmh: Make all VRMs optional", " - media: imon: Add iMON VFD HID OEM v1.2 key mappings", " - RDMA/mlx5: Use QP port when decoding responder CQEs", " - coresight: perf: Retrieve path and source from event data", " - coresight: Disable source helpers in coresight_disable_path()", " - drm/mediatek: dsi: Add compatible for mt8167-dsi", " - iomap: don't make REQ_POLLED imply REQ_NOWAIT", " - mailbox: Make mbox_send_message() return error code when tx fails", " - drm/amdgpu/userq: pin mqd and fw object bo to avoid eviction", " - PCI: Wait for device readiness after D3hot -> D0uninitialized transition", " - drm/amdkfd: Check bounds for allocate_sdma_queue restore_sdma_id", " - drm/amdkfd: Fix OOB memory exposure in get_wave_state()", " - drm/amdkfd: Check bounds on allocate_doorbell", " - ALSA: hda/ca0132: add QUIRK_GENERIC path for Gigabyte GA-Z170X-Gaming G1", " - ALSA: ice1724: Fix blocking open for independent surround PCMs", " - ALSA: usx2y: Drain pending US-428 pipe-4 output commands", " - drm/amdgpu: use atomic operation to achieve lockless serialization", " - sched/fair: Reject misfit pulls onto busy SMT siblings on asym-capacity", " - iommu: arm-smmu-qcom: Ensure smmu is powered up in set_ttbr0_cfg", " - drm/imagination: Don't timeout job if its fence has been signaled", " - 9p: invalidate readdir buffer on seek", " - arm64: panic from init_IRQ if IRQ handler stacks cannot be allocated", " - arm64/daifflags: Make local_daif_*() helpers __always_inline", " - drm/imagination: Populate FW common context ID before passing to the FW", " - 9p: use kvzalloc for readdir buffer", " - drm/amd/ras: reset CPER ring on corrupt entry size", " - drm/amdgpu: cap ATOM command table nesting depth", " - drm/amdgpu: validate and share PSP fw_pri_buf copies via psp_copy_fw", " - drm/amdgpu: add first record offset check", " - drm/amdgpu: Bound GPIO I2C table entry count from VBIOS", " - drm/amdgpu: avoid integer overflow in VA range check", " - drm/amdgpu: check and drop invalid bad page records", " - bridge: Add missing READ_ONCE() annotations around FDB destination port", " - thunderbolt: Don't access path config space on Lane 1 adapters in", " tb_switch_reset_host()", " - thunderbolt: Improve multi-display DisplayPort tunnel allocation", " - thunderbolt: Verify PCIe adapter in detect state before tunnel setup", " - firmware: arm_scmi: Validate SENSOR_UPDATE payload size", " - firmware: arm_scmi: Validate BASE_ERROR_EVENT payload size", " - thunderbolt: Increase timeout for Configuration Ready bit", " - wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not", " needed", " - thunderbolt: Verify Router Ready bit is set after router enumeration", " - bitfield: wire __bf_shf to __builtin_ctzll", " - nvme-core: align fabrics_q teardown with admin_q in nvme_free_ctrl", " - net: usb: qmi_wwan: add MeiG SRM813Q", " - net: bridge: remove stale rcu_barrier() in br_multicast_dev_del()", " - net/sched: sch_drr: make cl->quantum lockless", " - net/rds: Don't sleep inside rds_ib_conn_path_shutdown", " - net/mlx5: Switch vport HCA cap helpers to kvzalloc", " - spi: dw-mmio: Add ACPI ID LECA0002 for LECARC SoCs", " - befs: handle set_blocksize failures", " - ntfs3: handle set_blocksize failures", " - affs: handle set_blocksize failures", " - bfs: handle set_blocksize failures", " - minix: handle set_blocksize failures", " - qnx4: handle set_blocksize failures", " - jfs: handle set_blocksize failures", " - hpfs: handle set_blocksize failures", " - omfs: handle set_blocksize failures", " - isofs: handle set_blocksize failures", " - HID: bpf: Add Huion Inspiroy Frego M button quirk", " - drm/panel-edp: Add LG LP129WT232166 panel", " - usbip: vhci_hcd: fix NULL deref in status_show_vhci", " - usb: core: hcd: fix possible deadlock in rh control transfers", " - usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET", " log", " - USB: cdc-acm: start bulk-IN polling when ALWAYS_POLL_CTRL is set", " - usb: gadget: aspeed_udc: avoid past-the-end iterator in dequeue", " - serial: 8250: fix possible ISR soft lockup", " - usb: host: add ARCH_AIROHA in XHCI MTK dependency", " - tty: serial: 8250: protect against NULL uart->port.dev in register", " - driver core: Avoid warning when removing a device while its supplier is", " unbinding", " - crypto: atmel-sha204a - remove sysfs group before hwrng", " - char/nvram: Remove redundant nvram_mutex", " - gpib: Suppress setting END on error from NI_USB dongle", " - irqchip/gic-v5: Immediately exec priority drop following activate", " - pwm: mediatek: set mt7628 pwm45_fixup flag to false", " - rcu-tasks: Fix possible boot-time tests failed for the call_rcu_tasks()", " - virt: acrn: Fix irqfd use-after-free during eventfd shutdown", " - wifi: rtw89: pci: enable LTR based on pcie control register", " - netlabel: fix IPv6 unlabeled address add error handling", " - RDMA/counter: Fix num_counters leak on bind_qp failure in", " alloc_and_bind()", " - ALSA: seq: Remove arbitrary prioq insertion limit", " - rds: filter RDS_INFO_* getsockopt by caller's netns", " - rds: annotate data-race around rs_seen_congestion", " - s390/zcore: Removed unused variables", " - clk: socfpga: agilex: implement l3_main_free_clk", " - thermal/drivers/tegra/soctherma: Switch to devm cooling device", " registration", " - wifi: iwlwifi: fix the access to CNVR TOP registers", " - wifi: iwlwifi: mld: honor BSS_CHANGED_BEACON_ENABLED", " - wifi: iwlwifi: pcie: fix ACPI DSM check", " - wifi: iwlwifi: mld: call iwl_mld_free_ap_early_key() for AP only", " - wifi: iwlwifi: Transition to basic uAPSD with MAC_PM_POWER_TABLE API", " VER_3", " - wifi: iwlwifi: pcie: add two LNL PCI IDs", " - wifi: iwlwifi: mld: disallow puncturing in US/CA for WH", " - wifi: iwlwifi: mld: purge async notifications upon nic error", " - wifi: iwlwifi: mld: keep healthy link on EMLSR missed beacon exit", " - powercap: intel_rapl: Fix memory leak in rapl_add_package_cpuslocked()", " - genirq/manage: Make NMI cleanup RT safe", " - drm/panel: simple: Add AM-1280800W8TZQW-T00H", " - mips: cps: Assemble jr.hb with an R2 ISA level", " - iio: adc: qcom-spmi-iadc: balance enable_irq_wake() on driver unbind", " - irqchip/gic-v4: Don't advertise VLPIs if no ITS is probed", " - ALSA: usb-audio: Add quirk for Novation Mininova", " - net: hsr: require valid EOT supervision TLV", " - ipv6: addrconf: fix temp address generation after prefix deprecation", " - net: napi: Skip last poll when arming gro timer in busy poll", " - net: thunderx: fix PTP device ref leak in nicvf_probe()", " - ALSA: hda: cs35l41: imply SERIAL_MULTI_INSTANTIATE", " - drm/dp: Add DSC virtual DPCD quirk for Realtek MST branch device", " - drm/amd/pm/si: Fix updating clock limits from power states", " - drm/amd/display: Initialize dsc_caps to 0", " - ACPICA: Fix condition check in acpi_ps_parse_loop()", " - ACPICA: Fix use-after-free in acpi_ds_terminate_control_method()", " - ACPICA: add boundary checks in acpi_ps_get_next_field()", " - ACPICA: validate byte_count in acpi_ps_get_next_package_length()", " - ACPICA: Prevent adding invalid references", " - ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op)", " - ACPICA: Improve argument parsing in acpi_ps_get_next_simple_arg()", " - ACPICA: validate handler object type in two places", " - ACPICA: Add package limit checks in parser functions", " - ACPICA: Add validation for node in acpi_ns_build_normalized_path()", " - ACPICA: Enhance OEM ID and Table ID validation in", " acpi_ex_load_table_op()", " - ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package()", " - ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources()", " - ACPICA: add boundary checks in two places", " - hfs: rework hfsplus_readdir() logic", " - net: sfp: add quirk for OEM 2.5G optical modules", " - pinctrl: renesas: rzv2m: Use -ENOTSUPP instead of -EOPNOTSUPP", " - host1x: bus: Fix missing ops null check in error teardown", " - scripts: modpost: detect and report truncated buf_printf() output", " - drm/nouveau/gsp: add SEC2 to GA100 chip table", " - x86/topology: Add missing struct declaration and attribute dependency", " - ASoC: Intel: catpt: Complete coredump handling", " - drm/nouveau/bios: skip the IFR header if present", " - libbpf: Add __NR_bpf definition for LoongArch", " - soc/tegra: fuse: Register nvmem lookups at probe", " - soundwire: dmi-quirks: Disable ghost Realtek devices", " - gfs2: page poisoning fix", " - soundwire: only handle alert events when the peripheral is attached", " - mmc: davinci: fix mmc_add_host order in probe", " - ARM: tegra: tf600t: Invert accelerometer calibration matrix", " - mmc: renesas_sdhi: Add OF entry for RZ/G2N SoC", " - ARM: tegra: p880: Lower CPU thermal limit", " - tracing: Disable KCOV instrumentation for trace_irqsoff.o", " - mmc: renesas_sdhi: Add OF entry for RZ/G2E SoC", " - clk: samsung: exynos990: Fix PERIC0/1 USI clock types", " - media: qcom: camss: vfe-340: Proper client handling", " - iio: light: stk3310: Deal with the ps interrupt issue in PM", " - perf/ftrace: Fix WARNING in __unregister_ftrace_function", " - iio: accel: mma8452: switch to non-devm request_threaded_irq()", " - libbpf: Also reset {insn,data}_cur on realloc failure", " - spi: tegra210-quad: Allocate DMA memory for DMA engine", " - net: ibm: emac: Reserve VLAN header in MJS limit", " - wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi", " - ASoC: codecs: pcm3168a: Prevent regulator double-disable in S4", " - ASoC: qcom: q6apm: return error code to consumers on failures", " - ASoC: codecs: pcm3168a: Drop CONFIG_PM-conditional preproc directive", " - wifi: ath12k: Prevent incorrect vif chanctx switch when handling multi-", " radio contexts", " - ata: ahci: fail probe if BAR too small for claimed ports", " - ACPI: scan: Honor _DEP for ACPI0016 PCI/CXL host bridge", " - ACPI: PCI: Clear _DEP dependencies after PCI root bridge attach", " - ppc/fadump: invoke kmsg_dump in fadump panic path", " - net: qrtr: fix node refcount leak on ctrl packet alloc failure", " - net: wwan: t7xx: Add delay between MD and SAP suspend", " - net: txgbe: fix phylink leak on AML init failure", " - iommu/rockchip: disable fetch dte time limit", " - powerpc/fadump: Add timeout to RTAS busy-wait loops", " - fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib", " - nvme: refresh multipath head zoned limits from path limits", " - fs/ntfs3: validate index entry key bounds", " - ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e()", " - ASoC: codecs: rk3328: Use managed GPIO and clock helpers", " - ALSA: seq: oss: Reject reads that cannot fit the next event", " - dpaa2-switch: rework FDB management on the bridge leave path", " - dpaa2-switch: fix the error path in dpaa2_switch_rx()", " - net: dsa: sja1105: flower: reject cross-chip redirect", " - dpaa2-switch: fix handling of NAPI on the remove path", " - wifi: rtw89: 8851bu: add Mercusys MA60XNB (2c4e:0128)", " - thermal/drivers/qcom/tsens: Atomic temperature read with hardware-guided", " retries", " - nvme: validate FDP configuration descriptor sizes", " - wifi: mac80211: clarify beacon parsing with MBSSID/EMA", " - wifi: mac80211: unify link STA removal in vif link removal", " - wifi: cfg80211: harden cfg80211_defragment_element()", " - wifi: iwlwifi: mld: don't WARN on WoWLAN suspend w/o netdetect", " - wifi: iwlwifi: mvm: fix P2P-Device binding handling", " - wifi: iwlwifi: add support for AX231", " - usb: xhci: Improve Soft Retries after short transfers", " - usb: xhci: remove legacy 'num_trbs_free' tracking", " - drm/amd/display: Avoid DPMS-on for phantom stream", " - xhci: Prevent queuing new commands if xhci is inaccessible", " - drm/amd/display: Check for sharpening case when calculating max vtaps", " for scaler", " - drm/amdkfd: fix UAF race in destroy_queue_cpsch", " - drm/amdgpu: harden FRU PIA parsing with bounded helpers", " - drm/amd/pm: bound pp_dpm_set_pp_table() memcpy", " - drm/amdgpu/pm: fix SmartShift bias sysfs store PM refcount on parse", " error", " - drm/amdgpu: fix buffer overflow during vBIOS update", " - drm/amdgpu: validate RAS EEPROM tbl_size before record count", " - net/mlx5e: Verify unique vhca_id count instead of range", " - RDMA/irdma: Fix typo in SQ completions generation", " - drm/amdgpu/ras: add ras_suspend callback and use it for cp_ecc_error_irq", " - net/mlx5: E-Switch, align disable sequence with switchdev-to-legacy", " transition", " - net: ibm: emac: fix unchecked platform_get_irq return value", " - clk: keystone: don't cache clock rate", " - ALSA: hda/realtek: ALC882: Fixup for Clevo P775TM1", " - ALSA: hda/realtek: Add quirk for ASUS VivoBook X509DAP", " - perf/x86/intel/uncore: Guard against invalid box control address", " - ipmi: si: Use platform_get_irq_optional() to retrieve interrupt", " - cxl/region: Validate partition index before array access", " - x86/microcode/AMD: Move the no-revision fixup to get_patch_level()", " - net: ethtool: cmis_cdb: hold instance lock for ops locked devices", " - drm/amdkfd: fix SMI event cross-process information leak", " - drm/amdkfd: Unwind debug trap enable on copy_to_user failure", " - ipv6: use READ_ONCE() for bindv6only default in inet6_create()", " - wifi: nl80211: Increase ie_len size to prevent truncated IEs in new peer", " notifications", " - RDMA/umem: Be careful about boundary conditions in", " ib_umem_find_best_pgsz()", " - RDMA/umem: Make ib_umem_is_contiguous() safe on 32 bit", " - firmware: stratix10-svc: fix FCS SMC call kernel-doc", " - RDMA/mlx5: Fix state and counter desync on loopback enable failure", " - bpf: NUL-terminate replaced sysctl value", " - net: cpsw_new: unregister devlink on port registration failure", " - hsr: broadcast netlink notifications in the device's net namespace", " - net: microchip: sparx5: clean up PSFP resources on flower setup failure", " - ALSA: es18xx: check control allocation before private data setup", " - netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack()", " - riscv: panic if IRQ handler stacks cannot be allocated", " - btrfs: balance: fix potential bg lookup failure in", " btrfs_may_alloc_data_chunk()", " - btrfs: tree-checker: validate names in ROOT_REF and ROOT_BACKREF", " - NFS: fix eof updates after NFSv4.2 fallocate/zero-range", " - ASoC: mediatek: mt8365-afe-pcm: fix possible NULL-pointer dereferences", " in mt8365_afe_suspend()", " - RDMA/rtrs-srv: Fix integer underflow in process_read and process_write", " - xprtrdma: Add request-pool slack for delayed recycling", " - RDMA/mlx5: Create ODP EQ for non-pinned dmabuf MRs", " - configfs_depend_prep(): pass configfs_dirent instead of dentry", " - pds_core: quiesce DMA before freeing resources", " - net: ibm: emac: mal: fix potential system hang in mal_remove()", " - tls: Flush backlog before waiting for a new record", " - platform/x86: dell-laptop: add Inspiron N5110 to touchpad LED quirk", " table", " - wifi: mt76: mt7925: handle 320MHz bandwidth in RXV and TXS", " - platform/x86: msi-ec: Add support for MSI Pulse GL66 12th Gen", " - wifi: mt76: mt7925: add Netgear A8500 USB device ID", " - wifi: mt76: mt7925: populate EHT 320MHz MCS map in sta_rec", " - wifi: mt76: mt7925: add 320MHz bandwidth to bss_rlm_tlv", " - wifi: mt76: transform aspm_conf for pci_disable_link_state", " - netconsole: take target_cleanup_list_lock in drop_netconsole_target()", " - btrfs: protect sb_write_pointer() with invalidate lock", " - fbcon: don't suspend/resume when vc is graphics mode", " - PCI: Avoid FLR for MediaTek MT7925 WiFi", " - hwmon: (raspberrypi) Fix delayed-work teardown race", " - hwmon: (adt7462) Add of_match_table to support devicetree", " - btrfs: use on-disk uuid for s_uuid in temp_fsid mounts", " - btrfs: use lockless read in nr_cached_objects shrinker callback", " - net: dsa: qca8k: Add support for force mode for fixed link topology", " - net: lan966x: restore RX state on reload failure", " - vdpa/ifcvf: handle dev_set_name() failure in ifcvf_vdpa_dev_add()", " - vdpa/octeon_ep: Use 4 bytes for mailbox signature", " - ALSA: hda/realtek: Add quirk for HP 255 15.6 inch G9 Notebook PC", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IRH8", " - ata: libata-pmp: add JMicron JMS562 quirk", " - platform/x86: intel-hid: Add HP ProBook x360 440 G1 to", " button_array_table", " - nvme-fc: Do not cancel requests in io target before it is initialized", " - sctp: Unwind address notifier registration on failure", " - HID: multitouch: Honor ContactCount for Yoga Book 9 to suppress ghost", " contacts", " - hwmon: (dell-smm) Add Dell Latitude 7530 to fan control whitelist", " - PCI: Avoid SBR for Qualcomm WCN6855/WCN7850 WiFi, SDX62/SDX65 modems", " - dmaengine: altera-msgdma: Use memcpy_toio for descriptor FIFO writes", " - dmaengine: dw-axi-dmac: fix PM for system sleep and channel alloc", " - hwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i", " - spi: xilinx: let transfers timeout in case of no IRQ", " - Bluetooth: btusb: MT7922: Add VID/PID 0e8d/223c", " - Bluetooth: btusb: Add support for Intel Lizard Peak 2 (0x8087:0x0040)", " - Bluetooth: btusb: Add Realtek RTL8922AE VID/PID 0bda/d922", " - Bluetooth: btusb: Add Mercusys MA530 for Realtek RTL8761BUV", " - Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925", " - Bluetooth: btusb: MT7925: Add VID/PID 0e8d/8c38", " - Bluetooth: btusb: Add support for TP-Link TL-UB250", " - Bluetooth: L2CAP: validate connectionless PSM length", " - Bluetooth: btintel_pcie: Add 50 ms delay before MAC init on BlazarIW", " - ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in", " set_fmt", " - ASoC: rockchip: rockchip_pdm: Reorder clock enable sequence", " - ASoC: rockchip: spdif: Restore regcache cache-only mode on sync failure", " - Bluetooth: btusb: Add Realtek RTL8922AE VID/PID 0bda/d923", " - sparc64: uprobes: add missing break", " - net: stmmac: xgmac2: disable RBUE in default RX interrupt mask", " - ptp: ocp: add shutdown callback", " - vsock: use sk_acceptq_is_full() helper in all transports", " - e1000e: limit endianness conversion to boundary words", " - net: hns3: improve the unused_tuple parameter setting", " - net/sched: act_csum: don't mangle UDP tunnel GSO packets", " - smb: client: fix races in cifsd thread creation", " - i3c: mipi-i3c-hci: Tolerate i3c_master_add_i3c_dev_locked() failures in", " DAA", " - bpftool: Pass host flags to bootstrap libbpf", " - sparc: Disable compat support with LLD", " - exfat: fix handling of damaged volume in exfat_create_upcase_table()", " - ALSA: hda/realtek: Add quirk for Lenovo Xiaoxin 14 GT", " - virtio-fs: avoid double-free on failed queue setup", " - HID: hidpp: fix potential UAF in hidpp_connect_event()", " - fuse: set ff->flock only on success", " - scsi: bfa: Reduce kernel stack usage in", " bfa_fcs_lport_fdmi_build_portattr_block()", " - gpio: pisosr: Read \"ngpios\" as u32", " - spi: Add NULL check for spi_get_device_id() in", " spi_get_device_match_data()", " - ALSA: usb-audio: Add quirk flags for SC13A", " - tls: reject the combination of TLS and sockmap", " - ALSA: hda/conexant: Add pin config quirk for Lenovo IdeaPad Slim 5", " 16AKP10", " - leds: uleds: Return -EFAULT on copy_to_user() failure", " - leds: pca9532: Don't stop blinking for non-zero brightness", " - mfd: tps65219: Make poweroff handler conditional on system-power-", " controller", " - leds: trigger: gpio: Use GPIOD_FLAGS_BIT_NONEXCLUSIVE", " - mfd: rsmu: Add 8a34002 support", " - drm/amdkfd: Let driver decide buffer size at AMDKFD_IOC_GET_DMABUF_INFO", " ioctl", " - drm/amdkfd: check find_first_zero_bit before __set_bit on", " kfd->doorbell_bitmap", " - drm/amdgpu: Use system unbound workqueue for soft IH ring", " - ALSA: usb-audio: Add quirk for YAMAHA CDS3000", " - drm/amdkfd: Properly acquire queue buffers in CRIU restore", " - PCI: iproc: Protect root bus removal with rescan lock", " - PCI: altera: Protect root bus removal with rescan lock", " - PCI: rockchip: Protect root bus removal with rescan lock", " - PCI: mediatek: Protect root bus removal with rescan lock", " - PCI: plda: Protect root bus removal with rescan lock", " - perf: Fix addr_filter_ranges lifetime", " - mailbox: imx: Use devm_pm_runtime_enable()", " - md/raid5: account discard IO", " - mailbox: imx: Add a channel shutdown field", " - mailbox: imx: use devm_of_platform_populate()", " - md/raid5: let stripe batch bm_seq comparison wrap-safe", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 16IAP7", " - f2fs: validate inline dentry name lengths before conversion", " - rtc: mv: add suspend/resume support for wakeup", " - rtc: aspeed: add AST2700 compatible", " - ksmbd: fix lease break and ack state handling", " - ksmbd: validate SMB2 lease create contexts", " - ksmbd: align SMB2 oplock break ack handling", " - ksmbd: use connection ClientGUID for lease lookup", " - ksmbd: treat unnamed DATA stream as base file", " - ksmbd: apply create security descriptor first", " - ksmbd: deny renaming directory with open children", " - ksmbd: start file id allocation at 1", " - ksmbd: break RH leases before delete-on-close", " - ksmbd: treat read-control opens as stat opens only for leases", " - PCI/proc: Fix race between pci_proc_init() and pci_bus_add_device()", " - PCI/sysfs: Use kstrtobool() to parse the ROM attribute input", " - regulator: da9121: Use subvariant ids in the I2C table", " - net: au1000: move free_irq out of the close-time spinlocked section", " - blk-cgroup: protect iterating blkgs with blkcg->lock in", " blkcg_print_stat()", " - rtc: bq32000: add delay between RTC reads", " - eth: mlx5: fix macsec dependency", " - ALSA: hda: Add Lenovo Legion 7i 16IAX7 17AA3874 quirk", " - fbdev: pm2fb: unwind WC setup on probe failure", " - ASoC: tas2781: Update default register address to TAS2563", " - spi: core: Abort active target transfer on controller suspend", " - btrfs: tree-checker: validate INODE_REF's namelen", " - drm/arm/malidp: use clk_bulk API in runtime PM resume and suspend", " - netfilter: nf_conntrack_expect: zero at allocation time", " - ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr", " - ALSA: hda/realtek: Add quirk for HP Victus 16-e0xxx (88EE) to enable", " mute LED", " - drm/arm/komeda: fix error handling for clk_prepare_enable() and callers", " - ksmbd: fix n.data memory leak in ksmbd_vfs_set_dos_attrib_xattr", " - ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling", " - xen/front-pgdir-shbuf: free grant reference head on errors", " - freevxfs: don't BUG() on unknown typed-extent type", " - xen/gntalloc: validate grant count before allocation", " - cachefiles: Fix double fput", " - netfs: Fix decision whether to disallow write-streaming due to fscache", " use", " - ASoC: amd: yc: Add Alienware m15 R7 AMD to DMIC quirk table", " - drm/amdgpu: flush pending RCU callbacks on module unload", " - ksmbd: fix credit charge calculation for SMB2 QUERY_INFO", " - ALSA: usb-audio: caiaq: validate EP1 reply lengths", " - wifi: ralink: RT2X00: init EEPROM properly", " - wifi: mac80211: validate deauth frame length before reason access", " - wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers", " - wifi: libertas: reject short monitor TX frames", " - wifi: cfg80211: validate assoc response length before status and IE", " access", " - ksmbd: find bound sessions during reauthentication", " - ksmbd: mark invalid session responses as signed", " - ksmbd: validate SID namespace before mapping IDs", " - wifi: cfg80211: validate rx/tx MLME callback frame lengths before access", " - wifi: mac80211: ibss: wait for in-flight TX on disconnect", " - gpio: dwapb: Mask interrupts at hardware initialization", " - wifi: libipw: fix key index receive bound checks", " - netfilter: ipset: mark the rcu locked areas properly", " - wifi: rsi: validate beacon length before fixed buffer copy", " - ASoC: rt712-sdca: reset codec at io_init to fix silent headphone", " - cifs: Fix support for creating SFU socket", " - smb/client: zero-initialize stack-allocated cifs_open_info_data", " - ALSA: hda/realtek: Fix speakers on MECHREVO WUJIE Series", " - ALSA: hda/realtek - Add quirk for HP Victus 15-fa0xxx (MB 8A50)", " - ALSA: hda: cs35l56: Fail if wmfw file is missing", " - cifs: Fix support for creating SFU fifo", " - btrfs: only account delalloc bytes for regular file inodes in", " btrfs_getattr()", " - btrfs: fix use-after-free on reloc root after error in", " insert_dirty_subvol()", " - spi: dw-dma: Wait for controller idle before completing Tx", " - wifi: iwlwifi: mvm: validate sta_id in BA window status notif", " - btrfs: fix reloc root cleanup in merge_reloc_roots()", " - wifi: iwlwifi: mvm: validate mac_link_id in session protect notif", " - wifi: iwlwifi: mvm: fix an off-by-1 boundary check", " - wifi: iwlwifi: mvm: parse beacon notif per layout", " - wifi: iwlwifi: mvm: fix sched scan IE sizing", " - wifi: iwlwifi: pcie: null RX pointers after free", " - ALSA: hda/realtek: Add quirk for HP EliteBook 830 G8 (8AB8) to enable", " mute LEDs", " - blk-cgroup: fix leaks and online flag on radix_tree_insert failure", " - smb/client: flush dirty data before punching a hole", " - ASoC: Intel: sof_sdw: Add quirks for new Dell laptops", " - wifi: iwlwifi: mvm: validate TX_CMD response layout", " - wifi: iwlwifi: mvm: fix a possible underflow", " - arm64: fixmap: Allow 256K early_ioremap() at any offset", " - wifi: iwlwifi: mvm: add a check on the tid coming from the firmware", " - wifi: iwlwifi: mvm: fix out-of-bounds tid_data access in BA notif", " - arm64: kprobes: Allow reentering kprobes while single-stepping", " - drm/amd/pm/si: Don't schedule thermal work when queue isn't initialized", " - ALSA: hda/realtek: Add quirk for HP Pavilion x360", " - wifi: iwlwifi: bound aligned TLV advance in FW parser", " - ALSA: usb-audio: Add FIXED_RATE quirk for JBL Quantum650 Wireless", " - wifi: iwlwifi: acpi: validate WGDS table revision index", " - ALSA: hda/realtek: Add HDA_CODEC_QUIRK for Samsung 750XBE/730XBE", " - wifi: mwifiex: replace one-element arrays with flexible array members", " - smb: client: bound dirent name against end of SMB response in", " cifs_filldir", " - regulator: core: clamp voltage constraints before applying apply_uV", " - wifi: mac80211_hwsim: reject undersized HWSIM_ATTR_TX_INFO", " - ksmbd: preserve VFS inherited POSIX ACL mask", " - drm/gma500: return errors from Oaktrail HDMI I2C reads", " - phonet: check register_netdevice_notifier() error in", " phonet_device_init()", " - ALSA: usb-audio: Add dB map quirk for Razer Barracuda X 2.4", " - ALSA: hda/realtek: Add mute LED quirk for HP Laptop 14s-dr1xxx", " - ice: pass the return value of skb_checksum_help()", " - powerpc/pseries: Ensure vpa,slb_shadow & dtl are unregistered during", " crash", " - cifs: validate idmap key payload length", " - wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie()", " - Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame", " - ALSA: usb-audio: Add quirk for Corsair Virtuoso (later revision)", " - ata: libata-core: Disable LPM on some WD drives", " - ALSA: hda/realtek: Add mute LED quirk for HP Victus 16-e0xxx (MB 88ED)", " - ata: libata-core: Disable LPM on WD Green 2.5 480GB", " - Drivers: hv: vmbus: add VTL2 redirect connection ID", " - ASoC: amd: yc: Add DMI quirk for HP Victus Laptop 16-e1xxx", " - vhost-scsi: flush backend after device ioctls", " - hwmon: (corsair-psu) Fix linear11 calculation", " - ata: libata-core: Disable LPM on WDC WD141KFGX-68FH9N0", " - spi: dw: fix wrong RX_SAMPLE_DLY setting after resume", " - ASoC: rt5645: Perform the initial jack detect at probe", " - scsi: core: Do not block on tag allocation in scsi_eh_lock_door()", " - ASoC: amd: yc: Add DMI quirk for HyperX OMEN Gaming Laptop 16-ap1xxx", " - netfilter: nfnetlink_log: wait for rcu grace period before freeing", " pernet state", " - bpftool: Strip all -Wformat* flags from bootstrap libbpf build", " - ksmbd: remove stale channels from all sessions on teardown", " - iommu/arm-smmu-v3: Disable implementations during devm teardown", " - wifi: mt76: mt7921: validate CLC firmware records", " - wifi: mt76: mt7921: skip unknown CLC firmware records", " - leds: st1202: Validate pattern input before stopping the sequence", " - ppp_async: drop the errored frame instead of resetting its headroom", " - ARM: ensure interrupts are enabled in __do_user_fault()", " - RAS/AMD/ATL, EDAC/amd64: Only load ATL when needed", " - EDAC/igen6: Fix interleave boundary condition", " - EDAC/igen6: Fix channel selection hash", " - EDAC/igen6: Fix channel address decode for non-hash mode", " - EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation", " - drm/virtio: Fix a NULL vs ERR_PTR() bug in", " virtio_gpu_user_framebuffer_create()", " - drm/virtio: use the DMA API for resource backing on Xen", " - accel/qaic: Address potential out-of-bounds read in resp_worker()", " - nvme-rdma: fix -EIO cleanup order in queue_rq", " - nvmet-rdma: fix queue leak when connect backlog is exceeded", " - sched_ext: Fix nonexistent field in sched-ext.rst example", " - selftests/cgroup: Fix cg_run_in_subcgroups ignoring arg parameter", " - bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic", " - drm/gud: validate GUD_ROTATION_0 is present in supported rotations", " - accel/amdxdna: Remove __counted_by from struct amdxdna_cmd_chain", " - ufs: do not treat unreadable directory blocks as empty", " - drm/cirrus-qemu: Validate BAR0 size during probe", " - net: icmp: avoid invalid transport header access in icmp_send tracepoint", " - tcp: use GFP_ATOMIC in tcp_send_active_reset()", " - net: iptunnel: fix stale transport header during tunnel decapsulation", " - net/sched: act_api: budget all shared attributes in notify skbs", " - net/sched: act_api: size the RTM_GETACTION reply from the actions", " - net/sched: act_api: fix skb sizing and action leak on reoffload delete", " - sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START", " - scsi: mpi3mr: Fix NULL pointer dereference in mpi3mr_sas_port_add()", " - scsi: mpi3mr: Fix target device refcount leak in mpi3mr_sas_port_add()", " - smb/client: validate new EOF for insert range", " - smb/client: validate new EOF for zero range", " - smb/client: mark file sparse before emulating insert range", " - smb/client: fix data corruption in emulated insert range", " - smb/client: fix integer truncation in collapse range", " - smb: client: transport: Fix debug printing in __release_mid()", " - sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration", " - raw: annotate disconnect-side IPv4 match writers", " - net: amd-xgbe: discard rx packets with bad FCS", " - vxlan: mdb: Fix use-after-free in vxlan_mdb_remote_src_del()", " - watchdog: msc313e: Fix NULL pointer dereference in PM callbacks", " - perf symbol: Do not use debug file as the binary type", " - OPP: of: Fix potential multiplication overflow when calculating freq", " - perf powerpc-vpadtl: Fix raw_size of DTL samples", " - netfs: Fix unbuffered/DIO write partial transfer error return", " - netfs: Fix error vs transferred passed to ->ki_complete()", " - netfs: Fix i_size update for partial transfer", " - netfs: Fix subreq ref leak", " - netfs: break unbuffered write when netfs_alloc_subrequest() fails", " - cachefiles: Fix potential UAF/KASAN warning", " - ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF", " - ksmbd: propagate DACL parsing errors", " - ksmbd: rate limit unmapped SID errors", " - s390/time: Use jiffies instead of jiffies_64", " - s390/ipl: Fix NULL deref in kdump without re-IPL parm block", " - s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block", " - s390/diag324: Preserve -EBUSY return code", " - sched_ext: Fix timer pinning and return value in scx_central", " - sched_ext: Update demo schedulers and selftests to use", " scx_bpf_task_set_dsq_vtime()", " - sched_ext: Fix vtime delta loss in scx_flatcg cgroup migration", " - Bluetooth: btintel_pcie: Clear automask on spurious interrupts", " - workqueue: reject watchdog thresholds that overflow jiffies", " - Bluetooth: btintel: validate version TLV value lengths", " - Bluetooth: btintel: bound firmware ID by TLV length", " - Bluetooth: hci_core: Fix race condition during device registration", " - Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan", " - Bluetooth: L2CAP: fix out-of-bounds write in l2cap_ecred_connect", " - Bluetooth: L2CAP: clear FLAG_DEFER_SETUP only for same PID/PSM", " - Bluetooth: hci_mrvl: Fix wrong return value check of", " wait_on_bit_timeout()", " - ASoC: ab8500: Reset the audio block before configuring it", " - ASoC: ab8500: Repair the DAPM capture graph", " - ASoC: ab8500: Correct digital interface format setup", " - ASoC: ab8500: Validate and program TDM slots correctly", " - net: ethernet: oa_tc6: Interrupt is active low, level triggered.", " - net: ethernet: oa_tc6: Handle the OA TC6 SPI protected mode", " - net: ethernet: oa_tc6: Export standard defined registers", " - net: ethernet: oa_tc6: Add the OA_TC6_ prefix to standard registers", " - net: ethernet: oa_tc6: Protect skb pointer used by two different kernel", " instances", " - net: ethernet: oa_tc6: Improve the error recovery", " - net: ethernet: oa_tc6: Disable tx queues on fatal error", " - net: ethernet: oa_tc6: Fix for the wrong data type", " - net/sched: cls_u32: fix duplicate handle when node ID pool is exhausted", " - igmp: convert struct ip_sf_list to RCU", " - ppp: ppp_async: simplify tty disc_data access", " - ppp: ppp_synctty: simplify tty disc_data access", " - ipv6: mcast: fix RCU list diversion in ip6_mc_del1_src()", " - ipv6: mcast: use copy-on-write RCU updates in ip6_mc_source()", " - ip6_gre: check tunnel info before xmit in ip6gre_tunnel_xmit", " - tipc: fix NULL deref in tipc_named_node_up() on empty publication list", " - tipc: Dont send random pad bytes in RESET/ACTIVATE messages", " - ipv6: sr: restore network header before routing and forwarding", " - af_packet: Don't cast tpacket_hdr.tp_len to int in", " tpacket_parse_header().", " - staging: fbtft: make dirty_lock IRQ-safe", " - ALSA: hda: restore MFG widget enumeration after core split", " - s390/boot: Fix physical memory search range", " - s390/boot: Avoid IPL parameter append past command line", " - ASoC: fsl_micfil: balance mclk enable/disable", " - ASoC: amd: renoir: fix disable_pdm_interrupts() to clear mask bits", " - ASoC: amd: yc: fix memory leak in acp6x_pdm_dma_close()", " - drm/xe/oa: Remove sysfs entry on idr_alloc failure in", " xe_oa_add_config_ioctl()", " - ALSA: dummy: Report a change when one capture switch channel moves", " - btrfs: detach failed sprout device from transaction update list", " - btrfs: restore active device pointers after failed sprout", " - bonding: alb: fix uninitialized transport header access in", " alb_determine_nd()", " - perf: RISC-V: check cpu_hw_evt before dereference in overflow IRQ", " - scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in", " _base_assign_reply_queues()", " - sched/rt,dl: Skip migrate-disabled tasks when picking a push candidate", " - x86/itmt: Don't make ITMT enablement depend on debugfs", " - perf/core: Skip empty AUX records with only format flags", " - locking/lockdep: Invalidate stale class_cache entries for zapped classes", " - octeontx2-af: Fix limiting SRIOV VF count logic", " - ALSA: ump: do not touch legacy_rmidi before it exists", " - printk/nbcon: Change nbcon_irq_work to IRQ_WORK_LAZY", " - ASoC: ux500: Fix MSP stream lifecycle handling", " - ASoC: ux500: Propagate MSP setup errors", " - ASoC: ux500: Correct MSP frame and bit clock setup", " - ASoC: ux500: Validate MSP DAI configuration", " - mfd: db8500-prcmu: Fold dbx500 header into db8500", " - ASoC: ux500: Deassert the MSP reset during probe", " - ASoC: ux500: Request the MSP MMIO resource", " - ASoC: ux500: Remove obsolete PRCMU QoS calls", " - ASoC: ux500: Allow repeated MSP prepare calls", " - ASoC: ux500: Program the MSP FIFO watermarks", " - btrfs: scrub: report the failing sector's address, not the stripe base", " - btrfs: fix transaction use-after-free in raid stripe insertion", " - btrfs: fix the possible bioc_list memory leak during error", " - btrfs: return proper negative error code for update_raid_extent_item()", " - btrfs: zoned: finish active block group cleanup if call_zone_finish()", " fails", " - btrfs: send: fix lost error return value in will_overwrite_ref()", " - btrfs: do not force reloc root creation during qgroup_account_snapshot()", " - btrfs: zstd: fix lost wakeup when waiting for a workspace", " - drm/amdgpu/userq: fix struct drm_amdgpu_info_device padding for 32bit", " compile", " - ipvs: fix reversed sequence option serialization", " - netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace()", " - tracing/probes: Fix use-after-free on field name/type of events with", " multiple probes", " - bpf: reject BPF_PSEUDO_FUNC reference to the main program", " - bonding: do not clear curr_active_slave prematurely when releasing all", " slaves", " - net: Remove conflicting altnames for dying netns in", " __dev_change_net_namespace().", " - net/rds: use wq_has_sleeper() in release_in_xmit()", " - net/rds: use clear_bit_unlock() in release_refill()", " - net/rds: clear cp_flags bits individually in rds_conn_path_reset()", " - net/rds: tcp: don't force RDS_CONN_RESETTING over a concurrent shutdown", " - net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()", " - net/rds: acquire the fastpath locks in rds_conn_shutdown()", " - net/rds: don't let rds_conn_shutdown() consume a concurrent drop", " - net: airoha: enable RX_DONE interrupt for RX queue 31", " - net: stmmac: reconfigure RX packet parser table in stmmac_hw_setup()", " after reset", " - net: gro: Fix nesting of TCP GSO SKBs in skb_gro_receive_list()", " - arm64: trans_pgd: clone only the linear map that exists at runtime", " - erofs: disable LZ4 rolling decompression for now", " - selftests/alsa: Fix the step check for INTEGER controls", " - ALSA: caiaq: Fix potential double-free at error path", " - drm/rockchip: dw_dp: Select DRM_BRIDGE_CONNECTOR", " - drm/rockchip: rk3066_hdmi: Add missing Kconfig selects", " - bpf: Fix NULL-ptr-deref when showing a void BTF type", " - bpf: Fix NULL-ptr-deref in btf_var_show()", " - bpf: Mark signal tracepoint siginfo arguments as scalar", " - bpf: Reject tail calls directly from callback frames", " - bpf: Reject resilient lock operations in rbtree callbacks", " - bpf: Mark sched_process_wait argument as nullable", " - nvme: remove stale namespaces by NSID range during scan", " - nvme-tcp: defer TLS inline send to io_work", " - ASoC: Intel: avs: Clean up the bus when fetching ML caps fails", " - ASoC: Intel: avs: Do not ignore -ENOENT when loading a topology", " - ASoC: Intel: avs: Fix unbalanced module reference count", " - ASoC: Intel: avs: Refactor and fix init_config access", " - net: bcmasp: clear txcb->last before writing each descriptor", " - net: bcmasp: fix tx_spb_ring_full() checking same slot cnt times", " - mlxsw: spectrum_ptp: Fix napi_gro_receive() call from GC workqueue", " context", " - bpf: Only enforce 8 frame call stack limit for all-static stacks", " - bpf: share several utility functions as internal API", " - bpf: Print breakdown of insns processed by subprogs", " - bpf: Report maximum combined stack depth", " - bpf: Track verifier instruction stats for each subprogram", " - bpf: Check ancestor frames for rbtree callbacks", " - bpf: Mark bpf_btf_find_by_name_kind() as sleepable", " - bpf: Mark faultable stack helpers as sleepable", " - bpf: Reject legacy packet loads from callbacks", " - bpf: Don't predict JMP32 pointer vs zero comparisons", " - thermal: sysfs: switch to use scnprintf() to suppress truncation warning", " - bpf: Require MEM_PERCPU for percpu kptr stores", " - bpf: Reject untrusted allocated-object pointers", " - tracing: Fix to avoid creating trace instances with duplicate names", " - selftests/bpf: Fix flaky bpf_nf test when random NAT port is 0", " - nexthop: Initialize extack in remove_nh_grp_entry()", " - bonding: use skb_cow_head() in bond_do_alb_xmit() and rlb_arp_xmit()", " - net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size", " - eth: nfp: bound the ntuple rule dump by the caller's buffer size", " - eth: nfp: drop the replaced rule from the list when reprogramming fails", " - net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer", " size", " - net: bridge: mcast: properly convert mglist to rcu", " - octeontx2-af: mcs: Clear stale X2P calibration state before calibration", " - ionic: use netif_txq_maybe_stop() in ionic_tx()", " - net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent", " partial_data heap overflow", " - dibs: change dibs_class to a const struct", " - dibs: Unregister dibs_class after error", " - s390/ism: folio_put() after error", " - vxlan: reject dynamic fdb entries that reference a nexthop id", " - net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations", " - net: reject oversized tx_queue_len at netlink parse time", " - pds_core: fix cmd_regs access racing BAR unmap on reset", " - pds_core: don't release PCI regions for VFs on reset", " - powerpc/kexec_file: Use inclusive range checks in add_usable_mem()", " - powerpc/kexec_file: Use inclusive range checks for excluded memory", " - net: mctp: i3c: serialize probe with bus removal", " - net/sched: defer qdisc freeing after failed creation", " - net/mlx5e: Fix missing FEC mode mapping for RS_544_514_INTERLEAVED_QUAD", " - net/mlx5e: Fix setting RS FEC after remapping", " - net/mlx5: LAG, use local tracker to update active ports", " - net/mlx5e: Fix ETS zero BW reporting when one TC holds 100%", " - net/mlx5e: Fix use-after-free race in sample_restore_put()", " - net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put", " - net/mlx5: E-Switch, prevent mc_list repopulation during vport disable", " - net/mlx5e: Keep HW timestamp stats monotonic across reconfiguration", " - net/sched: fq_pie: clamp quantum in change path", " - net/sched: sfq: clamp quantum in change path", " - net/sched: hhf: clamp quantum in change and init paths", " - net/sched: dualpi2: clamp psched_mtu at all call sites", " - net/sched: pie: clamp psched_mtu in pie_drop_early", " - net/sched: drr: clamp quantum in change class", " - net/sched: ets: clamp quantum in parse and fallback paths", " - net: macb: fix NULL pointer dereference on unbind with fixed-link", " - bpf: Reject non-scalar bpf_loop iteration counts", " - ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev", " - iommu/riscv: Add command queue lock", " - iommu/riscv: Disable SADE", " - iommu/amd: Add NUMA node affinity for IOMMU log buffers", " - iommu/amd: Do not reallocate GA log buffers on resume", " - iommu/amd: Fix premature break in init_iommu_one() again", " - hwmon: (ltc4282) Make sure clk_init_data is fully initialized", " - Documentation/hwmon: Document hwmon_notify_event()", " - hwmon: Fix potential UAF in pec_store", " - hwmon: (ina2xx) Acquire hwmon_lock in shunt_resistor_show()", " - hwmon: (ina2xx) Parameterize ina2xx_data in ina226_alert_read()", " - hwmon: (ina2xx) Replace masks with enum in alert functions", " - hwmon: (ina2xx) Decouple in0 and curr1 alarms", " - Documentation: hwmon: replace full-width colon by a standard ASCII colon", " - hwmon: (sht4x) Fix return value from heater_enable_store()", " - ASoC: bcm: bcm63xx: Publish the OF module aliases", " - ASoC: Intel: SST: Publish the PCI module aliases", " - netfilter: nfnetlink_log: cope with concurrent instance destruction", " - netfilter: ip6_tables: set F_PROTO when proto value is nonzero", " - ASoC: mt6351: Publish the OF module alias", " - irqchip/gic-v5: Preserve ICC_CR0_EL1 state", " - virtio: fix use-after-free in unregister_virtio_device()", " - virtio_console: do not free control-out buffers on remove", " - vhost/vdpa: reject VRING_NUM larger than device max", " - vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx", " - vhost-vdpa: protect config_ctx from being freed under the config", " callback", " - vdpa_sim_blk: reject out-of-range sector starts", " - vdpa_sim_net: check TX pull result before RX copy", " - virtio-pci: return IRQ_HANDLED after non-zero ISR", " - virtio_input: reset device if input_register_device() fails", " - virtio_input: stop callbacks before unregistering input device", " - af_unix: Update last skb marker in manage_oob().", " - af_unix: Return immediately when manage_oob() returns NULL for 0-length", " buffer.", " - net: ipv4: Fix UDP length overflow with PMTU discover and big MTU", " - net: ipv6: Fix UDP length overflow with PMTU discover and big MTU", " - net: ipv6: Clamp to IP6_MAX_MTU in ip6_dst_mtu_maybe_forward", " - net: ethernet: cortina: Fix budget accounting", " - net: ethernet: cortina: Finish RX updates before NAPI completion", " - net: ethernet: cortina: Count dropped frames as NAPI work", " - net: ethernet: cortina: No mapping is a dropped rx", " - net: ethernet: cortina: Count RX drops once per frame", " - net: ethernet: cortina: Count RX descriptors for freeq refill", " - drm/adp: Drop the select of the nonexistent CONFIG_DRM_KMS_DMA_HELPER", " - drm/logicvc: Drop the select of the nonexistent", " CONFIG_DRM_KMS_DMA_HELPER", " - ALSA: hda: Report a change when only the channel status bytes move", " - idpf: account for VLAN header when parsing RSC packet header", " - ice: add missing xa_destroy for sched_node_ids", " - eth: ice: don't dereference pointers from TP_printk()", " - Bluetooth: btusb: Fix UAF of btusb_data by rx_work", " - Bluetooth: btintel_pcie: validate packet_len before skb_put_data", " - Bluetooth: btintel_pcie: fix tx_handle bounds off-by-one", " - Bluetooth: hci_sysfs: Fix NULL pointer dereference in device_del()", " - Bluetooth: btusb: mediatek: Fix leaked runtime PM reference in reset", " - Bluetooth: btusb: Fix leaked runtime PM reference in btusb_reset", " - net: mana: Clear RDMA teardown and suspend state in mana_rdma_probe()", " - ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings()", " - net: macb: destroy the phylink instance on the probe error path", " - net: macb: put the \"mdio\" child node reference on success", " - mptcp: remove unneeded READ_ONCE() annotation", " - watchdog: fix hrtimer start when pretimeout is zero", " - watchdog: msc313e: Avoid division by zero", " - watchdog: msc313e: Fix clock leak and spurious timer in settimeout()", " - watchdog: msc313e: Enable clock before accessing hardware registers", " - watchdog: msc313e: Fix spurious reset on suspend", " - watchdog: msc313e: Fix undefined behavior", " - watchdog: msc313e: Sync timeout value if WDT was running at boot", " - net: dsa: lantiq_gswip: fix GSWIP_MDIO_PHY_FCONTX_EN value", " - net: ks8851: Fix receiver error in 100BASE-TX mode following software", " power-down", " - hwmon: (corsair-cpro) Create debugfs entries after hwmon registration", " - hwmon: (gpio-fan) take fan_data->lock in gpio_fan_shutdown()", " - hwmon: (aspeed-pwm-tacho) Propagate reset deassert errors", " - hwmon: (corsair-cpro) Remove debugfs entries when probe fails", " - hwmon: (nct6694) do not expose enable on DTIN temperature channels", " - octeontx2-pf: reset HTB scheduler topology before freeing queues", " - vxlan: initialize _md in vxlan_xmit_one()", " - ppp_synctty: ensure a writeable skb header", " - net: stmmac: initialize ptp_lock at probe time", " - devlink: Refactor resource functions to be generic", " - devlink: Add port-level resource registration infrastructure", " - net/mlx5: Register SF resource on PF port representor", " - net/mlx5e: Move representor vnic reporter to eswitch devlink port", " - selftests/powerpc/tm: Fix tcheck() reading uninitialised CR value", " - perf/core: Allow list_del during perf_event_overflow()", " - perf/x86/intel: Correct pt_regs->flags update for PEBS path", " - perf/x86/intel: Prevent drain_pebs() reentry", " - sched/eevdf: Fix augmented max_slice", " - sched/eevdf: Fix rb augmented with multi fields", " - sched: Account cgroup CPU time to the execution context", " - sched/core: Call wq_worker_tick() for the execution context", " - net/sched: cls_route: free emptied bucket on filter move", " - net/sched: cls_route: Reject handle aliasing", " - net/sched: cls_route: Fix in-place replace", " - net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain().", " - net: sun4i-emac: fix missing of_node_put() for phy_node", " - net: hinic: fix mailbox segment buffer overflow", " - net: dsa: mt7530: add EN7528 support", " - net: dsa: mt7530: populate lpi_interfaces to fix EEE support", " - net: ethernet: mtk_eth_soc: avoid writing to ESW registers on MT7628", " - net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support", " - net: phy: mediatek-ge: disable EEE on the MT7530 PHY", " - net: net_failover: Fix the deadlock in net_failover_slave_name_change()", " - octeontx2-af: fix PF/CGX debugfs PCI bus lookup", " - net: phy: dp83867: handle the active-high LED polarity mode", " - net: mana: restore the XDP program pointer when pre-allocation fails", " - net/rds: fix tcp stream corruption with large pages", " - net: stmmac: fix TSO support when some channels have TBS available", " - net: stmmac: add stmmac_tso_header_size()", " - net: stmmac: add TSO check for header length", " - net: stmmac: fix TX descriptor availability check for TSO traffic", " - net: hsr: enable promiscuous mode on interlink port with fwd offload", " - openvswitch: fix wrong flag value in get_ipv6_ext_hdrs()", " - sunvdc: unmap LDC cookies when the descriptor send fails", " - erofs: add missing buf->off in erofs_bread()", " - scripts/mksysmap: drop the MODULE_INFO() symbols from kallsyms", " - scripts/mksysmap: fix escape of '$' in the __pi_ pattern", " - scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands", " - configfs: pin the symlink target's dirent instead of chasing ->ci_dentry", " - powerpc/ps3: Fix repository.c build failure", " - powerpc/eeh: Fix recursive locking on devices without EEH sensitive", " driver", " - powerpc: pci-ioda: Fix the stale irq chip reference", " - x86/amd_node: Avoid divide by zero on virtualized systems", " - x86/amd_node: Fix potential NULL pointer dereference", " - crypto: x86/aria - add missing vzeroupper in AVX2 code", " - crypto: x86/aria - add missing vzeroupper in AVX-512 code", " - x86/amd_node: Fix PCI device reference counting in amd_smn_init()", " - x86/mm: Fix user-space data loss with MADV_FREE and THP", " - x86/cfi: Fix FineIBT hash offset in cfi_get_func_hash()", " - x86/mm/pat: Acquire init_mm write lock on collapse to avoid UAF", " - x86/alternatives: Exclude text poking against change_page_attr()", " - ipv6: fix fib6 walker UAF on seq stop", " - reboot: fix cad_pid use-after-free race", " - tracing: Fix memory corruption from the histogram stacktrace modifier", " - tracing: Restore :mod: trailer after parsing in ftrace_set_clr_event()", " - tracing: Fix memory corruption from a \"STACKTRACE\" histogram key", " - rust: allow `clippy::as_underscore` in the generated bindings", " - rust: allow `unknown_lints` in generated bindings for Rust < 1.88", " - drm/panic: clean new `clippy::needless_range_loop` lint for Rust 1.100.0", " - ALSA: ctxfi: Fix CA20K2 S/PDIF passthrough", " - ALSA: us122l: Prevent write upgrades for read mappings", " - ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf", " - ALSA: usbusx2y: validate URB actual_length in interrupt callback", " - Revert \"riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set\"", " - dm/amdgpu: fix malformed link_settings debugfs output", " - drm/amdgpu: skip gfx switch_power_profile during GPU reset", " - watchdog: sunxi_wdt: preserve boot-enabled watchdog", " - virtio_mmio: disable IRQ wake before free_irq", " - ufs: create the root dentry after loading cylinder metadata", " - ufs: validate cylinder group metadata before caching it", " - tunnels: Drop stale dst when building an ICMP error for PMTUD", " - tick/broadcast: Plug clockevents replacement race", " - tools/bootconfig: Fix integer overflow and truncation in size checks", " - tracing/user_events: Don't destroy fields when event removal fails", " - tracing: Free histogram the var ref when its initialization fails", " - tracing: Free histogram var refs regardless of how often they are", " referenced", " - tracing: Free histogram the field rejected for a bad modifier", " - tracing: Let histogram values keep the percent and graph modifiers", " - tracing: Keep the entry count when the histogram stats allocation fails", " - accel/ivpu: Validate full buffer range in ivpu_to_cpu_addr", " - accel/ivpu: Validate firmware log buffer metadata", " - accel/ivpu: Limit firmware log name prints to field size", " - ASoC: sprd: validate compress buffer sizes against fixed allocations", " - ASoC: sti: initialize IRQ lock before requesting IRQ", " - Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev", " - Bluetooth: btrtl: Don't leak return code when parsing firmware format v2", " - cpufreq: zero-initialize policy cpumask before sysfs publication", " - cpufreq: initialize policy rwsem before sysfs publication", " - exec: do_close_on_exec() before taking exec_update_lock", " - fs: don't return -EINVAL for successful nested thaw", " - function_graph: Use the saved entry's size when reprinting it", " - drm/bridge: tc358768: Enforce input bus flags via atomic_check", " - drm/drm_exec: fix up contended obj when num_objects is 0", " - drm/i915: Fix memory leak in query_perf_config_list()", " - drm/rockchip: analogix_dp: fix unchecked bound endpoint name length", " - drm/sched: Create a fake device for KUnit tests", " - io_uring/net: let io_recv_buf_select return the length of the buffer", " region", " - io_uring/net: don't overconsume buffers when using MSG_TRUNC", " - ring-buffer: Acquire the lock with irqsave in rb_wake_up_waiters()", " - ring-buffer: Check resize_disabled before publishing the new subbuf", " order", " - net/sched: act_api: release all action references on NEWACTION failure", " - net: bridge: use option bits for CFM/MRP frame handlers", " - net: dsa: tag_brcm: legacy FCS: request needed tailroom", " - net: hso: fix TIOCMIWAIT race", " - net: mana: Reserve extra CQ slot for the fence completion CQE", " - net: mpls: clear inner_protocol when the last label is popped", " - net: openvswitch: fix use-after-free of the flow table mask array", " - net: phy: dp83td510: handle the active-high LED polarity mode", " - netfs: Fix uninitialized return value in netfs_unbuffered_write()", " - netfilter: nf_log: unregister loggers before per-net teardown", " - netfilter: report NLM_F_DUMP_FILTERED when all is filtered out", " - vdpa: ifcvf: Put device on unsupported feature error", " - vdpa: solidrun: Free IRQs after request failure", " - scripts/sorttable: Mark long_size as __maybe_unused", " - fs: autofs: fix memory leak in autofs_fill_super()", " - erofs: preserve LZMA decoders on resize failure", " - fbdev: vfb: defer cleanup until the last reference", " - inet: frags: invalidate queues before flushing them", " - ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink", " - ieee802154: cc2520: fix FIFOP work use-after-free", " - ieee802154: hwsim: serialize pib updates to fix double-free", " - ipv4: fib: bound automatic table ID allocation", " - ipv6: flowlabel: cap duplicate leases per socket", " - ipvs: reject invalid states in connection template sync records", " - mac802154: fix use-after-free of sdata via queued RX frames", " - KVM: PPC: Book3S HV: Set irqfd->producer only on success", " - iommu/s390: Fix NULL dereference in iova_to_phys() with", " ZPCI_TABLE_TYPE_RFX", " - s390/qeth: allow bridgeport queries despite OS_MISMATCH", " - s390/crypto: Fix skcipher_walk return code handling in aes_s390", " - s390/crypto: Fix use of mutex in atomic context", " - s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm", " algorithm", " - s390/crypto: Fix missing cra_flags in paes_s390", " - s390/crypto: Fix handling of EBUSY in PHMAC when req is pushed to crypto", " engine", " - s390/crypto: Fix missing scrub of temp buffers with PAES algorithm", " - s390/crypto: Fix wrong return code to engine in asynch callbacks", " - s390/crypto: Map EBUSY to EIO when key conversion fails repeatedly", " - perf: RISC-V: store available counter mask as bitmap", " - perf: RISC-V: use BIT_ULL for u64 overflow masks", " - afs: Fix missing kunmap in afs_dir_search_bucket()", " - afs: Fix double-unmap of directory block", " - afs: Fix incorrect free in candidate cleanup in afs_lookup_server()", " - afs: Clear stale peer app data after address list changes", " - hwmon: (applesmc) fix key backlight workqueue leak on register failure", " - hwmon: (chipcap2) fix channels in humidity alarm notifications", " - hwmon: (gpio-fan) Fix use-after-free in alarm work", " - hwmon: (pmbus) Clear generic status alarms with CLEAR_FAULTS", " - media: hevc: add bounded tile-count helpers", " - media: verisilicon: hantro: bound G2 HEVC tile loop to the buffer", " capacity", " - media: mediatek: vcodec: bound AV1 tile-start copy to the array capacity", " - media: v4l2-h264: Fix memcmp() size in B1 reference list comparison", " - media: verisilicon: rockchip: guard VPU981 AV1 divisor and tile buffer", " - media: verisilicon: rockchip: reject AV1 frames exceeding the tile", " capacity", " - media: v4l2-ctrls: validate HEVC tile counts", " - media: v4l2-ctrls: validate AV1 tile counts", " - bnxt_en: Only restore LRO if the device supports TPA", " - bnxt_en: Don't free the live ring's TPA state on queue restart failure", " - bnxt_en: Propagate RX ring init failures in bnxt_init_nic()", " - bnxt_en: Propagate TPA buffer allocation failures in", " bnxt_queue_mem_alloc()", " - mptcp: options: handle MPC data + csum reqd + no csum", " - mptcp: subflow: no need to copy thmac during ulp_clone", " - mptcp: syncookies: remember the request backup flag", " - selftests: mptcp: fix an UAF in mptcp_connect.c", " - mptcp: pm: kernel: drop pending ADD_ADDR when removing ID0", " - mptcp: pm: userspace: fix address ID overflow", " - smb: client: reject userspace cifs.idmap descriptions", " - smb: client: reject short READ responses in CIFSSMBRead()", " - smb: client: pin DFS superblock in iterator callback", " - smb: client: fix one-byte OOB read in smb2_parse_native_symlink()", " - smb: client: fix file type corruption in cifs_reparse_point_to_fattr()", " - smb: client: fix file type corruption in posix_reparse_to_fattr()", " - smb: client: fix file type corruption in wsl_to_fattr()", " - smb: client: avoid leaking refcount in cifs_queue_oplock_break()", " - smb: client: avoid leaking refcount when cifs_sb_tlink() fails", " - smb: client: fix heap overflow in DACL owner/group rewrite", " - xfs: use the rtgroup extent count to find rtrefcount gaps", " - xfs: truncate quota file correctly when repairing quota file", " - xfs: strengthen the \"is cow staging\" helpers in scrub", " - xfs: snapshot scrub stats when rendering them", " - xfs: snapshot old AGFL before rewriting it", " - xfs: signal inode btree xref error if get_rec returns an error", " - xfs: reset parent pointer args before each dir tree unlink repair", " - xfs: report nonexistent parents as a filesystem corruption", " - xfs: report healthy filesystem events in scrub stats", " - xfs: release alleged child inode on metapath unlink error", " - xfs: preserve owner on in-memory btree creation", " - xfs: make the rtsummary repair fix the file size too", " - xfs: log the tempip after we convert it to extents format", " - xfs: initialise error in xfs_defer_finish_one()", " - xfs: fix xfs_rtrmapbt_mem_cursor for non-rmap filesystems", " - xfs: fix unit conversions in per_binval computation", " - xfs: fix the rtrmap and rtrefcount _maxlevels_ondisk functions", " - xfs: fix short ifork reaping computation in xreap_bmapi_binval", " - xfs: fix rtrmap cross-referencing elision logic", " - xfs: fix rtrefcount btree block counting in scrub", " - xfs: fix replaying dirent removals into the temporary directory", " - xfs: fix reclaimed page accounting in xfs_buf_free", " - xfs: fix parent rec lookup initialization in xrep_metapath_unlink", " - xfs: fix name string recording in slowpath pptr tracepoints", " - xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN", " - xfs: fix bnobt repair space reservation disposal failure", " - xfs: fix backwards skipping logic in xrep_quota_block", " - xfs: fix backwards mergeability logic in refcount scrubber", " - xfs: don't spin forever on zero-length dirents when salvaging them", " - xfs: don't modify file attributes or poke fsnotify for dry runs", " - xfs: don't leak new_bp if xfs_btree_bload_drop_buf fails", " - xfs: don't leak dqacct if rhashtable insertion fails", " - xfs: destroy seen inode bitmap when we fail to add a dirpath", " - xfs: cross-reference the rtgroup superblock extent, not block", " - xfs: count escaped corruption errors in scrub stats", " - xfs: compute dquot checksum after resetting dd_lsn in repair", " - xfs: bail out on bitmap errors in xrep_agfl_fill", " - xfs: advance the findparent inode scan cursor while holding ILOCK", " - xfs: actually recover intended file sizes in xfs_xmi_item_recover_intent", " - xfs: actually check internal-rtdev fields in the superblock", " - hwmon: (sht4x) Add missing locks", " - ksmbd: don't hold ci->m_lock while waiting for a lease break ack", " - crypto: ccp - Fix possible deadlock in SEV init failure path", " - usb: xusbatm: don't rely on id table pointer arithmetic", " - wifi: ath9k_htc: don't store usb_device_id", " - usb: usbtmc: don't store usb_device_id", " - usb: serial: spcp8x5: don't store usb_device_id", " - media: as102: do not rely on id table address comparison", " - net: usb: pegasus: don't rely on id table pointer arithmetic", " - i2c: smbus: reject oversized block transfers in the common path", " - net: appletalk: fix NULL pointer dereference in aarp_send_ddp()", " - media: remove conditional return with no effect", " - media: qcom: iris: fix runtime PM reference leaks", " - scsi: qla2xxx: Null out freed pointers in qla2x00_mem_alloc() error path", " - scsi: qla2xxx: Fix queue teardown NULL dma_free and bitmap locking", " - scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown", " - scsi: qla2xxx: Bound VP index against VP_CTRL IOCB bitmap size", " - scsi: qla2xxx: Fix 64G link speed reporting in get_data_rate", " - scsi: qla2xxx: Skip vport under deletion in report ID acquisition", " - scsi: qla2xxx: Use ring-slot helpers in __qla2x00_alloc_iocbs", " - scsi: qla2xxx: Use memset_io() to clear QLAFX00 request ring slot", " - scsi: qla2xxx: Fix soft lockup polling continuation IOCB signature", " - scsi: qla2xxx: Clamp max_npiv_vports to VP_CTRL bitmap capacity", " - scsi: qla2xxx: Unlink NVMe unsol ctx before freeing on LS reject error", " - scsi: qla2xxx: Serialize NVMe unsol ctx list with a per-fcport lock", " - scsi: qla2xxx: Validate BSG request_len before reading vendor_cmd[]", " - f2fs: accurately adjust free_sections during free_segment_range", " - Revert: \"f2fs: check in-memory block bitmap\"", " - drm/amdgpu: add a helper to calculate ring distance", " - drm/amdgpu: reorder IB schedule sequence", " - drm/amdgpu: Make amdgpu_vm_flush() non-failing in submission path", " - drm/amdgpu: plumb timedout fence through to force completion", " - i2c: designware: Global register definitions", " - drm/pagemap: dma-unmap pages before handling migration errors", " - ipmr: account multicast table and route memory", " - x86/mm/pat: Convert split_large_page() to use ptdescs", " - x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()", " - x86/mm/pat: Acquire init_mm read lock on attribute changes to avoid UAF", " - x86/mm/pat: Allocate split page tables as kernel page tables", " - bootconfig: Fix integer overflow in initrd size check", " - genetlink: pin family module during policy dump", " - io_uring/rw: end write accounting from ->ki_complete", " - drm/amd/display: Rebuild InfoFrames on output color space changes", " - drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches", " - drm/amd/display: Propagate HDMI RGB quantization selectability", " - drm/amd/display: Honor Broadcast RGB for BT.2020 RGB output", " - drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work()", " - xfs: initialise args->total for parent pointer updates", " - tracing: Set the trace clock before registering the histogram trigger", " - tracing: Take the reference before publishing the named histogram", " trigger", " - tracing: Undo the registration when enabling the histogram trigger fails", " - EDAC/altera: Use ECC manager compatible to select A10/S10 IRQ layout", " - EDAC/altera: Use parent device for devres in altr_portb_setup()", " - netfilter: cttimeout: prevent UAF during module unload", " - exit: hold a reference to thread_pid across proc_flush_pid", " - net: macb: Replace open-coded implementation with napi_schedule()", " - net: macb: Use netif_napi_add_tx() instead of netif_napi_add() for TX", " NAPI", " - net: macb: unify device pointer naming convention", " - net: macb: initialize PTP state before registering clock", " - erofs: add sysfs feature entry for xattr prefixes", " - idpf: disable DIM work before freeing q_vectors", " - landlock: Use mem_is_zero() in is_layer_masks_allowed()", " - landlock: Fix use-after-free of the source's parent directory", " - mptcp: pm: reset retrans_time when ADD_ADDR entry is reused", " - bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset()", " - mptcp: do not reschedule the RTX timer for fallback sockets", " - mptcp: prevent race between disconnect() and rtx", " - smb: client: refactor ACL setting control flow in id_mode_to_cifs_acl()", " - smb/client: fix security flag calculation when setting security", " descriptors", " - smb: client: fail DACL rewrite when the new DACL exceeds 64K", " - misc: amd-sbi: Add null check for devm_kasprintf()", " - x86/mm: Fix and document DEBUG_PAGEALLOC", " - mptcp: move the stale logic out of retrans scheduler", " - mptcp: avoid unneeded actions on subflow reset", " - mptcp: close race between scheduler and state change", " - mptcp: fix bad accounting in __mptcp_subflow_push_pending()", " - btrfs: abort transaction before releasing tree_log_mutex on commit", " failure", " - ksmbd: fix maximum allowed access checks", " - smb/server: fix tree connection leak in smb2_tree_connect()", " - drm/tegra: dsi: Re-add clear enable register if DSI was powered by", " bootloader", " - drm/connector: Introduce drm_output_color_format enum", " - drm/display: hdmi: Use drm_output_color_format instead of", " hdmi_colorspace", " - drm/display: hdmi-state-helper: Try subsampling in mode_valid", " - cgroup/cpuset: Avoid unnecessary cpus & mems update in", " cpuset_hotplug_update_tasks()", " - ARM: imx: avic: Fix OF node reference leaks", " - ARM: OMAP2+: Fix OF node reference leaks in omap_hwmod", " - firmware: imx: sm-misc: Add NULL check for kmalloc in syslog_show", " - sched/core: Fix inter-class wakeup_preempt()", " - perf/x86/intel/uncore: Fix PCI PMU cleanup on setup failure", " - perf/x86/intel/uncore: Fix refcnt and other cleanups", " - perf/x86/intel/uncore: Let init_box() callback report failures", " - perf/x86/intel/uncore: Factor out box setup code", " - perf/x86/intel/uncore: Introduce PMU flags and broken state", " - perf/x86/intel: Keep cap_user_rdpmc in sync with RDPMC user-disable", " state", " - drm/panthor: Split panthor_vm_prepare_map_op_ctx() to prepare for", " reclaim", " - drm/panthor: Pass vm_bind_op to vm_prepare_map_op_ctx", " - workqueue: only show running workers in stall diagnostics", " - wifi: ath12k: fix TLV32 length mask", " - perf util: Sort includes and add missed explicit dependencies", " - perf evlist: Add reference count", " - perf evsel: Add reference count", " - perf evlist: Add reference count checking", " - perf parse-events: Restrict core PMU bypass to --cputype option", " - perf tests: Fix Python JIT dump profiling test failure", " - wifi: rtw89: fw: correct preload field of w2 in", " rtw89_fw_h2c_default_cmac_tbl_be()", " - wifi: rtw89: fw: fix link ID filling for LPS MLO common info", " - uprobes/x86: Remove struct uprobe_trampoline object", " - uprobes/x86: Do not leak trampoline vma mapping on optimization failure", " - uprobes/x86: Allow to copy uprobe trampolines on fork", " - perf cs-etm: Filter synthesized branch samples", " - libbpf: Add uprobe syscall feature detection", " - libbpf: Add support to detect nop,nop5 instructions combo for usdt probe", " - libbpf: Change has_nop_combo to work on top of nop10", " - perf test amd ibs: avoid using executable heap", " - perf vendor events amd: Update Zen 6 core events", " - hwrng: omap - Fix probe error path cleanup", " - fuse: move \"epoch\" from dentry.d_time to fuse_dentry.epoch", " - arm64: dts: qcom: monaco: fix wrong connection for the replicator", " - arm64: dts: qcom: sc8280xp: sort reserved memory regions", " - PCI: qcom: Skip PERST# GPIOs provided by downstream PCIe devices", " - perf record: fix poll storm when monitored threads exit", " - bpf: Introduce jit_required flag and remove bpf_prog_has_kfunc_call()", " - arm64: dts: mediatek: tungsten-smarc: Remove unnecessary cells", " - remoteproc: qcom_wcnss: Fix handling the lack of PD regulators in v3", " - usb: typec: tcpm: fix EPR AVS APDO maximum voltage decoding", " - usb: chipidea: imx: fix missing ret assignment for dev_err_probe", " - perf record: Fix teardown hang on system-wide multi-threaded sessions", " - clk: spacemit: k3: fix parent clock of UFS aclk", " - tools/sched_ext: scx_flatcg: Fix uninitialized stats on allocation", " failure", " - arm64: dts: renesas: rzt2h-n2h-evk: Remove unused MII/GMII pins", " - wifi: ath12k: fix MLO peer delete race", " - wifi: ath12k: fix rx_mpdu_start layout for QCC2072", " - firmware: arm_scmi: Clear SystemPower flag on create failure", " - firmware: arm_scmi: Fix OF node reference handling", " - PCI: keystone: Fix OF node reference leak in init", " - media: ti: vpe: Select V4L2_FWNODE for VIP", " - drm/amd/display: remove duplicate link_dp_panel_replay.h include", " - arm64: dts: qcom: milos: Add reset for sdhc_2", " - perf sched: Add missing perf_session__delete()", " - perf sched: Fix memory leaks in perf sched stats report", " - perf sched: Free subcommand string after perf sched stats", " - drm/solomon: remove unneeded variables in blit functions", " - perf stat: Fix duplicate output with --for-each-cgroup", " - gpu: host1x: Avoid double device_add when clients already present", " - drm/msm/a6xx: Fix IRQ storm during msm_recovery test", " - bpf: Sync tail_call_reachable with callee state on entry", " - crypto: aspeed - Propagate platform_get_irq() errors", " - tlclk: if sscanf() fails, fall back to 0, not random value", " - gpib: use 'static inline' instead of 'extern inline'", " - vfio: selftests: Add helper to set/override a vf_token", " - vfio: selftests: Avoid VLAs", " - soc: ti: knav_qmss_queue: Implement resource cleanup in remove()", " - soc: ti: knav_qmss: Remove debugfs file on teardown", " - drm/v3d: Drop unused drm_encoder.h include from v3d_drv.h", " - drm/v3d: Extract v3d_job_add_syncobjs() helper", " - drm/v3d: Migrate BO reservation locking to DRM exec", " - drm/v3d: Introduce struct v3d_submit and convert CL/TFU/CSD ioctls", " - drm/v3d: Make v3d_get_cpu_indirect_csd_params() a pure parser", " - drm/v3d: Convert submit helpers to operate on struct v3d_submit", " - bpf: Disallow interpreter fallback for BPF_ADDR_PERCPU insn", " - samples: rust: debugfs: fix excessive stack use", " - selftests/bpf: Fix make install target", " - wifi: ath12k: advertise ieee_link_id in vdev start MLO params", " - wifi: ath12k: fix ML-STA authentication timeout on QCC2072", " - wifi: ath12k: fix survey indexing across bands", " - riscv: dts: spacemit: set console baud rate on K3 Pico-ITX board", " - gpu: nova-core: correct RISC-V HALTED field", " - clk: sunxi-ng: mux: fix determine helper rate propagation", " - ASoC: spacemit: rename clock inputs to match binding", " - perf evsel: Add bounds checking to trace point raw data accessors", " - perf trace: Correct default cpumask formatting to hexadecimal", " - selftests/bpf: Fix missing allocation null checks in test_progs.c", " - pinctrl: Kconfig: drop unneeded dependencies on OF_GPIO", " - pinctrl: PINCTRL_STMFX should depend on CONFIG_OF", " - pinctrl: fix unmet dependencies from missing GPIOLIB", " - liveupdate: reject nonzero reserved value for SESSION_FINISH", " - liveupdate: Reference count outgoing FLB data", " - scsi: ufs: rpmb: Validate request frame length before parsing", " - ACPI: bus: Avoid confusing complaints regarding missing _OSC features", " - PCI/pwrctrl: tc9563: Fix parsing the integrated Ethernet MAC Endpoint", " node", " - PCI/pwrctrl: tc9563: Power off only the external ports in", " tc9563_pwrctrl_disable_port()", " - gpu: nova-core: build SetRegistry entries dynamically", " - gpu: nova-core: fix packed registry table size", " - perf ui hists: In report UI ensure thread is set with reference counting", " - remoteproc: qcom: pas: Add late attach support for subsystems", " - remoteproc: qcom: q6v5: Request shutdown if crash is triggered host-side", " - PCI: Make pci_match_one_device() match on ID instead of device", " - PCI: Fix dyn_id add TOCTOU", " - clk: rockchip: Fractional PLL coefficient on RK3588/RK3576 is two's", " complement", " - clk: spacemit: k3: fix missing /2 factor in i2s sysclk dividers", " - nvme-pci: return error when parsing a quirk string fails", " - media: qcom: iris: Remove duplicate HFI_PROP_OPB_ENABLE entry", " - s390/vdso: Pass --eh-frame-hdr to the linker", " - regulator: tps65185: handle gpiod_get_value_cansleep() error returns", " - md/raid5: fix lockless max_nr_stripes reads", " - md/raid1: restrict atomic write limits and handle runtime constraints", " - PCI: dwc: ep: Clear MSI iATU mapping in dw_pcie_ep_cleanup()", " - soc: qcom: pmic_glink_altmode: Define the TBT extradata properly", " - arm64: dts: qcom: talos: Fix cpu6 1094.4MHz OPP frequency typo", " - arm64: dts: qcom: kaanapali: Fix the PCIe iommu-map entries", " - arm64: dts: qcom: monaco: Fix the PCIe iommu-map entries", " - arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Fix the PCIe iommu-map", " entries", " - platform/chrome: lightbar: Limit payload to max packet size", " - clk: qcom: dispcc-qcm2290: Move to the latest common qcom_cc_probe()", " model", " - clk: qcom: dispcc-qcm2290: Enable runtime PM support", " - clk: qcom: qcm2290: Set POLL_CFG_GDSCR flag for DISPCC and GPUCC GDSCs", " - clk: qcom: qcm2290: Add RETAIN_FF_ENABLE flag for DISPCC and GPUCC GDSCs", " - clk: qcom: qcm2290: Update DISPCC and GPUCC GDSC *wait_val values", " - clk: qcom: gpucc-qcm2290: Drop pm_clk handling", " - clk: qcom: gpucc-qcm2290: Move to the latest common qcom_cc_probe()", " model", " - clk: qcom: gpucc-qcm2290: Keep the critical clocks always-on from probe", " - iomap: avoid memset iomap when iter is done", " - wifi: mt76: mt792x: add common USB transport reset helpers", " - wifi: mt76: mt7921u: escalate broken USB transport to device reset", " - wifi: mt76: mt792x: stop USB register access after bus hang", " - wifi: mt76: connac: add NAN connection type", " - wifi: mt76: add init_wiphy callback", " - wifi: mt76: fix 4th chain ACK RSSI bitmask in sta_poll", " - wifi: mt76: fix HE DCM max-RU capability encoding", " - wifi: mt76: decode the full VHT Rx STBC capability field", " - wifi: mt76: fix ER-SU 106-tone RU check in RX rate decode", " - wifi: mt76: report data NSS for STBC frames in RX rate decode", " - drm/msm/dpu: Fix DMA SSPP REC block offsets on DPU v13", " - ARM: tegra: Fix OF node reference leaks in IRQ init", " - arm64: tegra: Fix CMDQV interrupt type on Tegra264", " - perf unwind-libdw: Fix unwinding of multi-threaded processes", " - perf libdw: Fix outer-frame name resolution and spurious \"(inlined)\" tag", " - wifi: mt76: add offchannel check to mt76_roc_complete", " - wifi: mt76: check chanctx before restoring channel after ROC", " - wifi: mt76: optimize ROC for same-channel case", " - wifi: mt76: send nullfunc PS frames on offchannel transitions", " - wifi: mt76: set MT76_SCANNING when starting a hw scan", " - wifi: mt76: mt7996: do not leave state behind after a failed WED attach", " - wifi: ath12k: fix encrypted EAPOL TX in encap offload mode", " - objtool/klp: Fix module name normalization for paths with dots", " - objtool/klp: Normalize Module.symvers paths to module names", " - objtool/klp: Fix false module dependencies caused by dead relocs", " - objtool/klp: Extricate checksum calculation from validate_branch()", " - objtool/klp: Create empty checksum sections for function-less object", " files", " - objtool/klp: Fix --debug-checksum for duplicate symbol names", " - objtool/klp: Add \"objtool klp checksum\" subcommand", " - livepatch/klp-build: support patches that add/remove files", " - livepatch/klp-build: switch to GNU patch and recountdiff", " - livepatch/klp-build: report patch validation fuzz", " - klp-build: Suppress excessive fuzz output by default", " - modpost: Add __llvm_covfun and __llvm_covmap to section_white_list", " - objtool/klp: Remove \"objtool --checksum\"", " - objtool: Grow __cfi_* prefix symbols for all CFI+CALL_PADDING", " - [Config] Remove PREFIX_SYMBOLS from configs.", " - objtool/klp: Add .klp.symid for sympos disambiguation", " - klp-build: Print \"objtool klp diff\" command in verbose mode", " - klp-build: Use \"objtool klp checksum\" subcommand", " - objtool/klp: Fix symbol resolution for duplicate data symbols", " - powerpc/xive: make xive IPI allocation NULL-safe", " - powerpc/xive: add error return value to xive_smp_probe()", " - powerpc/xive: propagate IPI init errors to prevent use-after-free", " - PCI: dwc: ep: Fix unmap potentially unmapping the wrong iATU", " - HID: asus: fix a off-by-one in mcu_parse_version_string() validation", " - block/blk-iolatency: account per-cpu latency stats over possible CPUs", " - ocfs2: validate inline xattr header before ibody lookups", " - ocfs2: do not use make_bad_inode() in ocfs2_read_inode_block_full()", " - ublk: clear auto buf reg before updating io->buf in batch commit", " - ALSA: hda/realtek: ALC269 fixup for Yoga/Legion Mic noise", " - PCI/sysfs: Add static PCI resource attribute macros", " - selftests/mm: fix mmap() return value check in run_migration_benchmark", " - selftests/mm: fix memleak in migration benchmark", " - arm64: dts: qcom: sa8540p: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: sdm845: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: sdm850: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: sm8150: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: sm8250: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: sm8350: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: sm8450: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: sm8550: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: qcm6490: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: qcs6490: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: sc7180: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: sc7280: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: sc8180x: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: hamoa: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: purwa: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: sm8650: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: sm8750: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: lemans: Fix swapped USB QMP PHY vdda-phy/vdda-pll", " supplies", " - arm64: dts: qcom: sa8155p-adp: Fix swapped USB and UFS QMP PHY vdda-", " phy/vdda-pll supplies", " - perf header: Use write lock when translating BPF prog info pointers", " - ocfs2/heartbeat: fix slot mapping rollback leaks on error paths", " - bpf: Factor callchain_store function from __bpf_get_stack", " - bpf: Factor callchain_finalize function from __bpf_get_stack", " - bpf: Remove trace_in argument from __bpf_get_stack", " - perf c2c: Fix error masking, OOM, and unchecked caller errors in", " hpp_list__parse()", " - perf c2c: Clean up registered formats on c2c_hists__init() and", " c2c_hists__reinit() failure", " - drm/sun4i: Fix V3s YUV scanline size", " - drm/sun4i: vi scaler: Restore opaque alpha in video modes", " - drm/sun4i: tcon-top: Keep mixer routes distinct", " - drm/sun4i: Drop node references while building component list", " - soundwire: cadence_master: add BRA_NumBytes[8] support", " - tools: Ensure tools copy of linux/filter.h exports the UAPI", " - drm/gfx12: Program DB_RING_CONTROL", " - drm/amdgpu: read TRUNCATE_COORD_MODE on gfx12", " - ALSA: hda: cix-ipbloq: Avoid build with 32bit archs", " - PCI: cadence: Fix host/endpoint dependencies for cadence-plat driver", " - selftests/mm: unpoison pages in memory-failure teardown", " - ext4: teach ext4_meta_trans_blocks() about number of allocated extents", " - ext4: fix transaction overflow during writeback", " - coresight: etm4x: Set active path on target CPU", " - ACPI: PCI: Avoid misleading _OSC messages for non-PCIe host bridges", " without _OSC", " - scsi: sd: Enable sector size > PAGE_SIZE in SCSI sd driver", " - btrfs: make sure EXTENT_BUFFER_READING is cleared under refs_lock", " - perf sched: Suppress latency table output when trace samples are missing", " - perf header: Add utility to convert feature number to a string", " - perf header: Refactor pipe mode end marker handling", " - perf sched: Handle missing trace samples in pipe mode", " - perf script: Fix metric_evlist leak in script_find_metrics", " - perf tools: Fix sb_evlist leaks in top and record", " - perf python: Fix memory leak in pyrf_evlist__get_pollfd", " - perf python: Validate attribute setters in pyrf_evsel", " - perf python: Fix count_values memory leak in pyrf_evsel__read", " - netfilter: nft_ct: support expectation creation for natted flows", " - netfilter: nf_conntrack_helper: add refcounting from datapath", " - nfsd: add protocol support for CB_NOTIFY", " - lockd: Regenerate NLMv4 XDR code", " - xdrgen: Emit a blank line ahead of enum declarations", " - xdrgen: Add XDR width macros for short integer types", " - selftests/cgroup: Avoid awk -e in cpuset tests", " - pinctrl: rockchip: Decode drive strength in the get function", " - selftests: drv-net: Test queue stall upon reconfig", " - selftests: drv-net: so_txtime: remember to deploy the binaries", " - selftests: drv-net: so_txtime: only send test traffic to sch_etf", " - phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc", " - phy: rockchip: samsung-hdptx: Prevent divide-by-zero when computing clk", " rate", " - phy: rockchip: samsung-hdptx: Guard against clk rate integer underflow", " - phy: rockchip: samsung-hdptx: Fix rate recalculation for 3.2GHz FRL", " - phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes", " - objtool/klp: Fix vmlinux .klp.symid link error for .no_trim_symbol", " symbols", " - objtool/klp: Fix size of empty special section entries", " - objtool/klp: Ignore replacement offset of empty x86 alternatives", " - objtool/klp: Fix cross-module klp relocation section naming", " - objtool/klp: Don't match local symbols against exports", " - objtool/klp: Fix relocations for EXPORT_SYMBOL_FOR_MODULES() symbols", " - iomap: iomap_bio_read_folio_range_sync is missing a call to bio_uninit", " - mfd: cs42l43: Fix regmap defaults ordering", " - backlight: aw99706: Validate all DT property values consistently", " - backlight: ktd2801: Fix unmet dependency on GPIOLIB", " - bpf, riscv: Clear fetch destination on faulting arena atomic", " - bpf, x86: Clear fetch destination on faulting arena atomic", " - bpf: Derive the atomic load register in one place", " - bpf, arm64: Clear fetch destination on faulting arena atomic", " - ASoC: spacemit: advertise only DMA-backed DAI streams", " - objtool/klp: Fix vmlinux .klp.symid link error for .exitcall.exit", " symbols", " - power: supply: bd71815: Fix temperature reading", " - power: supply: bd71828: Fix current direction", " - power: supply: bd71828: Drop duplicate power-supply property", " - power: supply: bd71828: Do not hide errors", " - selftests: drv-net: so_txtime: fix qdisc replace with handle", " - sched/isolation: Defer freeing of cpumask memblock memory to initcall", " - HID: tmff: Use 64-bit arithmetic for force feedback scaling", " - bpf: Fix arm64 KASAN false positive after bpf_throw", " - ACPI: bus: Introduce acpi_bus_get_primary_device()", " - ACPI: platform: Use acpi_bus_get_primary_device()", " - ACPI: scan: Use acpi_bus_get_primary_device()", " - selftests/bpf: Fix selftest build after filter.h update", " - sched_ext: Drop unlocked scx_rq_clock_invalidate() from", " scx_root_disable()", " - smb/server: fix memory leak in ksmbd_vfs_set_durable_owner()", " - objtool/klp: Fix vmlinux klp relocations for EXPORT_SYMBOL_FOR_MODULES()", " - ksmbd: validate SMB2 write offsets", " - ksmbd: fix encrypted request lookup on bound channels", " - ksmbd: add procfs monitoring for active shares", " - smb/server: warn if ksmbd_proc_create() fails", " - smb/server: update session counter under sessions table lock", " - smb/server: fix session counter on session removal", " - selftests/bpf: Retry stat generation in cgroup_iter_memcg", " - NFS: Fix delayed delegation return list handling", " - regulator: tps65185: wait for the IC to wake before the first I2C access", " - can: m_can: Use of_property_present() for wakeup-source", " - ionic: add missing dma_rmb() after the completion publish check", " - netfilter: ctnetlink: do not expose expectation DEAD flag", " - i3c: mipi-i3c-hci: Fix missing STAT_IBI_STATUS_THLD in PIO mode", " - smb: client: set replay flag on the read send-error retry path", " - irqchip/gic-v5: Disable IRSes on probe failures", " - irqchip/gic-v5: Release IRS iomem region on driver init failure", " - irqchip/gic-v5: Defer default SPI and LPI IAFFID programming", " - drm/xe: don't WARN on kernel job timeout when device already wedged", " - powercap: intel_rapl: Sign-extend the PMU delta on counter wraparound", " - ASoC: fix unmet dependencies on PPC_BESTCOMM and SND_SOC_AC97_BUS", " - net: hibmcge: fix page_pool DMA direction mismatch", " - net/sched: sch_cake: fix autorate reconfiguration throttling", " - fuse: use release/acquire for fch->initialized", " - f2fs: use adjusted write range after f2fs_write_checks()", " - Bluetooth: hci_sync: add conditional locking annotations", " - net: enetc: extract common helpers for MAC promiscuous mode setting", " - net: enetc: extract common helpers for MAC hash filter configuration", " - net: enetc: remove invalid code from enetc4_pl_mac_link_up()", " - net: enetc: restore RX ring congestion mode for ENETC v4", " - smb/client: use stack-allocated smb2_file_all_info in", " smb3_query_mf_symlink()", " - smb/client: pass cifs_open_info_data to SMB2_open()", " - smb/client: preserve open info type across compound queries", " - selftests/mm: fix read_file() return value check", " - of/irq: Fix device node refcount leak in of_irq_get_affinity()", " - net: phy: air_en8811h: move LED GPIO configuration to config_init", " - net: stmmac: selftests: Don't test flow control for small rx fifos", " - Revert \"esp: do not unref managed frag pages in esp_ssg_unref()\"", " - perf hists browser: Increase MAX_OPTIONS to prevent stack buffer", " overflow", " - perf ui hists: Fix dso_filter reference leak and exit zoom cleanup", " - perf python: Add missed explicit dependencies", " - EDAC/igen6: Fix Raptor Lake-P logged error address", " - nvme: add context annotations for nvme_subsystem::lock", " - nvme: set ns->head in nvme_alloc_ns_head", " - nvme: fix racy access to FDP placement id array", " - selftests/cgroup: set the test plan after the setup checks", " - bpf: Fix BPF_F_CPU validation for sparse CPU IDs", " - bpf: Fix percpu map update indexing with sparse CPU IDs", " - printk: Don't WARN on kthread_run failure.", " - selftests/cgroup: Drop invalid boot isolation comparison", " - cgroup/cpuset: Preserve boot-isolated CPUs on partition release", " - accel: ethosu: Don't read the U65 rounding mode as a storage mode", " - bpf: check_cond_jmp_op(): properly infer if register is null", " - net: stmmac: helpers for filling tx_q->tx_skbuff_dma", " - net: stmmac: add helper to get hardware transmit descriptor", " - net: stmmac: fix dma mapping leak in stmmac_tso_xmit()", " - scsi: ufs: core: Introduce a new ufshcd vops negotiate_pwr_mode()", " - smb/client: fix stale page cache in insert/collapse range", " - smb/client: invalidate fscache for fallocate range operations", " - netfs: Fix readahead synchronisation issues by loading all folios", " upfront", " - netfs: Mark folios with COPY_TO_CACHE whilst issuing subreqs", " - netfs: Fix read progress reporting", " - drm/i915/cdclk: Fix dg2_power_well_count() return type", " - ovl: return EINVAL instead of EIO in case of mismatched user_ns", " - smb/server: cancel async requests when closing connection", " - ksmbd: safely drain sessions during logoff", " - ksmbd: fix listener task lifetime on netdev events", " - s390/pai: Reduce excessive debug feature size", " - ASoC: ab8500: Skip missing DMIC GPIOs on AB8505", " - drm/pagemap: Prevent double migration of device pages", " - drm/pagemap: Reset migration page count on eviction retry", " - rust: samples: add missing newlines in rust_print_main", " - klp-build: Fix wrong index in funcs cleanup error path", " - objtool/klp: Fix checksums for constant pool references", " - ipv6: mcast: fix delay calculation in igmp6_join_group()", " - ipv6: mcast: use rcu_assign_pointer() for __rcu list updates", " - ipv6: mcast: use jiffies_delta_to_clock_t() in igmp6_mc_seq_show()", " - net: bonding: annotate lockless writes with WRITE_ONCE()", " - ASoC: cs35l56: Request IRQ in cs35l56_common_probe()", " - ASoC: cs35l56: Fix probe deadlock waiting for SoundWire enumeration", " - sched/core: Skip rq->avg_idle update without a valid idle_stamp", " - ksmbd: fix sparc build with atomic work state", " - bpf: backtrack_insn(): Handle ld_{abs,ind} subprog exit edge", " - bpf: backtracking shouldn't clear outer frame R1-R5 for callbacks", " - net: macb: exclude software FCS from TX byte statistics", " - powerpc: Don't drop _TIF_RESTOREALL on syscall restart", " - bpf: Reject key-less BTF for hash maps", " - bpf: Mark syscall helpers as sleepable", " - ring-buffer: Add checking nr_subbufs to persistent ring buffer", " validation", " - nvme: print namespace IDs as unsigned 32bit value", " - nvmet: print namespace IDs as unsigned 32bit value", " - bpf: zero extend the result of an arena 32-bit cmpxchg", " - bpf: don't rewrite bpf_fastcall patterns entered by a jump", " - bpf: Don't infer non-NULL from a pointer with an unbounded offset", " - bpf: detect non null pointer with register operand in JEQ/JNE.", " - bpf: Mark the zero register precise for a register-form NULL check", " - bpf: Mark NULL kptr stores precise", " - bpf: Preserve inner map identity in callback frames", " - ring-buffer: Remove ring_buffer_per_cpu::mapped", " - tracing: Fix subbuf resize races with trace_pipe_raw readers", " - ring-buffer: Cap static ring buffer nr_pages", " - tracing: Fix comment in tracing_buffers_splice_read()", " - bpf: mark a NULL call argument precise", " - bpf: propagate mark_chain_precision() errors out of loop_flag_is_zero()", " - net/mlx5e: Fix reporting support for all RS FEC variants", " - erofs: delimit inode_share cache key components", " - iommu/riscv: Serialize command queue publishing", " - iommu/riscv: Avoid waiting on failed command enqueue", " - iommu/amd: Fix ineffective error check in nested domain allocation", " - regulator: pf1550: fix which regulator is notified", " - virtio_ring: fix stale descriptor flags after a failed packed add", " - vduse: validate virtqueue alignment", " - vhost: invalidate vring access on IOTLB transitions", " - vduse: return compat ioctl results directly", " - net: macb: zero the link settings taprio reads back", " - net: macb: reject an unknown link speed in the taprio setup", " - Bluetooth: Properly disable remote wakeup for MT7922/MT7925 on Ryzen", " platform", " - nstree: check listing permission before taking a namespace reference", " - drm/xe: Guard page-fault worker with runtime PM check", " - net: phylink: initialise link_state before a forced major config", " - drm/i915/dp: Gate UHBR SST SDP splitting on sink capability", " - block: Fix start and length check added to iov_iter_extract_bvecs()", " - ublk: clear force_abort in ublk_queue_reset_io_flags()", " - tracing: Fix ring_buffer_read_page_size() kernel-doc", " - x86/MCE/AMD: Fix inverted interrupt enablement during storm handling", " - ftrace: Use rcu_assign_pointer() for tmp_ops filter hash", " - tracing: Take trace_array reference when opening a tracer options file", " - tracing: Don't dereference trace_event_file in deferred trigger free", " - rust: num: seal Integer", " - rust: pin-init: use irrefutable pattern for `stack_pin_init`", " - riscv: hwprobe: initialize pair->value in hwprobe_one_pair()", " - drm/amdgpu: statically assign gart windows to ttm entities", " - drm/amdgpu: skip the VMID 0 flush for VRAM", " - accel: ethosu: Fix ethosu_job_open() return value", " - accel: ethosu: Drop IRQF_SHARED flag", " - accel: ethosu: Ensure cmd stream ends with a stop op", " - accel: ethosu: Ensure SRAM size is 0 on mapping failure", " - accel: ethosu: Validate SRAM size on submit", " - accel: ethosu: Ensure SRAM region size matches job", " - ata: pata_legacy: remove documentation for removed module parameters", " - drm/amd/pm: fix gpu metrics energy accumulator for smu 13.0.0/13.0.7", " - drm/amd/display: Exit IPS before connector detection on resume", " - selftests: ublk: install test_common.sh and trace/ scripts", " - media: rkvdec: bound HEVC tile loops and PPS id to the array capacity", " - selftests: mptcp: lib: dump nstat for the right test", " - selftests: mptcp: lib: get counters for the right test", " - smb: client: reject out-of-bounds DataOffset in CIFSSMBRead()", " - cifs: validate full SID length in security descriptors", " - smb: client: honor forceuid/forcegid when mapping SIDs to uid/gid", " - smb: client: fix uid/gid override in getattr with posix extensions", " - smb: client: fix cifsFileInfo reference leak in deferred close", " - smb: client: avoid using uninitialized SIDs in cifs_posix_to_fattr()", " - xfs: lock the healthmon when inserting unmount event", " - xfs: fix under-reservation of blocks when repairing sf directories", " - xfs: fix media verification ioctl for internal rt volumes", " - xfs: don't stash removename operations with unknown ftype", " - xfs: check healthmon outbuffer space correctly", " - xfs: bump lost_prev_errors if we lose even the healthmon lost event", " - xfs: always set xfs_healthmon::first_event when inserting at front of", " list", " - ASoC: cs35l56: Fix race between kexec and snd_soc_register_component()", " - hwmon: (asus_rog_ryujin) Add per-device configuration", " - hwmon: (asus_rog_ryujin) Validate HID report lengths", " - hwmon: (asus_rog_ryujin) Synchronize HID command and report handling", " - f2fs: fix to shrink gc_lock coverage in f2fs_gc_range()", " - f2fs: fix to reset all pinned status during fggc", " - drm/i915/cdclk: Avoid spurious cdclk sanitization on PTL+", " - accel/amdxdna: Disable device buffer exporting", " - drm/xe/i2c: Assert/Deassert I2C IRQ", " - drm/xe/i2c: Fix the interrupt handling", " - s390/pai: Use PAI PMU index as parameter replacing event", " - s390/pai: Move locking to event init and delete", " - s390/pai: Support CPU hotplug for PMU PAI", " - Upstream stable to v6.18.52, v6.18.53, v7.2.6, v7.2.7", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90061", " - netfilter: nf_tables: skip double clone set expressions on element", " insert", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90079", " - octeontx2-af: fix cn20k mailbox lifetime on repeated rvu_mbox_init()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90082", " - net: mana: Cap MSI-X vectors to the device MSI-X table size", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90087", " - Bluetooth: do not leak an hci_conn when a second LE connect is rejected", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90093", " - Bluetooth: L2CAP: access chan->conn safely in get/setsockopt", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90095", " - fuse: Fix the condition to enable over-io-uring", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90099", " - net/sched: account classifier filter allocations to memcg", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90104", " - NFSv4.1: zero referring call lists before decoding", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90105", " - vxlan: fix reading neigh ha", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90106", " - net: bridge: arp/nd proxy: fix reading neigh ha", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90111", " - ip6mr: do not clone dst in ip6mr_cache_report()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90120", " - irqchip/gic-v5: Check get_logical_index() return value in MADT IAFFID", " parsing", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90121", " - irqchip/gic-v5: Clear per-CPU IRS data on teardown", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90142", " - virtio_net: Fix resize of the RX ring", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90154", " - ksmbd: scope session state changes to bound connections", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90156", " - ksmbd: safely discard unregistered deferred locks", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90163", " - smb/server: call ksmbd_proc_cleanup() on module init failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90164", " - smb/server: abort initialization when proc setup fails", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90174", " - ksmbd: fix slab-out-of-bounds read in ksmbd_alloc_user()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90177", " - bpf: Check pointer type for all atomic RMW paths", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90182", " - blk-iocost: clear delay state when freeing policy data", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90183", " - blk-iolatency: clear delay state when freeing policy data", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90206", " - nvmet: fix max_qid race between configfs and controller allocation", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90208", " - clocksource/drivers/samsung_pwm: Switch to raw_spinlock_t type", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90211", " - bpf, s390: Clear fetch destination on faulting arena atomic", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90212", " - arm64/efi: Avoid voluntary preemption with efi_mm installed", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90217", " - bpf: Compare iterator types during state pruning", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90231", " - apparmor: fix unconfined user namespace restriction forced stack", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90234", " - NFS: Return a delegation the client fails to record", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90237", " - netfilter: nft_ct: move custom expectation support to helper", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90242", " - iommu/vt-d: Fix iopf_refcount leak on RID domain replacement", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90246", " - apparmor: fix integer overflow in verify_tags() bounds check", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90256", " - Bluetooth: L2CAP: use proto_lock for l2cap_data to fix l2cap_disconn_ind", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90261", " - btrfs: zoned: flush active metadata block group at btree_writepages()", " start", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90263", " - btrfs: check if root is readonly when setting posix acl", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90267", " - scsi: sd: Fix special_vec mempool leak when scsi_alloc_sgtables() fails", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90270", " - arm_mpam: Disable driver unbind to avoid UAF", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90271", " - arm_mpam: Fix a NULL pointer dereference on unbinding after an error", " interrupt", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90273", " - coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf", " enable", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90288", " - phy: renesas: rcar-gen2: Fix double of_node_put on phy creation failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90289", " - drm/amd/display: Resize MST HDCP per-connector arrays to 32", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90300", " - bpf: Clear buf on error in __bpf_get_task_stack", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90301", " - ocfs2: o2hb: quiesce negotiate handlers and timeout work", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90310", " - xen/xenbus: check otherend_id only after it has been initialized", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90311", " - thermal: hwmon: Remove hwmon class device along with its parent", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90315", " - PCI/sysfs: Add lockdown checks to legacy I/O and memory handlers", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90320", " - ocfs2: validate external xattr entries when reading metadata", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90321", " - ocfs2: validate inline xattrs during inode block validation", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90323", " - ublk: validate auto buf reg before taking uring_cmd", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90330", " - HID: logitech-hidpp: Fix FF device cleanup on init failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90331", " - HID: asus: refactor the two workqueues and init sequence", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90332", " - PCI: dwc: ep: Flush cached MSI write before unmapping the iATU", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90335", " - tty: skip cdev_del() when no cdev is registered", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90336", " - serial: core: clear freed pointers on uart_register_driver() failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90337", " - serial: core: do fallible allocations before the console can be", " registered", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90342", " - bpf: Fix mmap_lock deadlock on arena lock failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90345", " - wifi: brcmfmac: fix P2P action frame handling without device vif", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90346", " - wifi: nl80211: clean up color-change beacon data on errors", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90347", " - arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90355", " - wifi: mt76: mt7996: clear stale link state on full reset", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90359", " - bpf: Reject >8 byte return values on return-reading trampoline paths", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90365", " - wifi: mt76: cancel reset and rc work on device unregister", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90369", " - wifi: mt76: fix out-of-bounds access in mmio copy helpers", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90380", " - wifi: mt76: mt792x: fix use-after-free in mt76_rx_poll_complete", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90381", " - wifi: mt76: fix handling channel context with different bands in", " mt76_switch_vif_chanctx()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90384", " - iomap: release the folio batch on iomap callback failures", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90401", " - md: remove REQ_NOWAIT support from raid1/10/456", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90408", " - wifi: ath12k: fix overreads in", " ath12k_wmi_process_csa_switch_count_event()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90409", " - drm/panthor: Add vm_bind region with kbo range overlap check", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90412", " - nvmet: fix return status of RMI log page on allocation failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90417", " - RDMA/cxgb4: Fix dereg_skb leak and double free in write_tpt_entry()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90421", " - PCI: Fix UAF when probe runs concurrent to dyn ID removal", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90427", " - iommu/tegra241-cmdqv: Don't fall back to a freed smmu after", " devm_krealloc()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92479", " - scsi: ufs: Avoid NULL CQE dereference when reporting invalid tags", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92480", " - scsi: ufs: core: Validate string descriptors", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92482", " - pinctrl: mediatek: use devm_gpiochip_add_data() for GPIO chip", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92483", " - liveupdate: Remember FLB retrieve() status", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92485", " - bpf: Fix WARNING in bpf_tracing_link_release", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92503", " - ext4: fix ABBA deadlock in ext4_xattr_inode_cache_find()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93043", " - bpf: Disallow interpreter fallback for gotox insn", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93044", " - bpf: Disallow interpreter fallback for arena-related insns", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93047", " - drm/v3d: Associate BOs with every job that accesses them", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93069", " - OPP: Fix cleanup ordering", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93081", " - firmware: arm_scmi: Fix SCMI device destroy lifetimes", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93094", " - wifi: ath12k: fix dp_link_peer dangling references on AP vdev rollback", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93096", " - cxl/features: Serialize multi-part Get/Set Feature transfers", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93099", " - fs/resctrl: Fix UAF from worker threads when domains are removed", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93104", " - RDMA/rvt: Return NULL after port allocation failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93105", " - esp: do not unref managed frag pages in esp_ssg_unref()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93116", " - platform/x86: asus-wmi: fix resource leaks on probe failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93122", " - usb: gadget: uac: validate rate list length before storing", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93125", " - bpf: Reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93127", " - bpf: Drop scalar id on sign-extending narrowing stack fills", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93129", " - platform/x86: dell-wmi-base: Fix handling of ultra performance key", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93135", " - bpf: Reject programs with inlined helpers if JIT is not available", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93144", " - bpf: Reject writes through untrusted BTF pointers", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93148", " - bpf: Reject MEM_ALLOC BTF accesses past object bounds", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93153", " - RDMA/bng_re: return a timeout when firmware responses stall", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93164", " - uprobes/x86: Move optimized uprobe from nop5 to nop10", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93168", " - dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93176", " - drm/amd/display: Fix dangling pointer in plane reset function", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93179", " - drm/amd/powerplay: fix VoltageObjectInfo zero-stride loop and OOB read", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93181", " - perf/x86/intel/uncore: Fix uncore_box ref/unref ordering", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89788", " - ksmbd: fix tree connection use-after-free in smb2_tree_connect()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93201", " - dm-pcache: validate seg_id fields from persistent memory", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89792", " - ksmbd: prevent out-of-bounds reads in share config responses", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90051", " - tcp: reject non zerocopy devmem tx", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90053", " - net/sched: sch_htb: limit htb_classify inner-class filter hops", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90054", " - tcp: fix corruption of urgent data on multi-segment retransmit", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90055", " - usb: atm: usbatm: fix invalid ci_range initialization", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90056", " - net: fec: only stop PTP if it was initialized", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90057", " - slip: remove slip_hangup() to fix use-after-free in slip_receive_buf()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90058", " - net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90059", " - net: stmmac: restore NET_IP_ALIGN in the RX DMA offset", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90060", " - ALSA: control: Don't add invalid kcontrols to LED layer", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90062", " - netfilter: nf_tables: move hardware offload step after building the", " chain blob", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90063", " - virtio-net: Ensure that TCP packets don't overflow gso_segs", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90065", " - net/smc: release the internal TCP sock on IPPROTO_SMC socket creation", " failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90066", " - samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-multi-", " modify", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90067", " - libceph: validate banner payload length", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90068", " - ASoC: dapm: Fix off-by-one check on the second enum channel", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90069", " - crypto: acomp - allocate async request context when cloning", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90070", " - tpm: st33zp24: Return zero on status read failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90071", " - net/sched: sch_teql: restore skb->dev on the slave failure path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90072", " - net/sched: sfq: clamp quantum to avoid signed overflow soft lockup", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90073", " - net/sched: hhf: clamp quantum before hhf_change() to avoid overflow", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90074", " - net/sched: fq_pie: clamp default quantum to avoid signed overflow", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90075", " - net/sched: fq_codel: clamp default quantum and mtu", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90076", " - net/sched: fq: add overflow bounds to quantum and initial quantum", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90077", " - net: fix a resource leak in copy_net_ns() error handling path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90078", " - net/sched: act_skbmod: fix length calculations and avoid invalid header", " warnings", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90080", " - octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90081", " - net/rds: use wq_has_sleeper() in rds_cong_map_updated()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90083", " - net/sched: act_ife: Only operate on Ethernet frames", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89780", " - net: qualcomm: rmnet: restore skb->dev on deaggregated frames", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90084", " - octeontx2-vf: fix workqueue and netdev race in probe/remove", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90085", " - octeontx2-af: fix NULL deref in NIX TM tree debugfs read path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89789", " - gtp: add synchronize_net() in gtp_newlink() error path to prevent use-", " after-free", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90086", " - xsk: honor XDP_TX_METADATA in zero-copy path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90088", " - Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite", " loop", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90089", " - Bluetooth: btnxpuart: Validate the FW dump header length", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90090", " - Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90091", " - Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90092", " - Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90094", " - arm64: process: Fix context switching MTE store-only tag check", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90097", " - Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root", " partition", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90100", " - ptp: netc: fix period truncation and potential divide-by-zero in PEROUT", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90101", " - bnxt_en: Fix call to hardware monitoring event handler", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90102", " - NFSv4/pnfs: key the data server cache on the NFS version", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90103", " - NFSv4.2: fix LAYOUTSTATS send buffer exhaustion", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90107", " - net/smc: free pending qentry in smc_llc_flow_stop() before memset", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90108", " - net/smc: free stashed qentry before overwrite in REQ_ADD_LINK to", " ADD_LINK transition", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90109", " - net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90110", " - inetpeer: randomize RB-tree node comparison using SipHash", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90112", " - net: qlcnic: validate unified ROM sections before loading", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89790", " - ipv6: avoid divide by zero in rt6_multipath_rebalance", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90113", " - netdevsim: update queue NAPI association on queue reset", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90114", " - net: bridge: Reject descending VLAN tunnel ranges", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90115", " - xsk: fix NULL pointer dereference in __xsk_rcv()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90116", " - ALSA: mtpav: shut down output timer before card teardown", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90119", " - ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90122", " - clk: visconti: Make sure clk_init_data is fully initialized", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90124", " - irqchip/renesas-rzg2l: Fix loss of interrupt", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90125", " - smb: client: fix request buffer leak in smb2_new_read_req()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90126", " - rtc: pcf8563: fix clock provider leak on unbind", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90127", " - virtio: rtc: time out alarm requests", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90128", " - vdpa/mlx5: fix wrong list iterated in add_direct_chain error path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90129", " - virtio_balloon: quiesce balloon work before device shutdown", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90130", " - vdpa_sim: fix cleanup after worker creation failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90135", " - net: add missing ref_tracker_dir_exit() to alloc_netdev_mqs()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90136", " - platform/x86/amd/hsmp: Reject negative power cap writes in hwmon", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90137", " - platform/x86: hp-bioscfg: fix password encoding bounds check", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90138", " - vsock: don't check the listener's sk_err in vsock_accept()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90139", " - fuse: check for NULL root inode in fuse_fill_super_submount", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89779", " - fs/ntfs3: validate ef->size covers the record's name and value", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89781", " - fs/ntfs3: fix out-of-bounds read in read_log_rec_buf()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90140", " - cuse: wait for pending RCU callbacks on module exit", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89776", " - vxlan: vnifilter: enforce exact length of GROUP/GROUP6 attributes", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90141", " - ipvs: fix integer overflow in ftp helper port/address parsing", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90143", " - net: kcm: Hold RCU read lock while running BPF parser", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90145", " - hinic3: Fix skb linearization mismatch and drop skb when", " skb_checksum_help() failed", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90146", " - bpf, xdp: move offload check into dev_xdp_install()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90147", " - clk: devres: fix cleanup in devm_clk_get_optional_enabled_with_rate()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90148", " - NFSv4: Fix incorrect argument passed to nfs4_delete_lease() in", " nfs4_add_lease()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90149", " - NFSv4/flexfiles: fix NULL dereference for NFSv4.0 data servers", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90150", " - pnfs/blocklayout: Fix device leaks on parse failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90151", " - NFSv4: remove callback IDR entry on client allocation failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90152", " - smb/server: fix session leak in ksmbd_session_register()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90153", " - ksmbd: bound smb_check_perm_dacl() ACE walks by DACL size", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90157", " - bpf: Reject negative optlen in cgroup getsockopt hook", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90158", " - m68k: nfcon: Do not call console_is_registered() in nfcon_device()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90159", " - bpf: Disallow bpf_{g,s}etsockopt() in cgroup UNIX getname hooks", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90160", " - lwt_bpf: Restore reserved headroom after xmit program", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90161", " - erofs: fix interlaced ztailpacking pclusters", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90165", " - smb/server: fix invalid pointer dereference in", " ksmbd_stop_durable_scavenger()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90166", " - smb/server: fix null-ptr-deref in ksmbd_ipc_tree_connect_request()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90169", " - ksmbd: free preauth sessions on connection teardown", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90170", " - ksmbd: validate ipc response length before dereferencing its fields", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90175", " - smb: server: fix leak of ksmbd_ipc_login_request_ext() returned buffer", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90176", " - ksmbd: Do not skip lock checks for single-byte ranges", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90178", " - hwmon: (coretemp) Fix core_data leak on CPUs without PTS", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90179", " - apparmor: fix deadlock in complain-mode change_hat", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90180", " - block: mtip32xx: synchronize ioctls with device removal", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90184", " - null_blk: serialize configfs attribute updates with device setup", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90185", " - null_blk: serialize configfs attribute stores with the lock", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90186", " - null_blk: reject per-device queue resize for shared tag set", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90187", " - null_blk: free zones array on device power-off", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90188", " - null_blk: free global tag_set on init error path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90189", " - null_blk: register configfs subsystem after creating default devices", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90190", " - null_blk: use DEFINE_MUTEX for the file-scope mutex", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90191", " - mailbox: riscv-sbi-mpxy: validate RPMI notification lengths", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90192", " - mailbox: qcom-cpucp: handle NULL data in send_data callback", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90193", " - mailbox: qcom-cpucp: fix PREEMPT_RT self-deadlock in IRQ handler", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90194", " - ACPI: scan: fix bus ID cleanup on device_add() failures", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90195", " - riscv, bpf: Fix missing sign-ext for signed 1-byte and 2-byte kfunc args", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90196", " - ASoC: SOF: validate topology volume range before allocation", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90197", " - HID: haptic: don't write an uninitialized value to unhandled usages", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90198", " - ALSA: core: Fix use-after-free in snd_card_do_free()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90199", " - fs/ntfs3: reject out-of-range evcn in mi_enum_attr()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90200", " - fs/ntfs3: fix integer overflow in MFT cluster validation", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90201", " - net: page_pool: fix UAF in __page_pool_release_netmem_dma on xa_cmpxchg", " race", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90202", " - scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90203", " - Squashfs: check block offset is not negative", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90204", " - ocfs2: validate DIO orphan slot during inode read", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90205", " - ocfs2: validate orphan slot during inode read", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90207", " - ALSA: seq: midi: Serialize input teardown with event_input", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90209", " - s390/debug: Fix deadlock during unregister", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90213", " - firewire: core: fix memory leak in error path of build_tree()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90214", " - ASoC: xilinx: formatter_pcm: fix stream_data leak on open error", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90215", " - mtd: ubi: Release device reference on busy detach", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90216", " - ubi: Fix rollback for explicit UBI device numbers", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90218", " - RDMA/cma: Fix WARNING in res_to_rt", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90219", " - RDMA/cxgb4: Free debugfs on registration failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90220", " - ALSA: seq: Don't leak the extension cell pointer in the bounce payload", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90221", " - nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90222", " - nfc: pn533: hold a reference to the request skb during send_frame", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90223", " - nfc: llcp: bound SNL TLV parsing to the skb and add length checks", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90224", " - nfc: nci: fix double completion race in nci_data_exchange_complete", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90225", " - nfc: llcp: read llcp_sock->local under the socket lock in getsockopt", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90226", " - nfc: llcp: avoid userspace overflow on invalid optlen", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90227", " - nvme/ioctl: check SUBMIT_IO with nvme_cmd_allowed()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90228", " - nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90229", " - nvme-apple: Destroy the admin queue on removal", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90230", " - nvmet: fix heap out-of-bounds read in nvmet_auth_negotiate()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90232", " - amt: Don't support cross-netns setup.", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90233", " - nvme-pci: release descriptor pools on probe failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90235", " - sunrpc: xprtsock: annotate shared socket callbacks with", " READ_ONCE/WRITE_ONCE", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89784", " - SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90240", " - iommu/vt-d: Flush context cache with correct SID when tearing down", " aliases", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90241", " - iommu/vt-d: Tear down scalable-mode context on probe failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90243", " - iommu/vt-d: Clear Present bit before tearing down copied context entry", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90244", " - iommu/dma: Restore locking around msi_page_list", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90245", " - fbdev: kyro: Validate overlay viewport coordinates", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90247", " - bpf: Fix mmap_lock leak in irq_work path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90248", " - net/sched: cls_api: fix teardown of an adopted proto on insert-race loss", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90249", " - iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90250", " - bpf, cgroup: Fix storage null-ptr-deref after replacing prog", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90251", " - Bluetooth: MSFT: validate evt_prefix_len against the response length", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90252", " - Bluetooth: MGMT: free the HCI command when it is cancelled", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90253", " - Bluetooth: MGMT: free the mesh send cancel command when it is cancelled", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90254", " - Bluetooth: hci_sync: free the advertising instance on the failure and", " cancel paths", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90255", " - Bluetooth: hci_conn: fix the SCO setup context lifetime", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90257", " - Bluetooth: virtio_bt: avoid OOB read of build info string", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90258", " - pinctrl: airoha: add missed IRQ resource helpers", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90259", " - btrfs: qgroup: fix a wrong length calculation in", " qgroup_free_reserved_data()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90260", " - btrfs: zoned: don't clobber the extent buffer when zeroing it out", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90262", " - btrfs: retry verity reads for not-uptodate Merkle folios", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90264", " - btrfs: always wait for ordered extents to avoid OE races", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90265", " - btrfs: defrag: fix deadlock between defrag and delalloc space", " reservation", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90269", " - bpf: Reject load-acquire from pointers requiring fault protection", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90272", " - perf: arm_pmuv3: Zero initialize hw_id branch stack field", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90274", " - coresight: etm4x: fix underflow for usage of (nrseqstate - 1)", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90275", " - md/raid1: don't set array_frozen in raid1_takeover()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90276", " - md/md-llbitmap: stop daemon timer rearm on destroy", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90277", " - md/md-llbitmap: prevent create failure bitmap UAF", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90278", " - md: wait for behind writes before destroying bitmap", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90279", " - md/raid5: round bitmap stripes with sector division", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90280", " - phy: qcom: qmp-usb: Fix possible NULL-deref on early runtime suspend", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90281", " - phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime", " suspend", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90282", " - phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime", " suspend", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90283", " - hugetlbfs: release subpool on fill_super failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90284", " - firmware_loader: do not queue completed sysfs fallback requests", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90285", " - scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90286", " - drm/amdgpu/gfx6: Use PFP on the compute queues too", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90287", " - phy: sunplus: fix error handling in sp_uphy_init()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90290", " - arm64: hibernate: Restore DAIF state on error", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90291", " - module/dups: Fix use-after-free in kmod_dup_req lifetime handling", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90292", " - RDMA/siw: Fix use-after-free in siw_accept()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90293", " - IB/isert: post the full-feature receive buffers after session", " registration", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90294", " - IB/isert: delay the final Login Response until the session is registered", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90295", " - cpufreq: imx6q: fix out-of-bounds write when probed more than once", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90296", " - cpufreq: imx6q: fix devres accumulation across driver rebind", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90297", " - drm/sun4i: crtc: Propagate layer initialization error", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90298", " - drm/sun4i: tcon: Drop TCON TOP device reference", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90302", " - ocfs2: synchronize heartbeat callbacks with o2net teardown", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90303", " - ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user", " faults", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90306", " - ARM: 9481/2: breakpoint: CFI breakpoints only on demand", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90307", " - RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90308", " - RDMA/erdma: Hold QP references for AE and CM processing", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90309", " - RDMA/erdma: Hold CQ references when processing EQ events", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90312", " - bpf: Check load-acquire src ptr type before the load", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90313", " - bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90314", " - remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90316", " - drm/omap: dsi: Do not copy isr table", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90318", " - fat: release buffer head after rebuilding parent", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90319", " - rapidio: clear mport->net when rio_add_net() fails", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90322", " - ocfs2/cluster: keep heartbeat local node stable", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90324", " - ublk: check import_ubuf() return value", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90325", " - blk-cgroup: skip dying blkg in blkcg_activate_policy()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90326", " - blk-cgroup: fix race between policy activation and blkg destruction", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90327", " - phonet: pep: do not write beyond optlen in getsockopt", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90328", " - HID: steam: Reject short reads", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90329", " - HID: synchronize input before cleaning up a failed probe", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90333", " - dm-integrity: replace forgeable discard filler with a keyed sector", " marker", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90334", " - tty: clear cdev pointer after cdev_add() failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90338", " - serial: amba-pl011: keep console clock enabled for atomic writes", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90341", " - firmware: coreboot: Validate table bounds", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90343", " - wifi: cfg80211: stop PMSR before P2P and NAN teardown", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90344", " - wifi: mac80211: disconnect on CSA to channel 0", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90348", " - wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90349", " - wifi: mt76: mt7996: fix out-of-bounds link array access in mt7996_tx()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90350", " - wifi: mt76: reject out-of-range link ids in mt76_vif_link()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90351", " - wifi: mt76: mt7996: do not attach hif2 WED when the main WED attach", " failed", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90352", " - wifi: mt76: mt7915: release hif2 reference on probe IRQ failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90353", " - wifi: mt76: mt7915: fix ext PHY use-after-free on register error path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90354", " - wifi: mt76: mt7915: fix double hif2 init on the non-WED path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90356", " - wifi: mt76: mt7996: free vif links after clearing wcid entries on full", " reset", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90357", " - wifi: mt76: mt7915: unlink TWT flow if the MCU rejects the agreement", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90358", " - bpf, x86: Fix trampoline stack size for 128-bit arguments", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90360", " - regulator: core: use system_freezable_wq for init complete work", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90361", " - wifi: ath11k: fix leak in ath11k_service_ready_ext_event()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90362", " - drm/msm/dsi: Drop dev_pm_opp_set_rate(0)", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90363", " - drm/msm: don't tear down KMS twice when KMS init fails", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90364", " - ACPI: processor: Unregister cpufreq notifier on init failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90366", " - wifi: mt76: mt7996: reserve space for the CSA-abort countdown TLV", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90367", " - wifi: mt76: mt7996: hold dev->mt76.mutex while disabling tx worker in", " SER", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90368", " - wifi: mt76: mt7915: unwind state on add_interface failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90370", " - wifi: mt76: mt7996: bound TLV walk in mt7996_mcu_get_chip_config", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90371", " - wifi: mt76: fix RXDMAD_C buffer recycling race", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90372", " - wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90373", " - wifi: mt76: mt7915: clear wcid mask under mutex after RCU pointer clear", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90374", " - wifi: mt76: mt7996: validate RX band_idx before dereferencing phys[]", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90375", " - wifi: mt76: fix non-AQL packet accounting for MLO stations", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90376", " - wifi: mt76: mt7996: fix MLD ID in MAC TXD and HIF TXP", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90377", " - wifi: mt76: fix RX data queuing of RRO 3.0", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90378", " - wifi: mt76: mt792x: Fix memory leak in SDIO TX path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90379", " - wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90382", " - wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90383", " - misc: sgi-gru: remove interrupt-context page-table walks", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90385", " - md/raid1: create serial pool adding rdev to array with", " serialize_policy=1", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90386", " - i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90387", " - swiotlb: Preserve allocation virtual address for dynamic pools", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90388", " - iommu/dma: Check atomic pool allocation result directly", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90389", " - md: scope memalloc_noio to allocation critical sections", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90390", " - md/bitmap: resume array on backlog_store() error path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90391", " - lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90392", " - bpf: Fix potential UAF when reading bpf link info", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90393", " - bpf: Fix potential UAF in bpf_netns_link_update_prog", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90394", " - power: supply: sc2731_charger: cancel work on remove", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90395", " - power: supply: isp1704_charger: cancel work on remove", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90396", " - block: fix dio leak on metadata mapping error", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90397", " - firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is", " published", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90398", " - wifi: ath11k: fix stride mismatch in mac_phy_caps_parse()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90399", " - wifi: ath12k: fix stride mismatch in mac_phy_caps_parse()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90400", " - md: recheck spare changes before starting sync", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90402", " - bus: mhi: host: Fix controller cleanup on EDL sysfs failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90403", " - wifi: rtlwifi: pci: fix error path in rtl_pci_probe()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90404", " - platform/chrome: cros_ec_debugfs: Unregister panic notifier", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90406", " - media: qcom: iris: handle runtime PM resume failure in core deinit", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90407", " - wifi: ath11k: fix overreads in", " ath11k_wmi_process_csa_switch_count_event()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90410", " - spi: davinci: switch to managed controller allocation", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90411", " - nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90413", " - IB/isert: reject login PDUs declaring more data than was received", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90414", " - IB/isert: reject PDUs declaring more data than was received", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90415", " - RDMA/cxgb4: free STAG index when TPT entry write fails", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90416", " - RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90418", " - nilfs2: fix BUG in nilfs_copy_dirty_pages() on dirty state mismatch", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90419", " - nilfs2: prevent out-of-bounds read in super root block parsing", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90420", " - nilfs2: fix infinite loop in nilfs_clean_segments()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90422", " - clk: mediatek: pllfh: Fix IO remapping leak in register_pllfhs error", " path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90423", " - RDMA/rxe: Fix UAF in ODP init error-handling path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90424", " - iommu/tegra241-cmdqv: Fix VINTF0 leak on the init-failure path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90425", " - iommu/tegra241-cmdqv: Require exactly one Stream ID for a vSID", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90426", " - iommu/tegra241-cmdqv: Free the error IRQ before tearing down VINTFs", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90428", " - iommu/tegra241-cmdqv: Don't run the error ISR before probe sets up", " vintfs", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90429", " - iommu/tegra241-cmdqv: Synchronize the error ISR against VINTF (de)init", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90430", " - iommu/tegra241-cmdqv: Publish an LVCMDQ only after it is fully", " initialized", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89782", " - fs/ntfs3: reject restart table growth beyond U16_MAX entries", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90431", " - remoteproc: Prevent crash handling to race with rproc_del()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90433", " - spi: oc-tiny: switch to managed controller allocation", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90434", " - isofs: release zisofs block pointer buffer head", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-90435", " - RDMA/mlx5: Fix integer overflow of user QP buffer size", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92476", " - crypto: keembay - Initialize completion before requesting IRQ", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92477", " - scsi: ufs: debugfs: Reserve space for a string terminator", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92481", " - pinctrl: mediatek: free EINT resources on unbind", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92484", " - cxl/region: Fix use-after-free in find_pos_and_ways() error path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92486", " - bpf: Fix CFI mismatch in task work callback", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89785", " - fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92488", " - RDMA/erdma: complete object teardown when the destroy command fails", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92489", " - xfrm: Fix skb double-free in xfrm_dev_direct_output()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92490", " - firmware: arm_scmi: Unrequest devices if driver registration fails", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92491", " - firmware: arm_scmi: Roll back partial protocol table registration", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92493", " - cpufreq: amd-pstate-ut: Skip tests when amd-pstate driver is not active", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89787", " - ext4: check dir entry fits before reading the hash trailer in", " ext4_search_dir()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92494", " - ext4: fix buffer_head leak in ext4_init_orphan_info", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92495", " - RDMA/bnxt_re: Clear VM_MAYWRITE on DBR/toggle page mmap", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92496", " - wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92497", " - wifi: ath12k: Avoid buffer overread in ath12k_wmi_op_rx()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92498", " - wifi: ath6kl: avoid buffer overreads in WMI event handlers", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92499", " - ext4: validate readdir offset before accessing dirent", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92500", " - ext4: use fsdata to track inline data write state and fix race", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92501", " - ext4: drain in-flight DIO before buffered write fallback", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92504", " - thermal: intel: int3400: clean up ODVP on probe failures", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92505", " - iommu/amd: Fix undefined behavior in devid_write debugfs function", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92506", " - firmware: arm_scmi: Fix requested device removal race", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92507", " - RDMA/core: Fix potential use after free in ib_dealloc_pd_user()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92508", " - RDMA/core: Fix potential use after free in ib_free_cq()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92509", " - RDMA/core: Fix potential use after free in counter_release()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92510", " - RDMA/core: Fix potential use after free in ib_destroy_srq_user()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92511", " - RDMA/core: Fix potential use after free in ib_destroy_cq_user()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92512", " - RDMA/core: Fix use after free in ib_query_qp()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92513", " - RDMA/mana_ib: drain QP references after partial table insertion", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92514", " - RDMA/erdma: Fix CEQ tasklet use-after-free on removal", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92515", " - bpf: Preserve unique-field state across nested structs", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92516", " - bpf: Fix offset warn check for bpf_res_spin_lock", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92517", " - bpf, riscv: Fix extable handling for arena load_acquire", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92518", " - riscv, bpf: Fix kernel stack corruption in tailcall with CFI", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92519", " - riscv, bpf: Fix memory leak in bpf_jit_free", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92520", " - bpf: Zero queue and stack outputs on lock failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89786", " - ext4: fix out-of-bounds read in ext4_read_inline_dir()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92521", " - ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92522", " - ACPI: processor: validate MADT IOAPIC entry bounds", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92523", " - RDMA/nldev: validate dynamic counter attribute length", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92524", " - irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-92525", " - RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[]", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93037", " - RDMA/hfi1: Propagate sdma_txinit_ahg() errors", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93039", " - ASoC: meson: Keep link pointers valid on realloc failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93040", " - dmaengine: dw-edma: Serialize channel state checks", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93041", " - dmaengine: dw-edma: Serialize abort state updates", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93042", " - dmaengine: dw-edma: Terminate all descriptors without callbacks", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93045", " - bpf: Reject arena frees below the arena base", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93046", " - software node: Fix software_node_get_reference_args() with index -1", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93048", " - mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93049", " - mtd: mtdswap: Avoid freeing registered blktrans device twice", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89777", " - vfio/pci: clear vdev->msi_perm after freeing it on init failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93050", " - ipack: ipoctal: fix UAF, null-ptr-deref, and use-after-free in cleanup", " on remove", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93051", " - misc: ad525x_dpot: use driver core groups for sysfs files", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93052", " - misc: bcm-vk: Use acquire/release for msgq_inited", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93053", " - speakup: keyhelp: guard letter_offsets possible out-of-range indexing", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93054", " - uio: Fix stale info pointer in failed registration path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93055", " - UDF symlink pathComponent header OOB read", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93056", " - usb: gadget: f_uac1_legacy: remove broken string configfs attributes", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93058", " - drm/msm: Only fini scheduler after successful init", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93059", " - drm/msm: Fix task_struct reference leak in recover_worker", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93061", " - gpu: host1x: Avoid stack over-read in debug output helpers", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93062", " - wifi: iwlwifi: guard against division by zero in", " iwl_dbg_tlv_alloc_fragments", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93063", " - wifi: iwlwifi: mei: check SAP message length before reading it", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93064", " - wifi: iwlwifi: mvm: fix off-by-one in TXF key sanitiser", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93065", " - wifi: iwlwifi: fix counter type in iwl_fwrt_dump_error_logs", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93066", " - x86/mm/pat: Take cpa_lock around large-page collapse", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93067", " - drm/bridge: tc358767: clamp the reported AUX read size to the request", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93068", " - drm/amd/display: Fix DM I2C teardown race", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93070", " - media: ipu6: Do not free aux device pdata after init", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93071", " - media: bcm2835-unicam: Fix asc leaked in error/remove path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93072", " - irqchip/renesas-irqc: Fix generic interrupt chip leak on remove", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93073", " - dax: read holder_ops once in dax_holder_notify_failure()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93077", " - cxl/features: Clamp Get Feature output size to the remaining buffer", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93078", " - cxl/features: Reject Set Features output buffer smaller than the header", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93079", " - cxl/features: Reject Get Feature count larger than the output buffer", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93080", " - firmware: arm_scmi: Fix transport device teardown lookup", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93082", " - firmware: arm_scmi: Unwind P2A receiver mailbox setup failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93083", " - firmware: arm_scmi: Unwind TX receiver mailbox setup failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93084", " - firmware: arm_scmi: Drop handle on protocol bind failures", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93085", " - firmware: arm_scmi: Reject out of range DT protocol IDs", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93086", " - firmware: arm_scmi: Avoid IDR updates while cleaning channels", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93089", " - firmware: arm_scmi: Free transport channel on IDR failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93090", " - firmware: arm_scmi: Clean up channels on setup failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93091", " - firmware: arm_scmi: Quiesce notifications before teardown", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93092", " - firmware: arm_scmi: Unregister device notifier before IDR teardown", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93093", " - firmware: arm_scmi: Publish channel state before callbacks", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93095", " - hfsplus: validate thread record before delete key rebuild", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93097", " - cxl/mbox: Break poison list loop on an empty payload", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93098", " - rpmsg: glink: fix deadlock in endpoint destroy during driver detach", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93100", " - fs/resctrl: Prevent use-after-free in rdtgroup_kn_put()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93101", " - media: v4l2-async: Unregister sub-device if asc_list is empty", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89778", " - isofs: fix out-of-bounds page array access on empty zisofs block", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93102", " - RDMA/hfi1: Free RX data on late probe failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93103", " - RDMA/hfi1: Preserve unit 0 on allocation failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-89783", " - xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is", " full", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93106", " - crash_dump: release keyring reference at the correct time", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93107", " - RDMA/rxe: Avoid reprocessing the current packet after the QP enters the", " error state", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93108", " - RDMA/ipoib: Drain RCU callbacks during module teardown", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93109", " - RDMA/mlx5: Drain RCU callbacks during module teardown", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93110", " - RDMA/core: Wait for RCU callbacks before unloading ib_core", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93112", " - bpf: Require a BPF cpumask for bpf_cpumask_populate()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93113", " - clk: qcom: camcc-sc8280xp: unregister CAMCC_GDSC_CLK", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93114", " - platform/surface: acpi-notify: Check ACPI companion before use", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93115", " - platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93117", " - usb: fix UAF when probe runs concurrent to dyn ID removal", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93118", " - usb: gadget: aspeed_udc: check endpoint DMA allocation", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93119", " - usb: ljca: bound bank_num in ljca_enumerate_gpio()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93120", " - usb: gadget: configfs: fix out-of-bounds read of qw_sign", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93121", " - usb: gadget: f_fs: Fix fence cleanup in ffs_dmabuf_transfer() error", " paths", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93123", " - serial: qcom-geni: do not advance stale DMA completions", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93126", " - remoteproc: qcom_q6v5_adsp: Fix reference leak for device node", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93128", " - platform/x86: lg-laptop: Fix LED resource handling", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93130", " - platform/x86: dell-wmi-base: Fix resource leak on module load failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93131", " - platform/x86: dell-privacy: Fix race condition", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93132", " - ACPI: RISC-V: Fix riscv_acpi_add_prt_dep() loop handling", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93133", " - ACPI: RISC-V: Check acpi_get_handle() status in riscv_acpi_add_prt_dep()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93134", " - printk: Fix possible console use-after-free", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93136", " - bus: mhi: ep: Fix device refcount leak in the error path of MHI device", " creation", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93137", " - bpf: Fix use-after-free on mm_struct in bpf_find_vma()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93138", " - bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93140", " - udf: Mark LVID buffer as uptodate before marking it dirty", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93141", " - usb: gadget: r8a66597: avoid double free of ep0_req in probe error path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93142", " - thermal/drivers/rcar: Fix error checking in probe()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93143", " - staging: media: ipu7: fix pm_runtime refcount leak in ipu7_resume()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93145", " - clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93146", " - time/namespace: Validate nanosecond field in proc_timens_set_offset()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93149", " - wifi: mac80211_hwsim: avoid NULL skb in stop queue drain", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93150", " - cgroup/cpuset: Make nr_deadline_tasks an atomic_t", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93151", " - nvmet-rdma: fix response resource leak on queue teardown", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93152", " - nvme-apple: Use acquire/release for queue enabled state", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93154", " - RDMA/irdma: Add refcounting to user ring MRs", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93155", " - crypto: keembay - Fix AEAD unregister count in error path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93156", " - crypto: rk3288 - fail ahash requests on HASH idle timeout", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93157", " - hwrng: xilinx-trng - propagate timeout before any data is read", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93158", " - crypto: sa2ul - stop probe if context pool creation fails", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93159", " - crypto: atmel-sha204a - fix heap info leak on I2C transfer failure", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93160", " - crypto: atmel-ecc - reject hardware ECDH without a public key", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93161", " - crypto: qat - clear AES key schedule from stack", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93162", " - crypto: qat - cancel work on re-enable SR-IOV timeout", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93163", " - hwrng: core - fix rng list on registration error", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93165", " - platform/chrome: sensorhub: Fix memory overread in ring handler", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93167", " - csky: Fix a4/a5 restoration in syscall trace path", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93169", " - dmaengine: zynqmp_dma: fix race between runtime PM and device removal", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93170", " - dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and", " MCDMA interrupt handlers", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93172", " - mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93173", " - bpf,lsm: Drop bpf_prog_free from sleepable_lsm_hooks", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93174", " - bpf: Copy per-CPU map value padding in copy_map_value_long()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93177", " - drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93178", " - drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93182", " - sched/fair: Fix overflow in update_tg_cfs_runnable()", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93183", " - drm/lima: call drm_mm_init() with a valid allocation range", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93184", " - ASoC: fsl_audmix: rework runtime PM handling in probe", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93185", " - ASoC: rt700-sdw: always drain jack work on remove", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93186", " - cxl/mbox: Clamp mailbox output allocation to the payload size", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93188", " - HID: roccat: bound device-supplied profile index", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93189", " - HID: core: quiesce input in hid_hw_stop() to prevent use-after-free", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93190", " - platform/chrome: cros_ec_typec: Reject out-of-bounds PD cap count", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93191", " - smack: fix incorrect task context in smack_msg_queue_msgrcv", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93192", " - drm/v3d: Clear queue->active_job when v3d_fence_create() fails", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93193", " - drm/rockchip: analogix_dp: Fix OF node reference leak via auto cleanup", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93194", " - drm/rockchip: dw_dp: Release core resources", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93195", " - drm/bridge: synopsys: dw-dp: Support unregistering the AUX channel", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93198", " - dm-pcache: validate the persisted dirty_tail chain at load", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93200", " - i3c: master: Fix use-after-free of master->this", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93199", " - i3c: master: Do not treat master device as a duplicate target", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93196", " - nvdimm: virtio_pmem: refcount requests for token lifetime", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93202", " - i3c: master: Fix recursive locking during device registration", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93203", " - batman-adv: bla: avoid CRC corruption due to parallel claim add", "", " * Resolute update: upstream stable patchset 2026-10-05 (LP: #2169638) //", " CVE-2026-93204", " - batman-adv: dat: atomically update mac addresses", "" ], "package": "linux", "version": "7.0.0-41.41", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 2170001, 2163215, 2166838, 2169175, 2169736, 2169900, 2169641, 2169641, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638, 2169638 ], "author": "Mehmet Basaran ", "date": "Mon, 12 Oct 2026 10:06:38 +0300" }, { "cves": [ { "cve": "CVE-2026-89795", "url": "https://ubuntu.com/security/CVE-2026-89795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: Allow per function PCI slots to fix slot reset on s390 On s390 systems, which use a machine level hypervisor, PCI devices are always accessed through a form of PCI pass-through which fundamentally operates on a per PCI function granularity. This is also reflected in the s390 PCI hotplug driver which creates hotplug slots for individual PCI functions. Its reset_slot() function, which is a wrapper for zpci_hot_reset_device(), thus also resets individual functions. Currently, the pci_create_slot() assigns the same pci_slot object to multifunction devices. This approach worked fine on s390 systems that only exposed virtual functions as individual PCI domains to the operating system. Since commit 44510d6fa0c0 (\"s390/pci: Handling multifunctions\") s390 supports exposing the topology of multifunction PCI devices by grouping them in a shared PCI domain. This creates a problem when resetting a function through the hotplug driver's slot_reset() interface. When attempting to reset a function through the hotplug driver, the shared slot assignment causes the wrong function to be reset instead of the intended one. It also leaks memory as we do create a pci_slot object for the function, but don't correctly free it in pci_slot_release(). Add a flag for struct pci_slot to allow per function PCI slots for functions managed through a hypervisor, which exposes individual PCI functions while retaining the topology. Since we can use all 8 bits for slot 'number' (for ARI devices), change slot 'number' u16 to account for special values PCI_SLOT_PLACEHOLDER and PCI_SLOT_ALL_DEVICES.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89796", "url": "https://ubuntu.com/security/CVE-2026-89796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid infinite kdamond_merge_regions() internal loop Patch series \"mm/damon: unurgent fixes for infinite loop, NULL de-ref and races\", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89804", "url": "https://ubuntu.com/security/CVE-2026-89804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dmem: fix mismatched DMA unmap size for large folios Device-private THP migration maps migration buffers with page_size() and records that length in dma_info->size. For a compound folio page_size() is PAGE_SIZE << order, but two teardown sites still pass a literal PAGE_SIZE to dma_unmap_page(): - nouveau_dmem_migrate_to_ram() on the success path, and - nouveau_dmem_migrate_copy_one() on the copy-error path. For an order > 0 folio this unmaps less than was mapped, leaking the remainder of the IOMMU/IOVA mapping. The other unmap sites, in nouveau_dmem_migrate_chunk() and nouveau_dmem_evict_chunk(), already use the saved size; use it here too.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89809", "url": "https://ubuntu.com/security/CVE-2026-89809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix scope of mqd_mgr dereference in pqm_debugfs_mqds Reading /sys/kernel/debug/kfd/mqds while a process holds an active KFD queue triggers a NULL pointer dereference because the for loop that calls mqd_mgr->debugfs_show_mqd() is incorrectly placed outside the if (pqn->q) block that initializes mqd_mgr. The queue list can contain entries where pqn->q is NULL (kernel queues where only pqn->kq is valid). In the original code: if (pqn->q) { ... mqd_mgr = q->device->dqm->mqd_mgrs[mqd_type]; size = mqd_mgr->mqd_stride(...); } for (xcc = 0; xcc < num_xccs; xcc++) { // WRONG: outside if block mqd = q->mqd + size * xcc; r = mqd_mgr->debugfs_show_mqd(m, mqd); } When iterating over a queue node where pqn->q is NULL: 1. The if (pqn->q) block is skipped 2. mqd_mgr remains uninitialized (NULL from declaration) 3. The for loop executes anyway 4. mqd_mgr->debugfs_show_mqd(m, mqd) dereferences NULL The crash manifests as: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode RIP: 0010:0x0 Call Trace: pqm_debugfs_mqds+0x10c/0x1d0 [amdgpu] kfd_debugfs_mqds_by_process+0x9b/0x110 [amdgpu] seq_read_iter+0x132/0x4b0 ... Fix by moving the for loop inside the if (pqn->q) block, so mqd_mgr and related variables are only used when properly initialized. (cherry picked from commit 8bfe29d5c798940f797aa24135d2734c3ffce9de)", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89812", "url": "https://ubuntu.com/security/CVE-2026-89812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: force complete the MES ring fences on reset The MES scheduler ring has no drm scheduler (no_scheduler = true), so it is skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). It uses a polling fence whose hw value lives in wb (GTT) memory and survives a MODE1 reset, while fence_drv.sync_seq keeps advancing for every packet. When the reset is triggered because MES itself stopped responding, the timed-out packets advance sync_seq past the last hw fence value MES wrote. After resume the first MES submission polls forever on a seq that is never written back, failing the resume and wedging the box on a second reset: amdgpu: MES ring buffer is full. amdgpu: *ERROR* ring gfx_0.0.0 test failed (-110) amdgpu: resume of IP block failed -110 amdgpu: GPU reset end with ret = -110 Force complete the MES scheduler ring fences together with the scheduler rings so their hw fence is realigned to sync_seq. v2: cover all XCCs (one scheduler ring each), not just mes.ring[0].", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89813", "url": "https://ubuntu.com/security/CVE-2026-89813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: force complete the KIQ ring fences on reset Like the MES scheduler ring, the KIQ ring sets no_scheduler = true and uses a polling fence, so it is skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). Its hw fence value lives in wb (GTT) memory and survives a MODE1 reset while fence_drv.sync_seq keeps advancing, so after a reset the first KIQ submission can poll forever on a seq that is never written back. Force complete the KIQ ring fences too so their hw fence is realigned to sync_seq.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89815", "url": "https://ubuntu.com/security/CVE-2026-89815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Drop tt->restore after successful restore ttm_pool_restore_and_alloc() can successfully complete the restore process via ttm_pool_restore_commit(), but tt->restore is not dropped afterward. As a result, subsequent backup/restore flows observe what appears to be a completed restore, while in reality shmem handles are still installed in tt->pages, leading to the stack trace below. Fix this by freeing and dropping tt->restore in ttm_pool_restore_and_alloc() upon successful completion of the restore. 20545 [  309.784531] RIP: 0010:sg_alloc_append_table_from_pages+0x38c/0x490 20547 [  309.809570] RSP: 0018:ffffc9000623b838 EFLAGS: 00010206 20548 [  309.814827] RAX: 0000000000001000 RBX: ffff88816e42a160 RCX: 0000000000000000 20549 [  309.821986] RDX: 0000000000002000 RSI: 0000000000000003 RDI: 0000000000001000 20550 [  309.829147] RBP: ffff88816e42a168 R08: 0000000000000002 R09: 000000007ffff000 20551 [  309.836310] R10: ffffc9000623b928 R11: 0000000000000000 R12: 000000007ffff000 20552 [  309.843471] R13: ffff88815ba5a100 R14: 0000000000000000 R15: 0000000000000001 20553 [  309.850634] FS:  00007f9ff305e700(0000) GS:ffff888276c94000(0000) knlGS:0000000000000000 20554 [  309.858749] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 20555 [  309.864519] CR2: 00007f9fca701000 CR3: 00000001565e2005 CR4: 0000000008f70ef0 20556 [  309.871678] PKRU: 55555558 20557 [  309.874403] Call Trace: 20558 [  309.876866]  20559 [  309.878988]  sg_alloc_table_from_pages_segment+0x60/0x100 20560 [  309.884415]  ? ttm_resource_manager_usage+0x36/0x60 [ttm] 20561 [  309.889845]  ? xe_tt_map_sg+0x7d/0xd0 [xe] 20562 [  309.894045]  xe_tt_map_sg+0x7d/0xd0 [xe] 20563 [  309.898037]  xe_bo_move+0x927/0xaa0 [xe] 20564 [  309.902029]  ttm_bo_handle_move_mem+0xba/0x170 [ttm] 20565 [  309.907022]  ttm_bo_validate+0xbe/0x190 [ttm] 20566 [  309.911405]  xe_bo_validate+0x9a/0x120 [xe] 20567 [  309.915663]  xe_gpuvm_validate+0xd9/0x140 [xe] 20568 [  309.920206]  drm_gpuvm_validate+0x2f0/0x5b0 [drm_gpuvm] 20569 [  309.925459]  ? drm_exec_lock_obj+0x63/0x210 [drm_exec] 20570 [  309.930627]  xe_vm_validate_rebind+0x46/0xb0 [xe] 20571 [  309.935428]  xe_exec_fn+0x20/0x40 [xe] 20572 [  309.939249]  drm_gpuvm_exec_lock+0x78/0xc0 [drm_gpuvm] 20573 [  309.944410]  xe_validation_exec_lock+0x5a/0xa0 [xe] 20574 [  309.949385]  xe_exec_ioctl+0x806/0xc30 [xe] 20575 [  309.953639]  ? ttwu_queue_wakelist+0xd9/0xf0 20576 [  309.957935]  ? __pfx_xe_exec_fn+0x10/0x10 [xe] 20577 [  309.962449]  ? __wake_up_common+0x73/0xa0 20578 [  309.966482]  ? __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20579 [  309.971263]  drm_ioctl_kernel+0xa3/0x100 20580 [  309.975209]  drm_ioctl+0x213/0x440 20581 [  309.978637]  ? __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20582 [  309.983415]  xe_drm_ioctl+0x67/0xd0 [xe] 20583 [  309.987408]  __x64_sys_ioctl+0x7f/0xd0", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89827", "url": "https://ubuntu.com/security/CVE-2026-89827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid force-completing uninitialized UVD rings uvd_v7_0_sw_init() does not initialize the UVD decode ring for an SR-IOV VF. However, amdgpu_uvd_resume() unconditionally force-completes the decode ring when restoring its fence sequence. Skip fence completion when the fence driver is not initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89831", "url": "https://ubuntu.com/security/CVE-2026-89831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: protect critical_task_priority updates with s_umount The sysfs store path already takes s_umount for GC thread control entries, and ckpt_thread_ioprio is covered as well. critical_task_priority also updates checkpoint or GC kthread scheduling state, but it is not covered by that serialization. It can race with remount or teardown paths that are stopping those threads. Protect critical_task_priority sysfs writes with s_umount too.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89836", "url": "https://ubuntu.com/security/CVE-2026-89836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix folio_nr_pages() race after put in large folio invalidate Our v6.18 based Android system is continuely suffering livelock and bad page stat as shown in[1] which related to broken xarray slot status. By investigating big folio operations within f2fs, we find below races and fix it by get the nr_pages before drop the refcount and folio_lock. f2fs_get_read_data_folio() calls f2fs_folio_put() before folio_nr_pages() when invalidating a large folio from the page cache. That unlocks the folio and drops the caller reference, leaving a window where a concurrent truncate or folio split can shrink the compound folio or free it before the invalidate range is computed. An undersized range then leaves split sub-folios in mapping->i_pages, which can later interact badly with truncate and reclaim (stale xarray entries and bad page state when folio->mapping no longer matches the mapping being truncated). [1] PID: 2594 TASK: ffffff8169b81580 CPU: 7 COMMAND: \"Thread-3\" #0 [ffffffc08ef2b8a0] xas_load at ffffffe52d1f42a4 #1 [ffffffc08ef2b900] find_get_entries at ffffffe52c185798 #2 [ffffffc08ef2bb60] truncate_inode_pages_range at ffffffe52c19e83c #3 [ffffffc08ef2bbc0] truncate_inode_pages_final at ffffffe52c19ec2c #4 [ffffffc08ef2bc20] f2fs_evict_inode at ffffffe52c4c8400 #5 [ffffffc08ef2bcc0] evict at ffffffe52c2de9f4 #6 [ffffffc08ef2bd00] iput at ffffffe52c2db1b4 #7 [ffffffc08ef2bd30] dentry_unlink_inode at ffffffe52c2d7204 #8 [ffffffc08ef2bd50] __dentry_kill at ffffffe52c2d3dcc #9 [ffffffc08ef2bd80] dput at ffffffe52c2d3c3c #10 [ffffffc08ef2bda0] __fput at ffffffe52c2b0a7c #11 [ffffffc08ef2bde0] ____fput at ffffffe52c2b1034 #12 [ffffffc08ef2bdf0] task_work_run at ffffffe52beea200 #13 [ffffffc08ef2be20] exit_to_user_mode_loop at ffffffe52bfbc17c #14 [ffffffc08ef2be80] el0_svc at ffffffe52d1f8e54 #15 [ffffffc08ef2beb0] el0t_64_sync_handler at ffffffe52d1f8d10", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89838", "url": "https://ubuntu.com/security/CVE-2026-89838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: limit recovery filename logging to stored length F2FS stores recovery filenames as a length plus a fixed-size i_name buffer. The buffer is not NUL-terminated, but recover_inode() and recover_dentry() print it with %s. For a 255-byte filename, recovery logging can read past i_name into the following raw inode fields. Print the name with a precision bounded by i_namelen and F2FS_NAME_LEN.", "cve_priority": "negligible", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89840", "url": "https://ubuntu.com/security/CVE-2026-89840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate MOVE_RANGE destination size F2FS_IOC_MOVE_RANGE checks the source range, but not the destination end before updating i_size. A source hole can expose this: __clone_blkaddrs() skips NULL_ADDR entries and returns success, so the caller can still extend the destination inode with unchecked pos_out + len. Reject destination overflow and use inode_newsize_ok() before extending the destination inode.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89859", "url": "https://ubuntu.com/security/CVE-2026-89859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero dport diagnostics buffer to avoid info leak qla2x00_do_dport_diagnostics() allocates the qla_dport_diag response buffer with kmalloc_obj() (non-zeroing) and, on success, copies the full sizeof(*dd) back to user space via sg_copy_from_buffer(). The inbound sg_copy_to_buffer() only fills as many bytes as the user request payload provides, and qla26xx_dport_diagnostics() zeroes only dd->buf. The options and unused[] fields are therefore copied out uninitialized, leaking kernel heap contents to user space. Allocate with kzalloc_obj(), matching qla2x00_do_dport_diagnostics_v2().", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89862", "url": "https://ubuntu.com/security/CVE-2026-89862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix BSG job leak on validate flash image error path qla28xx_validate_flash_image() returns QLA_SUCCESS (0) unconditionally, telling the FC BSG transport (fc_bsg_host_dispatch()) that the driver owns and will complete the request. But bsg_job_done() is guarded by \"if (!rval)\", so on the error path (rval == -EINVAL) neither the driver nor the transport completes the job. The request dangles until it times out, leaking block layer resources. Commit c2c68225b145 (\"scsi: qla2xxx: Fix bsg_done() causing double free\") added the \"if (!rval)\" guard to a batch of BSG handlers. That is correct for handlers that also return the error code (the transport then completes the job once via fail_host_msg), but this function returns QLA_SUCCESS unconditionally, so the guard turned a correct single completion into a leak. Always call bsg_job_done(): bsg_reply->result is DID_OK and the error is reported in vendor_rsp[0], and since the function returns 0 the transport will not complete the job a second time.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89866", "url": "https://ubuntu.com/security/CVE-2026-89866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Resume device before setting EOS flag Setting the EOS flag talks to the firmware via send_firmware_command(), which accesses VPU registers. Both the STREAMOFF path (wave5_vpu_dec_job_abort()) and the V4L2_DEC_CMD_STOP path (wave5_vpu_dec_stop()) can run while the device is runtime suspended, so those register accesses hit powered-down hardware and the SoC raises an asynchronous SError, panicking the kernel: SError Interrupt on CPU3, code 0x00000000bf000000 -- SError send_firmware_command+0x2c/0x160 [wave5] wave5_vpu_dec_set_bitstream_flag+0x6c/0x80 [wave5] wave5_vpu_dec_update_bitstream_buffer+0x80/0xec [wave5] wave5_vpu_dec_job_abort+0x44/0xa0 [wave5] v4l2_m2m_cancel_job+0x110/0x19c [v4l2_mem2mem] v4l2_m2m_streamoff+0x24/0x140 [v4l2_mem2mem] Resume the device with pm_runtime_resume_and_get() around the EOS firmware command and release it with pm_runtime_put_autosuspend(), matching the runtime PM handling already done in wave5_vpu_dec_device_run().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89867", "url": "https://ubuntu.com/security/CVE-2026-89867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Defer job_finish() only when a DEC_PIC was queued Decoder instances sharing a VPU also share one v4l2_m2m job slot, released when the running context calls v4l2_m2m_job_finish(). While draining, device_run() defers job_finish() once EOS is sent (sent_eos), expecting a later finish_decode() (from a DEC_PIC completion IRQ) to release the slot. But the m2m core checks job_ready() only when a job is queued, not when it is dispatched. A job queued while draining can run after finish_decode() has already moved the instance to STOP and sent EOS. device_run() then runs in STOP, issues no DEC_PIC, yet still skips job_finish() - so no IRQ, no finish_decode(), and the shared slot is leaked, stalling every instance. With several v4l2h264dec instances in parallel, GStreamer hangs at EOS. Track whether the run actually queued a DEC_PIC (cmd_issued) and defer job_finish() only then. Otherwise finish the job immediately", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89868", "url": "https://ubuntu.com/security/CVE-2026-89868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Add timeout while stop_streaming When stop_streaming is called, an infinite loop may occur in some cases. Add a bounded poll of the queue status: loop until the queues drain, sleeping briefly between polls, and bail out once VPU_DEC_STOP_TIMEOUT elapses.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89873", "url": "https://ubuntu.com/security/CVE-2026-89873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC EXT SPS RPS counts The HEVC SPS control carries the short-term and long-term RPS counts that decoder drivers use to walk the matching EXT SPS dynamic arrays. Reject SPS values that exceed the HEVC limits of 64 short-term sets and 32 long-term references so drivers cannot later index beyond those controls. Also reject EXT SPS ST RPS entries whose negative or positive picture counts exceed the 16-entry arrays, or whose combined delta-POC count exceeds the HEVC DPB maximum.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89875", "url": "https://ubuntu.com/security/CVE-2026-89875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: quiesce overflow recovery before freeing streams The VIP overflow recovery worker is armed from the hardirq handler when a FIFO overflow is detected, and the list-complete path looks the stream up through the VPDMA list private pointer. Both keep touching stream, port and device state; the recovery worker also resets the parser and VPDMA, repopulates the descriptor list, and re-enables the per-list IRQs. vip_stop_streaming() masks and clears the per-list IRQs, but it neither synchronizes the hardirq handler nor disables recovery_work. An overflow IRQ that has already queued recovery_work, or a list-complete IRQ in flight when the stream is torn down, can therefore still dereference the stream after its resources are released: the descriptor list is freed by vip_release_stream() on file release, and the stream itself by free_stream() on unbind/remove. Drain the recovery worker and the IRQ handler at both teardown points through a shared vip_quiesce_stream() helper, before any stream-owned resource is released. disable_work_sync() cancels pending recovery_work, drains a running instance, and raises its disable depth, so a subsequent schedule_work() issued by a racing IRQ handler is rejected at the workqueue scheduler: recovery_work cannot be requeued after disable_work_sync() takes effect. The worker may still re-enable the per-list IRQs before disable_work_sync() returns; disable_irqs() then masks those sources and synchronize_irq() waits for any in-flight handler that still dereferences stream state. In vip_stop_streaming() the helper runs before the parser is stopped, since a worker drained by disable_work_sync() may re-enable the parser before exiting and would otherwise undo the stop. recovery_work is created disabled and enabled in vip_start_streaming() before IRQs, pairing the enable with the teardown disable across the streaming lifecycle. This issue was found by an in-house static analysis tool and confirmed by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89882", "url": "https://ubuntu.com/security/CVE-2026-89882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rkvdec: hevc: guard INTER_REF_PIC_SET_PRED index underflow st_ref_pic_set_prediction() computes the reference RPS index as st_rps_idx - (delta_idx_minus1 + 1) per HEVC spec equation 7-59. Both operands are u8, so when delta_idx_minus1 + 1 exceeds the current index the subtraction wraps and the subsequent array access at calculated_rps_st_sets[ref_rps_idx] reads far out of bounds. A userspace V4L2 client that can open the RKVDEC m2m decoder can submit an EXT_SPS_ST_RPS control with INTER_REF_PIC_SET_PRED set and delta_idx_minus1 crafted to trigger the underflow. Reject the entry early when the reference index would underflow.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89905", "url": "https://ubuntu.com/security/CVE-2026-89905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Move arena register slot below TCC context Currently, the stack layout places the optional arena register slot above the tail call counter context. When arena_vm_start is dynamically enabled, it shifts the relative offset of the tcc_ptr slot within the stack frame, causing hardcoded tracking macros to mismatch and leading to memory misalignment or corruption potentially. To fix this, move the arena register save and restore sequences below the tail call counter context slots in both build_prologue() and the epilogue. Update __build_epilogue() to insert a proper offset decrement to safely skip the unneeded tcc_ptr reading block while accurately aligning with the relocated arena slot at the very bottom. With this patch, the tcc_ptr slot is always positioned at a fixed distance directly underneath the base callee-saved registers that is independent of whether the arena features are on.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89915", "url": "https://ubuntu.com/security/CVE-2026-89915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Remove VM-wide VNCR mapping counter The global VNCR mapping counter is used to decide whether an L1 provided VNCR page is mapped in L0 on any CPU at the point of dealing with a TLB invalidation. It is incremented when a mapping is made in the fixmap, and decremented when unmapped. As it turns out, this tracking has several flaws: - we are trying to invalidate TLBs, and the mapping is only an opportunistic consequence of the TLB. Checking this counter to decide whether a TLB needs to be invalidated may result in missed invalidations. - an L1 vcpu invalidating its own TLB (a very likely case) will not succeed in invalidating the VNCR pseudo TLB because that page is not mapped in L0 at this stage. Given that this tracking fails at delivering the minimum guarantees that are required and is only a performance optimisation, remove it completely.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89917", "url": "https://ubuntu.com/security/CVE-2026-89917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping While VNCR TLB invalidation always occurs under the MMU lock, vcpu_put() doesn't, while it unmaps the VNCR page. The problem is that the invalidation evaluates vncr_tlb::cpu to decide whether an unmapping needs to take place (cpu != -1) before performing it. On the other hand, this_cpu_reset_vncr_fixmap() unconditionally unmaps if L1_VNCR_MAPPED is set. These two obviously can race, with a TOCTOU pattern on the TLBI path, and a BUG_ON() on the vcpu_put() path. And the two can end-up calling vncr_fixmap(-1), with extra lethal effects. Move the reset of vncr_tlb::cpu to -1 to a common function, and make this update atomic so that only a single thread can reset the field and perform the corresponding unmap. The vcpu_put() still need to unconditionally unmap the current VNCR to close another ugly race. Finally, the assignment of vncr_tlb::cpu is moved to be kept in sync with the actual mapping, similar to L1_VNCR_MAPPED being set.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89919", "url": "https://ubuntu.com/security/CVE-2026-89919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: keyop: use mmu_lock to read gmap->asce Every other dat_* consumer in this file (kvm_s390_get_skeys, set_skeys, get_cmma_bits, set_cmma_bits, MEM_CLR_CMMA, kvm_s390_fixup_prefix, kvm_test_age_gfn, kvm_age_gfn) reads kvm->arch.gmap->asce *inside* the mmu_lock read-side. keyop is the only outlier. gmap->asce is mutated under write_lock(mmu_lock) by gmap_set_limit() and keyop might use a stale asce value for walking as KVM_S390_KEYOP and KVM_S390_VM_MEM_LIMIT_SIZE can run concurrently. This can result in memory corruption.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89921", "url": "https://ubuntu.com/security/CVE-2026-89921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Zero initialize data structures for inject_pfault_token __kvm_inject_pfault_token() only sets .type and .u.ext.ext_params2 of the on-stack struct kvm_s390_irq but the full ext substructure is copied into the cpu local variable on inject. ext_params and pad contain stale stack values. Interrupt delivery only uses ext_params2, so nothing leaks to the guest, but a host user can use the migration ioctls to get to the data. Fix by zero-initializing the irq struct. Do the same for the inti data structure.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89935", "url": "https://ubuntu.com/security/CVE-2026-89935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: apds9306: fix PM reference leak in apds9306_read_data() apds9306_read_data() calls pm_runtime_resume_and_get() but several error paths return directly without calling pm_runtime_put_autosuspend(), leaking the runtime PM reference and preventing the device from autosuspending. Use PM_RUNTIME_ACQUIRE_AUTOSUSPEND() and PM_RUNTIME_ACQUIRE_ERR() to automatically handle runtime PM reference release on all return paths.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89966", "url": "https://ubuntu.com/security/CVE-2026-89966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb_cma: fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio alloc_buddy_hugetlb_folio_with_mpol() can pass a NULL nodemask to alloc_fresh_hugetlb_folio() as a fallback to allocate from all nodes. If order is gigantic, alloc_fresh_hugetlb_folio() propagates the NULL nodemask down to hugetlb_cma_alloc_frozen_folio() via alloc_gigantic_frozen_folio(). Additionally, hugetlb_cma_alloc_frozen_folio() previously attempted allocation on hugetlb_cma[nid] without verifying if nid is included in the caller's nodemask. Adding a node_isset(nid, *nodemask) check ensures the initial preferred node allocation honors the memory policy / nodemask. However, hugetlb_cma_alloc_frozen_folio() dereferences the nodemask in node_isset(nid, *nodemask) and for_each_node_mask(node, *nodemask), leading to a null pointer dereference kernel panic when nodemask is NULL. Fix this by checking if nodemask is NULL in hugetlb_cma_alloc_frozen_folio() and defaulting it to cpuset_current_mems_allowed. Enclose the allocation attempts within the cpuset seqcount retry loop so that if the cpuset changes concurrently during allocation, the attempts are retried using the updated nodemask. This ensures that the initial node check and fallback loop safely honor the task's cpuset without violating cpuset constraints or causing NULL pointer dereferences or unexpected allocation failures. From a userspace perspective, this bug allows an unprivileged user to crash the kernel (trigger a panic) by requesting a gigantic hugepage allocation with MPOL_PREFERRED_MANY on a system where CMA is only configured on a subset of NUMA nodes. This can be reproduced by booting a VM with two NUMA nodes, restricting CMA to Node 1 (e.g., hugetlb_cma=1:1G default_hugepagesz=1G hugepagesz=1G hugepages=0), and running a program that allocates a 1GB hugepage area without reserving, restricts allocation to Node 0 using mbind() with MPOL_PREFERRED_MANY, and triggers a page fault: void *ptr = mmap(NULL, 1UL << 30, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB | MAP_HUGE_1GB | MAP_NORESERVE, -1, 0); unsigned long nodemask = 1; /* Node 0 */ mbind(ptr, 1UL << 30, MPOL_PREFERRED_MANY, &nodemask, sizeof(nodemask) * 8, 0); memset(ptr, 0, 1UL << 30); /* Trigger fault */ This results in a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:hugetlb_cma_alloc_frozen_folio+0x75/0x120 Call Trace: only_alloc_fresh_hugetlb_folio.isra.0+0x2c/0x160 alloc_surplus_hugetlb_folio+0x6d/0x100 alloc_hugetlb_folio+0x3c5/0x660 hugetlb_no_page+0x3d9/0x650", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89967", "url": "https://ubuntu.com/security/CVE-2026-89967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/migrate_device: avoid out-of-bounds writes for compound folios migrate_device_range() and migrate_device_pfns() clear the entries following a compound folio so that the PFN arrays retain their page-granular representation. If a compound folio extends beyond the end of the caller-provided range, the loops clear all following folio entries without limiting them to the number of slots remaining in the npages-sized array, causing an out-of-bounds write. Do not proceed with a compound folio if its page-granular representation does not fit entirely in the remaining PFN array. If this happens, drop any reference and lock acquired for the folio, clear the remaining entries, and stop collecting. Observed with a KASAN x86 QEMU kernel using the HMM migrate_anon_huge_zero selftest. Closing /dev/hmm_dmirror0 after migrating an anonymous huge page to device memory exercises: dmirror_fops_release() -> dmirror_device_evict_chunk() -> migrate_device_range()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89971", "url": "https://ubuntu.com/security/CVE-2026-89971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: skip the zoned limits update if the zone info query failed nvme_query_zone_info() returns either a negative errno or a positive NVMe status code, but nvme_update_ns_info_block() only tests for the negative case: \tret = nvme_query_zone_info(ns, lbaf, &zi); \tif (ret < 0) \t\tgoto out; If the device fails the Identify Namespace (I/O Command Set specific) command, or the Identify Controller command issued by nvme_set_max_append(), the positive status falls through and setup continues with the zero-initialized zone info. nvme_update_zone_info() then marks the queue zoned with chunk_sectors and ns->head->zsze set to zero. blk_validate_zoned_limits() does not check chunk_sectors, so the limits commit succeeds. blk_revalidate_disk_zones() does reject the zero zone size, but by then the limits are live and nothing rolls them back, so I/O keeps being submitted to a zoned queue with a zero zone size and disk_zone_no() shifts by ilog2(0): nvme0n1: Invalid non power of two zone size (0) UBSAN: shift-out-of-bounds in include/linux/blkdev.h:747:16 shift exponent -1 is negative disk_zone_no include/linux/blkdev.h:747 [inline] bio_straddles_zones include/linux/blkdev.h:1058 [inline] blk_zone_wplug_handle_write block/blk-zoned.c:1423 [inline] blk_zone_plug_bio.cold+0x25/0x1c8 block/blk-zoned.c:1605 blk_mq_submit_bio+0x18fb/0x2870 block/blk-mq.c:3196 submit_bh_wbc+0x575/0x740 fs/buffer.c:2824 __block_write_full_folio+0x728/0xdd0 fs/buffer.c:1933 Any device, firmware or NVMe-oF target that fails this one command reaches this. Skip the zoned limits update in that case, and log which of the two things happened: during a revalidation the queue keeps the zone geometry it was last validated with, and on a first scan the namespace is registered without zoned limits, so that it is still available as a handle for admin commands. Neither of the paths in nvme_query_zone_info() that return a positive status logs anything, so the failure would otherwise be silent. zi.zone_size is an exact indicator: every path that returns a positive status returns before it is assigned, and after that the only failure left is -ENODEV, which the caller already handles. Found by FuzzNvme.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89976", "url": "https://ubuntu.com/security/CVE-2026-89976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: fix job completion fence cleanup ethosu_ioctl_submit_job() allocates done_fence before validating buffer handles. Errors after allocation call ethosu_job_err_cleanup(), which frees the job but leaks the uninitialized fence. A scheduler dependency error also lets ethosu_job_run() return before dma_fence_init(). Normal cleanup then passes a zeroed refcount to dma_fence_put(). Release done_fence in the common cleanup path and use dma_fence_was_initialized() to distinguish initialized fences from raw allocations. [robh: also fix goto]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89977", "url": "https://ubuntu.com/security/CVE-2026-89977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: check MMIO mapping errors in probe devm_platform_ioremap_resource() returns an error pointer when the register resource cannot be mapped. ethosu_probe() stores it and continues until initialization dereferences it through MMIO accessors. Return the mapping error before initializing the device.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89978", "url": "https://ubuntu.com/security/CVE-2026-89978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: return early from a zero-length flush SYNC_BO does not constrain its size, so a request for zero bytes reaches drm_clflush_virt_range(), which ends with an unconditional clflushopt(end - 1). For an empty range that is the byte before the mapping, and abo->mem.kva comes from vmap(), so the access lands in the guard page below the vmalloc area and faults: BUG: unable to handle page fault for address: ffffd16fbbc70fff #PF: supervisor read access in kernel mode Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 1000 Comm: sync_bo_probe RIP: 0010:drm_clflush_virt_range+0x3c/0x70 Call Trace: amdxdna_drm_sync_bo_ioctl+0x124/0x430 [amdxdna] drm_ioctl+0x301/0x4c0 __x64_sys_ioctl+0x115/0x2f0 do_syscall_64+0xa6/0x3d0 Any process that can open the render node can do this. Reproduced 3 of 3 times on a Strix Point NPU (1022:17f0), by calling SYNC_BO with size 0 on an AMDXDNA_BO_SHARE object. The import arm takes the same request but flushes the whole scatterlist, so it survives it. Nothing needs flushing for an empty range, so answer before choosing a path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89981", "url": "https://ubuntu.com/security/CVE-2026-89981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Don't read GMID_EL1 when MTE is disabled __cpuinfo_store_cpu() gates the GMID_EL1 read on the raw ID_AA64PFR1_EL1, so it reads the register even when the kernel has disabled MTE (CONFIG_ARM64_MTE=n or arm64.nomte). KVM sets HCR_EL2.TID5 in that case, and pKVM injects an UNDEF the host cannot handle: Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP pc : __cpuinfo_store_cpu+0xf4/0x264 Kernel panic - not syncing: Attempted to kill the idle task! Only pKVM reaches it, and only after a CPU is offlined and brought back online: its CPU_ON relay sets the host HCR before the CPU enters EL1, while plain nVHE sets it at CPUHP_AP_KVM_ONLINE. Gate the read on the CPU's own ID_AA64PFR1_EL1 with the command-line override applied, and on CONFIG_ARM64_MTE, which no register reflects. The boot CPU stores its registers before init_cpu_features() strips an unsafe override, so clamp against the hardware value here too.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89791", "url": "https://ubuntu.com/security/CVE-2026-89791", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: Fix use-after-free when perf mmap() revival races with the last munmap() perf_mmap_close() drops rb->mmap_count *without* holding event->mmap_mutex (the refcount_dec_and_test() right before the refcount_dec_and_mutex_lock() of event->mmap_count). A concurrent perf_mmap_rb() can slot its entire \"revival\" path into that window (perf_mmap holds event->mmap_mutex for its whole duration, including rb_alloc): munmap side (perf_mmap_close) mmap side (perf_mmap_rb) ----------------------------------- -------------------------------- rb->mmap_count 1 -> 0 (no lock) (holds event->mmap_mutex) inc_not_zero(rb->mmap_count) fails ring_buffer_attach(event, NULL) rb_alloc() + attach new rb refcount_set(&event->mmap_count, 1) lock; event->mmap_count 1 -> 0 ring_buffer_attach(event, NULL) ring_buffer_put() -> frees the *new* rb The revival's refcount_set(&event->mmap_count, 1) is an invisible 1 -> 1 write: the close frees the just-revived buffer although the other process still has it mapped -- a page-level use-after-free allowing local privilege escalation to root by any unprivileged user (default kernel.perf_event_paranoid=2). Swap the order of the two counter updates: event->mmap_count is dropped first via refcount_dec_and_mutex_lock(), so its 1 -> 0 transition and the ring_buffer_attach() stay serialized with perf_mmap(). rb->mmap_count == 0 then implies every event using the buffer is detached already, so the result of the rb->mmap_count drop can gate the remaining teardown directly and detach_rest is no longer needed. An earlier fix for this race from Kyle Zeng and David Lee takes event->mmap_mutex around both counter updates [0]; here the not-last close stays lockless.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89987", "url": "https://ubuntu.com/security/CVE-2026-89987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: transfer the pmd dirty bit to the folio on zap zap_huge_pmd_folio() propagates the pmd young bit to the folio for the file case, but not the dirty bit. The pte path does propagate it, in zap_present_folio_ptes() and so does the pmd split path, in __split_huge_pmd_locked(). For most file mappings the omission is harmless, because writing to a shared file mapping goes through page_mkwrite(), which dirties the folio. tmpfs is different: it has no page_mkwrite(), and vma_wants_writenotify() is false for it, so a *read* fault on a MAP_SHARED tmpfs mapping installs a writable pmd via do_read_fault(). do_read_fault() does not call fault_dirty_shared_page(), so subsequent stores through that mapping set only the hardware dirty bit in the pmd and never call folio_mark_dirty(). A shmem folio allocated by a fault is marked uptodate but not dirty (see the clear: block in shmem_get_folio_gfp()), so PG_dirty is never set at all. Unmapping such a folio - munmap(), or exit_mmap() when the process dies - then loses the only record that it was written, because zap_huge_pmd() drops the pmd without transferring the dirty bit. Reclaim afterwards sees a clean shmem folio: the whole swap-out block in shrink_folio_list() is inside \"if (folio_test_dirty(folio))\", so pageout() is skipped and the folio falls into __remove_mapping(). There, folio_is_file_lru() is false for a swapbacked folio, so no shadow entry is created and __filemap_remove_folio(folio, NULL) simply empties the i_pages slot. The data is freed without ever being written to swap, and the next fault on that index returns a freshly zeroed folio. This is silent data loss for any process that keeps state in a MAP_SHARED tmpfs segment across an unmap - for example a cache handed from one process generation to the next through /dev/shm. It requires the folio to be PMD-mapped, so it only shows up once shmem THP is enabled (which is what we did in Meta fleet and started noticing crashes); with THP off the pte path transfers the dirty bit correctly. It also only becomes visible when swap is enabled, because with no swap device shmem folios (which are on the anon LRU) are not scanned by reclaim at all, so the clean folio is never dropped. Reproduced on x86_64 with a tmpfs mounted huge=within_size: read-fault a 2MB-backed region, write a known pattern through the resulting mapping, munmap, force reclaim of the cgroup, then re-map and read back. Without this patch the region reads back as zeros and vmstat shows zswpout 0 - the data was discarded rather than swapped. With this patch the region reads back correctly and the pages are swapped out as expected. With huge=never, or when the first touch is a write, the test passes either way.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89996", "url": "https://ubuntu.com/security/CVE-2026-89996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious \"close it on the failure path\" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/ remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90002", "url": "https://ubuntu.com/security/CVE-2026-90002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Take trace_array reference before accessing its ftrace_ops The trace instance files set_ftrace_filter and set_ftrace_notrace was updated to work with specific trace instances (trace_arrays). The issue is that when these files are opened, there is a small race window where it will use the ftrace_ops from the inode->private pointer to get a reference to the trace_array and then take its reference. The problem is that the ftrace_ops itself could be freed. If the rmdir on the instance happens at the same time the set_ftrace_filter file is opened, the rmdir could have also freed the ftrace_ops and referencing it will cause a use-after-free bug and crash the kernel. Instead, pass in the trace_array as the file private data (NULL for the top level instance), and then pass both the trace_array and the ftrace_ops to the ftrace_regex_open() function. If the trace_array is NULL, then it just uses the ftrace_ops without the need to take its reference (like normal). If the ftrace_ops is NULL, that is only the case for the top level instance and the global_ops can be used. This allows the trace_array to have its reference incremented before touching the ftrace_ops that could also be freed when the instance is.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90013", "url": "https://ubuntu.com/security/CVE-2026-90013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Take trace_array reference when opening options file The options files do not take the trace_array reference for the options they represent. This could cause a use-after-free kernel crash if one of these files is opened by one task and another task removes the instance that the option is for. Because it doesn't take a reference upon opening, it will not stop the removal which will free the options descriptor that is being used. As the options are somewhat dynamic in their creation at boot up, each file represents a flag in the trace_array. The trace_array has an array of indexes to represent each of these flags that is stored in the trace_flags_index array. The address of the index array element is used to pass to the inode->i_private pointer. Then that element is read which holds the index (which represents the flag) and then the index is used to calculate the trace_array descriptor from its trace_flags_index array. One issue is that the index element can not be referenced until the trace_array's reference is taken. To handle this, create a new helper function called: trace_array_options_get() that will iterate all the existing trace_arrays in the ftrace_trace_arrays list (under the trace_types_lock), and compare the passed in address of the index element with the entire array of the trace_array's trace_flags_index array. If it matches, then up the corresponding trace_array's reference and return.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90014", "url": "https://ubuntu.com/security/CVE-2026-90014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Have show_event_filters/triggers files take trace array ref The newly added files show_event_filters and show_event_triggers that show all filters or triggers that are set within the trace array do not take a reference for the trace array it is showing. Without taking a reference, the trace_array may be freed via \"rmdir\" while a task is reading one of theses files. Those files iterate all the events within an instance (trace_array) and nothing prevents that instance from being freed while its data is being read. This causes a use-after-free crash. Have the open of both those files take the trace_array reference via the trace_array_get() that prevents the trace_array from being freed while the files are opened.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90016", "url": "https://ubuntu.com/security/CVE-2026-90016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie() rtw_restruct_wmm_ie() scans in_ie for a WMM IE with: \twhile (i < in_len) { \t\t... \t\tif (i + 5 < in_len && in_ie[i] == 0xDD && ...) { \t\t\t... \t\t\tbreak; \t\t} \t\ti += (in_ie[i + 1] + 2); /* to the next IE element */ \t} When the \"i + 5 < in_len\" match check fails simply because i is within 5 bytes of the end of the buffer (i.e. no WMM IE was found near the tail of in_ie), execution falls through to \"i += (in_ie[i + 1] + 2)\", which reads in_ie[i + 1]. If i == in_len - 1 at that point, this is a 1-byte out-of-bounds read of an attacker-influenced IE buffer built from association/scan data. Commit a75281626fc8f (\"staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie\") added the \"i + 5 < in_len\" guard to the match condition itself, but did not add an equivalent guard before the fallthrough advance, so the same class of OOB read remained reachable through the non-matching path. Add an explicit bounds check before advancing to the next IE.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90023", "url": "https://ubuntu.com/security/CVE-2026-90023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_mass_storage: fix null pointer dereference in fsg_common_set_num_buffers() Previously fsg_num_buffers_validate() was removed as it was not necessary due to Kconfig setting the limits for n from 2 to 256 with default as 2. However, setting the page content in such a way that kstrtou8() reflects n value as either 0 or 1 bypasses these restrictions leading to a null pointer dereference if n is 0. Fix this by adding a check for n < 2 and returning -EINVAL if n is either 0 or 1 consistent with Kconfig logic.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90028", "url": "https://ubuntu.com/security/CVE-2026-90028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: hd3ss3220: track VBUS enable state per consumer regulator_is_enabled() reports the aggregate regulator state, not whether this consumer holds an enable reference. If another consumer enables VBUS first, the driver can skip its own regulator_enable() call and later attempt to drop a reference it never acquired, triggering an unbalanced regulator disable warning. Track successful enable and disable calls locally. Keep the state unchanged when an operation fails so a later role or ID notification retries the operation while this consumer keeps balanced references.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90040", "url": "https://ubuntu.com/security/CVE-2026-90040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped Wire up a gmem_invalidate_range() call for SNP VMs, and use it to force vCPUs to reload/recheck their guest-provided VMSA if the backing gmem page is being invalidated, e.g. is being PUNCH_HOLE'd. Use the same core logic to handle invalidations as VMX does for the APIC-access page, as the two concepts are nearly identical: shove the physical address of a page into the vCPU's control structure: 1. Snapshot the invalidation sequence counter 2. Grab the pfn (from guest_memfd in this case) 3. Acquire mmu_lock for read 4. Re-request reload if retry is needed, otherwise commit the change. Note, the re-request action in #4 is necessary as KVM's retry logic is fuzzy, i.e. can get false positives. If the guest_memfd page has been dropped, at some point a subsequent reload will fail to get a PFN from guest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false positive, KVM will retry until there are no relevant MMU notifier events (and will retry in the \"outer\" loop, i.e. will drop locks and resched as needed). Note #2! Take care to invalidate the VMSA when a relevant memslot is DELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated on memslot bindings (KVM doesn't know what GFN range(s) to invalidate without a binding). And more importantly, the VMSA mapping requires a memslot, i.e. must be invalidated if its memslots disappears, regardless of the state of the underlying guest_memfd inode. Failure to invalidate the vCPU's control.vmsa_pa (which is checked by pre_sev_run()) can prevent KVM from properly freeing the page as firmware will reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU is actively running, i.e. if VMSA page is in-use. That in turn leads to an RMP #PF on the next use, as the page will still be assigned to the SNP VM. SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3 SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f] CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 Call Trace: dump_stack_lvl+0x54/0x70 rmpupdate+0x12c/0x140 rmp_make_shared+0x3b/0x60 sev_gmem_invalidate+0xe0/0x170 [kvm_amd] delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e ------------[ cut here ]------------ SEV: Failed to update RMP entry for PFN 0x78d198 error -14 WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345 CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd] Call Trace: delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e irq event stamp: 20689 hardirqs last enabled at (20699): [] __console_unlock+0x5c/0x60 hardirqs last disabled at (20708): [] __console_unlock+0x41/0x60 softirqs last enabled at (20722): [] __irq_exit_rcu+0x7e/0x140 softirqs last disabled at (20717): [] __irq_exit_rcu+0x7e/0x140 ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: ffff99 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90043", "url": "https://ubuntu.com/security/CVE-2026-90043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix slot lock bit position on big-endian 64-bit The slot lock is a bit operation on the whole __lock word, which flags and ac_time alias as two u32s. On little-endian the lock bit lands in the position ZRAM_ENTRY_LOCK reserves in flags, so the aliasing works out. On 64-bit big-endian it lands in ac_time instead: with ZRAM_TRACK_ENTRY_ACTIME enabled, storing the access time from mark_slot_accessed() or slot_free() wipes out the held lock bit, letting another CPU take the same slot lock; an access time value with that bit set makes the slot look locked forever. Shift the lock bit into the flags half of the word on big-endian 64-bit.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89794", "url": "https://ubuntu.com/security/CVE-2026-89794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: zero pipe read compound padding Compound response handling extends the last response iov to an eight-byte boundary. smb2_read_pipe() allocates only the payload size, so the alignment padding can expose up to seven bytes of uninitialized kernel heap memory. Allocate the aligned size and clear the unused tail before pinning the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89797", "url": "https://ubuntu.com/security/CVE-2026-89797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500_fg: fix use-after-free on remove ab8500_fg_remove() destroys the driver workqueue while the threaded interrupt handlers are still armed; they are devm-managed and freed only after ->remove() returns, so a handler that fires in that window queues work on the freed workqueue. Tear the workqueue down through devm instead, registering its cleanup after the power supply and before the interrupt requests. devm then frees the interrupts first, so the handlers can no longer queue work, before disabling the delayed and plain work items and destroying the workqueue. Disabling the items, rather than cancelling them, keeps them disabled so no producer (including the power-supply external_power_changed callback) can requeue them. Found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-90037", "url": "https://ubuntu.com/security/CVE-2026-90037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during close_lru reaping An nfs4_openowner left on nn->close_lru after its final CLOSE keeps its last closed stateid in oo_last_closed_stid, holding only a raw pointer to its nfs4_client. The laundromat reaps timed-out entries, drops nn->client_lock, and calls nfs4_put_stid(), which dereferences the client through cl_lock. Nothing pins the client across that window, so a concurrent force_expire_client() can free it and nfs4_put_stid() reads freed memory. __destroy_client() hits the same race, walking clp->cl_openowners without cl_lock. Pin the client with cl_rpc_users before dropping client_lock, and skip clients already expiring. __destroy_client() then cleans up its own close_lru entries through release_last_closed_stateid(), so teardown no longer races the laundromat.", "cve_priority": "critical", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90036", "url": "https://ubuntu.com/security/CVE-2026-90036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during blocked-lock reaping A bare lock owner -- its only remaining reference a blocked lock on nn->blocked_locks_lru -- holds a raw pointer to its nfs4_client but no reference keeping the client alive. When the per-net laundromat reaps such a lock, freeing the nbl drops the owner reference held through flc_owner, and the final nfs4_put_stateowner() takes the client's cl_lock. Because the laundromat detaches the nbl first, __destroy_client() no longer finds it, so a concurrent force_expire_client() can free the client before nfs4_put_stateowner() runs, dereferencing cl_lock in freed memory. Pin the client with cl_rpc_users before dropping nn->blocked_locks_lock, and skip clients already expiring, whose blocked locks __destroy_client() frees while holding an owner reference. Take nn->client_lock outside nn->blocked_locks_lock. Every other site holds nn->blocked_locks_lock as a leaf, acquiring no further lock, so placing nn->client_lock outside it cannot form a lock-order cycle.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89520", "url": "https://ubuntu.com/security/CVE-2026-89520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/core: Make core-sched flips wait for in-flight selections Core scheduling's pick_next_task() operates on all sibling rqs under one acquisition of the shared core-wide lock. A ->pick_task() that releases the rq lock leaves every sibling __lock momentarily free, letting __sched_core_flip(false) complete mid-selection and rebind rq_lockp() under it. The selection resumes on the split locks, touching sibling state it no longer protects, and __schedule() finally releases a lock that was never taken while leaking the one that was. Count in-flight core-wide selections in the leader's rq->core_pick_in_flight and make __sched_core_flip() wait for the count to drain. The count only changes under the shared lock, which the flip holds while sampling, so no other ordering is needed. The wait can repeat while selections overlap, but the flip backs off between samples and flips are rare cookie-lifetime events. sched_core_cpu_deactivate() moves the count to the new leader - a stale copy left behind would bias it forever if that CPU later returns as its own leader.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89798", "url": "https://ubuntu.com/security/CVE-2026-89798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: arm rn_done before publishing the notification rpcrdma_rn_register() inserts @rn into rd_xa with xa_alloc() before storing the caller's callback in rn->rn_done. The xarray makes @rn reachable to rpcrdma_remove_one(), which walks rd_xa and invokes rn->rn_done(rn) for every registered notification. A device removal that races a fresh registration can therefore observe @rn with rn_done still NULL, because the notification objects are zero allocated by their owners, and call through a NULL function pointer. Store rn->rn_done before xa_alloc() publishes @rn. The xarray's store-side and load-side ordering then guarantees that any CPU which finds @rn in rd_xa also observes the armed callback. rpcrdma_rn_unregister() treats a non-NULL rn_done as the sentinel for a completed registration, so the early store must not survive a failed registration. Clear rn_done again when xa_alloc() fails. Were it left set, the failed-accept cleanup path would call rpcrdma_rn_unregister() on an @rn that was never inserted, erasing an unrelated rd_xa slot and underflowing rd_kref.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89799", "url": "https://ubuntu.com/security/CVE-2026-89799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disable preemption in bpf_get_stackid The get_perf_callchain call needs disabled preemption plus we need it disabled as long as we access its returned trace entries buffer. Note the bpf_get_stackid_pe function is executed already with preemption disabled.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-90041", "url": "https://ubuntu.com/security/CVE-2026-90041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sony: clean up device list on probe failure sony_input_configured() adds some controllers to sony_device_list before HID core registers their input devices. input_register_device() can fail after the callback returns successfully. sony_probe() then observes that HID_CLAIMED_INPUT is clear and unwinds, but only stops the HID hardware. The devres-managed sony_sc is freed while its list node remains linked, so the next matching controller traverses freed memory. Initialize the list node and device ID to inactive states. Make list removal idempotent and run the driver-private cleanup on every probe failure path. This also makes a second cleanup safe when sony_input_configured() already unwound a partial initialization before sony_probe() handles the missing input claim. Found by 0sec (https://0sec.ai) using automated source analysis; verified against the HID input registration and probe unwind paths.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90042", "url": "https://ubuntu.com/security/CVE-2026-90042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: properly decrypt filenames in vmalloc() buffers The fscrypt subsystem uses the scatterlist crypto API, inheriting its requirement that any buffers are in the linear mapping region. However, the messenger client uses kvmalloc() to create buffers for messages, which will occasionally place those buffers in the vmalloc() region when physical memory fragmentation doesn't permit a large enough kmalloc(). The various callers of ceph_fname_to_usr() directly pass (slices of) raw messages from the MDS without considering that the messages may be in vmalloc() buffers, resulting in oopses especially on non-x86 platforms (see 'Closes:' for more details and a reproducer). Make ceph_fname_to_usr() explicitly tolerant of vmalloc()-allocated fname->ctext, fname->name, and/or oname->name buffers, using `tname` (which, when non-null, must be a linear address; when null, is briefly allocated as necessary) as a bounce buffer to avoid passing any inappropriate addresses to fscrypt_fname_disk_to_usr(). Additionally change parse_reply_info_readdir() -- the only function to supply its own `tname` -- to follow the new \"tname must never come from vmalloc()\" rule by passing NULL when the message is not in the linear region. Though this causes a per-dentry kmalloc()+kfree(), this overhead exists only when processing the minority of messages that spill into vmalloc(). My (crude) testing puts this at only about 1 in 8,000 readdir messages. Still, if the overhead proves unreasonable in the future, it is easy enough to mitigate: a future change could allocate a bounce buffer in parse_reply_info_readdir() and use that as `tname` instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90039", "url": "https://ubuntu.com/security/CVE-2026-90039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Guard admin state-revocation walks with NFSD_NET_UP Writing to /proc/fs/nfsd/unlock_filesystem, or sending the NFSD_CMD_UNLOCK_FILESYSTEM or NFSD_CMD_UNLOCK_EXPORT netlink command, walks the NFSv4 client hash tables to revoke open state and cancel async COPY operations. All three handlers gate that walk on nn->nfsd_serv, but a listener added via portlist or netlink listener_set sets nn->nfsd_serv before any nfsd thread starts. nfsd_startup_net() has not yet allocated nn->conf_id_hashtbl, so the walkers dereference a NULL table. A local administrator with CAP_SYS_ADMIN can crash the kernel this way without ever starting the server. nn->nfsd_serv is set when the service is created, which precedes table allocation. NFSD_NET_UP instead brackets the window where the tables are live: set at the end of nfsd_startup_net() and cleared in nfsd_shutdown_net() after they are freed, both under nfsd_mutex. Gating the three unlock paths on NFSD_NET_UP fixes the startup-time NULL dereference while preserving the earlier post-shutdown use-after-free fix.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90044", "url": "https://ubuntu.com/security/CVE-2026-90044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix Use-After-Free in AIO error path In ffs_epfile_write_iter() and ffs_epfile_read_iter(), when ffs_epfile_io() fails with an error other than -EIOCBQUEUED, the io_data structure (`p`) is freed. However, for AIO operations, the kiocb cancel function was already armed and kiocb->private was set to `p`. If a concurrent cancel operation (such as sys_io_cancel()) executes after ffs_epfile_io() fails but before the function frees `p`, a Use-After-Free can occur when the cancellation handler accesses the freed pointer. To securely fix this race condition, we must properly un-arm the cancellation. Invoking `kiocb->ki_complete()` does exactly this by acquiring `ctx->ctx_lock` and safely removing the kiocb from the active sequence. In doing so, it ensures that a parallel io_cancel can no longer discover the kiocb, effectively closing the race window. We then return -EIOCBQUEUED to notify the VFS layer that the kiocb has been consumed and it should avoid attempting to complete the request again or triggering subsequent completion handlers.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90045", "url": "https://ubuntu.com/security/CVE-2026-90045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: ffs: fix mm lifetime handling io_data stores a pointer to the submitting task's mm_struct, but does not currently hold a reference to it while async requests are pending. This can result in a use-after-free if the task exits before completion handling finishes. Take a reference with mmgrab() when queuing the read request and release it with mmdrop() on request completion.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90046", "url": "https://ubuntu.com/security/CVE-2026-90046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: don't spin_trylock() in NMI on UP Patch series \"mm/page_alloc: fixes for free_pages_nolock() on RT/UP\". Pre-existing bugs found by Sashiko during review of this other series: https://lore.kernel.org/all/20260703-alloc-trylock-v5-0-c87b714e19d3@google.com/ I have not reproduced these bugs, and I suspect there is no real-world user that is affected by them. This patch (of 2): As noted in can_spin_trylock(), using this is unsafe in this context. commit 620b46ed6ae17 (\"mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP\") fixed this on the alloc side but missed the free side. Impact: If BPF programs using these features in NMI (probably tracing) are present on non-SMP builds this might crash the kernel and is probably exploitable by local attackers for privilege escalation.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80926", "url": "https://ubuntu.com/security/CVE-2026-80926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in oplock break notification smb2_oplock_break_noti() reads opinfo->conn without any lock and dereferences it after two allocations which may sleep. When the durable handle owning the oplock is disconnected, session_fd_check() clears opinfo->conn and drops its conn reference under ci->m_lock, and the last ksmbd_conn_put() frees the connection. A break triggered by another connection that races with the teardown can then resurrect the freed connection: ksmbd_conn_get() is a plain atomic_inc, and the queued break work later dereferences the stale conn via ksmbd_conn_write(), a use-after-free reachable by any authenticated client holding a durable batch oplock. Thread the caller's inode into the notification path instead of taking a new reference on it. Every caller of oplock_break() already holds a live ksmbd_file (or an explicit ksmbd_inode_lookup_lock() reference, in the parent lease break paths) on the inode that owns the break target's oplock list, so ci cannot be freed during the call, and its lock can be taken without dereferencing opinfo->o_fp, which a concurrent close may free. Select and pin the connection under ci->m_lock, the same lock session_fd_check() and ksmbd_reopen_durable_fd() use to update opinfo->conn, so a concurrent detach either loses the race to the clear or keeps the connection alive until the notification work releases it. Transfer the reference to the work item and release it on allocation failures.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-89800", "url": "https://ubuntu.com/security/CVE-2026-89800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSE A successful OP_UNMAP_SPARSE marks its region dirty with nouveau_uvma_region_dirty() and defers the teardown to nouveau_uvmm_bind_job_cleanup(); it does not remove the region from uvmm->region_mt. If a later op in the job fails, the unwind path never clears reg->dirty (set in one place, cleared nowhere) and sets op->reg = NULL, so cleanup skips the teardown. The region is left in the tree with dirty set and its completion never signalled. Later binds over that range then fail permanently -- -ENOENT or -EINVAL from the dirty checks, or an unkillable wait_for_completion() in bind_validate_region() -- for the lifetime of the uvmm. Clear reg->dirty when the unwind reverts the sparse unmap, restoring the region to the state it was found in.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89801", "url": "https://ubuntu.com/security/CVE-2026-89801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: fix premature region free on failed OP_UNMAP_SPARSE In nouveau_uvmm_bind_job_submit()'s OP_UNMAP_SPARSE arm, op->reg is set from nouveau_uvma_region_find(), which only looks the region up and takes no reference; a region's sole reference is its membership in uvmm->region_mt. Two failure paths leave op->reg set: the -ENOENT check when the region is busy, and the drm_gpuvm_sm_unmap_ops_create() failure. The sibling nouveau_uvmm_sm_unmap_prepare() failure just below clears op->reg; these two do not. unwind_continue steps back one op, so the failing op is skipped by the unwind loop and its op->reg stays set. nouveau_uvmm_bind_job_cleanup() then enters its if (op->reg) branch and calls nouveau_uvma_region_remove() and nouveau_uvma_region_put() on it, dropping the tree's sole reference and freeing a region this job never created. The comment above the cleanup loop documents the broken invariant: op->reg must be NULL on submit failure. This frees a live region on an unrelated failure, reachable single-job when drm_gpuvm_sm_unmap_ops_create() returns -ENOMEM; if another job owns the same region, its cleanup then removes and puts the freed region, a use-after-free. Clear op->reg on both failure paths.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89802", "url": "https://ubuntu.com/security/CVE-2026-89802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: fix NULL deref unwinding an OP_MAP_SPARSE op Each bind_job_op is zeroed by kzalloc_obj() in bind_job_op_from_uop(), and the OP_MAP_SPARSE case in nouveau_uvmm_bind_job_submit() only creates a region, so op->ops stays NULL for a successfully processed sparse map. If a later op in the same job fails, the reverse unwind loop revisits that op and calls drm_gpuva_ops_free(&uvmm->base, op->ops) unconditionally. drm_gpuva_ops_free() dereferences its argument right away (list_for_each_entry_safe on &ops->list), so a NULL op->ops oopses. The path is reachable by any render-node fd holder, since NOUVEAU_VM_BIND is DRM_RENDER_ALLOW. Guard the free with IS_ERR_OR_NULL(), as nouveau_uvmm_bind_job_cleanup() already does for the identical free.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89803", "url": "https://ubuntu.com/security/CVE-2026-89803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: unsubscribe the channel-kill event before the fence context nouveau_channel_del() tears the fence context down first and only drops the channel-kill subscription later, in the middle of the nvif object teardown: \tif (chan->fence) \t\tnouveau_fence(chan->cli->drm)->context_del(chan); \t... \tnvif_object_dtor(&chan->vram); \tnvif_event_dtor(&chan->kill); The subscribed handler is nouveau_channel_killed(), which calls nouveau_channel_kill() and from there nouveau_fence_context_kill() on chan->fence. A kill event delivered in that window takes fctx->lock and walks fctx->pending on a fence context that context_del() has already freed. Nothing reaches this below Fermi today, because the subscription is gated on FERMI_CHANNEL_GPFIFO and nothing kills a channel there. On Fermi and newer the window is real but narrow, since a kill has to land exactly while the channel is being destroyed. That is reason enough on its own, which is why this carries a Fixes: tag. The last patch in this series subscribes Tesla channels as well; nothing kills those today, so it does not widen the exposure now, but it is the groundwork for a recovery path that would, and the ordering is better fixed before that lands than alongside it. Drop the subscription before anything it depends on is torn down.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89806", "url": "https://ubuntu.com/security/CVE-2026-89806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: ofdrm: Fix integer overflow in fb_size calculation The framebuffer size calculation `fb_size = linebytes * height` can overflow when both values are large (e.g., 46341 * 46341 > INT_MAX). Since linebytes and height are both int types, the multiplication is performed as int * int, which results in undefined behavior on overflow. Use check_mul_overflow() to detect and prevent this overflow, consistent with the approach used in simpledrm.c and corebootdrm.c.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89807", "url": "https://ubuntu.com/security/CVE-2026-89807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: guard against NULL restore_mqd in CRIU queue restore Both create_queue_cpsch() and create_queue_nocpsch() unconditionally call mqd_mgr->restore_mqd() when a CRIU restore is in progress (qd != NULL), with no NULL guard. On any system where restore_mqd is not implemented for the given queue type, a user holding CAP_CHECKPOINT_RESTORE can trigger a kernel NULL pointer dereference and panic the machine by issuing KFD_IOC_CRIU_OP_RESTORE with a crafted queue restore object. Note that checkpoint_mqd is likewise unimplemented on GFX12, so no legitimate CRIU image can reach this path — only a hand-crafted restore payload. Add a NULL guard for restore_mqd immediately after mqd_mgr is resolved, unwinding via the existing error labels and returning -EOPNOTSUPP if the callback is not implemented. This mirrors the existing checkpoint_mqd guard in checkpoint_mqd().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89808", "url": "https://ubuntu.com/security/CVE-2026-89808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vram When migration vm range is hole at cpu side(MIGRATE_PFN_MIGRATE set + MIGRATE_PFN_VALID unset) driver still allocates device pages. There is no dma map of src pages and migration. j is 0 and svm_migrate_copy_memory_gart() will return an uninitialized r. That can trigger out_free_vram_pages to drop all VRAM just set up. Initialize r and only call the last svm_migrate_copy_memory_gart if j > 0. Current code postponed the last page to the final copy. This patch flushes on the last page when reach to the end of current drm_buddy_block; avoids another svm_migrate_copy_memory_gart.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89810", "url": "https://ubuntu.com/security/CVE-2026-89810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix error path at svm_migrate_copy_to_ram If page migration from device to sys ram fails for some reasons driver needs release and unlock allocated system pages. To do that driver should use page physical address, or pfn, then get struct page*. Current driver uses dma address(for adev) that is not correct with IOMMU enabled, or even in general. The patch releases and unlocks allocated system pages based on where migration failed by struct page* of sys ram pages. Also dma_unmap correspodent system ram pages at error path.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89811", "url": "https://ubuntu.com/security/CVE-2026-89811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Add TLB flush after MES queue eviction/suspension MES (Micro Engine Scheduler) does not perform heavy-weight TLB invalidation after unmapping queues, unlike HWS which does this automatically. This causes a race condition where in-flight DMA descriptors can access memory that has been unmapped, leading to page faults and GPU queue hangs during SVM page migration. The issue manifests as KFDSVMRangeTest.MultiThreadMigrationTest failures on gfx1151 (Strix Point) with XNACK mode 1 enabled - the GPU compute queue hangs with packets submitted but never consumed. Add kfd_flush_tlb() calls after MES queue removal in two locations: - evict_process_queues_cpsch(): after all queues removed during eviction - suspend_queues(): after debug/criu queue suspension (with mem_fence barrier) This ensures all in-flight memory accesses from unmapped queues are flushed before memory is freed or migrated. (cherry picked from commit f5c4f88e0f9c45a8fb9dfac0c1df726c95e41b77)", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89814", "url": "https://ubuntu.com/security/CVE-2026-89814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: clamp the isolation index for rings outside a partition adev->isolation[] has one slot per partition, but a ring that is not assigned to one keeps AMDGPU_XCP_NO_PARTITION, which is ~0, so indexing the array with it is out of bounds. SDMA submissions hit this on both the isolation enforcement and the VM flush path and trip UBSAN. Fall back to the first slot the way the cleaner shader path already does, and stop taking the address before the ring type check that makes it relevant.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89816", "url": "https://ubuntu.com/security/CVE-2026-89816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used Commit 1c6ceeee6ebb (\"drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits\") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89817", "url": "https://ubuntu.com/security/CVE-2026-89817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: NUL-terminate TV mode names read from the device gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89818", "url": "https://ubuntu.com/security/CVE-2026-89818", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn: fix integer overflow in dec_msg buffer count check If the supplied msg[2] (num_buffers) is 0x3FFFFFFF, the expression 6 + num_buffers * 4 wraps to 2 and the bounds check passes, letting the parser loop far past the end of the message BO. Triggering it additionally requires a ~4GiB mapping so that msg[1] survives the earlier \"header does not fit in BO\" check. Rewrite the test in division form, which is overflow-free by construction. Also update the message to reflect that msg is invalid.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89819", "url": "https://ubuntu.com/security/CVE-2026-89819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: validate plane degamma LUT size for private color prop Unlike the CRTC degamma path, which is guarded by amdgpu_dm_verify_lut_sizes(), the per-plane degamma LUT size was never validated before use. __set_dm_plane_degamma() passed the user-supplied size straight into __is_lut_linear() and, for a non-linear LUT, into __set_input_tf() -> __drm_lut_to_dc_gamma(), the latter always iterating MAX_COLOR_LUT_ENTRIES entries regardless of the actual LUT size. A malformed AMD_PLANE_DEGAMMA_LUT blob (e.g. a single entry) could thus trigger a divide-by-zero in __is_lut_linear() or an out-of-bounds read in __drm_lut_to_dc_gamma(). Reject any plane degamma LUT whose size does not match MAX_COLOR_LUT_ENTRIES, mirroring the invariant the code already asserts a few lines below (and which the CRTC path enforces). The AMD_PLANE_DEGAMMA_LUT property is only exposed on builds with AMD_PRIVATE_COLOR defined.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89820", "url": "https://ubuntu.com/security/CVE-2026-89820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix dc_lock leak on GPU reset error paths On GPU reset, dm_suspend() takes dc_lock and leaves it for dm_resume() to drop. If amdgpu_dm_commit_zero_streams() or dm_dmub_hw_init() fails, the function returns with the lock still held. The matching resume path is then skipped, so every later dc_lock take hangs. Release the cached DC state and unlock before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89821", "url": "https://ubuntu.com/security/CVE-2026-89821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid divide-by-zero in __is_lut_linear() __is_lut_linear() computes the expected value of each entry with \texpected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89822", "url": "https://ubuntu.com/security/CVE-2026-89822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Guard against NULL driver_data in i915_pci_probe() pci_match_device() can return the dummy pci_device_id_any entry when a device is force-bound via sysfs driver_override, in which case ->driver_data is unset (NULL). i915_pci_probe() casts it to struct intel_device_info * unconditionally and dereferences intel_info->require_force_probe, causing a NULL-ptr-deref. (cherry picked from commit 2727922084672cc274ecea726ea00363c2893731)", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89823", "url": "https://ubuntu.com/security/CVE-2026-89823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: fix race between partial drm_dev_register() failure and ioctl If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89824", "url": "https://ubuntu.com/security/CVE-2026-89824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel-edp: fix i2c adapter leak on probe failure Make sure to drop the i2c adapter reference on probe failure (e.g. probe deferral) and on driver unbind also if a devicetree redundantly uses the 'ddc-i2c-bus' property to point to the aux ddc bus.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89825", "url": "https://ubuntu.com/security/CVE-2026-89825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: fix firmware control interface bounds checks panthor_init_cs_iface() and panthor_init_csg_iface() validate firmware control interface offsets with 32-bit arithmetic and the size of the host wrapper structures. The offsets are derived from firmware-provided strides, so the arithmetic can wrap before the bounds check, and the host wrapper size is not the size of the firmware control interface being mapped. Use 64-bit arithmetic for the computed offsets and validate against the actual firmware control interface structure sizes with subtraction-based bounds checks. Also validate that the shared section is large enough for the global control interface before using it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89826", "url": "https://ubuntu.com/security/CVE-2026-89826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: harden firmware build-info bounds checks panthor_fw_read_build_info() checks whether the metadata range fits in the firmware image with hdr.meta_start + hdr.meta_size. Both fields are u32, so the addition can wrap and let an out-of-bounds range pass validation. The function also reads the \"git_sha: \" prefix without first checking that the metadata is long enough, and meta_size == 0 can underflow the NULL terminator index. Use subtraction-based bounds checking and reject metadata that is too short to contain the expected prefix and trailing NULL byte.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89828", "url": "https://ubuntu.com/security/CVE-2026-89828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init() drmm_cgroup_register_region() is called before INIT_LIST_HEAD() and gpu_buddy_init() in amdgpu_vram_mgr_init(). If it fails, the function returns early and bypasses those initializations. Since adev->mman.initialized is set to true before amdgpu_vram_mgr_init() is called, a failure triggers amdgpu_ttm_fini(), which calls amdgpu_vram_mgr_fini(), which then: - Calls list_for_each_entry_safe() on reservations_pending and reserved_pages, whose list_head::next pointers are zero-initialized (NULL). The loop does not recognize them as empty and dereferences NULL. - Calls gpu_buddy_fini(), which iterates free_trees[] unconditionally via for_each_free_tree(). Since mm->free_trees is NULL (never allocated), this dereferences NULL. Both result in a kernel panic on the module load error path. Fix by moving drmm_cgroup_register_region() to after the list and buddy allocator are fully initialized, so the teardown path is safe to run.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89829", "url": "https://ubuntu.com/security/CVE-2026-89829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to pass folio->index to f2fs_sanity_check_node_footer() Otherwise in f2fs_sanity_check_node_footer(), it will check the same nid incorrectly.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89830", "url": "https://ubuntu.com/security/CVE-2026-89830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix valid block count leak on data block allocation failure In __allocate_data_block(), when allocating a new data block (dn->data_blkaddr == NULL_ADDR), inc_valid_block_count() is called first to increment total_valid_block_count and i_blocks. If the subsequent f2fs_allocate_data_block() fails, the function returns the error directly without rolling back the already-incremented block counts, causing a permanent leak. Fix this by calling dec_valid_block_count() to undo the increment before returning the error. The condition old_blkaddr == NULL_ADDR precisely identifies the case where inc_valid_block_count() was called.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89832", "url": "https://ubuntu.com/security/CVE-2026-89832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to clear dirty flag on folio in error path If node block is corrupted due to chksum mismatch or inconsistent footer info, it needs to drop clear flag of node folio, in order to persist inconsistent node data to storage.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89833", "url": "https://ubuntu.com/security/CVE-2026-89833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid potential deadloop in f2fs_fsync_node_pages() There is potential deadloop in race condition: Thread A\t\t\t\tThread B - fsync - f2fs_do_sync_file - f2fs_fsync_node_pages - last_fsync_dnode - folio_get(last_folio) \t\t\t\t\t- f2fs_setattr \t\t\t\t\t - f2fs_truncate \t\t\t\t\t - f2fs_truncate_blocks \t\t\t\t\t - f2fs_do_truncate_blocks \t\t\t\t\t - f2fs_truncate_inode_blocks \t\t\t\t\t - truncate_dnode \t\t\t\t\t - truncate_node \t\t\t\t\t - invalidate_mapping_pages \t\t\t\t\t - folio->mapping = NULL - is_node_folio alwasy return false - atomic && !marked is always true, then goto retry", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89834", "url": "https://ubuntu.com/security/CVE-2026-89834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to migrate all curseg types during free_segment_range In free_segment_range(), the curseg evacuation loop only iterates up to NR_CURSEG_PERSIST_TYPE (0..5), missing non-persistent in-memory curseg types such as CURSEG_COLD_DATA_PINNED and CURSEG_ALL_DATA_ATGC. Even though these in-memory curseg types are not saved in the on-disk checkpoint header, they still occupy active physical segments at runtime. If an active in-memory curseg happens to be allocated within the segment range being truncated during filesystem shrink, failing to evacuate it will cause subsequent writes to the curseg attempting out-of-bounds I/O on the truncated storage range. Fix this by expanding the curseg evacuation loop upper bound to NR_CURSEG_TYPE to ensure all active curseg types are safely migrated out of the target range.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89835", "url": "https://ubuntu.com/security/CVE-2026-89835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: avoid NULL checkpoint thread access in sysfs checkpoint_merge can be enabled even when no checkpoint merge thread is running. A read-only mount is one case: f2fs does not start f2fs_issue_ckpt there, but ckpt_thread_ioprio is still writable through sysfs. The ckpt_thread_ioprio store path updates the saved ioprio value and, when checkpoint_merge is enabled, calls set_task_ioprio() for the checkpoint thread. If cprc->f2fs_issue_ckpt is NULL, that dereferences a NULL task pointer. Protect ckpt_thread_ioprio sysfs writes with s_umount as well, so the checkpoint thread cannot disappear under the store path while updating its ioprio.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89837", "url": "https://ubuntu.com/security/CVE-2026-89837", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix dentry folio leak in find_in_level find_in_level() gets a dentry folio with f2fs_find_data_folio() before calling find_in_block(). If find_in_block() returns an error, the function stores the error in res_folio and breaks out of the loop without dropping the dentry folio. This leaks the folio reference on the find_in_block() error path. Drop the dentry folio before returning the error to the caller.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89839", "url": "https://ubuntu.com/security/CVE-2026-89839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: use the mount idmap for the owner check in f2fs_xattr_advise_set() f2fs_xattr_advise_set() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing the \"system.advise\" xattr to be set, instead of the idmap that the VFS passes to the ->set() handler. f2fs supports idmapped mounts, so on such a mount this checks the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EPERM and an unrelated caller wrongly allowed. Pass the handler's idmap instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89841", "url": "https://ubuntu.com/security/CVE-2026-89841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: only redirty pinned folios in redirty_blocks redirty_blocks() pins folios with read_cache_folio() and then walks the same range again with filemap_lock_folio() to redirty them and drop the references it took. Commit 5951fee46bef (\"f2fs: Use a folio in redirty_blocks()\") changed the second pass to a do/while loop. If read_cache_folio() fails before anything is pinned, page_idx does not advance but the cleanup loop still runs once. If readahead has already populated the failed folio in page cache, that extra iteration finds it and folio_put_refs(folio, 2) drops one reference too many. Later drop_caches or reclaim can then report \"BUG: Bad page state\". Only redirty the range that was pinned successfully.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89842", "url": "https://ubuntu.com/security/CVE-2026-89842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Skip NVMe LS reject IOCB when FW not started qla_nvme_xmt_ls_rsp() bails out to the out: label when firmware is not started (!ha->flags.fw_started), but the out: path unconditionally calls qla_nvme_ls_reject_iocb(), which ends in qla2x00_start_iocbs() and an unconditional doorbell write to the request queue in-pointer register. This rings the firmware doorbell and queues an IOCB that stopped or resetting firmware cannot consume, and touches MMIO during the reset/EEH window where fw_started is also clear. Only emit the LS reject IOCB (and ring the doorbell) when fw_started is set; otherwise just clean up and return. The post-allocation failure cases (SRB alloc / qla2x00_start_sp() failure) run with firmware started and still send the reject. Apply the same guard to the reject emission in qla2xxx_process_purls_pkt().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89843", "url": "https://ubuntu.com/security/CVE-2026-89843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89844", "url": "https://ubuntu.com/security/CVE-2026-89844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold vport_slock for host map update in report ID acquisition qla24xx_report_id_acquisition() format-1 handling drops vport_slock after taking the vport reference and then calls qla_update_host_map() without the lock. That reaches qla_update_vp_map(), which mutates the ha->host_map btree via btree_insert32()/btree_update32()/btree_remove32() and is documented to require vport_slock to be held by the caller. Running it unlocked can race concurrent host_map updates and corrupt the btree. The format-2 path in the same function already wraps its host_map update (SET_AL_PA) in vport_slock; the format-1 path is the lone outlier. Hold vport_slock across the format-1 qla_update_host_map() call to honor the documented locking contract. The vref_count taken in the loop keeps the vport valid, so this only adds the missing host_map serialization.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89845", "url": "https://ubuntu.com/security/CVE-2026-89845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89846", "url": "https://ubuntu.com/security/CVE-2026-89846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: \tif (IS_FWI2_CAPABLE(ha)) { \t\tsense_data += rsp_info_len; \t\tpar_sense_len -= rsp_info_len; \t} rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): \tif (sense_len > par_sense_len) \t\tsense_len = par_sense_len; \tmemcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89847", "url": "https://ubuntu.com/security/CVE-2026-89847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid double completion in async IOCB timeout qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates \"if (sp->comp) complete(sp->comp)\"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89848", "url": "https://ubuntu.com/security/CVE-2026-89848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Quiesce response IRQ before freeing request queue qla2xxx_delete_qpair() deletes the request queue before the response queue. qla25xx_delete_req_que() frees the request queue memory (kfree(req) in qla25xx_free_req_que()), but the response-queue MSI-X is only released later, in qla25xx_free_rsp_que(). In that window the response interrupt can still fire, qla2xxx_msix_rsp_q() queues qpair->q_work, and qla_do_work() -> qla24xx_process_response_queue() dereferences the now-freed rsp->req (LOGINOUT/CT/ELS entries and the status path), a use-after-free. The cancel_work_sync() added for the qpair teardown lives in the response free path, which runs after the request queue is already freed, so it does not protect rsp->req. Release the response-queue interrupt and flush qpair->q_work before deleting the request queue, so no late completion can reach the freed request queue. Clearing have_irq makes the subsequent qla25xx_free_rsp_que() skip its free_irq(), and the firmware queue-delete order (request then response) is preserved; the request-delete mailbox completes on the default vector and is unaffected by dropping the qpair response interrupt early.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89849", "url": "https://ubuntu.com/security/CVE-2026-89849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path qla2x00_status_entry() filters out non-TYPE_SRB entries and the SRB_NVME_CMD, SRB_BIDI_CMD and SRB_TM_CMD types, then falls through to a SCSI fast path that assumes the command is an SRB_SCSI_CMD. The first thing on that path, qla_chk_edif_rx_sa_delete_pending(), and the subsequent handling both evaluate GET_CMD_SP(sp), i.e. sp->u.scmd.cmd. The srb u union overlays the SCSI command pointer with other command layouts (bsg_job, iocb_cmd). If firmware delivers an unexpected STATUS_TYPE IOCB for a non-SCSI handle, sp->u.scmd.cmd can read as a non-NULL garbage pointer, bypassing the NULL checks in qla_chk_edif_rx_sa_delete_pending() and at the cp == NULL test, and leading to a wild pointer dereference. Reject any SRB whose type is not SRB_SCSI_CMD before entering the fast path. The outstanding_cmds slot is left untouched so a genuinely non-SCSI command still completes through its proper handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89850", "url": "https://ubuntu.com/security/CVE-2026-89850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Don't query firmware state while chip is down qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89851", "url": "https://ubuntu.com/security/CVE-2026-89851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace enable parsing in debugfs qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as \"disable\" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89852", "url": "https://ubuntu.com/security/CVE-2026-89852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89853", "url": "https://ubuntu.com/security/CVE-2026-89853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89854", "url": "https://ubuntu.com/security/CVE-2026-89854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix cs84xx use-after-free on host teardown qla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via __qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran before scsi_remove_host(), which is what removes the 84xx_fw_version host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx_84xx_fw_version_show(), which dereferences the freed ha->cs84xx, resulting in a use-after-free. Move qla84xx_put_chip() to after scsi_remove_host() in both qla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once scsi_remove_host() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89855", "url": "https://ubuntu.com/security/CVE-2026-89855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize flash version read in reset handler The \"update cache versions without reset\" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89856", "url": "https://ubuntu.com/security/CVE-2026-89856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as \"ha->max_req_queues = ha->msix_count - 1\" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent \"ha->max_req_queues--\" then underflows 0 to 255. When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following \"ha->req_q_map[0] = req\" dereferences ZERO_SIZE_PTR, corrupting memory or crashing the kernel. Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89857", "url": "https://ubuntu.com/security/CVE-2026-89857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject qla_nvme_ls_reject_iocb() allocates from and advances the request ring through __qla2x00_alloc_iocbs() (which assumes the hardware_lock is held) and qla2x00_start_iocbs() (which advances the ring and rings the request-in doorbell), but takes no lock itself. Two of its callers invoke it without the producer lock held: - qla_nvme_xmt_ls_rsp(), the NVMe-FC .xmt_ls_rsp transport callback, on its error path, and - qla2xxx_process_purls_pkt(), run from the purex work/DPC context. Both use ha->base_qpair, whose qp_lock_ptr is hardware_lock, so they can run concurrently with normal I/O submission on the base ring and corrupt the ring producer state, leading to duplicated or dropped commands. The third caller, qla2xxx_process_purls_iocb(), runs inside qla24xx_process_response_queue() with the qpair lock already held and is safe; that is also why the lock cannot be taken inside the helper itself (it would recursively re-acquire hardware_lock on the response path). Take qp_lock_ptr around the two unlocked callers and document the helper as caller-locked. Both run in process context, so spin_lock_irqsave() is used and nothing in the locked region sleeps.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89858", "url": "https://ubuntu.com/security/CVE-2026-89858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89860", "url": "https://ubuntu.com/security/CVE-2026-89860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Initialize NVMe abort_work once at submission qla_nvme_fcp_abort() and qla_nvme_ls_abort() ran INIT_WORK() on priv->abort_work immediately before schedule_work(). INIT_WORK() reinitializes the work_struct, resetting its list head and clearing the pending bit. If an abort is issued more than once for the same command (for example, concurrent transport teardown and a timeout-driven abort), the second INIT_WORK() reinitializes a work item that is already queued, which can corrupt the workqueue list and lead to crashes or a looping worker. Initialize priv->abort_work once at command submission, next to the existing per-command spin_lock_init(&priv->cmd_lock), and leave only schedule_work() in the abort paths. schedule_work() already does nothing when the work item is still pending, so a repeated abort no longer disturbs an in-flight work item. The command is not returned to the transport until the final kref_put()/release callback runs after abort_work has completed, so the work item is idle before priv is reused and the single submission-time INIT_WORK() is safe.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89861", "url": "https://ubuntu.com/security/CVE-2026-89861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition() In the format 1 path, the virtual port is located on ha->vp_list while holding vport_slock, but the lock is dropped before vp is used: qla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED are set on vp. No reference is taken across that window, so a concurrent qla24xx_deallocate_vp_id() can tear the vport down and free it, leading to a use-after-free. Take a vport reference (vref_count) under vport_slock when the matching vp is found, and drop it after the last use of vp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before unlinking and freeing the vport, so the pointer stays valid. This matches the reference idiom already used by the other ha->vp_list traversals.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89863", "url": "https://ubuntu.com/security/CVE-2026-89863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check qla_chk_edif_rx_sa_delete_pending() obtains the SCSI command via GET_CMD_SP(sp) and immediately dereferences cmd->sc_data_direction. That command pointer can be NULL: the firmware may post a status completion for a command that has already been returned or aborted. The caller qla2x00_status_entry() acknowledges this on the very same status path, re-fetching GET_CMD_SP(sp) and bailing out with the \"Command already returned\" message when it is NULL -- but that check runs only after qla_chk_edif_rx_sa_delete_pending() has already dereferenced the pointer, so a NULL cmd crashes the kernel in interrupt context. Return early when cmd is NULL, before touching cmd->sc_data_direction.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89864", "url": "https://ubuntu.com/security/CVE-2026-89864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound i2c->length in I2C bsg handlers struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: \tstruct qla_i2c_access { \t\tuint16_t device, offset, option, length; \t\tuint8_t buffer[0x40]; \t} __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89865", "url": "https://ubuntu.com/security/CVE-2026-89865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: \tif (len == 1) \t\topt |= BIT_0; \tif (opt & BIT_0) \t\tlen = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89869", "url": "https://ubuntu.com/security/CVE-2026-89869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: qcom: iris: use disable_irq() during power-off The IRQ is registered as a threaded IRQ. Using disable_irq_nosync() in iris_vpu_power_off() does not wait for an already queued threaded IRQ handler to complete before returning. As a result, a threaded IRQ handler may still run after the VPU has been powered down and access hardware registers after power-off. Replace disable_irq_nosync() with disable_irq() so the power-off path waits for any in-flight threaded IRQ handler to complete before returning.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89870", "url": "https://ubuntu.com/security/CVE-2026-89870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: zoran: Avoid freeing a registered video_device twice zoran_init_video_device() installs zoran_vdev_release() as the video_device release callback through zoran_template. After video_register_device() succeeds, video_unregister_device() drops the registered video_device reference and the V4L2 core eventually invokes that release callback, which kfree()s the video_device. zoran_exit_video_devices() called video_unregister_device() and then kfree(zr->video_dev), so device teardown could free the same video_device twice. Remove the direct kfree() and clear the cached pointer after unregistering. The pre-registration failure path keeps its manual free because the video_device was not registered there. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89871", "url": "https://ubuntu.com/security/CVE-2026-89871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure kthread_run() returns an ERR_PTR on failure, not NULL. When start_streaming() fails, data->kthread_vid_cap is left holding this error pointer instead of being cleared. This causes two subsequent bugs: 1. A future call to start_streaming() sees a non-NULL kthread_vid_cap and returns 0 (success) immediately, without actually starting the capture thread. 2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which is false for an error pointer, and proceeds to call kthread_stop() on the error pointer, leading to a kernel crash. Fix this by resetting kthread_vid_cap to NULL on failure before jumping to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89872", "url": "https://ubuntu.com/security/CVE-2026-89872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. [Sakari Ailus: Fix subject prefix and coding style a little.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89874", "url": "https://ubuntu.com/security/CVE-2026-89874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-async: avoid deleting unlinked ASC entry on link error v4l2_async_match_notify() creates ancillary media links before adding asc->asc_subdev_entry to sd->asc_list. If ancillary link creation fails, the function jumps to err_call_unbind while asc_subdev_entry has not been linked yet. Async connections are zero-allocated, so the list entry still has NULL next and prev pointers on this path. Calling list_del() on it can therefore dereference NULL instead of returning the original link creation error. Do not delete asc_subdev_entry from err_call_unbind. There is no list insertion to undo on this path; the bound callback and sub-device registration are the operations that need to be rolled back.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89876", "url": "https://ubuntu.com/security/CVE-2026-89876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: tda18250: fix possible integer overflow Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89877", "url": "https://ubuntu.com/security/CVE-2026-89877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7164: fix cleanup on resource allocation failure saa7164_dev_setup() adds the device to the global saa7164_devlist before requesting the PCI BAR memory regions. If get_resources() fails, saa7164_dev_setup() decrements the device count and returns an error, but leaves the device on saa7164_devlist. The probe error path then frees the device, leaving a dangling entry on the global list. Reuse the existing MMIO mapping error path to remove the device from saa7164_devlist and decrement the device count before returning. Also release BAR0 if it was successfully requested but the BAR2 request fails.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89878", "url": "https://ubuntu.com/security/CVE-2026-89878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: check firmware size before reading trailing marker s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89879", "url": "https://ubuntu.com/security/CVE-2026-89879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: bound JPEG frame size before copying into the buffer s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: \tpayload = le32_to_cpu(pdword[3]); \tif (payload > vc->req_image_size)\t/* payload is checked ... */ \t\treturn -EINVAL; \tvc->pkt_size = payload; \tvc->jpg_size = le32_to_cpu(pdword[4]);\t/* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89880", "url": "https://ubuntu.com/security/CVE-2026-89880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89881", "url": "https://ubuntu.com/security/CVE-2026-89881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89883", "url": "https://ubuntu.com/security/CVE-2026-89883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: sunxi-cir: Unregister rc device on probe failure After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89884", "url": "https://ubuntu.com/security/CVE-2026-89884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: platform: mtk-mdp3: fix NULL deref on failed SCP lookup Add the missing sanity check after looking up the SCP to avoid dereferencing a NULL-pointer in case its driver has not yet been bound.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89885", "url": "https://ubuntu.com/security/CVE-2026-89885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: platform: mtk-mdp3: Fix SCP device refcounting mdp_probe() first tries to get the SCP handle with scp_get(). When that fails, it falls back to looking up the SCP platform device with __get_pdev_by_id() and then reads its driver data. The fallback lookup returns the platform device with a reference, just like scp_get() does. However, the fallback path currently drops that reference immediately after platform_get_drvdata(). The driver later still calls scp_put(mdp->scp) unconditionally from the probe error path and from mdp_video_device_release(), which drops the SCP device reference again. Keep the fallback reference until the existing scp_put() call, so that the fallback path follows the same ownership rules as the scp_get() path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89886", "url": "https://ubuntu.com/security/CVE-2026-89886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: intel/ipu6: fix async notifier cleanup leak on parse error isys_notifier_init() calls v4l2_async_nf_init() and then adds fwnode remote subdevs in a loop with v4l2_async_nf_add_fwnode_remote(). If an endpoint parse or add fails partway through the loop, it jumps to err_parse and returns without calling v4l2_async_nf_cleanup(), leaking every v4l2_async_connection already added to the notifier's waiting list. The register-failure path just below already cleans up correctly, and the caller only tears the notifier down (isys_notifier_cleanup()) once isys_notifier_init() has returned success. Clean up the notifier on the parse error path too.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89887", "url": "https://ubuntu.com/security/CVE-2026-89887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov7740: fix use-after-destroy in remove The ov7740_remove() function had a severe teardown order bug where it destroyed the driver's mutex before freeing the V4L2 control handler which relies on that mutex, leading to a use-after-destroy kernel panic. Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and mutex_destroy() sequentially, but then called ov7740_free_controls() which invokes both of them a second time, resulting in a double-free. This patch fixes the issue by unregistering the subdevice first, and relying exclusively on ov7740_free_controls() to safely tear down the mutex and control handler in the correct order.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89888", "url": "https://ubuntu.com/security/CVE-2026-89888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov02a10: fix endpoint parsing use-after-free The ov02a10_check_hwcfg() function calls fwnode_handle_put(ep) immediately after allocating and parsing the endpoint. However, it subsequently calls fwnode_property_read_u32() using the same 'ep' handle, leading to a potential use-after-free. Additionally, reading the optional 'ovti,mipi-clock-voltage' property used to overwrite the 'ret' variable. If the property was missing, 'ret' would become negative, and this failure code would be incorrectly returned at the end of the function, causing probe to fail entirely. Fix the use-after-free by moving fwnode_property_read_u32() before the endpoint is parsed and freed. Avoid the error leak by not assigning the result of fwnode_property_read_u32() to 'ret'.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89889", "url": "https://ubuntu.com/security/CVE-2026-89889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: imx415: Release runtime PM reference on VBLANK error The VBLANK path returned immediately when programming VMAX failed after pm_runtime_get_if_in_use() had taken a runtime PM reference. Break out of the switch instead so the common pm_runtime_put() path is used.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89890", "url": "https://ubuntu.com/security/CVE-2026-89890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: go7007: defer the ALSA v4l2 put until card release go7007_snd_init() already takes a v4l2_device reference for the ALSA side, but go7007_snd_remove() drops it immediately after calling snd_card_free_when_closed(). That is too early when a userspace process still has the capture PCM open. The ALSA card and its PCM callbacks remain alive until the last file is closed, so the release path can still reach struct go7007 through pcm->private_data and call go7007_snd_hw_free() after the V4L2 release path has freed the object. Move the matching v4l2_device_put() to the ALSA card private_free callback so the existing ALSA reference covers the whole deferred card lifetime.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89891", "url": "https://ubuntu.com/security/CVE-2026-89891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free of dev_next->devlist on disconnect When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 (\"USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89892", "url": "https://ubuntu.com/security/CVE-2026-89892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: defer audio-only extension registration The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89893", "url": "https://ubuntu.com/security/CVE-2026-89893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: cancel NetUP CI work before teardown netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state. netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state. Call cancel_work_sync() before dvb_ca_en50221_release() and kfree(). This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89894", "url": "https://ubuntu.com/security/CVE-2026-89894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: reject geometry changes while the VBI queue is busy vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: \toffset = lines_completed * (dev->width << 1) + ...; \tif (dma_q->current_field == 2) \t\toffset += dev->width * 2 * dma_q->lines_per_field; \tmemcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89895", "url": "https://ubuntu.com/security/CVE-2026-89895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cobalt: Avoid freeing ALSA private data twice snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89896", "url": "https://ubuntu.com/security/CVE-2026-89896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: fix memory leak in cedrus_init_ctrls() In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89897", "url": "https://ubuntu.com/security/CVE-2026-89897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: Serialize exclusive follower delivery cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89898", "url": "https://ubuntu.com/security/CVE-2026-89898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: extron-da-hd-4k-plus: add sanity check Add check to prevent overflowing msg.msg[] in case the incoming data is malformed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89899", "url": "https://ubuntu.com/security/CVE-2026-89899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: disable delayed work before freeing an interrupted transmit cec_transmit_msg_fh() drops adap->lock to wait for a blocking transmit in wait_for_completion_killable(). If that wait is interrupted by a signal, cancel_delayed_work_sync() can run before the CEC kthread arms the reply timeout via schedule_delayed_work(&data->work) in cec_transmit_done_ts(). The work is then armed after the cancel, and the data is freed with its delayed_work still pending: ODEBUG: free active (active state 0) object: ... hint: cec_wait_timeout Use disable_delayed_work_sync(): it cancels the work and disables it, so the later schedule_delayed_work() becomes a no-op and the work cannot be re-armed. The data is freed right after, so it need not be re-enabled.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89901", "url": "https://ubuntu.com/security/CVE-2026-89901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89902", "url": "https://ubuntu.com/security/CVE-2026-89902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: Avoid preempt count underflow without probe LoongArch uses break 11 for the breakpoint placed after an instruction that Kprobes executes out of line. Since userspace can issue the same break instruction, do_bp() can reach kprobe_singlestep_handler() when there is no current probe. The handler actually returns false in this case, but it first calls preempt_enable_no_resched(). The corresponding preempt_disable() is done by kprobe_breakpoint_handler() on a real Kprobe hit, so it has not run here. As a result, an ordinary userspace breakpoint (code 11) underflows the current task's preempt count. This also makes in_interrupt() return true until the task schedules. One visible consequence is the socket cgroup attribution: cgroup_sk_alloc() treats the allocation as interrupt context and assigns the socket to the root cgroup. A socket opened from the SIGTRAP handler can then avoid a BPF_CGROUP_INET_SOCK_CREATE policy attached to the task's own cgroup. Return as soon as kprobe_running() reports no active probe. The same check has appeared in [PATCH v10 2/4] of the original LoongArch Kprobes series, but was dropped before the feature reached mainline.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89903", "url": "https://ubuntu.com/security/CVE-2026-89903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: Do not save/restore percpu base register in rethook trampoline The rethook trampoline saves $r21 ($u0), the percpu base, into its frame at entry and restores it at exit. Inbetween rethook_trampoline_handler() may schedule via preempt_enable_notrace(). If the task migrates to another CPU, the frame's $r21 holds the old CPU's percpu base, and restoring it poisons $r21 on the new CPU. Until the next user->kernel transition heals $r21, all this_cpu_*() accesses (runqueues, RCU per-CPU data, timer tick programming, FPU ownership) hit the wrong CPU's percpu area. Under kretprobe-heavy preemptible load this can corrupt scheduler and timer state: scheduling-while-atomic splats, wrong-CPU RCU warnings, WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), and CPUs parking in the idle loop with the constant timer never re-armed (hard lockup). Reproduces on a Loongson-3A6000 with kretprobes on VFS paths plus heavy file churn (OS install / unsquashfs). By convention $r21 always holds the current CPU's percpu base in kernel mode: SAVE_SOME() at exception entry reloads it only when coming from user mode, and RESTORE_SOME() restores it only when returning to user mode; the context-switch path never writes it. Therefore the live $r21 at trampoline exit is already correct, and nothing inbetween can change it legitimately (kernel C code cannot write a global register variable). The same flaw existed even in the pre-rethook kretprobe trampoline since v6.3; it was carried over when rethook replaced it. Drop both the save and the restore here. Drop the restore is enough to solve the issue, and drop the save is to keep the code tidy and no need to clear it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89904", "url": "https://ubuntu.com/security/CVE-2026-89904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: Fix acpi_package_ids[] array overflow With LoongArch virt machine, a typical setting is one core per socket, there will max 256 sockets (packages) on one VM. With PPTT acpi table, array acpi_package_ids[] will be overflowed. Here change the array size of acpi_package_ids[] with the max value of MAX_PACKAGES and KVM_MAX_VCPUS.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89906", "url": "https://ubuntu.com/security/CVE-2026-89906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Refactor jump offset calculation in tail call The old macro-based jmp_offset calculation derives the jump distance from a stale prior-pass code stride, which can lead to wrong branch offsets and soft lockups under extra JIT passes. Fix this by calculating the offset directly on the absolute target: \"ctx->offset[insn + 1] - ctx->idx\". To avoid a false 16-bit range check abort during size estimation, add a \"ctx->image == NULL\" guard to inject a safe dummy offset.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89908", "url": "https://ubuntu.com/security/CVE-2026-89908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY kvm_arch_prepare_memory_region() computes new->arch.flags, i.e. whether a memslot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE, only for KVM_MR_CREATE and KVM_MR_MOVE, and returns early for every other change. But the generic code allocates a zeroed memslot for every change and never copies old->arch, so after a KVM_MR_FLAGS_ONLY update, e.g. toggling KVM_MEM_LOG_DIRTY_PAGES for live migration, the active memslot has arch.flags == 0. With both flags clear, fault_supports_huge_mapping() falls through to the alignment check on the HVA range alone, which no longer verifies that the GPA and HVA have the same offset within a PMD. A memslot that was marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can then be mapped with PMD entries on read faults, and since kvm_map_page() aligns the gfn and the pfn independently, the guest ends up accessing the wrong host pages, exactly the \"d -> f, e -> g\" case described in the comment above the check. Carry the arch flags over from the old memslot for KVM_MR_FLAGS_ONLY, as the GPA, HVA and size are guaranteed to be unchanged for that case.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89909", "url": "https://ubuntu.com/security/CVE-2026-89909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Free init resources if kvm_init() fails kvm_loongarch_init() calls kvm_loongarch_env_init() to allocate the per-CPU kvm_context (vmcs) and kvm_loongarch_ops and to register the perf callbacks, and then calls kvm_init(). If kvm_init() fails its result is returned directly, but since module_init() does not run the module_exit() stuff on failure, so kvm_loongarch_env_exit() is never called and those resources are leaked. So call kvm_loongarch_env_exit() when kvm_init() fails, matching the teardown-on-failure pattern used by riscv_kvm_init().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89911", "url": "https://ubuntu.com/security/CVE-2026-89911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Correctly cap TLBI Range to the architural limit TLB Invalidation by Range has a fairly powerful way of encoding pretty large ranges in a small number of bits. This range can be based on an arbitrary VA, which means it is pretty easy for a guest to generate an overflow should the hypervisor be naive enough to add the range to the base... Make sure the range is capped to the limit dictated by the address bit that determines the VA range. For an IPA invalidation, this is further corrected down the line to ignore the upper range.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89912", "url": "https://ubuntu.com/security/CVE-2026-89912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save MAPC with V=0 drops ite->collection but leaves the ITE on the device's ITT list, and vgic_its_save_ite() dereferences it unconditionally. A guest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the host when the VMM issues KVM_DEV_ARM_ITS_SAVE_TABLES to migrate it. That sequence is UNPREDICTABLE per the architecture, but KVM already handles the resulting state in the translate, MOVI and DISCARD paths. Save a zeroed entry, which vgic_its_restore_ite() reads back as invalid. Skipping the ITE instead would leave the ITT slot holding whatever is in guest memory, and restore rejects an entry naming a collection the restored collection table does not have.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89913", "url": "https://ubuntu.com/security/CVE-2026-89913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-v3: take an LPI reference in vgic_v3_save_pending_tables vgic_v3_save_pending_tables() iterates dist->lpi_xa using xa_for_each() and dereferences the returned struct vgic_irq in the loop body without holding a reference on the LPI. The xarray iterator only provides temporary RCU coverage while looking up the current entry. That is not sufficient for this loop body, which reads fields from struct vgic_irq and performs guest memory accesses before the iteration completes. A concurrent path can trigger this race: the irqfd cached injection path (vgic_its_inject_cached_translation) obtains a transient LPI reference via vgic_its_check_cache() without holding kvm->lock, vcpu->mutex, config_lock, or its_lock. If guest ITS DISCARD then drops the cache and ITE references under its_lock, the transient inject reference may become the final one. When vgic_put_irq() drops it, the LPI is erased from lpi_xa and freed via kfree_rcu(). Meanwhile, vgic_v3_save_pending_tables() may still hold a stale pointer obtained from the xarray iterator and dereference it after the RCU grace period completes. Fix this by re-fetching each iterated LPI via vgic_get_irq(), which takes a stable reference, and dropping it with vgic_put_irq() on all paths. This matches the pattern already used by other lpi_xa iterators in the vgic ITS code.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89914", "url": "https://ubuntu.com/security/CVE-2026-89914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Sign-extend VA for range-based TLBI invalidation When the decode_range_tlbi() helper was moved to be used for S1 TLBIs, the required sign extension was omitted. Add it. As a result, special care must be taken to not overflow PA bits when this is used for S2 invalidation.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89916", "url": "https://ubuntu.com/security/CVE-2026-89916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry A VNCR TLB invalidation can occur on one vcpu while another vcpu is faulting in this same page. Without correctly handling this, we can end up with the following scenario: - vcpu A walks the PTs to translate VNCR - before vcpu A is able to grab the MMU lock to insert the TLB, vcpu B updates the S1 PTs with an invalid entry, and issues a TLBI S1E2 for this VA - vcpu A inserts the TLB for something that is now invalid This isn't a new problem, and we manage S2 by having the MMU notifier to bump up mmu_invalidate_seq on invalidation so that the fault can be replayed. We can perform something similar here, and extend invalidate_vncr_va() to update the same counter, clearly indicating that the context has changed under our feet. This is safe as the invalidation always happen while holding the MMU lock for write, and that we sample the sequence number before walking S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89918", "url": "https://ubuntu.com/security/CVE-2026-89918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Correctly handle end of VA space TLBI invalidation Our TLB invalidation by VA code is based on comparing two ranges, one defined by the TLB, and one defined by the TLBI instruction. Each range is defined by a start and a size. However, the way the comparison is done doesn't account for address rollover, as it compares an address with (base + size). This works nicely until this expression represent the last page/block in the TTBR1 VA space, as the result is a big fat 0. And a failed TLB invalidation. Rewrite the comparison in a way that is immune to the address rollover (making the end address inclusive instead of exclusive), and move this into a common helper that is used by both VA and IPA invalidations, as suggested by Hyunwoo Kim (although the IPA version didn't suffer from this particular problem, obviously).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89775", "url": "https://ubuntu.com/security/CVE-2026-89775", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation Computing the effects of a TLB invalidation involves looking at the size of the mapping cached by the TLB. For S1 mappings such as VNCR, this is deducted from the combination of the base granule size and the mapping level. However, this implies that the S1 MMU is *on*. When the MMU is off, we indicate this with the level being set to a \"creative\" value of -127 (S1_MMU_DISABLED). This ends-up being misinterpreted by pgshift_level_to_ttl() as it doesn't handle negative levels at all (the level is immediately cast to a u8 and only the bottom two bits considered), leading to an invalidation size of 0. Not helpful. Tidy-up pgshift_level_to_ttl() to handle these negative levels, and ttl_to_size() to always return SZ_1G when no valid TTL is present. This allows the removal of open-coded checks for similar situations. Note that the check for a negative value not explicitely checking for S1_MMU_DISABLED is deliberate, so that actual negative levels introduced with LVA2 and D128 can take the same path if we ever support them.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89920", "url": "https://ubuntu.com/security/CVE-2026-89920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory corruption by not reinjecting CK machine checks Channel-subsystem damage machine checks are for the host channel subsystem. The guest channel subsystem is emulated in the userspace VMM. There is no point in forwarding such machine checks into the guest. This also simplifies the machine check reinjection and avoids kfree of a stack variable as reported by sashiko. There might be still machine checks that have the ck bit set with another bit (like instruction damage), mask out the CK bit in s390_backup_mcck_info(), like the CP and ED bits already are.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89922", "url": "https://ubuntu.com/security/CVE-2026-89922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Take srcu when importing watchpoint data __import_wp_info() backs up the original guest memory contents of a watchpoint with read_guest_abs(), which is kvm_read_guest() and therefore resolves the memslot via __kvm_memslots(). That requires kvm->srcu (or kvm->slots_lock) to be held, otherwise a concurrent memslot update can free the memslots array under us once its SRCU grace period has elapsed. As this is not fast path, following lock ordering (mutex first, then srcu) take the big hammer and hold the srcu for the full import.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89923", "url": "https://ubuntu.com/security/CVE-2026-89923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Free guest debug data on vcpu destroy kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89924", "url": "https://ubuntu.com/security/CVE-2026-89924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix old_data leak in guest debug error path __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89925", "url": "https://ubuntu.com/security/CVE-2026-89925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory leak in guest debug handling bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89926", "url": "https://ubuntu.com/security/CVE-2026-89926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix length check __import_wp_info() struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: \twp_info->len = bp_data->len; \t[...] \tif (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) \t\treturn -EINVAL; \twp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89927", "url": "https://ubuntu.com/security/CVE-2026-89927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89928", "url": "https://ubuntu.com/security/CVE-2026-89928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Consume the locked rmap value in the lockless rmap walk __kvm_rmap_lock() deliberately elides the rmap lock when it observes an empty rmap. In that case kvm_rmap_lock_readonly() also re-enables preemption and returns zero, so the caller holds neither the rmap lock nor a preemption reference. The elision documents the invariant it relies on: \t * Elide the lock if the rmap is empty, as lockless walkers (read-only \t * mode) don't need to (and can't) walk an empty rmap, nor can they add \t * entries to the rmap. I.e. the only paths that process empty rmaps \t * do so while holding mmu_lock for write, and are mutually exclusive. kvm_rmap_age_gfn_range() ignores the returned value and unconditionally enters for_each_rmap_spte_lockless(). The iterator started with rmap_get_first(), which re-reads rmap_head->val rather than using the value returned by the lock. If a writer populates the rmap between the lock's read and the iterator's re-read, the aging path walks the newly installed rmap without holding its lock. For a KVM_RMAP_MANY rmap this leaves the walker following a pte_list_desc chain that it never locked. A writer holding mmu_lock for write may free that chain (e.g. kvm_zap_all_rmap_sptes() on the recycle path, or any rmap zap) via kmem_cache_free() while the walk is in progress, giving a slab use-after-free. Nothing serialises the two: the aging path runs without mmu_lock when CONFIG_KVM_MMU_LOCKLESS_AGING=y, and the rmap lock that would otherwise exclude the writer was elided. Because the empty path re-enables preemption, the interval between the two reads can span an arbitrary scheduling delay. Fix the class of bug by having the lockless walk consume the value returned by the lock instead of re-reading the rmap. Split rmap_get_first() into __rmap_get_first(), which starts an iterator from an already-read rmap value, and make for_each_rmap_spte_lockless() take that value and call __rmap_get_first() directly. kvm_rmap_age_gfn_range() passes the value returned by kvm_rmap_lock_readonly(): when the lock was elided the value is zero, __rmap_get_first() returns NULL, and the walk is skipped. No lockless walker re-reads the rmap, so the lock-elision invariant cannot be violated, and no lock()-without-paired-unlock() path is added to the aging code.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89929", "url": "https://ubuntu.com/security/CVE-2026-89929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU When emulating INVVPID, KVM executes INVVPID on the physical CPU using vpid02 (instead of the L1 assigned VPID), after doing some validations on the operands. However, it is possible that the physical CPU KVM executes INVVPID on is different from the CPU L2 is running on. For example, in the following scenario: - L2 runs on CPU #1 and exits to L1 (vmx->nested.vmcs02.cpu=1) - L1 migrates to CPU #2 and executes INVVPID - KVM executes INVVPID on CPU #2 - L1 migrates back to CPU #1 and runs L2 (vmx->nested.vmcs02.cpu=1) The TLB entries on CPU #1 are never invalidated, because INVVPID was executed on CPU #2, and vmcs02 never ran on a different pCPU (i.e. vmx_vcpu_load_vmcs() will *not* request KVM_REQ_TLB_FLUSH). Ensure that INVVPID is being executed on the same pCPU that L2 last ran on, and if not, fallback to clearing last_vpid=0 to trigger a full VPID flush on the next nested VM-Enter (as KVM will detect L1 using a different VPID for L2). If L2 ends up running on a different pCPU, KVM will flush the TLB anyway through vmx_vcpu_load_vmcs().", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89930", "url": "https://ubuntu.com/security/CVE-2026-89930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Service local TLB flushes on failed nested VM-Enter KVM services local TLB flushes on \"full\" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition. The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case. More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89931", "url": "https://ubuntu.com/security/CVE-2026-89931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit Always check and clear KVM_REQ_GET_NESTED_STATE_PAGES when emulating a nested VM-Exit to ensure the request is cleared, even when KVM was built with CONFIG_KVM_HYPERV=n, as KVM subtly relies on the \"check\" to clear the flag and thus avoid double-mapping the vmcs12 pages, e.g. if KVM manages to bail from VM-Enter without processing the request, and then emulates VMLAUNCH or VMRESUME.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89932", "url": "https://ubuntu.com/security/CVE-2026-89932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always flush vpid02 on first use Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID. This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM). Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM happens to reuse a VPID that has TLB entries on the physical CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89933", "url": "https://ubuntu.com/security/CVE-2026-89933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: pressure: dps310: fix NULL pointer dereference on ACPI probe When the device is enumerated through its ACPI HID (IFX3100), i2c_client_get_device_id() returns NULL: the ACPI-derived client name does not match the driver's i2c_device_id table. dps310_probe() then dereferences that NULL pointer in \"iio->name = id->name\" and crashes the kernel during probe. The IIO device name is always \"dps310\", so set it directly and drop the now-unused device-id lookup.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89934", "url": "https://ubuntu.com/security/CVE-2026-89934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: ltrf216a: fix runtime PM reference leak in error path ltrf216a_get_lux() acquires a runtime PM reference by calling ltrf216a_set_power_state(data, true). However, if ltrf216a_read_data() fails, the function returns immediately without dropping the reference. This leaves the runtime PM usage count unbalanced, preventing the device from autosuspending after a failed read. Fix this by releasing the runtime PM reference before returning from the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89936", "url": "https://ubuntu.com/security/CVE-2026-89936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: dac: m62332: Fix regulator reference count imbalance m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89937", "url": "https://ubuntu.com/security/CVE-2026-89937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sgp30: Handle IAQ thread creation failure kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89938", "url": "https://ubuntu.com/security/CVE-2026-89938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF The atlas driver requests its hardware data-ready IRQ with devm_request_threaded_irq(); its threaded handler queues an irq_work, atlas_work_handler(), that calls iio_trigger_poll(data->trig). The IRQ is devm-managed, so free_irq() runs from the devres unwind after atlas_remove() returns without flushing that irq_work. Once a buffer is enabled, conversion-complete IRQs keep firing and queueing it; a pending irq_work can therefore run after the unwind has freed atlas_data/indio_dev and the trigger, when atlas_work_handler() derives the atlas_data pointer via container_of() and dereferences data->trig, a use-after-free. Call iio_trigger_poll_nested() directly from the threaded handler instead of bouncing through irq_work. free_irq() then drains the threaded handler, closing the window; other iio drivers with a threaded data-ready IRQ do the same (e.g. bmi270). This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89939", "url": "https://ubuntu.com/security/CVE-2026-89939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89940", "url": "https://ubuntu.com/security/CVE-2026-89940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: buffer: Tie IIO dma fence lock lifetime to the fence The `iio_dma_fence` implementation currently uses a lock embedded in the `iio_dmabuf_priv`. But the `iio_dma_fence` can outlive the `iio_dmabuf_priv`, which can cause a use-after-free. Tie the lifetime of the lock to the lifetime of the fence by embedding them in the same struct. We can't just hold a reference to the `iio_dmabuf_priv` from the `iio_dma_fence` since `iio_buffer_dmabuf_release()` might sleep and the fence release callback is not allowed to sleep. Note that the `dma_fence` framework now has an internal lock that gets used when the passing `NULL` for `lock` in `dma_fence_init()`, but in order to allow this patch to be backportable use an external lock.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89941", "url": "https://ubuntu.com/security/CVE-2026-89941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: buffer: Make IIO DMA fence release RCU-safe The `dma_fence` documentation states that if a custom release implementation is provided, the `dma_fence` object must be freed in an RCU-safe way. The current `iio_dma_fence` implementation uses `kfree()`, which might result in a use-after-free. Remove the custom `release` implementation. This makes the DMA fence core fall back to `dma_fence_free()`, which calls `kfree_rcu()` on the fence. This requires that the fence be the first member of `struct iio_dma_fence`. Using the default release method for extended DMA fence structures is a common pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89942", "url": "https://ubuntu.com/security/CVE-2026-89942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: buffer: Fix potential use-after-free in anonymous buffer release An anonymous buffer handle holds a reference to the underlying IIO device. The reference is dropped in the buffer handle's release function. If the device has been removed, either through unbind or hot-unplug, the buffer handle might hold the last reference. The release function takes the mutex for the buffer using a guard, which means the unlock happens after all the code in the function, including `iio_device_put()`. If the anonymous buffer holds the last reference this might free both the IIO device and the buffer, which contains the mutex, leading to use-after-free when the mutex is unlocked. Fix this by using a scoped guard just around the buffer dmabuf list access, making sure the mutex is unlocked before releasing the IIO device. Version 10 of the patch that introduced this issue used this exact scheme of first unlocking and then dropping the reference [1]. During review it was suggested to use a guard instead, and version 11 made that change [2].", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89943", "url": "https://ubuntu.com/security/CVE-2026-89943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: loongson: Fix error handling in ACPI property parsing In loongson_card_parse_acpi(), the return value of device_property_read_string() for the `codec-dai-name` property was ignored. If the property is missing or invalid, an uninitialized pointer would be used later, potentially leading to undefined behavior. Fix this by checking the return value and propagating the error appropriately.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89944", "url": "https://ubuntu.com/security/CVE-2026-89944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: hdac_hda: Fix hlink refcount leak on component registration failure hdac_hda_dev_probe() gets the HDA link with snd_hdac_ext_bus_link_get() before registering the ASoC component. If component registration fails, the function returns without dropping the link reference. Always call snd_hdac_ext_bus_link_put() after the registration attempt so the reference taken during probe is balanced on both success and failure.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89945", "url": "https://ubuntu.com/security/CVE-2026-89945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l34: drain threaded IRQ before runtime suspend cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89946", "url": "https://ubuntu.com/security/CVE-2026-89946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l33: drain threaded IRQ before runtime suspend cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89947", "url": "https://ubuntu.com/security/CVE-2026-89947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: meson: align gxbb_32k_clk_sel number of parents with actual count The following out-of-bounds read has been observed by Christian on a GXBB WeTek Hub: ================================================================== BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418 Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT Hardware name: WeTek Hub (DT) Call trace: show_stack+0x14/0x20 (C) dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8 __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188 __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 The buggy address belongs to the variable: gxbb_32k_clk_parents+0x60/0x400 The buggy address belongs to a vmalloc virtual mapping The buggy address belongs to the physical page: Memory state around the buggy address: ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 ================================================================== Commit 7915d7d5407c (\"clk: amlogic: gxbb: drop non existing 32k clock parent\") dropped a non-existing clock parent from the gxbb_32k_clk_sel mux but didn't adjust the hard-coded num_parents field. Fix the actual number of parents of that mux by using ARRAY_SIZE instead (avoiding similar problems in future).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89948", "url": "https://ubuntu.com/security/CVE-2026-89948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix freeing of claims on meshif deletion When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89949", "url": "https://ubuntu.com/security/CVE-2026-89949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: avoid unaligned fault in IP extraction Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89950", "url": "https://ubuntu.com/security/CVE-2026-89950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: mcast: linearize skbuff for packet generation batadv_mcast_forw_packet() and batadv_mcast_forw_scrape() is not only called (indirectly) by the unsharing+linearizing batadv_recv_mcast_packet() handler. When it is called (indirectly) by batadv_mcast_forw_mcsend() then it will be unshared but not linearized. The SKB_LINEAR_ASSERT() can therefore cause a fatal BUG(). The linearization should happen during the expansion of the head because the scrape function can be hit already during the initial batadv_mcast_forw_mode() selection code: * batadv_interface_tx * batadv_mcast_forw_mode * batadv_mcast_forw_mode_by_count() * batadv_mcast_forw_push() -> calls batadv_mcast_forw_expand_head() before everything else * batadv_mcast_forw_push_tvlvs() * batadv_mcast_forw_push_dests() * batadv_mcast_forw_push_adjust_padding() * batadv_mcast_forw_scrape()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89951", "url": "https://ubuntu.com/security/CVE-2026-89951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix stale receive device on merged fragments Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches the local mesh interface. Refresh the receive device metadata from the current receive device before running the packet handlers. This keeps internally reinjected merged fragments consistent with the normal receive path after hard interface teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89952", "url": "https://ubuntu.com/security/CVE-2026-89952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: validate ONFI extended parameter page sections nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89953", "url": "https://ubuntu.com/security/CVE-2026-89953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89954", "url": "https://ubuntu.com/security/CVE-2026-89954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: afs: validate v2 image info bounds The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use. Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89955", "url": "https://ubuntu.com/security/CVE-2026-89955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix NULL deref in status_show() during queue probe When vfio_ap_mdev_probe_queue() creates the sysfs attribute group, the queue's driver data has not yet been set. A concurrent read of the 'status' attribute can therefore call dev_get_drvdata() and get NULL, which is then passed directly to vfio_ap_mdev_for_queue() where q->apqn is unconditionally dereferenced, causing a NULL pointer dereference. Fix this by acquiring the update locks before calling sysfs_create_group(). The status_show() function acquires guests_lock before reading the driver data, so any concurrent read will block until after dev_set_drvdata() has been called and the update locks are released. As a bonus, the APQN no longer needs to be read from the queue struct after allocation — it can be read directly from apdev before allocation and stored in a local variable, which is then assigned to q->apqn once the allocation succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89956", "url": "https://ubuntu.com/security/CVE-2026-89956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects In order to traverse or add/remove ap_matrix_mdev objects in the matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held. There are two functions that access the list without holding the mutex: vfio_ap_mdev_probe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock mutex to guard the add of a newly created ap_matrix_mdev object to the matrix_dev->mdev_list. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an ap_matrix_mdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently. The adding of an ap_matrix_mdev object to matrix_dev->mdev_list is now guarded by the matrix_dev->guests_lock which is the correct way to protect against concurrent mdev_list access. Also removed the following two lines of code because the matrix_mdev is allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger and cfg_chg_trigger are already zero-initialised when the struct is allocated before the call to vfio_register_emulated_iommu_dev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace. matrix_mdev->req_trigger = NULL; matrix_mdev->cfg_chg_trigger = NULL; vfio_ap_mdev_for_queue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The status_show function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue function which iterates the matrix_dev->mdev_list to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrix_dev->guests_lock mutex must be held. To fix this, the guests_lock mutex is taken prior to taking the matrix_dev->mdevs_lock mutex in the status_show function. It is taken there rather than the vfio_ap_mdev_for_queue function - where it is needed - because it must be taken prior to the mdevs_lock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevs_lock is needed there to access fields within the matrix_mdev object in that function. See the vfio-ap-locking.rst in the linux kernel tree.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89957", "url": "https://ubuntu.com/security/CVE-2026-89957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removed The vfio_ap_mdev_hot_unplug_cfg() function uses the return value of bitmap_andnot() to determine whether the guest APCB needs to be updated. However, bitmap_andnot() returns false when the resulting destination bitmap is empty. This means that if the only adapter, domain or control domain assigned to an mdev is removed from the host's AP configuration, the bit is correctly cleared from the shadow APCB, but bitmap_andnot() returns false because the result is an empty bitmap. Consequently, do_hotplug remains 0 and vfio_ap_mdev_update_guest_apcb() is never called, leaving the KVM guest with stale hardware access to the unplugged AP devices. Fix this by replacing the bitmap_andnot() return value check with bitmap_intersects() to determine whether the shadow APCB actually overlaps with the removal mask. If there is an intersection, call bitmap_andnot() solely for its side effect of clearing the bits, then unconditionally set do_hotplug to trigger the guest APCB update.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89958", "url": "https://ubuntu.com/security/CVE-2026-89958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL The ap_driver structure has two fields which are function pointers to callbacks: * .on_config_changed: called at the start of the AP bus scan function to notify the device driver that the host AP configuration has changed and the associated AP devices will be added or removed accordingly. This gives the implementor a chance to evaluate the configuration changes and respond to them before the associated devices are added or removed. * .on_scan_complete: Called at the end of the AP bus scan function to notify the device driver that the host AP configuration has changed and the AP devices have been added or removed accordingly. This gives the implementor the opportunity to respond to the changes after the associated devices are added or removed. These two callbacks are implemented in the vfio_ap device driver via the vfio_ap_on_cfg_changed and vfio_ap_on_scan_complete functions respectively. Within the call stack of these two callback functions the matrix_mdev->kvm->lock mutex is taken without checking whether matrix_mdev->kvm is NULL or not. If matrix_mdev->kvm has never been set, trying to take the lock will trigger a NULL pointer dereference. This patch adds checks for matrix_mdev->kvm == NULL before taking the matrix_mdev->kvm->lock mutex. Note that the matrix_mdev->kvm->lock mutex taken in the vfio_ap_mdev_hot_plug_config function is moved to the calling function along with the matrix_dev->mdevs_lock which is needed there to access the fields of the matrix_mdev. It makes little sense to make the change the check for matrix_mdev->kvm there before taking the kvm->lock mutex only to have to move it out via another patch, so it is done in this patch. It is important to make note of the following: 1. The matrix_dev->guests_lock is acquired at the start of both callback functions. This ensures that matrix_mdev will not be removed via the vfio_ap_mdev_remove function because it too takes matrix_dev_guests_lock before removing the object; so, matrix_mdev will be available for the duration of the callback functions. 2. The matrix_dev->mdevs_lock mutex must be taken in order to access fields within the matrix_mdev structure 3. matrix_mdev->kvm->lock mutex must be taken before the matrix_dev->mdevs_lock to prevent a lockdep splat. 4: The kvm->lock must be held while plugging the guest's AP configuration into its SIE state description via the vfio_ap_mdev_update_guest_apcb function. 5. The vfio_ap_mdev_update_guest_apcb checks matrix_mdev->kvm to verify it is not NULL before doing the hot plug of the guest's AP configuration.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89959", "url": "https://ubuntu.com/security/CVE-2026-89959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove The vfio_ap_config_remove function uses the bitmap_andnot function to clear bits from the matrix_mdev->matrix.adm bitmap (specifies the control domains assigned to the mdev). This prevents the explicitly unplugged control domains from being removed the KVM guest. The bitmap_and function is used instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89960", "url": "https://ubuntu.com/security/CVE-2026-89960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm() In vfio_ap_mdev_set_kvm(), kvm->arch.crypto.pqap_hook is set to &matrix_mdev->pqap_hook before the update locks are acquired and the mdev list is checked for a conflicting assignment. If another mdev is already attached to the same KVM instance, the function returns -EPERM without restoring the hook pointer, leaving kvm->arch.crypto.pqap_hook pointing at the failing matrix_mdev instead of the mdev that legitimately owns the KVM. Since matrix_mdev->kvm is never set on this error path, vfio_ap_mdev_unset_kvm() will not clean up the hook when matrix_mdev is later closed. If matrix_mdev is subsequently freed, any PQAP instruction executed by the guest will dereference the stale pointer through pqap_hook_rwsem, resulting in a use-after-free. Since kvm->arch.crypto.pqap_hook is only set in the vfio_ap_mdev_set_kvm() function and is cleared in the vfio_ap_mdev_unset_kvm() function, a check for 'kvm->arch.crypto.pqap_hook != NULL' is all that is needed to determine whether it belongs to another mdev. This will alleviate the need to iterate the matrix_dev->mdev_list list to see if the kvm object is assigned to another mdev.This was introduced in v3 to alleviate the need to take the mdevs_lock while iterating the list; however, this did not prevent a potential race condition. The pqap_hook_rwsem(write) is now performed inside get_update_locks_for_kvm(), which is updated to acquire pqap_hook_rwsem(write) between kvm->lock and mdevs_lock. This ordering is consistent with the PQAP intercept path, which acquires pqap_hook_rwsem in read mode while srcu is held under vcpu->mutex, establishing the dependency: kvm->lock -> vcpu->mutex -> srcu -> pqap_hook_rwsem(read). The pqap_hook_rwsem is now released inside the release_update_locks_for_kvm(), which is updated to release pqap_hook_rwsem(write) between mdevs_lock and kvm->lock. Additionally, kvm_put_kvm() in vfio_ap_mdev_unset_kvm() is moved after release_update_locks_for_kvm(). Previously it was called while kvm->lock was held; if it were ever the last reference, kvm_destroy_vm() would run under kvm->lock, which would deadlock.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89961", "url": "https://ubuntu.com/security/CVE-2026-89961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population vmemmap_populate_compound_pages() uses addr_pfn to determine the PFN offset within a compound page and to decide whether the current vmemmap slot should be populated as a head page mapping or should reuse a tail page mapping. However, addr_pfn is advanced manually in parallel with addr. The loop itself progresses in vmemmap address space, so each PAGE_SIZE step in addr covers PAGE_SIZE / sizeof(struct page) struct page slots. Since addr_pfn is compared against nr_pages in data-PFN units, it should advance by the same number of PFNs. The existing manual increments do not match that and therefore do not reliably track the PFN corresponding to the current addr. As a result, pfn_offset can be computed from the wrong PFN and the code can make the head/tail decision for the wrong compound-page position. Fix this by deriving addr_pfn directly from the current vmemmap address instead of carrying it as loop state.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89962", "url": "https://ubuntu.com/security/CVE-2026-89962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/kexec_file: Prevent kexec range truncation Sashiko AI review pointed out the following issue. The __merge_memory_ranges() function incorrectly handles overlapping memory ranges when merging them. Although sort_memory_ranges() sorts all ranges by their start address in ascending order beforehand, the merge logic remains defective in two ways: 1. It compares the current range's start against the previous element (i-1) instead of the running target index (idx) 2. It unconditionally overwrites 'ranges[idx].end' with 'ranges[i].end'. This logic flaw leads to critical memory truncation when a larger memory range completely subsumes subsequent smaller ranges. For example, consider a sorted input array with three ranges: Range A (idx=0): [0x1000 - 0x9000] Range B (i=1): [0x2000 - 0x5000] (completely inside Range A) Range C (i=2): [0x6000 - 0x8000] (completely inside Range A) 1. When i=1 (Range B): ranges[1].start (0x2000) <= ranges[0].end + 1 (0x9001) is TRUE. The code executes: ranges[0].end = ranges[1].end, which erroneously shrinks Range A's end from 0x9000 down to 0x5000. 2. When i=2 (Range C): ranges[2].start (0x6000) <= ranges[1].end + 1 (0x5001) is FALSE. The code falls into the else block, creating a broken new range. As a result, valid memory fragments [0x5001 - 0x5fff] and [0x8001 - 0x9000] are completely lost from the kexec exclude lists, potentially allowing the crash kernel to overwrite active memory, causing data corruption or crashes. Fix this by ensuring the start of the current range is compared against the end of the active merged range (idx), and use max() to safely prevent the outer boundary from being truncated.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89963", "url": "https://ubuntu.com/security/CVE-2026-89963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/kexec_file: Fix null-ptr-def in extra size calculation A static Sashiko AI review identified a potential NULL pointer dereference in kexec_extra_fdt_size_ppc64(). On platforms without any reserved memory regions, get_reserved_memory_ranges() can return 0 while leaving 'rmem' unallocated as NULL. Passing it directly leads to a kernel panic when evaluating 'rmem->nr_ranges'. Add a NULL check for 'rmem' to prevent this crash.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89964", "url": "https://ubuntu.com/security/CVE-2026-89964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: eisa: Fix infinite loop when parsing invalid IRQ value When an invalid value is passed via the \"eisa_irq_edge=\" kernel command line parameter (e.g. \"eisa_irq_edge=16,5\"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89965", "url": "https://ubuntu.com/security/CVE-2026-89965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: reject an arena whose nfree is below the lane count The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89968", "url": "https://ubuntu.com/security/CVE-2026-89968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: reject unsolicited H2CData PDUs nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the \"list_add double add\" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89969", "url": "https://ubuntu.com/security/CVE-2026-89969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as \tqueue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89970", "url": "https://ubuntu.com/security/CVE-2026-89970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: Synchronize timeout work during SQ teardown nvmet_auth_sq_free() cancels auth_expired_work with cancel_delayed_work(). If the work has already started, cancellation does not wait for the callback. Transport teardown can consequently free or reuse the queue containing struct nvmet_sq while nvmet_auth_expired_work() still accesses that SQ. Add a teardown-specific helper that synchronously drains the delayed work before freeing authentication state, and use it from nvmet_sq_destroy(). Keep the non-synchronous helper for in-band authentication state cleanup, where the SQ owner remains alive.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89972", "url": "https://ubuntu.com/security/CVE-2026-89972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: add missing SRCU grace period in error path nvme_alloc_ns() error path at out_unlink_ns removes ns from the namespace head siblings list with list_del_rcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs. The normal removal path in nvme_ns_remove() correctly calls synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for in-progress readers. Add the same grace period in the error path.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89973", "url": "https://ubuntu.com/security/CVE-2026-89973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: check the data direction of a C2HData PDU nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89974", "url": "https://ubuntu.com/security/CVE-2026-89974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails nvmf_create_ctrl() owns the fabrics options and frees them whenever ->create_ctrl() returns an error, so a transport must not free them on its own error paths. nvme-fc tracks this by testing ctrl->ctrl.opts in nvme_fc_ctrl_free(), which requires nvme_fc_init_ctrl() to clear that pointer on every error exit. The coupling is implicit, and commit 1a9e218195a5 (\"nvme: split device add from initialization\") broke it by adding a second error exit. When nvme_add_ctrl() fails, nvme_fc_init_ctrl() jumps to out_put_ctrl:, past the \"ctrl->ctrl.opts = NULL\" that only sits on the fail_ctrl: path, so nvme_fc_ctrl_free() frees the options and nvmf_create_ctrl() frees them a second time: BUG: KASAN: slab-use-after-free in nvmf_free_options+0x30/0x190 nvmf_free_options+0x30/0x190 drivers/nvme/host/fabrics.c:1284 nvmf_create_ctrl drivers/nvme/host/fabrics.c:1374 [inline] Freed by task 5534: nvme_fc_ctrl_free drivers/nvme/host/fc.c:2374 [inline] nvme_fc_init_ctrl+0xe17/0x1450 drivers/nvme/host/fc.c:3605 nvme_add_ctrl() fails when dev_set_name() cannot allocate, so this is reachable under memory pressure or fault injection. Without KASAN the options are freed twice. Rather than clear the pointer on the second exit as well, derive ownership the way nvme-tcp, nvme-rdma and nvme-loop do, from list membership: their free_ctrl leaves the options alone unless the controller made it onto the transport list. The list cannot simply be populated on the success path as it is there. nvme-fc runs the initial connect synchronously via flush_delayed_work(), and the controller has to be reachable on rport->ctrl_list for the whole of it: nvme_fc_unregister_remoteport() needs to find it to signal connectivity loss, nvme_fc_match_disconn_ls() matches an incoming Disconnect Association LS against ctrl->association_id, which is only assigned during that window, nvme_fc_resume_controller() needs it on remoteport re-registration, and nvme_fc_existing_controller() uses it to reject a duplicate connect racing the one in flight. Keep the insertion where it is and add a fail_unlist: label, falling into fail_ctrl:, for the error paths that run after it. The earlier error paths never reach the insertion and keep using fail_ctrl: directly, so the list is only touched where the controller is actually on it. nvme_fc_ctrl_free() cannot use the plain \"goto free_ctrl\" the other transports use, because it still has to put_device(), release the rport reference and free the ida entry for resources taken before the insertion. Sample list_empty() under rport->lock instead. ctrl->ctrl.opts also stays valid for the whole teardown now. That is not the bug being fixed, but it removes some fragility around the old idiom: nvme_free_ctrl() calls nvme_auth_free() before ->free_ctrl(), and ctrl_max_dhchaps() dereferences ctrl->opts without a NULL check when ctrl->dhchap_ctxs is set, which nvme-fc permits since NVMF_ALLOWED_OPTS allows the dhchap options. The nvme sysfs attributes that dereference ctrl->opts, such as hostnqn and address, evaluate their is_visible() test once at device_add() time and stay readable until cdev_device_del().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89975", "url": "https://ubuntu.com/security/CVE-2026-89975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fabrics: fix DHCHAP secret leak on parse failure nvmf_parse_options() duplicates dhchap_secret and dhchap_ctrl_secret with match_strdup() before validating the DHHC-1: representation. If validation fails, the parser returns -EINVAL before the temporary string in p is assigned to opts->dhchap_secret or opts->dhchap_ctrl_secret. nvmf_create_ctrl() subsequently frees opts, but nvmf_free_options() cannot release the unassigned temporary string. Each rejected option therefore leaks one allocation. This is easy to miss because valid secrets transfer ownership to opts and are freed normally, while the malformed-secret path still returns the expected -EINVAL to userspace. With CONFIG_NVME_HOST_AUTH enabled, the leak is reachable before the required-option checks and transport lookup. No NVMe-oF target or working transport connection is required; for example, repeatedly writing \tdhchap_secret=BAD or \tdhchap_ctrl_secret=BAD to /dev/nvme-fabrics deterministically takes the leaking parse path. Free the temporary string before leaving both validation error paths. Use kfree_sensitive() because the copied option may contain secret material even when its representation is rejected, matching the sensitive cleanup used for stored DHCHAP secrets.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89979", "url": "https://ubuntu.com/security/CVE-2026-89979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race between non-atomic ops and trigger-start We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89980", "url": "https://ubuntu.com/security/CVE-2026-89980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: harmony: initialize locks before requesting IRQ snd_harmony_create() registers the IRQ before initializing h->lock and h->mixer_lock. A pending interrupt can invoke the handler while these locks are uninitialized. Initialize both locks before requesting the IRQ so the handler always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89982", "url": "https://ubuntu.com/security/CVE-2026-89982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89983", "url": "https://ubuntu.com/security/CVE-2026-89983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89984", "url": "https://ubuntu.com/security/CVE-2026-89984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \\ \t./perf bench syscall basic --loop 1000 | \\ \t./perf script -i - --fields brstack|tr ' ' '\\n'| \\ \tgrep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90048", "url": "https://ubuntu.com/security/CVE-2026-90048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list() ni_create_attr_list() allocates a fixed buffer of al_aligned(record_size) (== record_size) bytes and then walks every attribute of the primary MFT record, writing one ATTR_LIST_ENTRY per attribute and advancing the cursor by le_size(name_len), with no check against the end of the buffer; the total size is only computed after the loop. A minimum-size resident attribute occupies SIZEOF_RESIDENT (0x18 = 24) bytes on disk, but an unnamed attribute expands to le_size(0) (0x20 = 32) bytes in the list. Because the number of attributes in a record is not bounded (mi_enum_attr() accepts arbitrarily many equal-type, nameless minimum-size attributes), a crafted record packed with such attributes produces a list larger than record_size and overflows the heap buffer. This is reachable from a crafted, loop-mounted NTFS image: opening the file and adding an attribute (e.g. via setxattr) drives ntfs_set_ea() -> ni_insert_resident() -> ni_insert_attr() -> ni_ins_attr_ext() -> ni_create_attr_list(). BUG: KASAN: slab-out-of-bounds in ni_create_attr_list+0xc48/0x1058 Write of size 4 at addr ffff000008984c00 by task setfattr/345 ni_create_attr_list+0xc48/0x1058 ni_ins_attr_ext+0x510/0x7c0 ni_insert_attr+0x3f8/0x70c ni_insert_resident+0xc8/0x3b0 ntfs_set_ea+0x66c/0xd28 ntfs_setxattr+0x4d8/0x5b0 __arm64_sys_setxattr+0xa4/0x124 Allocated by task 345: ni_create_attr_list+0x188/0x1058 The buggy address belongs to the cache kmalloc-1k of size 1024 (the write lands at object+1024). Size the buffer from the actual attributes instead of assuming a single record_size is always enough.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89986", "url": "https://ubuntu.com/security/CVE-2026-89986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix sleeping allocation in alloc_pages_bulk_weighted_interleave() syzbot reported a sleeping function called from invalid context splat in bucket_table_alloc(). When rhashtable_insert_slow() rehashes the table under rcu_read_lock(), it calls bucket_table_alloc(..., GFP_ATOMIC | __GFP_NOWARN). If the bucket table allocation uses vmalloc, __vmalloc_node_range_noprof() invokes vm_area_alloc_pages() -> alloc_pages_bulk_mempolicy_noprof() with the passed GFP_ATOMIC flags. If the current task has an MPOL_WEIGHTED_INTERLEAVE mempolicy, alloc_pages_bulk_weighted_interleave() is called and currently hardcodes GFP_KERNEL when allocating the temporary weights array, triggering a might_alloc() splat in atomic/RCU contexts. Pass the gfp flags (masked with GFP_RECLAIM_MASK to strip page-allocator zone modifiers like __GFP_HIGHMEM) received by alloc_pages_bulk_weighted_interleave() to kmalloc() instead of hardcoding GFP_KERNEL. Since the weights buffer is immediately initialized in full, kmalloc() is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89988", "url": "https://ubuntu.com/security/CVE-2026-89988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kprobes: Protect kprobe_blacklist with RCU __within_kprobe_blacklist() traverses kprobe_blacklist without holding kprobe_mutex. When a module is unloaded, kprobe_remove_area_blacklist() removes blacklist entries and immediately frees them with kfree(). A concurrent call to within_kprobe_blacklist() can therefore dereference freed memory. Furthermore, within_kprobe_blacklist() can be called in atomic or non-preemptible contexts where the sleeping kprobe_mutex cannot be taken. Protect kprobe_blacklist with RCU. Use guard(rcu)() and list_for_each_entry_rcu() for traversal, list_add_tail_rcu() for insertions, list_del_rcu() for deletions, and kfree_rcu() to reclaim entries safely after a grace period.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89989", "url": "https://ubuntu.com/security/CVE-2026-89989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89990", "url": "https://ubuntu.com/security/CVE-2026-89990", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: lock mutex in ceph_mds_check_access() MDS session OPEN handling replaces mdsc->s_cap_auths under mdsc->mutex, freeing the previous array and its strings. ceph_mds_check_access() traverses this array without holding the mutex. A concurrent session reopen can therefore free the array while it is being inspected, resulting in a use-after-free like this: Unable to handle kernel paging request at virtual address 003aaad64b2c8bb9 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 56 UID: 2953037534 PID: 1253231 Comm: php-cgi8.4 Not tainted 6.18.45-i2-ampere #1146 NONE [..] pc : ceph_mds_check_access+0xd4/0x550 lr : ceph_mds_check_access+0xc8/0x550 [...] Call trace: ceph_mds_check_access+0xd4/0x550 (P) ceph_atomic_open+0x138/0xbe8 path_openat+0xa24/0xfa8 do_filp_open+0x94/0x158 do_sys_openat2+0x88/0xf8", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89991", "url": "https://ubuntu.com/security/CVE-2026-89991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix infinite loop in pcpu_freelist push with one possible CPU __pcpu_freelist_push() can loop forever when only one CPU is possible and an NMI re-enters pcpu_freelist_push() while the interrupted context holds that CPU's freelist lock. After the current-CPU fast path fails, the fallback loop walks cpu_possible_mask while skipping the current CPU. With CONFIG_SMP=n, or when an SMP kernel is limited to one possible CPU with nr_cpus=1 or possible_cpus=1, there are no other possible CPUs to examine. The loop therefore makes no lock acquisition attempt and can never make progress. The following stack was observed on a UP system: NMI context: pcpu_freelist_push free_htab_elem htab_map_delete_elem [perf-event BPF program] __perf_event_overflow perf_event_nmi_handler exc_nmi Interrupted context: __pcpu_freelist_push pcpu_freelist_push free_htab_elem htab_map_delete_elem [raw_tp/sys_enter BPF program] __bpf_trace_sys_enter do_syscall_64 raw_res_spin_lock() detects the same-CPU recursive acquisition and returns -EDEADLK, but the subsequent fallback loop has no candidate head on a system with one possible CPU. Restore the extra fallback head that existed before the rqspinlock conversion. Keep the current-CPU fast path, then try the other possible CPUs and finally the extra head. The additional head lets a push, which cannot fail without losing a preallocated element, make progress when the only per-CPU head is held by the interrupted context. Also check the extra head from the pop path so that nodes placed there can be reused.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89992", "url": "https://ubuntu.com/security/CVE-2026-89992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuidle: dt_idle_genpd: kfree() the original name allocation dt_idle_pd_alloc() kasprintf()s the full node path, then points pd->name at kbasename() of that string. dt_idle_pd_free() kfree()s pd->name, which is no longer the start of the allocation. Copy the basename instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89993", "url": "https://ubuntu.com/security/CVE-2026-89993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Initialize IRQ data before requesting IRQs dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89994", "url": "https://ubuntu.com/security/CVE-2026-89994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-edma: tracing: no ptr dereference during log output The fsl edma events store a pointer to a struct fsl_edma_engine in the ringbuffer and dereference it when a log entry is printed. At this time, the pointer may no longer be valid. Event injection can be used to trigger a crash: $ cd /sys/kernel/tracing $ echo 'value = 0' > events/fsl_edma/edma_writeb/inject $ cat trace The log output needs only edma->membase. Add a membase field at the end of the event and use the new field for log output. Keep the existing fields for backward compatibility.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89995", "url": "https://ubuntu.com/security/CVE-2026-89995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dma-direct: return struct page from dma_direct_alloc_from_pool() Commit 5b138c534fda (\"dma-direct: factor out a dma_direct_alloc_from_pool helper\") changed dma_direct_alloc_from_pool() to return the CPU address from dma_alloc_from_pool(). That fits dma_direct_alloc(), but dma_direct_alloc_pages() also uses the helper and expects a struct page *. Fix this by making dma_direct_alloc_from_pool() return the struct page * again, and pass the CPU address back through an out-parameter for the dma_direct_alloc() caller.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89997", "url": "https://ubuntu.com/security/CVE-2026-89997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix resume-vs-remove race If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method. Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free. Fix this bug by refusing to resume if the device is being destroyed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89998", "url": "https://ubuntu.com/security/CVE-2026-89998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix race when loading and unloading a table If the userspace calls two concurrent table load ioctls and one of them succeeds and the other fails, there is a race condition because dm_setup_md_queue walks &md->table_devices without any lock. If the walk races with dm_table_destroy -> free_devices -> dm_put_table_device, there is access to invalid memory. Fix this race by extending the lock over the list walk.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89999", "url": "https://ubuntu.com/security/CVE-2026-89999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: validate report length in wacom_intuos_pro2_bt_irq wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: \twacom_intuos_pro2_bt_pen(wacom); \tif (type == INTUOSP2_BT || type == INTUOSP2S_BT) { \t\twacom_intuos_pro2_bt_touch(wacom); \t\twacom_intuos_pro2_bt_pad(wacom); \t\twacom_intuos_pro2_bt_battery(wacom); \t} else { \t\twacom_intuos_gen3_bt_pad(wacom); \t\twacom_intuos_gen3_bt_battery(wacom); \t} Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] \t(the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT (\"gen3\"): wacom_intuos_gen3_bt_battery() reads data[45], \tso the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 (\"HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq\") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90000", "url": "https://ubuntu.com/security/CVE-2026-90000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: rmi: fix OOB access with undersized RMI reports The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: \tdata->input_report_size = hid_report_len(input_report); \tdata->output_report_size = hid_report_len(output_report); \talloc_size = data->output_report_size + data->input_report_size; \tdata->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); \tdata->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly \"this probe validated the reports\"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90001", "url": "https://ubuntu.com/security/CVE-2026-90001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: bpf: serialize device reference release in struct_ops destroy path __hid_bpf_ops_destroy_device() and hid_bpf_unreg() can race on the same registration reference, double-putting struct hid_device and freeing it while hid_destroy_device() still uses it. Serialize the remove/NULL decision under hdev->bpf.prog_list_lock so exactly one path releases each registration reference: unreg re-checks ops->hdev under the lock and returns without putting when the destroy path already cleared it; all put_device() calls happen after the lock is dropped, which is safe because a concurrent unreg then observes ops->hdev == NULL under the lock. Background: each successful attach (hid_bpf_ops_reg) acquires one device reference (hid_get_device()). Two paths can release it: - device destruction: hid_destroy_device() -> hid_bpf_destroy_device() -> __hid_bpf_ops_destroy_device(), which walks hdev->bpf.prog_list under rcu_read_lock() and drops one reference per attached program; - BPF link release: bpf map delete (no BPF_F_LINK) synchronously calls st_ops->unreg() -> hid_bpf_unreg(), which drops the reference for its own registration. The coordination handshake (e->hdev = NULL on the destroy side vs \"if (!hdev) return\" on the unreg side) is a TOCTOU check: the two paths run under different lock domains (rcu_read_lock vs prog_list_lock), so a concurrent unreg can read ops->hdev as non-NULL, block on prog_list_lock, and then proceed while the destroy traversal executes - both paths then drop the same reference. The refcount reaches zero legitimately (each decrement is individually valid), so no refcount_t saturation fires: the device is simply freed while the transport is still inside hid_destroy_device(), and subsequent teardown touches freed memory. The fix serializes the remove/NULL decision under prog_list_lock on both sides and moves the destroy-side puts outside the lock. With the lock held, plain reads/writes of ops->hdev are sufficient; no READ_ONCE/WRITE_ONCE are added, keeping the patch minimal. Unlocked-read safety: the unlocked read of ops->hdev at the top of hid_bpf_unreg() cannot touch a freed device, because the unreg path itself still holds this registration's reference (released only by its own hid_put_device() after the lock is dropped), and a destroy traversal that already cleared ops->hdev makes the lock-internal re-check return early without any put. At most one of the two paths releases each registration reference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90003", "url": "https://ubuntu.com/security/CVE-2026-90003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent rcuwait use-after-free during requeue PI On PREEMPT_RT, FUTEX_CMP_REQUEUE_PI can trigger a KASAN report (slab-out-of-bounds) in futex_requeue_pi_complete() invocation of rcuwait_wake_up(). The futex_q used by futex_wait_requeue_pi() is allocated on the waiter's stack. An early wakeup can race with a PI requeue as follows: waiter requeue task ------ ------------ futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_NONE -> Q_REQUEUE_PI_IN_PROGRESS * timeout/ signal wakes waiter * futex_requeue_pi_wakeup_sync() Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_WAIT requeue_pi_wake_futex futex_requeue_pi_complete() cmpxchg Q_REQUEUE_PI_WAIT -> Q_REQUEUE_PI_LOCKED rcuwait_wait_event() if (atomic_read(&q->requeue_state) != Q_REQUEUE_PI_WAIT) break /* no schedule() */ /* q.pi_state->owner == current */ futex_private_hash_put() /* return from syscall */ rcuwait_wake_up(&q->requeue_wait) /* q is gone */ futex_requeue_pi_complete() publishes Q_REQUEUE_PI_LOCKED before calling rcuwait_wake_up(). The waiter observes this state in rcuwait_wait_event() before invoking schedule() in rcuwait_wait_event(). Here, the waiter is free leave the syscall before requeue task can complete the wake. To address this race skip rcuwait_wake_up() in the Q_REQUEUE_PI_LOCKED case. This state is only published by requeue_pi_wake_futex(), which saves q->task before futex_requeue_pi_complete() and wakes the waiter via wake_up_state(). This wake is intended to wake the waiter from its futex_do_wait() sleep. If the waiter is still sleeping there, it can not get into the Q_REQUEUE_PI_WAIT state (and require this removed wake). Should the waiter be woken up from futex_do_wait() by other means (as in this example) and sleep in futex_requeue_pi_wakeup_sync() then the wake_up_state() from requeue_pi_wake_futex() will wake it, too. Should the waiter task terminate before wake_up_state() had a chance to wake the task then the task pointer does not become invalid because the futex_hash_bucket::lock is held and the task pointer is RCU protected. [bigeasy: Updated comment and commit message]", "cve_priority": "high", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90005", "url": "https://ubuntu.com/security/CVE-2026-90005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: samples/damon/wsse: handle damon_start() failure Patch series \"samples/damon: handle damon_{start,stop}() failures\". All DAMON sample modules are not correctly handling failures from damon_start(). Among those, mtier also has an additional problem for handling of damon_stop() failures. wsse and prcl also have a problem in their damon_call() failure handling. As a result, memory leaks, next DAMON operation disruptions, and use-after-free can happen. Fix those. Note that only the damon_start() failure caused issues can reliably be reproduced. Reproducing those issues require the admin permission, though. This patch (of 6): damon_sample_wsse_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it leaks the memory for DAMON context. Free the context in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo $$ | sudo tee /sys/module/damon_sample_wsse/parameters/target_pid $ echo Y | sudo tee /sys/module/damon_sample_wsse/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the third command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the third and the fourth commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90006", "url": "https://ubuntu.com/security/CVE-2026-90006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: samples/damon/mtier: handle damon_stop() failure damon_sample_mtier_stop() assumes its damon_stop() call will always successfully stops the two DAMON contexts. Hence it deallocates the two DAMON contexts after the damon_stop() call. However, if a given context is already stopped, damon_stop() fails and returns an error while letting the DAMON contexts that have not yet stopped keep running. This kind of unexpected early DAMON context stops could happen due to memory allocation failures in kdamond_fn(). Because damon_sample_mtier_stop() just deallocates all DAMON contexts with damon_target and damon_region objects that are linked to the contexts, the execution of the unstopped DAMON context (kdamond) ends up using the memory that freed (use-after-free). Fix the issue by separating the damon_stop() to be invoked per context. Note that DAMON_SYSFS also allows multiple DAMON contexts execution. But, it calls damon_stop() for each context one by one. Hence this issue is only in mtier. For the long term, it would be better to refactor damon_stop() to always ensure stopping all contexts regardless of the failures in the middle. Make this fix in the current way, though, to keep it simple and easy to backport. I will do the refactoring later. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90007", "url": "https://ubuntu.com/security/CVE-2026-90007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Use rollback index when freeing MSI-X vectors pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90011", "url": "https://ubuntu.com/security/CVE-2026-90011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where \tpadding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90012", "url": "https://ubuntu.com/security/CVE-2026-90012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: Fix DMA mapping ownership on partial map failure If RX mapping fails after TX mapping succeeds, __spi_map_msg() unmaps TX but leaves tx_sg_mapped set. If TX mapping fails on a later transfer, mappings created for earlier transfers remain active. In both cases, cur_{tx,rx}_dma_dev have not yet been updated because they are assigned only after every transfer has been mapped. The subsequent spi_unmap_msg() may therefore unmap the TX mapping again or release earlier mappings using a NULL or stale device. Using a NULL device can trigger an oops. An empty SG table does not prevent the NULL dereference because dma_unmap_sg_attrs() accesses the device before checking the entry count. Publish both mapping devices before mapping starts and unwind all failures through __spi_unmap_msg(). This clears the mapping flags and releases each mapping once with the device that created it. Publishing the devices before the loop also refreshes them when no transfer needs mapping. No mapping flag is set in that case, so current users do not use the pointers as mapping owners.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89793", "url": "https://ubuntu.com/security/CVE-2026-89793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: clear VM_MAYWRITE on read-only ublk char device mmap ublk_ch_mmap() rejects mmap requests with VM_WRITE set, but never clears VM_MAYWRITE on the resulting read-only mapping. This allows a userspace daemon to mmap the per-queue command buffer PROT_READ, then upgrade it to PROT_WRITE via mprotect(), since VM_MAYWRITE was never cleared. The command buffer holds struct ublksrv_io_desc entries that are kernel-written ABI; a writable mapping lets an unprivileged daemon process corrupt fields such as addr, op_flags, nr_sectors, and start_sector. Same bug class as the drm/panthor and drm/vc4 VM_MAYWRITE fixes, and the 2026-08-13 ptp/vmclock fix (a5edadbae57e). Verified via mprotect() PoC: before the fix, a PROT_READ mapping can be upgraded to PROT_READ|PROT_WRITE and a write into the command buffer corrupts io_desc fields (confirmed under KASAN). After the fix, mprotect() returns -EACCES.", "cve_priority": "medium", "cve_public_date": "2026-09-16 10:16:00 UTC" }, { "cve": "CVE-2026-90015", "url": "https://ubuntu.com/security/CVE-2026-90015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90017", "url": "https://ubuntu.com/security/CVE-2026-90017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: \tconst u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); \t... \tc = frame_body[0]; \t... \ta = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90018", "url": "https://ubuntu.com/security/CVE-2026-90018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: \tif (attr_ptr + 4 > wps_ie + wps_ielen) \t\tbreak; \tu16 attr_id = get_unaligned_be16(attr_ptr); \tu16 attr_data_len = get_unaligned_be16(attr_ptr + 2); \tu16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: \tmemcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack \"u8 sr\"/\"u8 selected_registrar\" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The \"attr_ptr + 4 > wps_ie + wps_ielen\" header check above was added by commit 1463ca3ec6601 (\"staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()\"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90019", "url": "https://ubuntu.com/security/CVE-2026-90019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: fix null pointer dereference in usb_put_function_instance() usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90020", "url": "https://ubuntu.com/security/CVE-2026-90020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90021", "url": "https://ubuntu.com/security/CVE-2026-90021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: initialize work in f_midi_alloc() f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc().", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90022", "url": "https://ubuntu.com/security/CVE-2026-90022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi2: fix use-after-free in string attribute show path f_midi2_opts_str_show() takes the string lock internally, but its callers dereference the opts->info. pointer before calling it, outside the lock. This races with f_midi2_opts_str_store(), which frees the old string under opts->lock when the attribute is written concurrently, the show path can read a pointer that gets freed before the lock inside str_show() is even taken. Change f_midi2_opts_str_show() to take a pointer to the string field, matching the existing pattern in f_midi2_opts_str_store(), and dereference it only after the lock is held. Update all three callers (iface_name, block name, and the EP string option macro) accordingly.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90024", "url": "https://ubuntu.com/security/CVE-2026-90024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: midi2: Fix null-pointer dereference in f_midi2_free_ep_reqs A null-pointer dereference occurs in f_midi2_free_ep_reqs() when attempting to clean up an endpoint that was never initialized. When configuring the MIDI 2.0 gadget via configfs and setting the block direction to SNDRV_UMP_DIR_INPUT, the initialization of the midi1_ep_out endpoint is explicitly skipped during the gadget bind phase (f_midi2_bind()). As a result, the usb_ep->card field remains NULL. Later, when the host sets the alternate setting, f_midi2_set_alt() unconditionally stops both the IN and OUT endpoints by calling f_midi2_stop_eps(), which in turn calls f_midi2_free_ep_reqs() for both endpoints. When f_midi2_free_ep_reqs() is called for the uninitialized midi1_ep_out, it attempts to dereference usb_ep->card to determine the number of requests to free, leading to a crash. Fix this by using usb_ep->num_reqs instead of usb_ep->card->info.num_reqs in f_midi2_free_ep_reqs(). usb_ep->num_reqs is correctly set during f_midi2_init_ep() and remains 0 if the endpoint was never initialized, safely avoiding the loop. For consistency, apply the same change to f_midi2_alloc_ep_reqs(). Oops: general protection fault, probably for non-canonical address 0xdffffc00000000ee: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000770-0x0000000000000777] ... RIP: 0010:f_midi2_free_ep_reqs drivers/usb/gadget/function/f_midi2.c:1166 [inline] RIP: 0010:f_midi2_stop_eps+0x28e/0x4d0 drivers/usb/gadget/function/f_midi2.c:1246 ... Call Trace: f_midi2_set_alt+0x11c/0xf00 drivers/usb/gadget/function/f_midi2.c:1296 composite_setup+0x1ffd/0x3480 drivers/usb/gadget/composite.c:1933 configfs_composite_setup+0xbd/0x100 drivers/usb/gadget/configfs.c:1877", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90025", "url": "https://ubuntu.com/security/CVE-2026-90025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix OOB altmode array index The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90026", "url": "https://ubuntu.com/security/CVE-2026-90026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: cancel reset_work on stop pdphy_stop() disables IRQs but leaves reset_work pending. If the IRQ handler schedules it just before disable_irq(), the work runs after remove() frees the struct via devm. Call cancel_work_sync() after disabling IRQs to close the window. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90027", "url": "https://ubuntu.com/security/CVE-2026-90027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic-typec: disable cc_debounce_dwork on stop cc_debounce_dwork is queued from the set_cc() and start_toggling() callbacks, which run from TCPM's kthread worker. port_stop() returns before tcpm_unregister_port() destroys that worker. Flushing the worker during unregister may therefore run a callback which queues the delayed work after port_stop() has returned. The delayed work can then run after devres has freed pmic_typec_port. Use disable_delayed_work_sync() in port_stop() to cancel a pending instance and prevent the TCPM callbacks from queueing another one. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90029", "url": "https://ubuntu.com/security/CVE-2026-90029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: realtek_cr: fix use-after-free on disconnect realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free. Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed. Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90030", "url": "https://ubuntu.com/security/CVE-2026-90030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: clear forceRM when issuing EndTransfer The forceRM bit of the DEPCMD register controls the behavior of the EndTransfer command used to stop an active transfer. Older DWC3 programming guide revisions recommended setting forceRM=1 when issuing EndTransfer. Newer programming guide revisions recommend issuing EndTransfer with forceRM cleared. With forceRM=1 on DWC_usb31 v2.00a and v2.10a controllers, a transfer aborted through the ep_dequeue path was observed to remain active after EndTransfer completion. A subsequent StartTransfer issued on the same endpoint triggered writes associated with the aborted transfer. This resulted in an SMMU fault because the transfer buffer had already been unmapped during EndTransfer command-completion cleanup. Using forceRM=0 eliminates the issue. Although older DWC3 programming guide revisions recommended setting forceRM=1, no issues are known from using forceRM=0. Clear forceRM when issuing EndTransfer to provide consistent EndTransfer behavior and align with newer programming guide recommendations.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90031", "url": "https://ubuntu.com/security/CVE-2026-90031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90032", "url": "https://ubuntu.com/security/CVE-2026-90032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: usbtv: keep device alive while ALSA card exists The ALSA PCM callbacks store the driver state in pcm->private_data. An open PCM file can outlive USB disconnect because usbtv_audio_free() uses snd_card_free_when_closed(). The disconnect path can then drop the V4L2 device reference and free struct usbtv before ALSA releases the substream, so a later close dereferences freed memory in snd_usbtv_pcm_close(). Take a V4L2 device reference for the ALSA card and drop it from the card private_free callback. This keeps struct usbtv valid until ALSA has closed the remaining files and freed the card.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90033", "url": "https://ubuntu.com/security/CVE-2026-90033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90034", "url": "https://ubuntu.com/security/CVE-2026-90034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90035", "url": "https://ubuntu.com/security/CVE-2026-90035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix division by zero in get_estimated_bw() get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3)", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90047", "url": "https://ubuntu.com/security/CVE-2026-90047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Don't hand out the flat CCS storage as usable VRAM get_flat_ccs_offset() reads the base of the flat CCS storage from the hardware, scales it by the number of enabled L3 nodes, and rounds the result up to 128K. Everything below that offset is then handed to the VRAM allocator as usable memory. Rounding a limit that means \"usable memory ends here\" upwards publishes whatever lies between the real base and the rounded one as free memory, and that memory belongs to the compression hardware. The scaled value has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it is not: \tflat CCS base: raw 0x3fafff800, rounded 0x3fb000000 so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator's pool. Whatever is allocated there gets that tail overwritten by the compression hardware, which needs no page-table entry, no buffer object and no GPU submission to do it, and does it before userspace exists. On this machine a Mesa VM's level-3 page table landed on that page on every cold boot. It lost the entry covering the compositor's batch-buffer heap, so the compositor's first submission faulted fetching its batch and gdm restarted it forever: a black screen on an otherwise working machine. Restarting gdm cleared it because the next VM's page tables were allocated somewhere else. Round down instead, to the page size the allocator works in. On this machine that excludes exactly one page. Reading the reserved page afterwards shows what had been writing it: \t[369] 0xcccc000000000000 \t[371] 0xcc77000000000000 \t[373] 0xcccc000000000000 \t[375] 0xcc77000000000000 compression metadata, two bytes per sixteen, sitting where the driver used to hand out memory. The assertion that should have caught this compares the offset against GSMBASE - ccs_size for equality. That value is 128K aligned, so it agrees with the rounded-up offset precisely when the base is not aligned - the check cannot fail in the case it exists to catch, and is compiled out unless CONFIG_DRM_XE_DEBUG is set. Replace it with one that can fail: CCS storage must not run into GSM. [ And this was a debug session from hell, enormously helped by an AI doing much of the grunt-work. I'd like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it. I suspect those things have been trained by people who may not be quite as stubborn as I am. But while the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed. So credit where credit is due and I let the AI write the commit message above. This is basically a one-liner fixing a bogus \"round_up()\" to a \"round_down()\", but there were 24 patches adding more and more debug information to this, and 18 kernel boot to finally narrow it down to this. - Linus ]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90049", "url": "https://ubuntu.com/security/CVE-2026-90049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80724", "url": "https://ubuntu.com/security/CVE-2026-80724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: vmclock: prevent read-only mappings from becoming writable vmclock_miscdev_mmap() rejects writable mappings of the shared vmclock ABI page with -EROFS, but leaves VM_MAYWRITE set. Userspace can map the page read-only and then upgrade it to writable with mprotect(), after which the guest can corrupt the host-written timekeeping data (sequence counter, UTC time, TSC offset) that the vmclock ABI defines as read-only. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 does for its read-only objects and as fixed in drm/vc4 (CVE-2026-68445) and drm/panthor (CVE-2024-53071).", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80914", "url": "https://ubuntu.com/security/CVE-2026-80914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready iso_conn_ready() looks up the BIS listener socket with iso_get_sock(), which takes a reference, and then, without re-checking its state, creates a child socket from it: parent = iso_get_sock(hdev, ...); if (!parent) return; lock_sock(parent); sk = iso_sock_alloc(sock_net(parent), NULL, BTPROTO_ISO, ...); ... iso_chan_add(conn, sk, parent); ... release_sock(parent); sock_put(parent); If the listener socket is closed concurrently, between iso_get_sock() and lock_sock(), the reference taken by iso_get_sock() may be the last one: the close path drops the link-list reference, and once iso_conn_ready() drops its own reference at the end of the function the socket is freed. The child socket, however, is already linked to the freed parent, and a later disconnect of the child runs iso_chan_del() -> bt_accept_unlink(), which dereferences the dangling parent pointer into the freed accept queue (a use-after-free). The same dangling pointer is also dereferenced through parent->***() in iso_chan_del(). Fix it the same way the connected (non-BIS) path was fixed in commit 0d255e63fcf3 (\"Bluetooth: ISO: hold sk properly in iso_conn_ready\"): after taking the socket lock, re-check that the parent is still a listening, alive socket, and bail out otherwise.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80833", "url": "https://ubuntu.com/security/CVE-2026-80833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ss support which is one of the only remaining ones. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. Also, it had a buffer overread bug in the line 'memcpy(ctx->seed, d + dlen, ctx->slen);'. There's no point in fixing these bugs separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80834", "url": "https://ubuntu.com/security/CVE-2026-80834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ce support which is one of the only remaining ones. Note that the sun8i-ce support for hwrng remains in place. That is the interface that actually matters. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. There's no point in fixing this separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80925", "url": "https://ubuntu.com/security/CVE-2026-80925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vlan: fix skb_under_panic and races when toggling HW VLAN offload Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(), which dynamically changed vlandev->hard_header_len. This causes two issues: 1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2) read dev->hard_header_len without holding RTNL lock. Mutating hard_header_len dynamically under RTNL creates a data race where upper layers reserve insufficient headroom based on a stale hard_header_len, resulting in skb_under_panic when vlan_dev_hard_header() is called. 2. In addition, vlan_transfer_features() updated hard_header_len without updating header_ops, causing a mismatch between allocated headroom and header creation. Always setting dev->hard_header_len = real_dev->hard_header_len and dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN unconditionally ensures: - dev->hard_header_len remains 100% static and immutable at real_dev->hard_header_len, eliminating all dynamic runtime updates and data races on hard_header_len. - Upper layers allocating skbs via LL_RESERVED_SPACE() will always reserve sufficient headroom for software VLAN tag insertion (real_dev->hard_header_len + real_dev->needed_headroom + VLAN_HLEN). - vlandev inherits real_dev->needed_tailroom so underlying trailer/padding/ICV requirements are honored. - AF_PACKET SOCK_RAW network header offsets remain correctly aligned at real_dev->hard_header_len. - vlan_header_ops is used unconditionally. Note to stable teams: Make sure to backport these commits: e16e960d55a4 (\"ipvlan: inherit needed_headroom and needed_tailroom from phy_dev\") cef51860becd (\"macvlan: inherit needed_headroom and needed_tailroom from lowerdev\")", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80857", "url": "https://ubuntu.com/security/CVE-2026-80857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: wait for FR_FINISHED on abort_on_kill to prevent use-after-free The abort_on_kill path in request_wait_answer() calls fuse_abort_conn() and returns without waiting for FR_FINISHED. If fuse_dev_do_write() is concurrently processing the same request (FR_LOCKED set), the caller frees req->args while it is still being accessed, causing a use-after-free. Fix this by jumping to the existing wait_event(FR_FINISHED) instead of returning early. The wait will not hang because fuse_abort_conn() ensures all requests are ended.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80858", "url": "https://ubuntu.com/security/CVE-2026-80858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: publish io-uring queues with release semantics fuse_uring_create_queue() initializes a fuse_ring_queue and then publishes the pointer into ring->queues[qid] with WRITE_ONCE() under the fch->lock. There are several readers that may concurrently be fetching that pointer locklessly and then deferencing it. WRITE_ONCE() doesn't ensure ordering of the queue's field initialization before the ring->queues[qid] pointer assignment. The queue must be published with smp_store_release() so the field initialization is guaranteed to happen before. Readers in paths where the read may happen concurrently with the store need to use READ_ONCE() because any race involving a plain access is undefined.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80859", "url": "https://ubuntu.com/security/CVE-2026-80859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix missing barrier when checking io-uring readiness fuse_block_alloc() reads fch->initialized and then fch->io_uring. fch->io_uring is set before fch->initialized, ordered by the smp_wmb() in fuse_chan_set_intialized(), but fuse_block_alloc() has no matching read barrier between the two loads. This may lead a CPU to observe fch->initialized=1 but fch->io_uring=0, and skip the check that blocks request allocation until the io-uring queues are ready. This can reintroduce the lock-order inversion deadlock that commit 3393ff964e0f prevents. Add an smp_rmb() barrier to pair with the smp_wmb() in fuse_chan_set_initialized() to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80860", "url": "https://ubuntu.com/security/CVE-2026-80860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix race between interrupt and resend After commit f8fce75fedf7 (\"fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req\") the WARN_ON(!list_empty(&req->intr_entry)) in fuse_request_free() still triggers due to the following race: In request_wait_answer() if (test_bit(FR_SENT, &req->flags)) -> returns true In fuse_chan_resend() clear_bit(FR_SENT, &req->flags) In request_wait_answer() queue_interrupt(req) Fix by: - move clearing FR_SENT inside fpq->lock - move setting FR_PENDING inside fiq->lock - recheck FR_SENT after acquiring fiq->lock in fuse_dev_queue_interrupt()", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80590", "url": "https://ubuntu.com/security/CVE-2026-80590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 (\"net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list\") and by commit 9e4b7a99a03a (\"net: gso: fix panic on frag_list with mixed head alloc types\") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 (\"tun: Allow GSO using virtio_net_hdr\"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74735", "url": "https://ubuntu.com/security/CVE-2026-74735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: fix tunnel and session refcount leak on seq_file release In pppol2tp_proc_open() and l2tp_dfs_seq_open(), iteration state (pd->tunnel and pd->session) is kept in seq_file private data to allow iteration across multiple read() system calls. However, if userspace closes /proc/net/pppol2tp or /sys/kernel/debug/l2tp/tunnels before reading to end-of-file (EOF), any tunnel or session reference stored in pd->tunnel / pd->session is left un-dropped when seq_file private data is freed. Fix this by dropping any remaining pd->tunnel and pd->session references in pppol2tp_proc_release() and l2tp_dfs_seq_release() when closing the file.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74745", "url": "https://ubuntu.com/security/CVE-2026-74745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: avoid deadlock when canceling IRQ affinity notifier Unregistering IRQ affinity notifiers waits for the callback synchronously. bnxt takes the netdev instance lock in the notifier (to restart the queue) and cancels the work under the same lock. This may obviously deadlock. Move the restart to the async service task. The queue restart isn't super time sensitive. Store the new TPH tag, schedule the task. Safely canceling the service task is already ironed out. In bnxt_request_irq() the order of registering notifier, affinity and initial TPH programming has to be inverted. I think it was racy previously since user may trigger an update as soon as notifier is installed. There's a small known gap - if pcie_tph_get_cpu_st() fails at init and the target tag is 0 we may miss programming the entry. This does not seem worth fixing, the code has skip-on-failure all over the place, anyway.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74747", "url": "https://ubuntu.com/security/CVE-2026-74747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: revalidate ihl to prevent out-of-bounds access While the outer IP header is already pulled into the skb head, we must be careful and revalidate the embedded headers after reading them from the skb frags to prevent out-of-bounds access. One such place reported by Sashiko is ip_vs_nat_icmp() where local process can change the ihl field and after skb_ensure_writable() we can see larger value which is a problem for the ip_send_check(cih) calls. Add check to drop the packet if the ihl field is changed.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74750", "url": "https://ubuntu.com/security/CVE-2026-74750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: defer key slot crypto freeing to workqueue Key slots are released through a kref and the existing release path frees the AEAD transforms from an RCU callback. That is not safe for all crypto implementations: crypto_free_aead can sleep, for example when an async or hardware implementation has teardown work to complete. Use queue_rcu_work for key-slot release. This keeps the RCU grace period needed by lockless key-slot readers, but runs the actual crypto teardown from workqueue context where sleeping is allowed. Once the rcu_work callback runs, pre-existing RCU readers are gone, and the final kref put already proves that no transform user remains, so the worker can release the AEAD transforms and free the slot directly. The previous patch drains ovpn_wq during module exit, so queued key-slot teardown work cannot outlive module text.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74752", "url": "https://ubuntu.com/security/CVE-2026-74752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate cookie AUTH state before use When cookie authentication is disabled, COOKIE_ECHO restores fixed-size AUTH fields directly from peer-controlled cookie bytes. A forged RANDOM length, HMAC list, or CHUNKS list can then reach association consumers with lengths or identifiers that were never validated against the local backing arrays. A forged RANDOM length can cause out-of-bounds reads during key-vector construction. A forged HMAC identifier also caused a 32-byte write past a zero-length AUTH chunk, providing a primitive for a local privilege escalation chain. Validate the cookie's RANDOM, HMACS, and CHUNKS parameters at the cookie trust boundary before copying them into the association. Reject invalid types, malformed lengths, unsupported HMAC identifiers, HMAC lists without SHA1, and forbidden chunk ids.", "cve_priority": "high", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74754", "url": "https://ubuntu.com/security/CVE-2026-74754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: pair EH runtime PM get and put shost->eh_noresume is currently consulted twice in one error handling iteration: once before scsi_autopm_get_host() and once again before scsi_autopm_put_host(). That is racy when a PM-triggered error path flips shost->eh_noresume while the SCSI EH thread is still running. The problem flow looks like this: PM path ufshcd_set_dev_pwr_mode() shost->eh_noresume = 1 ufshcd_execute_start_stop <-- trigger EH ... shost->eh_noresume = 0 EH path scsi_error_handler() if (!shost->eh_noresume) scsi_autopm_get_host() <-- skipped ... if (!shost->eh_noresume) scsi_autopm_put_host() <-- executed later In that case one EH iteration can skip autoresume on entry and still drop a runtime PM reference on exit. That leaves an unmatched runtime PM put and can trigger a runtime PM usage count underflow. Fix this by making eh_noresume a regular bool so it can be accessed with READ_ONCE() and WRITE_ONCE(). Snapshot it once per EH iteration and use that snapshot for both runtime PM get and put decisions.", "cve_priority": "low", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-80521", "url": "https://ubuntu.com/security/CVE-2026-80521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Unlink scc_entry in unix_del_edge(). Kyle Zeng reported that GC could free a dead SCC partially. The scenario is as follows: 1) Create two SCCs: X -. A <-> B ^--' 2) Run the following concurrently: 2-1) send() sk-B to sk-B from sk-X 2-2) close() both A and B At 2-1), there is a small window where unix_add_edges() publishes a new edge (B <-> B) to GC but its skb is not queued by skb_queue_tail(). If 2-2) completes before skb_queue_tail() and GC is triggered, it judges A <-> B as dead, but B is not freed because GC cannot collect the not-yet-queued skb holding the B <-> B edge. X -. A <-> B -. This edge is visible ^--' ^..' but skb is not This itself is not a problem since the next GC run will judge B as dead as well and free it finally. X -. A <.> B -. ^--' ^--' However, X's SCC forces the next GC to call unix_walk_scc_fast(), and it iterates over A through B's scc_entry. Let's unlink scc_entry before freeing the vertex in unix_del_edge().", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80523", "url": "https://ubuntu.com/security/CVE-2026-80523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: spacemit: k3: set hdma clock as critical HDMA clock is responsible for the internal TCM access path of X100 RISC-V core, so set the clock flag as critical to prevent it from being shut off, otherwise the Linux system will hang, for example in the case of a vector instruction access generates a page fault.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80524", "url": "https://ubuntu.com/security/CVE-2026-80524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: optee: ffa: Add NULL check in optee_ffa_lend_protmem Sashiko (locally) reports a possible null dereference under memory pressure due to the lack of validation of the allocated pointer. Fix that by adding the missing check.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80557", "url": "https://ubuntu.com/security/CVE-2026-80557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix OOB read in decode_watchers() via missing bounds check ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80579", "url": "https://ubuntu.com/security/CVE-2026-80579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: clear fb_info->mode before deleting a videomode fb_set_var() can delete a mode from info->modelist when userspace passes FB_ACTIVATE_INV_MODE through FBIOPUT_VSCREENINFO. The code checks that the mode being deleted is not the current info->var and that fbcon is not using it, but it does not check fb_info->mode. fb_info->mode may still point into the modelist entry being deleted. If the entry is freed, later mode sysfs reads through show_mode() can dereference a stale pointer. Clear fb_info->mode before calling fb_delete_videomode() when it matches the mode being removed.", "cve_priority": "low", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80580", "url": "https://ubuntu.com/security/CVE-2026-80580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: bound mode sysfs output to the sysfs buffer mode_string() uses snprintf() which can return a value larger than the remaining buffer space. show_modes() accumulates the return value into i without checking whether i has reached PAGE_SIZE, causing the offset to advance past the sysfs buffer if the modelist is long enough. Add a size parameter to mode_string() and use scnprintf() to return only the bytes actually written. Add an early return when offset already exceeds the buffer. In show_modes(), stop accumulating once the buffer is full.", "cve_priority": "low", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80582", "url": "https://ubuntu.com/security/CVE-2026-80582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/shmem_helper: Check VMA boundaries for PMD mappings In the ->huge_fault handler do not install a PMD huge page mapping if the huge page exceeds the boundaries of the VMA. All other ->huge_fault handlers have similar checks and the resulting mapping will trigger a VM_BUG_ON_VMA() if it ever reaches copy_pmd_range().", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80583", "url": "https://ubuntu.com/security/CVE-2026-80583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses The \"DEC0 MODE\" to \"DEC7 MODE\" controls are enumerated, but tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 (\"ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type\") and commit 0ea5eff7c606 (\"ASoC: codecs: va-macro: fix accessing array out of bounds for enum type\"), but tx-macro was missed. On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value sanity check catches the 4 bytes written past the enumerated item and every read of these controls fails with -EINVAL: snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74734", "url": "https://ubuntu.com/security/CVE-2026-74734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: ohci: fix NULL pointer dereference in ar_context_release During the error handling path of the driver's probe function, a NULL pointer dereference can occur in ar_context_release(). When pci_probe() fails early (e.g., if pcim_enable_device() or MMIO mapping fails), the devres cleanup mechanism invokes release_ohci(). This function unconditionally calls ar_context_release() to clean up the asynchronous receive contexts. However, if ar_context_init() was not yet called, ctx->ohci remains NULL (as the fw_ohci structure is zero-initialized by devres_alloc()). ar_context_release() immediately dereferences ctx->ohci to get the dev pointer before checking if the context was actually initialized, leading to a crash: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:ar_context_release+0x3f/0x380 drivers/firewire/ohci.c:543 Call Trace: release_ohci+0x3f/0x60 drivers/firewire/ohci.c:3567 release_nodes drivers/base/devres.c:546 [inline] devres_release_all+0x1a8/0x260 drivers/base/devres.c:576 device_unbind_cleanup drivers/base/dd.c:597 [inline] really_probe+0x451/0xae0 drivers/base/dd.c:772 To fix this, move the assignment of the dev pointer after the !ctx->buffer check. If ctx->buffer is NULL, it indicates that the context was never successfully initialized and there is nothing to release, safely avoiding the dereference of the uninitialized ctx->ohci pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74736", "url": "https://ubuntu.com/security/CVE-2026-74736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: reject dev-bound programs bound to a different device cls_bpf_prog_from_efd() obtained a SCHED_CLS program via bpf_prog_get_type_dev() but never verified that a device-bound (offloaded) program's bound netdev matches the TC netdev the classifier is being attached to. This let a program loaded with prog_ifindex for device A be attached via cls_bpf + skip_sw to device B; deleting device A then destroyed the program's offload state while it was still attached to device B, triggering a netdevsim WARN (panic with panic_on_warn=1). Mirror the XDP attach path (net/core/dev.c) and reject the attach with -EINVAL when a dev-bound program's bound device does not match the target device.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74737", "url": "https://ubuntu.com/security/CVE-2026-74737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG On the packet reception path, the ID of the MAC Port on which the packet was received, is embedded in the RX DMA Descriptor's metadata. The ID is extracted using the helper function cppi5_desc_get_tags_ids() which fills in the 16-bit Source Tag into the 'port_id' variable. However, it is only the lower 8-bits of the 16-bit Source Tag that represent the MAC Port ID, while the upper 8-bits are Hardware-Reserved and carry an arbitrary value. With the existing logic, sporadic kernel crash is observed due to the subsequent driver code accessing out-of-bound memory because of an invalid port_id. Hence, fix the port_id extraction logic to use only the lower 8-bits of the Source Tag as the MAC Port ID.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74738", "url": "https://ubuntu.com/security/CVE-2026-74738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: sdw-mbq: don't call an unset readable_reg callback regmap_sdw_mbq_poll_busy() decides whether to poll the Function Busy bit by calling ctx->readable_reg(), which is a straight copy of config->readable_reg. That callback is optional: regmap_readable() treats a NULL ->readable_reg as \"every register is readable\", and drivers rely on that. es9356 and tac5xx2-sdw both build an MBQ regmap without one. Since commit ca1b11b36d82 (\"regmap: sdw-mbq: Allow defers on undeferrable controls\") the poll runs on every -ENODATA, not only for Controls the driver marked deferrable, so any of those devices answering COMMAND_IGNORED takes the kernel through a NULL function pointer. Treat a missing callback the way the rest of regmap does and poll.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74739", "url": "https://ubuntu.com/security/CVE-2026-74739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: skip hash tables in u32_bind_class() u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode through the walker callback. u32_bind_class() unconditionally casts the passed fh to tc_u_knode and accesses &n->res, so when fh is actually a tc_u_hnode, which has no tcf_result member, this results in a slab-out-of-bounds read of res->classid in tc_cls_bind_class(). The issue can be reproduced with the following commands: tc qdisc add dev lo root handle 1: hfsc tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit Fix this by skipping hash tables via the TC_U32_KEY(handle) check.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74740", "url": "https://ubuntu.com/security/CVE-2026-74740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain tcf_action_exec() handles TC_ACT_GOTO_CHAIN by first checking rcu_access_pointer(a->goto_chain) and then calling tcf_action_goto_chain_exec(), which does a second, independent rcu_dereference_bh(a->goto_chain) read and immediately dereferences chain->filter_chain. A concurrent tcf_action_set_ctrlact() (e.g. the gact replace path) can clear a->goto_chain between the two reads, so the second read returns NULL and tcf_action_goto_chain_exec() dereferences NULL. Fix the race by doing a single rcu_dereference_bh() read of a->goto_chain in tcf_action_exec(), checking it once for NULL, and passing the resulting chain pointer into tcf_action_goto_chain_exec(). This turns the split check/use into a single check/use on one value.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74741", "url": "https://ubuntu.com/security/CVE-2026-74741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling In non-MSI-X mode (such as legacy INTx or single MSI), wx->msix_entry is not allocated or initialized. Calling NGBE_INTR_MISC(wx) dereferences wx->msix_entry->entry, leading to a NULL pointer dereference crash. This issue was introduced by fixing the IRQ vector when the number of VFs is 7. Fix the issue by explicitly checking `pdev->msix_enabled` to determine the correct vector index. Additionally, as a side fix, set the interrupt mask to BIT(0) for the non-MSI-X fallback. In MSI/INTx mode, the MISC and queue interrupts share vector 0, and the WX_PX_MISC_IVAR register is only valid in the MSI-X case. Thus, BIT(0) is the correct mask for the miscellaneous cause when MSI-X is disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74742", "url": "https://ubuntu.com/security/CVE-2026-74742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: fix queue index used to wake the peer txq in veth_poll veth_poll() derives the index of the peer TX queue to wake from rq->xdp_rxq.queue_index. That field is only initialized by xdp_rxq_info_reg() in veth_enable_xdp_range(), which runs only when an XDP program is attached. On the plain GRO/NAPI path (veth_napi_enable_range()) xdp_rxq_info_reg() is never called, so queue_index stays 0 for every queue, as priv->rq is zero-allocated. So in a multi-queue setup with GRO enabled and no XDP program attached, every NAPI instance looks at the peer's TX queue 0. If veth_xmit() stops peer TX queue 1 because the ptr_ring is full (NETDEV_TX_BUSY), nothing ever wakes it again: the poller draining queue 1 wakes queue 0 instead. veth implements no ndo_tx_timeout, so the netdev watchdog does not kick in either, and the queue stays stopped indefinitely. Derive the index from the position of the rq within priv->rq instead, which is correct regardless of whether XDP was ever enabled. Scripts to reproduce the stall are available at https://github.com/netoptimizer/veth-backpressure-performance-testing", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74743", "url": "https://ubuntu.com/security/CVE-2026-74743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: inherit needed_headroom and needed_tailroom from lowerdev macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74744", "url": "https://ubuntu.com/security/CVE-2026-74744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvlan: inherit needed_headroom and needed_tailroom from phy_dev ipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying phy_dev (or stacked lower device) requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.", "cve_priority": "high", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74746", "url": "https://ubuntu.com/security/CVE-2026-74746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: publish GC-visible tuple last nf_flow_table_iterate() only treats original-direction tuple nodes as owning entries. Publishing the original node first lets GC observe and free a flow while flow_offload_add() is still inserting the reply node. Publish the reply node first and the original node last so GC never sees a partially installed flow. KASAN can trigger slab-use-after-free read and write reports in the flowtable/rhashtable path (rht_deferred_worker, jhash, flow_offload_del, flow_offload_lookup, etc.).", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74748", "url": "https://ubuntu.com/security/CVE-2026-74748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix refcount race between list:set GC and swap __ip_set_put_byindex() resolved the index to a set pointer under RCU, then took ip_set_ref_lock in __ip_set_put() to decrement set->ref. ip_set_swap() holds that same lock while swapping both the ip_set_list slots and the two sets' ref counters, so it can interleave between the dereference and the lock acquisition, leaving the caller to decrement a set whose reference already moved to the other index and hit BUG_ON(set->ref == 0). list_set_gc() reaches this from timer softirq, which the nfnl mutex does not serialize against swap: an expiring list:set member calls list_set_del() -> ip_set_put_byindex() while IPSET_CMD_SWAP runs on the referenced sets. Resolve the index and decrement under ip_set_ref_lock, as ip_set_swap() already does, keeping the refcount tied to the index rather than to a stale set pointer. kernel BUG at net/netfilter/ipset/ip_set_core.c:685! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ip_set_put_byindex (net/netfilter/ipset/ip_set_core.c:870) Call Trace: list_set_del (net/netfilter/ipset/ip_set_list_set.c:159) set_cleanup_entries (net/netfilter/ipset/ip_set_list_set.c:181) list_set_gc (net/netfilter/ipset/ip_set_list_set.c:578) call_timer_fn (kernel/time/timer.c:1748) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2374) run_timer_softirq (kernel/time/timer.c:2405) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74753", "url": "https://ubuntu.com/security/CVE-2026-74753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: Reject exited events as group leaders perf_event_remove_on_exec() sets remove-on-exec events to the EXIT state and detaches their group relationships. The event's file descriptor can remain open, however, and perf_event_open() currently accepts that event as a group leader because its early validation rejects only REVOKED and DEAD events. A new sibling can consequently be linked to the detached leader. When the leader is closed, perf_group_detach() observes that its PERF_ATTACH_GROUP bit is already clear and skips the new sibling. The sibling then retains a group_leader pointer to the freed event. Reject group leaders in the EXIT state. Perform the check while holding the shared context mutex so that an exec in the target task cannot detach the leader between validation and group attachment. [peterz: make the earlier test fully consistent]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-80519", "url": "https://ubuntu.com/security/CVE-2026-80519", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: finish crypto callback cleanup before peer release Crypto completion callbacks hold both key-slot and peer references. The peer reference pins the netdev, and dropping the last peer reference can let netdev unregistration and module removal make progress. Do not release that peer reference before the callback has finished its own cleanup. If ovpn_crypto_key_slot_put runs after ovpn_peer_put, it can schedule an RCU callback backed by module text after ovpn_cleanup rcu_barrier has already run. The TX error path also freed the remaining skb after ovpn_peer_put, leaving callback cleanup outside the peer/netdev lifetime window. Release the key slot and free any remaining skb first, then drop the peer reference as the last callback action.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80520", "url": "https://ubuntu.com/security/CVE-2026-80520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix NULL dereference when killing missing key ovpn_crypto_kill_key assumes both crypto slots are populated and dereferences each slot before checking it. That is not guaranteed: a peer can have only one installed key, and the kill path may be asked to remove a key that is not present. Read each slot once while holding the crypto state lock, check for NULL before looking at key_id, and only replace the slot that actually matches.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80522", "url": "https://ubuntu.com/security/CVE-2026-80522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: tegra - fix rctx->cryptlen calculation in tegra_gcm_do_one_req() Perform rctx->cryptlen calculation in tegra_gcm_do_one_req() the same way it is done in tegra_ccm_crypt_init(). The current formulae may lead to a crash if a caller does not call tegra_gcm_setauthsize() and so ctx->authsize remains zero. Then a decrypt operation with incorrect rctx->cryptlen will lead to a write beyound rctx->dst_sg buffer. As a follow-up cleanup delete struct tegra_aead_ctx->authsize field since it appears to be completely unused. Also simplify tegra_ccm_setauthsize() and tegra_gcm_setauthsize() functions respectively.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80525", "url": "https://ubuntu.com/security/CVE-2026-80525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-topology: Refresh copier IPC payload before widget setup The ipc_config_data buffer for copier widgets is built once during ipc_prepare (called from sof_pcm_setup_connected_widgets) and cached for reuse. For host copiers this buffer contains the copier_data with gtw_cfg.node_id (host DMA ID). For DAI copiers it additionally includes a dma_config_tlv trailer with stream_id and dma_channel_id for HDA link DMA. On suspend/resume, both host and link DMA streams are released and re-allocated with potentially different stream tags. The underlying copier_data and dma_config_tlv structures are correctly updated by host_config and sdw_hda_dai_hw_params respectively. However, since the widget list (spcm->stream[].list) persists across suspend, sof_pcm_hw_params skips sof_pcm_setup_connected_widgets and ipc_prepare never runs again to rebuild ipc_config_data. The stale cached payload is then sent to firmware with boot-time DMA channel assignments, causing DMA channel conflicts that lead to firmware errors and crashes. Fix this by refreshing copier_data and dma_config_tlv portions of ipc_config_data in sof_ipc4_widget_setup right before the IPC message is sent. This ensures the payload always reflects the current DMA state regardless of whether ipc_prepare ran. For DAI copiers, the gtw_cfg.config_length in copier_data is temporarily inflated to include the TLV size (matching the ipc_config_data layout) before copying, then restored, mirroring what sof_ipc4_prepare_copier_module does when first building the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80526", "url": "https://ubuntu.com/security/CVE-2026-80526", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2562: Validate values for volume writes tas2562_volume_control_put() does not do any validation of the control value written by userspace, it uses it to look up a value in a fixed size array which can easily be overflowed and then writes whatever value it gets back to the device. Add validation that we are loading a value we have in the array.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80527", "url": "https://ubuntu.com/security/CVE-2026-80527", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix hanging __ceph_get_caps() with stale mds_wanted A reader can hang forever in __ceph_get_caps() when the client no longer holds `FILE_RD`, but local cap state still says that the capability is already wanted (via `mds_wanted`). One way to trigger this is through MDS cap revocation. If another client performs a conflicting operation, the MDS can revoke `FILE_RD` from the reader; the next read then has to reacquire `FILE_RD`. If the cap update that should request `FILE_RD` never reaches the MDS after `cap->mds_wanted` was raised, the reader is left holding only non-file caps while local `mds_wanted` still includes the file read caps. In that state, try_get_cap_refs() sees `need <= mds_wanted` and returns 0, so __ceph_get_caps() just waits on `i_cap_wq`. If the cap update that was supposed to request `FILE_RD never reaches the MDS after `cap->mds_wanted was` raised, no further request is sent and the waiter can sleep indefinitely until unrelated cap traffic happens to wake it up. The ordering issue is that `cap->mds_wanted` is updated in __prep_cap() before the `CEPH_MSG_CLIENT_CAPS message` is actually queued for send. That makes one field serve two different meanings at once: what this client wants, and what the client believes the MDS already knows it wants. A proper fix would be to split those states and track whether a cap update is actually in flight or has been observed by the MDS. However, simply moving the `cap->mds_wanted assignment` later would not be sufficient: queueing the message in the messenger does not guarantee that the MDS processed that specific wanted set, and reconnect or message loss can still invalidate that assumption. Fixing that properly would require a larger rework of the cap state machine. To allow simpler backports to stable kernels, this patch implements a simpler workaround: - stop waiting forever in __ceph_get_caps(); after a bounded wait, fall back to the renew path - make ceph_renew_caps() issue a synchronous `OPEN` request whenever the inode still does not actually hold the wanted caps, instead of only calling ceph_check_caps() The extra issued-vs-wanted check in ceph_renew_caps() is necessary because the previous test only checked whether the inode still had any real caps at all. That is not enough after revocation: the client can still hold something like `pLs` and yet be missing `FILE_RD` completely. In that case, falling back to ceph_check_caps() is not sufficient, because it still trusts `cap->mds_wanted` and may resend nothing. By requiring `(issued & wanted) == wanted` before taking the asynchronous path, the code only uses ceph_check_caps() when the `wanted caps` are already actually issued. Otherwise, it sends the synchronous `OPEN` renew. This preserves the existing asynchronous fast path when the wanted caps are already issued, avoids changing cap-state semantics, and fixes the hang by guaranteeing that a stalled waiter eventually retries through a path that does not rely on the stale `mds_wanted` state. [ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to mds_client.h, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80528", "url": "https://ubuntu.com/security/CVE-2026-80528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: avoid fs reclaim while using current->journal_info handle_reply() stores a `ceph_mds_request` pointer in `current->journal_info` while filling the inode and dentry cache from an MDS reply. An allocation in this section can enter direct reclaim and prune dentries from another filesystem. If this dirties an ext4 inode, ext4 starts a JBD2 transaction. JBD2 interprets the Ceph request in `current->journal_info` as a journal handle and dereferences the request's `r_tid` as `h_transaction`, causing a kernel crash, e.g.: Unable to handle kernel paging request at virtual address 00000000077b4818 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 6 UID: 0 PID: 2699135 Comm: kworker/6:3 Tainted: G W 6.18.38-i3 #1113 NONE [...] Workqueue: ceph-msgr ceph_con_workfn pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : jbd2__journal_start+0x2c/0x208 lr : __ext4_journal_start_sb+0x100/0x178 [...] Call trace: jbd2__journal_start+0x2c/0x208 (P) __ext4_journal_start_sb+0x100/0x178 ext4_dirty_inode+0x3c/0x90 __mark_inode_dirty+0x58/0x400 iput.part.0+0x2b0/0x370 iput+0x18/0x30 dentry_unlink_inode+0xc0/0x158 __dentry_kill+0x80/0x250 shrink_dentry_list+0x90/0x130 prune_dcache_sb+0x60/0x98 super_cache_scan+0xe8/0x190 do_shrink_slab+0x174/0x388 shrink_slab+0xd8/0x4c0 shrink_node+0x31c/0x908 do_try_to_free_pages+0xd0/0x508 try_to_free_pages+0x11c/0x238 __alloc_frozen_pages_noprof+0x4d0/0xdd0 __folio_alloc_noprof+0x18/0x70 __filemap_get_folio+0x248/0x440 ceph_readdir_prepopulate+0x570/0x9e8 mds_dispatch+0x1424/0x1ba0 ceph_con_process_message+0x74/0xa0 ceph_con_v1_try_read+0x3a0/0x1510 ceph_con_workfn+0x260/0x460 Enter a scoped NOFS allocation context and leave it after clearing `journal_info`. This prevents filesystem reclaim from recursing into another filesystem while the field contains Ceph-private data.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80529", "url": "https://ubuntu.com/security/CVE-2026-80529", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: don't swallow dquot recovery verification errors xlog_recover_dquot_commit_pass2() validates the recovered dquot with xfs_dqblk_verify() and, on failure, sets error = -EFSCORRUPTED and jumps to out_release. But out_release unconditionally returns 0, so the corruption error is discarded: the caller xlog_recover_items_pass2() sees success, log recovery proceeds as if the dquot were valid, and the corrupt quota buffer can be written back to disk.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80530", "url": "https://ubuntu.com/security/CVE-2026-80530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN When exchanging two full-file ranges, xmi_can_exchange_reflink_flags() can move the reflink inode flag from the file that currently has it to the other file, as long as exactly one side is marked. This assumes that the file contents, and therefore all shared extents, are exchanged. That assumption is not true when XFS_EXCHMAPS_INO1_WRITTEN is set. xfs_exchmaps_can_skip_mapping() can skip hole and unwritten mappings from file1, so an exchange can complete without moving every mapping that the earlier flag-swap decision accounted for. In that case the post-operation cleanup can clear the reflink flag from an inode that still owns shared written extents. Later writes then take the non-reflink write path and may update blocks that should still have been protected by CoW, which shows up as data corruption between reflink-related files. Fix this by disabling the reflink flag exchange whenever XFS_EXCHMAPS_INO1_WRITTEN is requested. The contents exchange can still proceed; the conservative outcome is that both inodes keep the reflink flag. The regular reflink flag cleanup path can drop the extra flag later once the inode no longer has shared extents.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80531", "url": "https://ubuntu.com/security/CVE-2026-80531", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: avoid UAF on sc->tempip in xrep_tempfile_create LOLLM noticed a potential UAF if the tempfile creation code fails after it set sc->tempip. Fix that.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80532", "url": "https://ubuntu.com/security/CVE-2026-80532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix another iunlink infinite loop bug in online fsck xrep_iunlink_resolve_bucket is supposed to reconstruct as much of the incore prev and next unlinked list pointers based on what it finds on disk and in memory before we move on to relinking the truly lost inodes back into the unlinked list. However, it's still vulnerable to infinite loops that come in via the next_unlinked pointers. Fix this problem by remembering which inodes we've already seen and checking new agino pointers against that. If a bit is already set, either this is a loop or the inode has nonzero link count. We'll deal with the second case in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80533", "url": "https://ubuntu.com/security/CVE-2026-80533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: don't walk off the end of a null sc->sa.agi_bp in AGI repair LOLLM noticed a longstanding bug where xrep_iunlink_walk_ondisk_bucket tries to walk ragi->sc->sa.agi_bp to rebuild the unlinked inode lists. Unfortunately, it's possible for agi_bp to be null if the buffer verifier fails, so we have to use ragi->agi_bp (which skips verifier checks) instead.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80534", "url": "https://ubuntu.com/security/CVE-2026-80534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix ilock leak on error in xfs_dq_get_next_id xfs_dq_get_next_id() takes the quota inode ILOCK before calling xfs_iread_extents(). If xfs_iread_extents() fails, the function returns immediately without releasing the lock, leaking the quota inode ILOCK. This can leave the quota inode locked and cause subsequent quota operations to hang. Fix this by jumping to a common unlock path on error instead of returning directly.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80535", "url": "https://ubuntu.com/security/CVE-2026-80535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: don't double-lock when deleting a self-referential directory LOLLM notices that the dirtree scrubber can detect a directory that refers to itself. In this case, it's not correct for the directory tree repair code to try to iolock/ilock both sc->ip and dp, because they're the same inode. Fix this by detecting that corner case and handling it appropriately.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80536", "url": "https://ubuntu.com/security/CVE-2026-80536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: bounds-check buffer log item's dirty bitmap xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: \tmemcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), \t\titem->ri_buf[i].iov_base, \t\tnbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error. Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80537", "url": "https://ubuntu.com/security/CVE-2026-80537", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix off-by-one in rtrefcount btree root level validation xfs_rtrefcountbt_compute_maxlevels() sets \tmp->m_rtrefc_maxlevels = min(d_maxlevels, r_maxlevels) + 1; where the trailing \"+ 1\" already accounts for the inode-root level, so the deepest valid on-disk root level is m_rtrefc_maxlevels - 1 and a cursor must satisfy bc_nlevels <= bc_maxlevels (= m_rtrefc_maxlevels). The two on-disk validation paths, xfs_rtrefcountbt_verify() and xfs_iformat_rtrefcount(), check the root level with \">\" instead of \">=\", so a crafted rtreflink (metadir + realtime + reflink) image whose /rtgroups/N.refcount inode has bb_level == m_rtrefc_maxlevels is accepted on mount. xfs_rtrefcountbt_init_cursor() then sets bc_nlevels = bb_level + 1, exceeding bc_maxlevels by one. Since the xfs_rtrefcountbt_cur slab object is sized for exactly bc_maxlevels entries, the first btree op on such a cursor indexes bc_levels[m_rtrefc_maxlevels] past the end of the object. This is reached by the first rtrefcount cursor built after mount, via log/CoW recovery (xfs_reflink_recover_cow() during xfs_mountfs()) or an FS_IOC_GETFSMAP over the realtime device. Reject a root level equal to m_rtrefc_maxlevels, matching the \">=\" form already used by the sibling data-device refcount/rmap verifiers and the in-memory rtrmap verifier. BUG: KASAN: slab-out-of-bounds in xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101) Write of size 2 at addr ffff888018391658 by task exploit/144 xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101) xfs_btree_query_range (fs/xfs/libxfs/xfs_btree.c:5308) xfs_refcount_recover_cow_leftovers (fs/xfs/libxfs/xfs_refcount.c:2113) xfs_reflink_recover_cow (fs/xfs/xfs_reflink.c:1085) xlog_recover_finish (fs/xfs/xfs_log_recover.c:3551) xfs_mountfs (fs/xfs/xfs_mount.c:1158) xfs_fs_fill_super (fs/xfs/xfs_super.c:1940) get_tree_bdev_flags (fs/super.c:1634) vfs_get_tree (fs/super.c:1694) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address belongs to the cache xfs_rtrefcountbt_cur of size 216 The buggy address is located 8 bytes to the right of allocated 216-byte region [ffff888018391578, ffff888018391650) Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80538", "url": "https://ubuntu.com/security/CVE-2026-80538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: propagate errors from xfs_rtginode_load xfs_rtginode_ensure() treats every xfs_rtginode_load() error other than -ENOENT as success. This can leave the realtime group inode unset after an I/O, allocation, or corruption error. Growfs then continues as though the inode had been loaded. Only -ENOENT means that the inode needs to be created. Return all other errors to the growfs caller.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80539", "url": "https://ubuntu.com/security/CVE-2026-80539", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: disallow multiple FENCE chunks in one submit amdgpu_cs_pass1() dispatches on chunk_id once per chunk without rejecting repeated ids. p->uf_bo is a single-slot field, so a submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs amdgpu_cs_p1_user_fence() twice, and the second run overwrites p->uf_bo with a freshly referenced BO without dropping the reference taken by the first. amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE chunk but the last leaks a BO reference. The leaked BO outlives handle close and process exit. Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc (\"drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit\") did for p->bo_list. (cherry picked from commit 665b1fc2a1845206408f9a2c6da67101789edb82)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80540", "url": "https://ubuntu.com/security/CVE-2026-80540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix UVD decode image min size calculation This needs to use pitch instead of width. Also reject pitch over 4096 to avoid overflow. (cherry picked from commit b41c8cb12e202b220353332ab87dc01a11f69304)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80541", "url": "https://ubuntu.com/security/CVE-2026-80541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate GEM_CREATE domain combinations AMDGPU_GEM_CREATE checked domain bits against AMDGPU_GEM_DOMAIN_MASK, but did not validate domain combinations. Userspace could combine CPU|GTT|VRAM with DOORBELL, GDS, GWS, or OA, making amdgpu_bo_placement_from_domain() exceed AMDGPU_BO_MAX_PLACEMENTS and hit BUG_ON(). Allow combinations only within CPU/GTT/VRAM, and require non-CPU/GTT/ VRAM domains to be specified one at a time. Return -EINVAL for invalid combinations in amdgpu_gem_create_ioctl(). v2: Rename helper from amdgpu_gem_domain_valid() to amdgpu_gem_are_domains_valid() (Christian) (cherry picked from commit db39852d0c39843cb02048dfb47e4b8c703e9080)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80542", "url": "https://ubuntu.com/security/CVE-2026-80542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL pointer dereference in amdgpu_dm_crtc_set_vblank() amdgpu_dm_crtc_set_vblank() dereferences acrtc_state->stream when vblank is enabled/queried from DRM_IOCTL_MODE_CRTC_GET_SEQUENCE before a stream is attached to it. BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: amdgpu_dm_crtc_set_vblank+0x6b/0x4d0 [amdgpu] Call Trace: drm_vblank_enable drm_vblank_get drm_crtc_get_sequence_ioctl drm_ioctl_kernel drm_ioctl Reproduced by running VKCTS with WSI tests enabled on RADV. Guard the enable path on acrtc_state->stream being non-NULL, matching the existing checks in this function. (cherry picked from commit 7b1b31bf6942e6f43509b48da23f8e27269aac39)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80547", "url": "https://ubuntu.com/security/CVE-2026-80547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Implement a crw lock Unlike the channel_program struct, which covers synchronous I/O submissions and asynchronous interrupts, the CRW region relies exclusively on asynchronous events coming from hardware. Implement a lock to manage the list of those payloads, to ensure they are read cohesively.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80548", "url": "https://ubuntu.com/security/CVE-2026-80548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Selectively expand io_mutex The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share. With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80549", "url": "https://ubuntu.com/security/CVE-2026-80549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Move cp cleanup out of not operational The fsm_notoper() routine is called when the device has been lost, and is (by definition) no longer operational. Since this can happen asynchronously from the normal behavior of the driver, the cleanup may happen when holding other locks in the calling sequence (notably, the cio subchannel lock). Push the cleanup of the private->cp resources to a workqueue, where it can be done out from under that lock sequence and a future patch can safely manage the locking requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80550", "url": "https://ubuntu.com/security/CVE-2026-80550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Fix out of bounds check on CCW array The routine ccwchain_calc_length() counts the number of channel command words (CCWs) that are chained together in a single channel program, and rejects anything larger than CCWCHAIN_LEN_MAX (256) CCWs. The loop itself is \"do..while (count < 257)\", and while the logic in is_cpa_within_range() correctly adjusts between the 0-index array of CCWs and the count of CCWs starting at 1, this means it would look at a possible 257th CCW before ending the loop and (correctly) returning an error. Fix this by restructuring the loop to break as soon as 256 CCWs (thus indexes 0-255) are examined, without looking at memory outside the range.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80551", "url": "https://ubuntu.com/security/CVE-2026-80551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure first IDAW remains constant The first IDAW in a list does not need to be on a 2K/4K boundary like all others, and so is read separately to accurately calculate the size of the buffer needed to read the full IDAL. Verify that the address found in the first IDAW is unchanged between reads, to ensure a consistent set of IDAWs being worked with.", "cve_priority": "high", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80552", "url": "https://ubuntu.com/security/CVE-2026-80552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure index for read/write regions are within range The introduction of the capability chain rightly clamped the region indexes to the range of the capabilities itself, but neglected to do so for the existing read/write regions which should also be enforced.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80553", "url": "https://ubuntu.com/security/CVE-2026-80553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Cancel existing workqueues The initialization of the io_work and crw_work workqueues begs the question of whether they should be un-initialized. Add the corresponding cleanup tags in _release_dev to ensure work isn't dispatched after the private struct is free'd.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80554", "url": "https://ubuntu.com/security/CVE-2026-80554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Limit the number of channel program segments The processing of channel programs, and the CCWs within them, is done recursively. As such, there is an arbitrary (but not architectural) limit to the number of CCWs that can exist in a single channel program. The vfio-ccw logic breaks these channel programs into segments whenever it encounters a Transfer-In-Channel (TIC) CCW, and the combined number of segments count towards the global limit. Impose an equivalent limit to the number of segments until such logic can be made non-recursive.", "cve_priority": "high", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80555", "url": "https://ubuntu.com/security/CVE-2026-80555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Free all memory if cp_init() fails The routine cp_free() is called to unpin/free any memory once an I/O is completed successfully, or if cp_prefetch() fails. But if cp_init() fails, and cp->initialized is not enabled, the same routine cannot be used to free all the memory. An attempt to address this exists in ccwchain_handle_ccw(), where a single call to ccwchain_free() is made for the currently-processed CCW segment. But this will leak other segments (created as a result of a Transfer in Channel) that had been allocated as part of the same channel program. Address this by performing the cleanup outside of the recursive ccwchain_handle_ccw()/ccwchain_loop_tic() logic.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80556", "url": "https://ubuntu.com/security/CVE-2026-80556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: atmel-mci: Fix use-after-free in atmci_remove due to race condition In atmci_probe, &host->bh_work is bound with atmci_work_func, and atmci_interrupt, atmci_timeout_timer and atmci_dma_complete can all queue this work on system_bh_wq. If we remove the module, atmci_remove makes cleanup and the memory allocated for host with devm_kzalloc() is released after the remove callback returns, while the work mentioned above may still be pending or running. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | atmci_interrupt | queue_work(system_bh_wq, | &host->bh_work) atmci_remove | atmci_cleanup_slot(...) | atmci_writel(host, ATMCI_IDR, ~0UL) | timer_delete_sync(&host->timer) | dma_release_channel(host->dma.chan) | free_irq(platform_get_irq(pdev, 0), host) | | atmci_work_func | // use host // devm resources released after | // remove returns, host is freed | | // use host (use-after-free) Fix it by canceling the work after all the sources that can schedule it (IRQ handler, timeout timer and DMA completion callback) have been stopped, and before proceeding with the remaining cleanup in atmci_remove.", "cve_priority": "low", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80558", "url": "https://ubuntu.com/security/CVE-2026-80558", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Avoid using invalid osd indices from primary_temp A corrupted osdmap received from a Ceph monitor or OSD may contain osd indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts that don't exist, i.e., that are greater than max_osd or smaller than CEPH_HOMELESS_OSD (-1). These indices are used to create the up and acting set in ceph_pg_to_up_acting_osds(), called from calc_target(). While most of these osd indices are checked, the one from primary_temp is not. Subsequently, this may lead to calc_target() returning this (potentially invalid) index as target osd for a (linger) request. Because the osd_state, osd_weight, and osd_addr arrays only contain max_osd entries (with indices 0 to max_osd -1), this leads to out-of-bounds accesses when trying to read values from these arrays. This patch fixes the issue by adding a check to get_temp_osds(), so that only valid osd indices from primary_temp are used, and it falls back to using the primary from pg_temp or the up set if it is invalid. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80559", "url": "https://ubuntu.com/security/CVE-2026-80559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: sur40 - fix input device registration ordering In sur40_probe(), input_register_device() was previously called early before the V4L2 video device and vb2_queue components were fully initialized. If userspace opened the input device immediately upon registration, sur40_open() would trigger and start the sur40_poll() worker thread. This worker thread invokes sur40_process_video() and accesses the uninitialized vb2_queue structure, leading to a data race and potential system crash. Furthermore, if V4L2 or video registration failed after input_register_device() succeeded, the error path fell through to calling input_free_device() on a successfully registered device instead of input_unregister_device(), corrupting input core state. Move input_register_device() to the very end of sur40_probe(). This ensures the V4L2 and video queue structures are fully initialized before polling can start, and naturally resolves the error path bug since input_free_device() is now only called when input registration has not yet occurred. To maintain strict LIFO (Last-In, First-Out) teardown ordering, also move input_unregister_device() to the very beginning of sur40_disconnect(). This guarantees that the input polling worker thread is stopped before V4L2 video components or control handlers are unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80560", "url": "https://ubuntu.com/security/CVE-2026-80560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openrisc: signal: do not restore privileged SR bits on sigreturn restore_sigcontext() copies the whole supervision register (SR) from the signal frame and only clears SPR_SR_SM before the value is reloaded into the hardware SR (through ESR and l.rfe) on the return to user space. All other SR bits are left under user control. An unprivileged task can thus return from a signal handler through a crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the CPU performs no translation or protection on data accesses, so the task gains read and write access to arbitrary physical memory, a local privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH and the cache-enable bits are exposed the same way. The ptrace GPR regset already refuses any change to SR for exactly this reason. Restore only the arithmetic flag bits (F, CY, OV) from the signal frame and take every privileged control bit from the SR the kernel saved on signal entry. Verified with qemu-system-or1k -M or1k-sim: before this change an unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to physical address 0x03000000 (beyond the kernel's mem=32M); afterwards the same PoC receives SIGSEGV and physical memory is unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80561", "url": "https://ubuntu.com/security/CVE-2026-80561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix multiple unsafe decodes in decode_locker() decode_locker() in cls_lock_client.c contains three unsafe decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_copy() at the locker_id_t name field has no preceding bounds check. With p == end after ceph_start_decoding() accepts struct_len=0, this reads sizeof(ceph_entity_name) = 9 bytes past the validated buffer boundary. 2. *p += sizeof(struct ceph_timespec) after the locker_info_t header is an unchecked pointer advance. A malicious OSD can position p past end, causing all subsequent _safe checks to pass against a bogus boundary. 3. len = ceph_decode_32(p) has no preceding bounds check, and the immediately following *p += len is uncapped. A malicious OSD can send len=0xffffffff, advancing p gigabytes past end and escaping the decode window entirely. Fix all three by replacing bare operations with their safe variants: ceph_decode_copy -> ceph_decode_copy_safe *p += sizeof(...) -> ceph_decode_skip_n ceph_decode_32(p) -> ceph_decode_32_safe *p += len -> ceph_decode_skip_n A new label is added to return -EINVAL on any bounds violation. -EINVAL is appropriate here: the data received from the OSD is structurally malformed, which is an invalid argument to the decode contract regardless of whether the caller or the wire is at fault. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition) without any further privileges beyond OSD session establishment. [ idryomov: use ceph_decode_skip_string() to skip description, trim changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80562", "url": "https://ubuntu.com/security/CVE-2026-80562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: ml-ioh: use raw_spinlock_t for the register lock ioh_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. ioh_irq_enable() and ioh_irq_disable() take the same lock from the .irq_enable/.irq_disable callbacks, which are likewise invoked with desc->lock held. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, and those critical sections only perform short sequences of MMIO register accesses (ioread32()/iowrite32()); the .irq_set_type callback additionally emits a dev_warn() on an unsupported type. None of these are sleepable operations, so keeping this register lock non-sleeping is appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same fix as commit a02b8950d619 (\"gpio: pch: use raw_spinlock_t for the register lock\"); this driver shares the same structure as gpio-pch.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80563", "url": "https://ubuntu.com/security/CVE-2026-80563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: sloppy-logic-analyzer: fix use-after-free via debugfs trigger on unbind The \"trigger\" debugfs file has a hand-rolled ->write handler (trigger_write()) that dereferences the per-device gpio_la_poll_priv. The file is created with debugfs_create_file_unsafe(), and the handler never takes a debugfs reference. Nothing keeps the object alive while the handler runs. priv is allocated with devm_kzalloc(). devres frees it when the platform device is unbound. debugfs_create_file_unsafe() installs no full_proxy wrapper, so debugfs_remove_recursive() in gpio_la_poll_remove() does not wait for an in-flight trigger_write(). The blob_lock taken there does not help, because trigger_write() never takes it. A write that races an unbind therefore writes into freed memory: trigger_write() gpio_la_poll_remove() priv = m->private buf = memdup_user() [may sleep] mutex_lock(&priv->blob_lock) debugfs_remove_recursive() [no wait] mutex_unlock(&priv->blob_lock) (remove returns; devres frees priv) priv->trig_data = buf <-- use-after-free write priv->trig_len = count The race is reachable by root via /sys/bus/platform/drivers/gpio-sloppy-logic-analyzer/unbind. Create \"trigger\" with debugfs_create_file() instead. Its full_proxy wrapper makes debugfs_remove_recursive() drain any in-flight ->write before it returns. The use-after-free is confirmed under KASAN with a minimal reproducer of the same debugfs_create_file_unsafe() plus devm_kzalloc() pattern (available on request); it produces a slab-use-after-free write in the handler.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80564", "url": "https://ubuntu.com/security/CVE-2026-80564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix NULL dereference due to missing ptp adjfine Fix NULL dereference due to missing implementation of adjfine, which can be triggered from usermode as follows: sudo ./testptp -d /dev/ptp0 -f 0 [ 551.943697] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] [ 552.061946] Call Trace: [ 552.064487] [ 552.066681] ptp_clock_adjtime+0x1c0/0x2c0 [ 552.070874] ? get_clock_desc+0x6b/0xb0 [ 552.074825] pc_clock_adjtime+0x78/0xc0 [ 552.078755] __do_sys_clock_adjtime+0x85/0x110 [ 552.083293] do_syscall_64+0xea/0x610", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80565", "url": "https://ubuntu.com/security/CVE-2026-80565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qce - fix error path in devm_qce_register_algs If ops->register_algs() fails, the error path repeatedly calls the same ops->unregister_algs() from the failed registration. Use the loop index to unregister the previously registered algorithms instead.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80566", "url": "https://ubuntu.com/security/CVE-2026-80566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: hynitron_cstxxx - validate touch count and finger IDs The driver allocates max_touch_num input slots, which are indexed from zero through max_touch_num - 1. The current check allows a finger ID equal to max_touch_num to reach cst3xx_report_contact(). While the input core ignores out-of-range slot indices, reporting touch data without a valid slot change corrupts the touch state of the previously active slot. The touch count is read from the controller's report and is used to index the fixed-size report buffer without first checking its range. Reject counts larger than the supported number of touch slots before checking the trailing byte or parsing touch data. Reject finger IDs equal to or greater than max_touch_num, and return immediately when an invalid finger ID is encountered so that corrupt touch frames are discarded instead of reporting partial contact state. The V821 Avaota F1 board configures the vendor driver with one touch slot, so finger ID 1 is already invalid on that device.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80567", "url": "https://ubuntu.com/security/CVE-2026-80567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue Previously, rmi_f54_buffer_queue() waited for the worker thread to finish but ignored whether it succeeded. If the worker failed (e.g., due to a timeout or register read failure), the queue thread would silently return success, delivering stale or uninitialized memory to userspace. Add a 'report_error' field to struct f54_data to store the worker's exit status. Check this field in rmi_f54_buffer_queue() after the worker finishes, and mark the buffer as VB2_BUF_STATE_ERROR if an error occurred.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80568", "url": "https://ubuntu.com/security/CVE-2026-80568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - block s_input when F54 queue is busy Changing the input (diagnostic report type) mid-stream changes the report size. Since V4L2 buffers are allocated based on the size at stream start, changing the input while streaming could lead to a heap buffer overflow if the new size is larger than the allocated buffers. Prevent this by blocking VIDIOC_S_INPUT with -EBUSY if the V4L2 queue is busy (streaming).", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80569", "url": "https://ubuntu.com/security/CVE-2026-80569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer rmi_f54_work() reads a diagnostics report from the device into f54->report_data, sizing the transfer with rmi_f54_get_report_size(): \treport_size = rmi_f54_get_report_size(f54); \t... \tfor (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) { \t\tint size = min(F54_REPORT_DATA_SIZE, report_size - i); \t\t... \t\trmi_read_block(.., f54->report_data + i, size); \t} report_data is allocated once at probe from F54's own electrode counts (array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))), but rmi_f54_get_report_size() computes the size from drv_data->num_*_electrodes when those are set, i.e. from the F55 function's electrode counts. Both counts come straight from device queries (F54 and F55 each report up to 255 electrodes) and nothing constrains the F55 counts to the F54 ones. A malicious or malfunctioning RMI4 device that reports larger F55 electrode counts than its F54 counts makes report_size exceed the allocation, so the read loop writes past report_data (and the V4L2 dequeue memcpy() then reads past it). On conforming hardware the F55 configured electrodes are a subset of the F54 physical electrodes, so report_size never exceeds the buffer and well-behaved devices are unaffected. Record the allocation size and reject a report that does not fit, mirroring the existing zero-size check.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80570", "url": "https://ubuntu.com/security/CVE-2026-80570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - zero report size on F54 work error In rmi_f54_work(), if an error occurs during report request or command verification, the code jumped directly to the 'error' label, bypassing the 'abort' label where f54->report_size was normally zeroed out. This left f54->report_size containing its previous successful payload size. If a user then altered the V4L2 format to a smaller size, and a subsequent run failed, rmi_f54_buffer_queue() would copy the stale, larger payload size into the shrunken V4L2 buffer, causing a heap buffer overflow. Fix this by merging the 'abort' and 'error' labels into a single 'out' exit path, and ensuring that f54->report_size is always set to 0 on failure by checking for error and zeroing the local report_size first.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80571", "url": "https://ubuntu.com/security/CVE-2026-80571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: papr-phy-attest - validate cmd.length, plug mem leak In papr_phy_attest_create_handle(), the params->cmd.length is not validated before use, which can result in a buffer overlow. Check it and return -EINVAL if it is either 0 or exceeds sizeof(params->cmd). Also, params is freed on the success path but not error. Free it on errors after memory allocation. And free it on negative fd.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80572", "url": "https://ubuntu.com/security/CVE-2026-80572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: byd - synchronize timer deletion before freeing private data byd_disconnect() uses timer_delete() before freeing the driver's private data. This does not wait for a running byd_clear_touch() callback, which dereferences the private data and its psmouse pointer. A callback racing with disconnect can therefore access the private data after it has been freed. The timer can also still be re-armed by byd_process_byte() while the disconnect is in progress. Use timer_shutdown_sync() before freeing the private data: it waits for a running callback and turns any later re-arm attempt into a no-op.", "cve_priority": "low", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80573", "url": "https://ubuntu.com/security/CVE-2026-80573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: iforce - validate input packet lengths iforce_process_packet() reads fixed fields from joystick, wheel and status packets without first checking their lengths. In particular, the shared hats-and-buttons helper unconditionally reads data[6]. The status tail is a sequence of 16-bit effect addresses, but an incomplete final address is also consumed. A successful zero-length USB URB additionally reads the packet ID before the common parser is called. Reject the zero-length USB transfer, require the seven-byte joystick and wheel prefixes and the two-byte status prefix, and consume only complete status-tail addresses.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80574", "url": "https://ubuntu.com/security/CVE-2026-80574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: focaltech - fix array out-of-bounds in focaltech_process_rel_packet Make finger2 (and also finger1) unsigned, so that if the finger index in the packet is 0 then subtracting 1 creates an array index which overflows above the existing check for FOC_MAX_FINGERS, as the existing comment says it should, instead of writing to state->fingers[-1].", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80575", "url": "https://ubuntu.com/security/CVE-2026-80575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cs40l50-vibra - validate custom data from user space cs40l50_add() copies the custom data of an FF_PERIODIC/FF_CUSTOM effect straight from the ff_effect the user passed to EVIOCSFF, without requiring it to hold anything: work_data.custom_data = memdup_array_user(periodic->custom_data, periodic->custom_len, sizeof(s16)); work_data.custom_len = periodic->custom_len; The driver then reads two words out of that buffer: custom_data[0] as the waveform bank in cs40l50_effect_bank_set(), and custom_data[1] as the index within the bank in cs40l50_effect_index_set(). Neither read is covered by a length check, and custom_len is fully user controlled: - custom_len == 0 makes memdup_array_user() call memdup_user() with a length of zero, which returns ZERO_SIZE_PTR rather than an error, so custom_data[0] dereferences it. - custom_len == 1 allocates two bytes. A bank of ROM or RAM keeps effect->type out of the OWT case, and custom_data[1] is then read one word past the allocation. The bank value itself is also mishandled. It is masked with CS40L50_CUSTOM_DATA_MASK (0xffff) but stored in an s16, so a custom_data[0] of 0x8000 or above wraps to a negative value that passes the \"bank_type >= CS40L50_WVFRM_BANK_NUM\" test. cs40l50_effect_index_set() indexes vib->dsp.banks[] with it before the switch statement's default case gets a chance to reject it: base_index = vib->dsp.banks[effect->type].base_index; max_index = vib->dsp.banks[effect->type].max_index; Require the two words the driver reads to be present, and hold the masked bank in a u32 so the existing upper-bound test covers the whole range. The da7280 haptic driver already range checks custom_len this way.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80576", "url": "https://ubuntu.com/security/CVE-2026-80576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: reject oversized IBs with per-ring packet limits On GFX rings, amdgpu_cs_p2_ib() passed user-supplied ib_bytes through to ib->length_dw without a limit, while ring_emit_ib() encodes length into packet fields. Oversized values can corrupt adjacent control bits and destabilize command submission. Add a per-ring IB packet size limit helper and reject command submissions exceeding the corresponding dword limit before IB allocation. Use the documented 20-bit limit for GFX/compute/SDMA/VPE, and apply the MM fallback limit for other ring types. (cherry picked from commit 7f48fa2cf62e3fa6c9c3870aa74988f773247e52)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80577", "url": "https://ubuntu.com/security/CVE-2026-80577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: skip zero-sized firmware sections panthor_fw_load_section_entry() skips BO creation when the firmware section VA range is empty. If such a section is added to the firmware section list, section->mem is left as NULL. Later reload and unplug paths iterate over all firmware sections and dereference section->mem, which can lead to a NULL pointer dereference. Zero-sized firmware sections are valid, so accept them as no-op entries but skip adding them to the section list.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80578", "url": "https://ubuntu.com/security/CVE-2026-80578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: core: Fix pointer desynchronization in fb_io_read() In fb_io_read(), if copy_to_user() performs a partial copy (e.g., due to a faulty user buffer), the loop adjusts the chunk size 'c' and updates the remaining 'count'. However, the hardware 'src' pointer has already been eagerly advanced by the original chunk size. If the loop is allowed to continue, the read will resume from an incorrect, over-advanced offset. Since the remaining 'count' was only decremented by the successful bytes, this desynchronization causes the next iterations to execute more hardware reads than originally bounded, eventually leading to out-of-bounds I/O reads. Fix this by breaking out of the loop immediately upon a partial copy_to_user(). A partial copy indicates a faulty user buffer, making subsequent read attempts futile. Breaking out ensures we return the number of successfully read bytes without risking out-of-bounds hardware accesses in subsequent mismatched iterations.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80581", "url": "https://ubuntu.com/security/CVE-2026-80581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout Ignore IPC errors for pipeline state change if the firmware state is crashed or the IPC has timed out. If the firmware has crashed the kernel still needs to go through the state changes to reset its internal to be able to correctly work the next time the DSP is booted up. The case with IPC timeout is a bit more problematic, but it has been rootcaused to be the result of system scheduling blockage and the firmware did actually received and handled the message, but the reply handling got blocked by issues outside of the SOF stack. So far the best way to handle this is to continue with setting the state.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80584", "url": "https://ubuntu.com/security/CVE-2026-80584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/qeth: validate user buffer length in SNMP and ARP query ioctls qeth_snmp_command() and qeth_l3_arp_query() allocate a buffer sized by a user-supplied length (udata_len) without checking a lower bound, then set udata_offset to a fixed non-zero value and pass both to a reply callback. The callback bounds-checks the copy with if ((udata_len - udata_offset) < len) Both fields are u32, so a udata_len smaller than udata_offset makes the subtraction wrap and the check pass, and the following memcpy() writes past the allocation. A udata_len of 0 also yields ZERO_SIZE_PTR from kzalloc(), which the existing NULL check does not catch. Reject buffers smaller than udata_offset before allocating, so the callback subtraction can no longer underflow.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80585", "url": "https://ubuntu.com/security/CVE-2026-80585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fastopen: only mark MPTFO subflows with SYN data Passive TCP Fast Open accepts a valid-cookie SYN even when it carries no data. In that case the child socket's receive queue is intentionally left empty. mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking for queued SYN data. That made data-less TFO SYNs hit a WARN and, if the warning was non-fatal, left stale MPTFO state behind. The stale flag could later trigger a state-confusion bug in check_fully_established(). Only mark the subflow as MPTFO after confirming that an SKB was queued. Return quietly when the receive queue is empty. Note that mptcp_subflow_context's is_mptfo field is now not just about subflows where the TFO was present, but about MPTFO subflow that consumed SYN data. Only having a valid cookie but not carrying data is not really \"doing TFO\".", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80586", "url": "https://ubuntu.com/security/CVE-2026-80586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: options: reset DSS fields in case of unexpected size A remote peer could send a malformed DSS with a wrong size, followed by another DSS or MPC + Data. In this case, the first suboption will be ignored, but leaving some fields written, which could lead to inconsistency or access uninitialized data. Explicitly reset the fields that could have been modified in case of unexpected size.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80587", "url": "https://ubuntu.com/security/CVE-2026-80587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid combining some incoming suboptions Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A few points of attention: - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch. - In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption. - In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80588", "url": "https://ubuntu.com/security/CVE-2026-80588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: reclaim forward-allocated memory on RX path errors After commit 9db5b3cec4ec (\"mptcp: borrow forward memory from subflow\"), errors in the receive path prior to queueing skbs into the receive queue do not trigger forward-allocated memory reclaiming. Prevent forward memory from growing unboundedly in pathological drop scenarios by explicitly reclaiming memory when skbs are dropped.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80589", "url": "https://ubuntu.com/security/CVE-2026-80589", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: stop the timeout timer when releasing a never added disk disk_release() undoes blk_mq_init_allocated_queue() for a disk whose probe failed before add_disk(), but it only calls blk_mq_exit_queue(). Nothing there stops q->timeout, and that timer rolls forward: it stays pending until it next expires, not until the last request completes. So if the driver issued any I/O before adding the disk, the request_queue is freed while still linked into a timer wheel bucket. Commit 6f8191fdf41d (\"block: simplify disk shutdown\") dropped the blk_cleanup_queue() call that used to stop it. __del_gendisk() and blk_mq_destroy_queue() still do; only the probe failure path lost it. nvme gets there because nvme_update_ns_info() submits Report Zones or FDP io-mgmt-recv on ns->queue before the disk is added, so a later failure - a concurrent reset setting NVME_CTRL_FROZEN, or device_add_disk() failing - lands in put_disk() with the timer armed: BUG: KASAN: slab-use-after-free in detach_if_pending+0x30c/0x340 Write of size 8 at addr ffff888004d71310 by task kworker/u8:2/37 __timer_delete_sync+0x156/0x240 kernel/time/timer.c:1621 blk_sync_queue+0x22/0x40 block/blk-core.c:222 nvme_sync_queues+0x100/0x150 drivers/nvme/host/core.c:5362 nvme_reset_work+0x138/0x930 drivers/nvme/host/pci.c:3264 Allocated by task 34: __blk_mq_alloc_disk+0x33/0x100 block/blk-mq.c:4462 nvme_alloc_ns+0x290/0x3870 drivers/nvme/host/core.c:4146 Freed by task 0: blk_free_queue_rcu+0x3a/0x50 block/blk-core.c:254 rcu_core+0xc10/0x1730 kernel/rcu/tree.c:2857 The queue being synced there is ctrl->admin_q, only a victim sharing a timer wheel bucket with the freed queue's dangling entry; other runs tripped in enqueue_timer(), __run_timers() or blk_mq_timeout_work(). Failing nvme_alloc_ns() with a debug patch makes it deterministic: one leaked timer trips KASAN within seconds, while 1987 patched releases produced no splat. Stop the timer and the queue work items before blk_mq_exit_queue(), like blk_mq_destroy_queue() does. Found by FuzzNvme.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74593", "url": "https://ubuntu.com/security/CVE-2026-74593", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Take cgroup_lock() first in scx_cgroup_lock() scx_cgroup_lock() write-locks scx_cgroup_ops_rwsem and then takes cgroup_lock(), which can deadlock through kernfs: scx enable/disable cgroup rmdir cpu.weight write ------------------ ------------ ---------------- cgroup_lock() percpu_down_write(rwsem) cgroup_lock() kernfs_get_active() percpu_down_read(rwsem) kernfs_drain() The enable path waits for the rmdir to release cgroup_mutex. The rmdir, deactivating the cpu controller's files, waits in kernfs_drain() for the write's active reference. The write, in scx_group_set_weight(), waits for the rwsem behind the pending writer. Take cgroup_lock() first. The set_* paths take no cgroup locks inside the read side, so a pending write-lock then only waits for read sections that always run to completion, and no dependency from the rwsem back to cgroup_mutex remains.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74596", "url": "https://ubuntu.com/security/CVE-2026-74596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs,fsverity: remove check for fsverity being enabled in setattr_prepare() The check that fs-verity is available in the kernel is not necessary here. Filesystems could have fsverity files even without fs-verity enabled. In that case, truncate on fsverity file will succeed, what this check is trying to prevent.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74600", "url": "https://ubuntu.com/security/CVE-2026-74600", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_table_check: skip special zero mappings page_table_check_set() and page_table_check_clear() account mappings based on PageAnon(). Shared zero-page PTEs and huge zero PMDs are special mappings, but page_table_check can still account them as file-backed pages. An unprivileged process can populate enough zero mappings to overflow file_map_count and hit the existing BUG_ON(). The PTE path can do this with the shared zero page, and the PMD path can do the same with huge zero mappings. Skip special zero mappings in the user page-table accounting paths. Keep the PTE-side pte_special() check, and identify huge zero PMDs from the mapped folio instead of pmd_special(). That covers architectures where pmd_special() is a no-op without adding huge_zero_pfn checks to the generic counter helpers.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74605", "url": "https://ubuntu.com/security/CVE-2026-74605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventfs: Use children field for rcu head and add memory barriers When an eventfs inode is freed, it sets ei->is_freed and then uses its ei->list to add it to the srcu link list as the list field is a union with the rcu list head. As the ei->list is used to iterate over an SRCU protected list without taking the eventfs_mutex, there's nothing stopping the iteration over that list to see the ei->rcu instead of the ei->list and it will read a corrupt target. To fix this, change the union of the rcu list head with the children list. On freeing the eventfs inode, set the is_free and execute a smp_wmb() before adding the eventfs inode to the SRCU list. On iteration of the ei->children list, at the start, execute a smp_rmb() and then read the is_freed of the ei to see if the children list is still valid. If is_freed is set, then the ei_child read is not valid and the loop should exit immediately.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74626", "url": "https://ubuntu.com/security/CVE-2026-74626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_netdev: Preserve RX queue depth on allocation failure ntb_netdev_rx_handler() hands the received skb to the network stack before allocating its replacement. If the allocation fails, nothing is reposted. Every failure therefore takes one buffer out of the RX queue while the interface remains up, and enough failures eventually stall reception. A retry path could refill the queue later, but ntb_netdev has none. Allocate the replacement first instead. If that fails, drop the packet and repost the same skb. This keeps the queue full and lets packet delivery resume as soon as memory is available again.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74645", "url": "https://ubuntu.com/security/CVE-2026-74645", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/lru_sort: error out for >10000 active_mem_bp damos_quota_score() can trigger division by zero if the target value is zero. DAMON_LRU_SORT lets users set the target value for the hot memory scheme via active_mem_bp parameter. It avoids setting it as the target value if the parameter value is zero. However, it also sets the cold memory scheme with a target value that is calculated as '10000 - active_mem_bp + 2'. Hence, if a user sets active_mem_bp 10002, the cold memory scheme's quota goal target value can be zero. As a result, division by zero can be triggered. Fix by returning an error when the user tries to start DAMON with >10000 active_mem_bp parameter value. It makes no sense to set active_mem_bp with 10002. It also requires module parameters write permission to reproduce the issue. That said, the consequence is quite bad. One reliable way to reproduce the issue is like below: # cd /sys/module/damon_lru_sort/parameters # echo 1000 > wmarks_high # echo 995 > wmarks_mid # echo 0 > wmarks_low # echo 10002 > active_mem_bp # echo Y > enabled # dmesg -w [...] [ 597.421247] Oops: divide error: 0000 [#1] SMP NOPTI [ 597.428848] RIP: 0010:damos_quota_score+0x6f/0x480 This issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74674", "url": "https://ubuntu.com/security/CVE-2026-74674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix incorrect flush address in direct page table reclaim When zap_pte_range reclaims a page table, it does: pte_free_tlb(tlb, pmd_pgtable(pmdval), addr); and this is unconditionally wrong: if this code executes, addr *always* points one past the end of the range covered by the table. The addr parameter is used to flush the TLB (really the paging-structure-cache) to drop references to the to-be-freed table, and any architecture that cares about the parameter will flush the wrong address. (But they'll still free the correct page). I think it's worth contemplating why the kernel works at all. If we hit the offending line of code, we will first clear the PMD entry (line 1954, zap_empty_pte_table), then we will issue pending flushes if force_flush is set (tlb_flush_mmu_tlbonly(tlb)), then we will skip the retry on line 1979 (phew!), and then we will do the offending pte_free_tlb call. *Or* we will clear the PMD entry immediately before pte_free_tlb (line 1983, zap_pte_table_if_empty). If we have any pending flushes (i.e. we actually zapped any last-level entries) at the time we clear the PMD entry, then the flush really ought to flush all references to the table (Linus certainly seems to think it will on all architectures [0]). The condition under which we have no accumulated flushes at the time of the clear is very complex (the whole zap_pte_range function has absurdly complex control flow). If we do hit the bad case, then we will end up clearing the PMD entry after the last time the range is flushed, and any CPU is free to cache a reference to the (empty) page table. If this happens due to an ordinary read or write, it would segfault, so it would be rare. But the cache could be speculatively filled as well. Then we'll flush the wrong address and then free and possibly reuse the table. On x86, even flushing the wrong address works on non-KPTI Intel systems because INVLPG flushes *all* paging-structure-caches, not just the ones for the target address. But INVPCID does not, and flush_tlb_one_user will use INVPCID if it's available. And then we're toast. AMD systems are more susceptible: we set the EFER.TCE bit, which makes even INVLPG only flush the target address. I think this might fix an issue in ripgrep reported here: https://github.com/BurntSushi/ripgrep/issues/3494 [0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74686", "url": "https://ubuntu.com/security/CVE-2026-74686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rqspinlock: Reset tail when preserving queue on deadlock Currently, the destruction of the waiter queue is suppressed for rqspinlock in cases where a deadlock is detected. Deadlock checks happen relatively frequently (on entry for AA, within 1ms for ABBA), and waiter threads may not be involved in locking scenarios involving deadlocks. Thus, it is useful to not flush the queue and let other waiters take a stab at acquiring the lock after we detect a deadlock and exit. However, we need to follow the same logic as what we did previously for the waitq_timeout label: reset the tail, and if we cannot, signal the next waiter appropriately. In case of deadlocks, this signal would just mark the MCS node as unlocked, and in case of timeouts, it would signal RES_TIMEOUT_VAL. The difference thus is in the value propagated, which decides whether the queue remains active or gets flushed. Not doing the tail reset, and waiting for the next waiter can lead to cases where we are the final waiter, and thus no next waiter arrives, leading to intermittent stalls in this path. Once the next waiter does join, we will be unblocked. In the theoretical case when the next waiter never joins, we risk stalling indefinitely. This can only happen for ABBA deadlocks, since entry into the wait queue is guarded with AA checks. A precise sequence of executions leading up to this scenario can be: CPU 0 holds lock A. CPU 1 holds lock B. CPU 2 attempts lock B, becomes the pending waiter for B. CPU 0 attempts lock B. B has locked+pending bits set, thus CPU 0 queues. CPU 1 attempts lock A. CPU 0 detects an ABBA deadlock. Once deadlock detection happens for CPU 0, it will sit waiting for the next waiter in the queue to populate node->next, which will experience delays until such a waiter arrives. Fix this by adjusting the logic for the check for deadlocks preceding the waitq_timeout label. It would make sense to consolidate code for both cases and use 'ret' to distinguish the value being propagated, but that is left as an exercise for a future refactoring task to avoid diff noise in this patch.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74699", "url": "https://ubuntu.com/security/CVE-2026-74699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix memory leak in exec_queue_set_hang_replay_state() The q->replay_state is blindly overwritten, which can potentially leak memory that was previously allocated by vmemdup_user(). Return an error if q->replay_state is not empty. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit f6b6cc1118bdbc4265fa8b3bdf8565b26f13e56e)", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74706", "url": "https://ubuntu.com/security/CVE-2026-74706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnge: Fix NULL pointer dereference in aux device release If allocation of auxr_dev fails during auxiliary device setup, the error path calls auxiliary_device_uninit(), which eventually invokes bnge_aux_dev_release(). The release callback unconditionally dereferences aux_priv->auxr_dev->pdev to retrieve the parent bnge_dev. Since auxr_dev has not yet been allocated on this failure path, the dereference results in a NULL pointer exception Retrieve the parent bnge_dev from the auxiliary device's parent instead of auxr_dev, and free auxr_dev only when it was successfully allocated. This allows the release callback to correctly clean up partially initialized auxiliary devices.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74713", "url": "https://ubuntu.com/security/CVE-2026-74713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_iotlb: bound map allocation in add_range vhost_iotlb_add_range_ctx() only retires an old entry when the table has a non-zero limit, has exactly reached that limit and has VHOST_IOTLB_FLAG_RETIRE set. Non-retiring tables can keep allocating entries after reaching their configured limit. Existing vhost devices allocate their IOTLB with max_iotlb_entries from vhost.c, which defaults to 2048 and is tunable by module parameter. Use the caller-provided limit at the allocation point instead of adding a separate default in the common IOTLB helper, and reject non-positive values in vhost paths that can report an error. Other vhost IOTLB users should not create zero-limit tables when entries can be populated from userspace or guest-controlled requests. Add caller-side max_iotlb_entries parameters for mlx5 vDPA, VDUSE and vhost-vDPA. Reject non-positive VDUSE and vhost-vDPA values, and require at least two entries for vdpa_sim and mlx5 vDPA paths that install full-range mappings, since those mappings are split into two IOTLB entries. Handle full-range mappings in the common helper by checking that the IOTLB can hold both split entries before inserting the first half. This avoids returning an error after leaving a half mapping behind. When the table is full, keep the existing retire behavior for retiring tables and return -ENOSPC for non-retiring tables. Reuse the retired map node instead of freeing it and allocating a replacement, so a stream of IOTLB updates cannot keep forcing GFP_ATOMIC allocations after the table has reached its limit. If a zero-limit IOTLB still reaches the common helper, treat it as a configuration error and return -EINVAL. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74715", "url": "https://ubuntu.com/security/CVE-2026-74715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix netns reference imbalance in conntrack kfuncs The opts argument of the BPF conntrack kfuncs can point to a shared map value. __bpf_nf_ct_lookup() and __bpf_nf_ct_alloc_entry() read opts->netns_id separately when acquiring and releasing the network namespace reference. The reference imbalance can occur as follows: CPU 0 CPU 1 read opts->netns_id (-1) skip get_net_ns_by_id() write opts->netns_id (id) read opts->netns_id (id) put_net(net) /* no matching get */ The reverse transition leaks the reference. Repeating the unmatched put can destroy a live namespace and crash later users. The kernel reported: Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] RIP: 0010:bpf_prog_test_run_xdp+0x52c/0x1700 Call Trace: __sys_bpf+0x1662/0x50c0 __x64_sys_bpf+0x73/0xb0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception Snapshot every input field of opts with READ_ONCE() before validating or using it. The netns_id snapshot keeps the namespace get/put pair balanced, while the other snapshots keep the remaining options from changing partway through an invocation. The individual reads can still observe an inconsistent combination during a concurrent update, but each selected field value remains stable for that invocation.", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74716", "url": "https://ubuntu.com/security/CVE-2026-74716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix locally exploitable BUG_ON in amdxdna_insert_pages() In amdxdna_insert_pages(), vm_flags_mod() sets VM_MIXEDMAP and clears VM_PFNMAP. If an unprivileged userspace process mmaps a non-imported GEM object and then calls madvise(MADV_DONTNEED), the PTEs will be successfully cleared because VM_MIXEDMAP allows this (unlike VM_PFNMAP). When userspace subsequently accesses the memory, drm_gem_shmem_fault() handles the page fault and attempts to map the backing shmem page via vmf_insert_pfn() which calls vmf_insert_pfn_prot(). Because the backing shmem page is normal system memory (pfn_valid(pfn) is true) and the VMA now has VM_MIXEDMAP set, won't this predictably trigger the explicit assertion BUG_ON((vma->vm_flags & VM_MIXEDMAP) && pfn_valid(pfn)) Fix by removing the vm_flags_mod() call and replacing the vm_insert_pages() pre-population with the handle_mm_fault() loop that was already used for the import (dma-buf) path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74721", "url": "https://ubuntu.com/security/CVE-2026-74721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amxdna: Fix page-insertion errors in amdxdna_insert_pages() Two error paths in amdxdna_insert_pages() called vma->vm_ops->close(vma) before returning an error code to the caller. This is incorrect: amdxdna_gem_obj_mmap() registers an HMM interval notifier before calling amdxdna_insert_pages(), and on a hard error it jumps to hmm_unreg to undo that registration. Calling vm_ops->close() manually — which drops the shmem pages_pin_count and the GEM object reference that backs the VMA — before the mmap syscall has even returned causes those resources to be released while the VMA is still alive. The kernel VMA teardown will call vm_ops->close() a second time when the process later unmaps the range, producing a reference count underflow. Replace both hard-error returns with a deferred-fault approach that keeps the VMA alive and retries page insertion through the HMM range-fault path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74723", "url": "https://ubuntu.com/security/CVE-2026-74723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: lzo: reject inline extents without valid headers [BUG] For a crafted btrfs image, the following KASAN can be triggered when reading an inline lzo compressed file extent: BUG: KASAN: slab-out-of-bounds in lzo_decompress+0x57d/0x700 Read of size 4 at addr ffff888006f2e644 by task btrfs_lzo_inlin/77 Call Trace: dump_stack_lvl+0x5b/0x70 print_report+0xd1/0x610 kasan_report+0xe0/0x110 __asan_report_load_n_noabort+0x13/0x20 lzo_decompress+0x57d/0x700 btrfs_decompress+0x140/0x1c0 uncompress_inline+0x147/0x1b0 btrfs_get_extent+0xb23/0x10a0 btrfs_do_readpage.constprop.0+0x538/0x1ac0 btrfs_readahead+0x32f/0x5f0 read_pages+0x16f/0x850 page_cache_ra_unbounded+0x296/0x490 do_page_cache_ra+0xd9/0x130 page_cache_sync_ra+0x3ee/0x6f0 filemap_get_pages+0x306/0x15c0 filemap_read+0x329/0xd00 btrfs_file_read_iter+0x1f8/0x2b0 vfs_read+0x4ef/0x720 ksys_read+0xf8/0x1d0 __x64_sys_read+0x71/0xb0 x64_sys_call+0x1ab0/0x1b70 do_syscall_64+0x61/0x470 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [CAUSE] For an inline lzo compressed file extent, there should always be one lzo header, recording the total length of the compressed data, followed by one segment header, recording the compressed lzo payload. But if a crafted inline lzo compressed file extent contains only an lzo header, without the segment header or payload, lzo_decompress() will still try to read the segment header, causing a read beyond the item boundary. Furthermore if the inline lzo compressed file extent is the first item of the leaf, it will be at the extent buffer boundary. The above out-of-boundary read will go beyond the extent buffer boundary, triggering the above KASAN report. [FIX] Validate the total length of the inlined lzo compressed file extent, to make sure there is at least one LZO header and one segment header, and a non-zero payload. [ Rework the commit message to remove slop ]", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74729", "url": "https://ubuntu.com/security/CVE-2026-74729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read put_fifo_with_discard() acts as both producer and consumer on the kfifo: it calls kfifo_skip() (advances out) and kfifo_put() (advances in) from the IRQ handler without synchronizing with snoop_file_read(), which also consumes via kfifo_to_user(). On SMP systems this concurrent access can leave (in - out) larger than the ring buffer, so __kfifo_to_user()'s clamp to (in - out) is ineffective and kfifo_copy_to_user() can attempt a copy_to_user() past the kmalloc-2k backing store: usercopy: Kernel memory exposure attempt detected from SLUB object 'kmalloc-2k' (offset 0, size 2049)! kernel BUG at mm/usercopy.c! Call trace: usercopy_abort __check_heap_object __check_object_size kfifo_copy_to_user __kfifo_to_user snoop_file_read vfs_read Serialize kfifo access with a per-channel spinlock shared between the IRQ handler (producer) and the file reader (consumer). Annotate @fifo with __guarded_by(&lock) and opt the driver into context analysis so the compiler enforces that all fifo access holds the lock.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74733", "url": "https://ubuntu.com/security/CVE-2026-74733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: pca953x: fix pca953x_irq_bus_sync_unlock regmap lock Locking is disabled in the regmap config as this driver uses its own lock. This means that all calls to regmap functions (read or write) must hold the i2c_lock. The function pca953x_irq_bus_sync_unlock() did not do this, and it was therefore possible that multiple threads could cause an incorrect register to be read/written. A previous patch partly fixed this, but only protected the write to the interrupt mask register, and not the read from the direction register.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74585", "url": "https://ubuntu.com/security/CVE-2026-74585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound the DROM dual link port number before indexing sw->ports tb_drom_parse_entry_port() validates the device-supplied header->index against sw->config.max_port_number before indexing sw->ports[], but the sibling field entry->dual_link_port_nr -- a 6-bit value also read from the DROM -- indexes the same array with no such check. A malicious or malformed Thunderbolt device can set dual_link_port_nr beyond the allocated sw->ports[] (max_port_number + 1 entries), producing an out-of-bounds tb_port pointer that is stored and later dereferenced. Reject a port entry whose dual_link_port_nr exceeds max_port_number, the same bound already applied to header->index.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74586", "url": "https://ubuntu.com/security/CVE-2026-74586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: clear new_transport when removing a peer sctp_process_asconf_param() stores a newly added peer transport in asoc->new_transport. After all parameters in the ASCONF chunk have been processed, sctp_sf_do_asconf() uses this pointer to send a HEARTBEAT to the new transport. An authenticated ASCONF from a remote SCTP peer can add a transport and remove it again with a wildcard DEL-IP parameter in the same chunk. The wildcard deletion preserves the transport on which the ASCONF arrived, but removes the newly added transport through sctp_assoc_del_nonprimary_peers(). The removal does not clear asoc->new_transport, leaving it pointing to the removed transport. sctp_sf_do_asconf() then creates a HEARTBEAT whose chunk->transport points to the removed transport without holding a transport reference. During local address replacement, src_out_of_asoc_ok keeps this HEARTBEAT on control_chunk_list. After the transport is freed by RCU, a successful ASCONF_ACK for the replacement address releases the queued HEARTBEAT and sctp_outq_select_transport() reads the freed transport's state. The issue was found during a static audit of SCTP objects. With an authenticated peer, the reproducer triggered the same KASAN report in 2 of 2 unpatched runs on a KASAN-enabled netdev/main kernel: BUG: KASAN: slab-use-after-free in sctp_outq_select_transport Read of size 4 at addr ffff88800b9bd95c by task python3/197 Call Trace: sctp_outq_select_transport+0x549/0x8b0 [sctp] sctp_outq_flush+0x306/0x2c60 [sctp] sctp_transport_immediate_rtx+0xaf/0x260 [sctp] sctp_process_asconf_ack+0xa48/0xf70 [sctp] Allocated by task 197: sctp_transport_new+0x68/0x650 [sctp] sctp_assoc_add_peer+0x258/0x12a0 [sctp] sctp_process_asconf+0x5e9/0x1090 [sctp] Last potentially related work creation: __call_rcu_common.constprop.0+0x77/0xb70 sctp_assoc_del_nonprimary_peers+0x7c/0xd0 [sctp] sctp_process_asconf+0xd9c/0x1090 [sctp] The first invalid access was a four-byte read of transport->state at net/sctp/outqueue.c:833. The same reproducer completed the full authenticated ASCONF and local-address replacement sequence with this change without a KASAN report or oops. Clear new_transport when its peer is removed, before it can be used to create the HEARTBEAT.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74587", "url": "https://ubuntu.com/security/CVE-2026-74587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix use-after-free of cached ASCONF chunk addip_last_asconf caches the outstanding outbound ASCONF chunk. The normal ASCONF-ACK completion path releases the chunk and clears the pointer. However, sctp_asconf_queue_teardown() releases the cached chunk without clearing addip_last_asconf. During peer restart handling, sctp_sf_do_dupcook_a() queues SCTP_CMD_PURGE_ASCONF_QUEUE, which invokes sctp_asconf_queue_teardown() while the association remains alive and leaves the pointer dangling. A delayed authenticated ASCONF-ACK can then reach sctp_sf_do_asconf_ack(), which accesses the stale chunk and passes it to sctp_process_asconf_ack(), causing a use-after-free and a second release. Clearing the pointer exposes a race with T4 expiry. Peer restart handling queues the timer stop before the purge, but SCTP_CMD_TIMER_STOP uses timer_delete(), which does not wait for a callback already running on another CPU. Such a callback can reach sctp_sf_t4_timer_expire() after the purge and dereference NULL. Clear addip_last_asconf after releasing the cached chunk, and make sctp_sf_t4_timer_expire() consume a stale T4 expiry if no outstanding ASCONF remains.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74588", "url": "https://ubuntu.com/security/CVE-2026-74588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: keep chunk->transport in step with the list it is queued on __sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport: \tif (chunk->tsn_gap_acked) { \t\tlist_move_tail(&chunk->transmitted_list, \t\t\t &transport->transmitted); \t\tcontinue; \t} The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctp_assoc_rm_peer() from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk is left with a dangling pointer. sctp_assoc_rm_peer() scrubs peer->transmitted and asoc->outqueue.out_chunk_list, but the chunk is on neither. The pointer is not followed while tsn_gap_acked is set. A SACK that reneges on the TSN clears the flag, and the next SACK reaches \ttchunk->transport->flight_size -= sctp_data_size(tchunk); inside the freed transport. KASAN reports a slab-use-after-free read in sctp_check_transmitted(), freed from sctp_assoc_rm_peer(). Both the removal and the SACKs come from the association peer. Set chunk->transport at the move. The ordinary resend path needs nothing: it reaches its list_move_tail() only after sctp_packet_append_chunk() returned SCTP_XMIT_OK, and __sctp_packet_append_chunk() has rebound the chunk by then. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74589", "url": "https://ubuntu.com/security/CVE-2026-74589", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix sk_redir use-after-free in send verdict sk_psock_msg_verdict() takes a socket reference for psock->sk_redir. tcp_bpf_send_verdict() copies that pointer while holding the source socket lock, but does not take a reference for the local copy before dropping the lock around tcp_bpf_sendmsg_redir(). When apply_bytes keeps the cached verdict active, another sendmsg() on the same source socket can consume the remaining bytes and release the cached reference while the first thread still holds only the raw local pointer: CPU 0 CPU 1 sk_redir = psock->sk_redir apply_bytes remains nonzero release_sock(sk) lock_sock(sk) apply_bytes reaches zero psock->sk_redir = NULL release_sock(sk) tcp_bpf_sendmsg_redir(sk_redir) sock_put(sk_redir) tcp_bpf_sendmsg_redir(sk_redir) The final sock_put() can free sk_redir before CPU 0 dereferences it. KASAN reported: BUG: KASAN: slab-use-after-free in tcp_bpf_sendmsg_redir+0xf39/0x1020 Read of size 8 at addr ffff888108537090 by task poc/87 Call Trace: tcp_bpf_sendmsg_redir+0xf39/0x1020 tcp_bpf_sendmsg+0x977/0x1a50 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 85: sk_prot_alloc+0x56/0x210 sk_clone+0x6f/0x14b0 inet_csk_clone_lock+0x24/0x740 tcp_create_openreq_child+0x25/0x2710 tcp_v4_syn_recv_sock+0x10a/0xe00 Freed by task 0: __kasan_slab_free+0x43/0x70 slab_free_after_rcu_debug+0xa6/0x1e0 rcu_core+0x50a/0x1850 Last potentially related work creation: __sk_destruct+0x3da/0x540 sk_psock_destroy+0x81e/0xab0 process_one_work+0x63a/0x1070 Take a temporary socket reference while the source socket lock still protects psock->sk_redir, and drop it after tcp_bpf_sendmsg_redir() returns. This keeps each unlocked use independent of cached-verdict ownership.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74590", "url": "https://ubuntu.com/security/CVE-2026-74590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsverity: Fix bpf_get_fsverity_digest() dynptr assumptions The BPF verifier and the dynptr abstraction ensure that the memory space referenced by a dynptr remains valid. They do not, however, provide any guarantee that the contents of the memory are stable. kfuncs are expected to remain memory-safe even if concurrent modifications occur. bpf_get_fsverity_digest() didn't follow that: it could crash if arg->digest_size was concurrently modified. Fix that by using the known-good value hash_alg->digest_size instead. Also widen 'dynptr_sz' and 'out_digest_sz' to u64 to match the return type of __bpf_dynptr_size(). It doesn't appear that it can actually be more than INT_MAX currently (since __bpf_dynptr_data_rw() excludes file-based pointers), but the correct type might as well be used.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74591", "url": "https://ubuntu.com/security/CVE-2026-74591", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: __filemap_add_folio() restore index before retrying In __filemap_add_folio()'s split-a-conflict loop, xas_set_order() is applied repeatedly: each application modifies xas.xa_index, rounding it down according to the split_order attempted at that stage: and if all goes as intended, it eventually (or immediately) converges on an xas_try_split() to the required folio_order, with xas.xa_index now the same as index: then xas_store() puts the new folio into the xarray there. But if a new node was needed, and GFP_NOWAIT allocation did not get one, the lock is dropped, xas_nomem() used to allocate, and sequence retried. If (that part of) the xarray is unchanged when the lock is reacquired, no problem. But what if the conflict was meanwhile resolved by another thread (perhaps even doing the same thing, inserting a folio at that same index)? Isn't there a danger of now putting our folio into the xarray at an intermediate rounded-down index? With !folio_contains() bug to follow, when CONFIG_DEBUG_VM=y is checking for that. Fix this with an xas_set_order() to restore the original xas.xa_index at the bottom of the loop, so the retry does a full re-evaluation after reacquiring the lock, and cannot reach xas_store() with the wrong index. Production was suffering from rare SIGILLs and SIGSEGVs, executable text found a page away from where it belonged, !folio_contains() bug hit when debug enabled: symptoms not seen since this patch went in.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74592", "url": "https://ubuntu.com/security/CVE-2026-74592", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Instantiate file_truncate and path_truncate hooks Instantiate the file_truncate and path_truncate LSM hooks to reset the action cache flags (IMA_DONE_MASK) as soon as truncation is requested, so the file, based on policy, is re-collected, re-measured, re-audited, and re-appraised on next access.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74594", "url": "https://ubuntu.com/security/CVE-2026-74594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/psi: Shut down rtpoll_timer in psi_cgroup_free() psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath and can race psi_trigger_destroy() taking down the last rtpoll trigger under rtpoll_trigger_lock: psi_schedule_rtpoll_work() psi_trigger_destroy() rcu_read_lock(); task = rcu_dereference(rtpoll_task); rcu_assign_pointer(rtpoll_task, NULL); timer_delete(&rtpoll_timer); mod_timer(&rtpoll_timer, ...); rcu_read_unlock(); synchronize_rcu(); kthread_stop(task_to_destroy); The group can then be freed with the re-armed timer still pending, and poll_timer_fn() runs on freed memory. 461daba06bdc (\"psi: eliminate kthread_worker from psi trigger scheduling mechanism\") deleted the timer synchronously after the synchronize_rcu(), which prevented this but raced trigger creation instead: the deletion could cancel the timer that a new trigger set armed during the grace period and, as creation also reinitialized the timer at the time, corrupt it. 8f91efd870ea (\"psi: Fix race between psi_trigger_create/destroy\") moved the initialization into group_init() and the deletion into the locked section, trading the creation races for the window above. Neither placement in the destruction path works. A pending timer firing while the group is alive is harmless though. poll_timer_fn() just wakes the rtpoll waitqueue and doesn't re-arm itself. Bind the timer to the group's lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it by then. timer_shutdown_sync() because the timer is never armed again.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74595", "url": "https://ubuntu.com/security/CVE-2026-74595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy() fscrypt_ioctl_set_policy() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing an encryption policy to be set, instead of the idmap of the mount the ioctl was issued on. fscrypt is used by filesystems that support idmapped mounts (e.g. ext4, f2fs), so on such a mount this compares the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EACCES and an unrelated caller wrongly allowed. Use file_mnt_idmap(filp) instead.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74597", "url": "https://ubuntu.com/security/CVE-2026-74597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip6ip6_err() ip6ip6_err() clones an outer IPv6 ICMP error skb, pulls it to the quoted inner IPv6 packet, and then passes the clone to icmpv6_send(). The clone still carries the outer packet's inet6_skb_parm in skb->cb. If the outer packet had a Home Address Option, IP6CB(skb2)->dsthao remains non-zero after skb_pull(). icmpv6_send() later calls mip6_addr_swap(), which uses that stale dsthao offset against the quoted inner packet. A malformed inner destination-options header can then make the HAO lookup and address swap run past the end of the quoted packet and corrupt skb_shared_info. Clear skb2->cb[] before pulling the quoted inner IPv6 packet so the reply path does not reuse metadata left by the outer IPv6 stack.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74598", "url": "https://ubuntu.com/security/CVE-2026-74598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix Route Information option length validation rt6_route_rcv() validates the Route Information option (RFC 4191) length against the prefix length, but both checks are off by one. rinfo->length is the ND option length in units of 8 octets and it *includes* the 8-byte option header, so an option carrying N bytes of prefix has length == 1 + N/8. RFC 4191 section 2.3 requires length 3 when Prefix Length is greater than 64, and 2 or 3 when it is greater than 0. The code accepts length >= 2 and length >= 1 respectively. ipv6_addr_prefix() then copies prefix_len/8 bytes out of rinfo->prefix, so a Router Advertisement with (prefix_len=128, length=2) or (prefix_len=64, length=1) makes the kernel read up to 8 bytes past the end of the option. Those bytes end up in the prefix of the route that gets installed, so they are visible to userspace: # RA with a Route Information option (prefix_len=128, length=2) # followed by a source link-layer address option, 01 01 de ad be ef ca fe $ ip -6 route show 2001:db8:dead:beef:101:dead:beef:cafe via fe80::1234 dev veth0 proto ra ^^^^^^^^^^^^^^^^^^ the next option, read out of bounds When the Route Information option is the last one in the packet, those eight bytes come from the skb tail room instead. Reject the option lengths RFC 4191 does not allow.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74599", "url": "https://ubuntu.com/security/CVE-2026-74599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/ptdump: always stabilise against page table freeing using init_mm Previous commits have established the invariant that kernel page table freeing is performed while an mmap read lock on init_mm is held, which fixes races between ptdump and kernel page table freeing over init_mm. However, x86 and arm64 can perform a ptdump over an mm other than init_mm via ptdump_walk_pgd() and since kernel memory ranges are shared across non-kernel mm's, this means that the race still exists for these cases. Fix this by acquiring a nested mmap write lock for init_mm in ptdump_walk_pgd(). This is safe as we take this after mmap write locking the mm, and nothing acquires the init_mm lock first before locking an arbitrary mm, so no deadlock is possible. Also update walk_page_range_debug() to assert that init_mm is write locked, add a comment explaining why and remove some redundant code, and eliminate the unnecessary and confusing invocation of walk_kernel_page_table_range(). We can safely remove the non-NULL check for walk.mm, as the mmap lock asserts would NULL pointer deref if it was (and of course no callers do this). The first point at which ptdump can race kernel page table freeing is commit b6bdb7517c3d (\"mm/vmalloc: add interfaces to free unmapped page table\"), so we target this in the Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74601", "url": "https://ubuntu.com/security/CVE-2026-74601", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Use current_context for safe per-CPU buffer swap The ring_buffer_swap_cpu() function currently checks the per-CPU committing counter to determine if a buffer is actively being written to before performing the swap. However, there exists a race window where this check can be bypassed: ring_buffer_lock_reserve cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_a rb_reserve_next_event rb_start_commit // inc committing if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) {...} __rb_reserve_next rb_move_tail rb_end_commit(cpu_buffer); // dec committing => 0 /* interrupt hits here, successfully swaps! */ local_inc(&cpu_buffer->committing); ring_buffer_unlock_commit cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_b rb_commit rb_end_commit RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing)) // triggers warning The committing counter can temporarily drop to 0 during a single write operation (within rb_move_tail), creating a window where swap can succeed even though the write is still in progress. This leads to inconsistent buffer state and triggers the RB_WARN_ON in rb_commit(). Replace the committing counter check with current_context checks, which are set at the entry of ring_buffer_lock_reserve() and remain valid throughout the entire write operation, providing a reliable indicator of buffer busy state during swap.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74602", "url": "https://ubuntu.com/security/CVE-2026-74602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Initialise reader page order in rb_allocate_cpu_buffer() In rb_allocate_cpu_buffer(), bpage->order was omitted, leaving it as 0. This is an issue for a ring-buffer with subbufs bigger than PAGE_SIZE if when freed: free_buffer_page() relies on this value. Align the value with the actual allocation size (buffer::subbuf_order).", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74603", "url": "https://ubuntu.com/security/CVE-2026-74603", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ocp: Fix board ID over-read The EEPROM board ID is a fixed 13-byte field and is not guaranteed to contain a NUL terminator. Passing it directly to devlink_info_version_fixed_put() treats it as a C string and may read beyond the field. Format at most OCP_BOARD_ID_LEN bytes into the existing local buffer before reporting the ID. Use a precision limit because the snprintf() output size alone does not bound the source string scan.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74604", "url": "https://ubuntu.com/security/CVE-2026-74604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"thermal/drivers/hwmon: Cleanup coding style a bit\" Revert commit 030a48b0f6ce (\"thermal/drivers/hwmon: Cleanup coding style a bit\") that introduced a use-after-free into the error path of thermal_add_hwmon_sysfs() by removing a valid check from it.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74606", "url": "https://ubuntu.com/security/CVE-2026-74606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventfs: Fix use-after-free in eventfs_remove_rec() eventfs_remove_rec() recursively removes the child at the current loop position. After the recursive call returns, list_for_each_entry() advances by reading list.next from the removed child. If free_ei() drops the final reference, release_ei() reuses the list/rcu union to queue an SRCU callback. The child may be freed before that read. The eventfs_mutex serializes list updates, but it does not keep the removed child alive or prevent the SRCU callback from running. Use list_for_each_entry_safe() to save the next sibling before recursively removing the current child.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74607", "url": "https://ubuntu.com/security/CVE-2026-74607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Serialize accesses to the owner and mirror list with separate lock Interaction between KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM and KVM_CAP_VM_COPY_ENC_CONTEXT_FROM can cause two separate issues: - in sev_migrate_from(), when the destination KVM is a mirror, the mirror entry is moved from the source's list to the owner's mirror_vms list, without holding the owner's lock unlike other writers of the owner's mirror list (sev_vm_copy_enc_context_from(), sev_vm_destroy()). A concurrent COPY or destroy can race with sev_migrate_from() and corrupt the list. - In sev_vm_destroy(), the *owner* is still active and could receive concurrently a KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM that causes sev->enc_context_owner to change. In this case the incorrect VM receives kvm_put_kvm(). The second issue needs particular care because the owner could disappear altogether (even though the race window is impossibly small) between reading it and locking it. There is thus no way to perform the checks under the owner lock without putting struct kvm under SLAB_TYPESAFE_BY_RCU (which would allow kvm_get_kvm_safe() under RCU critical section). It is much simpler to just use a global lock, since the critical sections are so small and the new lock is always a leaf lock.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74608", "url": "https://ubuntu.com/security/CVE-2026-74608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free in cifs_try_adding_channels() cifs_try_adding_channels() takes a temporary reference to an interface before dropping iface_lock. If cifs_ses_add_channel() fails, it drops that reference and then increments iface->weight_fulfilled. A concurrent interface list refresh can remove the list reference while channel creation is in progress. In that case, the failure-path kref_put() releases the last reference and frees iface. Updating weight_fulfilled afterward then accesses freed memory. Increment weight_fulfilled before dropping the temporary reference, keeping iface alive for the final access.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74609", "url": "https://ubuntu.com/security/CVE-2026-74609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: read le->link under the node lock in tipc_node_link_down() tipc_node_link_down() caches the link pointer before taking n->lock: \tstruct tipc_link *l = le->link;\t\t/* unlocked */ \tif (!l) \t\treturn; \ttipc_node_write_lock(n); \tif (!tipc_link_is_establishing(l)) {\t/* deref l */ \t... \t\ttipc_link_reset(l);\t\t/* write into l */ \tif (delete) { \t\tkfree(l); \t\tle->link = NULL; The delete=true caller frees that very object under n->lock, so the lock does not protect the cached pointer against it: - CPU A, delete=false: tipc_rcv() on TIPC_LINK_DOWN_EVT, or the link supervision timer via tipc_node_timeout(), reads l unlocked and then dereferences it under n->lock; - CPU B, delete=true: netlink TIPC_NL_BEARER_DISABLE -> bearer_disable() -> tipc_node_delete_links() -> tipc_node_link_down(n, bearer_id, true) -> kfree(l). The link is freed with plain kfree(), not kfree_rcu(), and for UDP bearers disable_media() only schedules the asynchronous cleanup_bearer() work, so its synchronize_net() runs after the links are already gone. An in-flight CPU A that has read l therefore dereferences freed memory once B frees it: a use-after-free read in tipc_link_is_establishing(), and a use-after-free write via tipc_link_reset() on the establishing branch. The following trace was captured on 7.2.0-rc5-00284-gaf39eb111ce6: BUG: KASAN: slab-use-after-free in tipc_link_is_establishing (net/tipc/link.c:285) Read of size 4 at addr ffff88802e2aa068 by task swapper/2/0 tipc_link_is_establishing (net/tipc/link.c:285) tipc_node_link_down (net/tipc/node.c:1076) tipc_node_timeout (net/tipc/node.c:843) Allocated by task 9549: tipc_link_create (net/tipc/link.c:490) tipc_node_check_dest (net/tipc/node.c:1279) tipc_disc_rcv (net/tipc/discover.c:252) tipc_udp_recv (net/tipc/udp_media.c:389) Freed by task 9549: tipc_node_link_down (net/tipc/node.c:1084) tipc_node_delete_links (net/tipc/node.c:1320) bearer_disable (net/tipc/bearer.c:414) __tipc_nl_bearer_disable (net/tipc/bearer.c:992) Move the le->link read inside tipc_node_write_lock(), so it is serialised against the kfree() in the delete path. A racing teardown now either has not run yet, and we see a valid link, or has already run, and we see NULL.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74610", "url": "https://ubuntu.com/security/CVE-2026-74610", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: don't leave a full plaintext sk_msg ring unpushed When the copy path in tls_sw_sendmsg_locked() adds the fragment that fills the plaintext sk_msg ring, it does not set full_record, so the record is left full and unpushed. A later splice() then adds to an already full ring: sk_msg_page_add() has no fullness check of its own, so sg.end wraps onto sg.start and the ring appears empty. Fragments added after that overwrite live entries, and sg.size no longer matches what is reachable between sg.start and sg.end, so pushing the record runs the scatterwalk off the end of the scatterlist. An unprivileged user can trigger this on a loopback TCP socket with the \"tls\" ULP attached: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:memcpy_from_scatterwalk+0x32/0xc0 Call Trace: skcipher_walk_next+0x1d1/0x2c0 gcm_encrypt_aesni_avx+0x1e9/0x220 bpf_exec_tx_verdict+0x3bb/0x860 tls_sw_sendmsg+0xa1a/0xca0 __sys_sendto+0x1da/0x1f0 Set full_record in the copy path when the ring becomes full, and push a record that is already full on entry to the sendmsg loop.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74611", "url": "https://ubuntu.com/security/CVE-2026-74611", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: rx: restore msg_iter before TLS 1.3 optimistic retry tls_decrypt_sg() advances msg->msg_iter when it maps user pages for the optimistic TLS 1.3 zero-copy path. If the decrypted record turns out not to be unpadded application data, tls_decrypt_sw() retries into a kernel skb, but leaves the iterator advanced. The subsequent copy from the skb then writes decrypted bytes again at a later point in the caller iovecs while recvmsg() reports only the post-retry length. A TLS peer can trigger this after the receiver enables TLS_RX_EXPECT_NO_PAD. Revert the iterator by the number of bytes consumed by the optimistic mapping before retrying without zero-copy. Add a selftest which sends a TLS 1.3 control record with TLS_RX_EXPECT_NO_PAD enabled and verifies that recvmsg() does not overwrite later iovecs beyond the returned length.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74580", "url": "https://ubuntu.com/security/CVE-2026-74580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost: reset the vring metadata cache on vring reconfiguration vq->meta_iotlb[] caches the vhost_iotlb_map that backs each vring metadata region, and iotlb_access_ok() returns early on a cache hit, taking the hit as proof that the region has already been validated: \tif (vhost_vq_meta_fetch(vq, addr, len, type)) \t\treturn true; The cache is reset on VHOST_IOTLB_UPDATE and VHOST_IOTLB_INVALIDATE, on device IOTLB (re)initialisation and on vq reset, but not when VHOST_SET_VRING_ADDR replaces vq->desc, vq->avail and vq->used, nor when VHOST_SET_VRING_NUM changes the region sizes. With a device IOTLB attached both ioctls are accepted while the vq is live, and neither validates the addresses at ioctl time: vq_access_ok() and vq_log_used_access_ok() return true early because the addresses are GIOVAs, deferring validation to prefetch time. Once the cache has been populated that deferred validation no longer runs -- vq_meta_prefetch() hits the stale entry and returns true -- and vhost_vq_meta_fetch() keeps translating through the old mapping as \tmap->addr + addr - map->start for an address the mapping no longer covers. vhost_copy_to_user() and vhost_copy_from_user() consume the result with __copy_to_user() and __copy_from_user(), which do not check it either, so a subsequent used ring update or descriptor fetch accesses memory outside the region the IOTLB actually maps. Reset the metadata cache whenever the vring is reconfigured, so the new addresses are pushed back through iotlb_access_ok()'s slow path.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-74612", "url": "https://ubuntu.com/security/CVE-2026-74612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: fix skb length accounting after XDP frag adjustment veth exposes non-linear skb fragments through an xdp_buff. If an XDP program adjusts the fragment area, veth_xdp_rcv_skb() copies xdp_frags_size back to skb->data_len but leaves skb->len containing the old fragment contribution. After a fragment shrink, this makes skb_headlen() larger than the actual linear area. In the reproduced UDP receive path, __skb_datagram_iter() copied 1024 bytes past the actual linear tail to userspace, starting at struct skb_shared_info. The copied bytes included the affected skb's nr_frags, xdp_frags_size, and a kernel pointer from skb_shinfo(skb)->frags[0]. Real packet data was displaced by the same amount and truncated at the end. Subtract the old data_len before replacing it and add the new data_len afterwards, keeping skb->len and skb->data_len synchronized. Additionally, bpf_xdp_pull_data() can advance data_end while leaving frags present. The skb is then still non-linear, so the old __skb_put(skb, off) triggers SKB_LINEAR_ASSERT(). Use skb_set_tail_pointer() and update skb->len explicitly instead, following bpf_prog_run_generic_xdp(). Unlike __skb_put(), skb_set_tail_pointer() does not require a linear skb. A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by 1024 bytes from its fragment area. Before the fix, all 10 runs produced corrupted payloads. After the fix, all 10 runs matched the expected payload exactly. A forced-tailroom reproducer also exercises bpf_xdp_pull_data() with frags still present; the old code triggers SKB_LINEAR_ASSERT(), while this fix passes 10/10 runs.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74613", "url": "https://ubuntu.com/security/CVE-2026-74613", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: avoid refilling the RX queue after teardown Commit b917507e5ad9 (\"vsock/virtio: stop workers during the .remove()\") made the RX worker jump to its common exit when rx_run is clear. That exit still refills the RX queue when the buffer count is low, so work queued across virtio_vsock_vqs_del() can add buffers after the virtqueues have been deleted. BUG: KASAN: slab-use-after-free in virtqueue_add_sgs Read of size 4 by task kworker/0:1 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtqueue_add_sgs (drivers/virtio/virtio_ring.c:2796) virtio_vsock_rx_fill (net/vmw_vsock/virtio_transport.c:332) virtio_transport_rx_work (net/vmw_vsock/virtio_transport.c:701) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Freed by task 141: kfree (mm/slub.c:6566) vp_del_vq (drivers/virtio/virtio_pci_common.c:259) vp_del_vqs (drivers/virtio/virtio_pci_common.c:285) virtio_vsock_freeze (net/vmw_vsock/virtio_transport.c:912) virtio_device_freeze (drivers/virtio/virtio.c:658) virtio_pci_freeze (drivers/virtio/virtio_pci_common.c:601) pci_pm_freeze (drivers/pci/pci-driver.c:1098) device_suspend (drivers/base/power/main.c:1968) Kernel panic - not syncing: KASAN: panic_on_warn set ... Jump to a no-refill exit when rx_run is clear, leaving the normal exit to replenish a running queue.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74614", "url": "https://ubuntu.com/security/CVE-2026-74614", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: read virtqueues under worker locks Commit bd50c5dc182b (\"vsock/virtio: add support for device suspend/resume\") made the *_run flags transition from false to true when restore installs replacement virtqueues. The RX, TX and event workers read their virtqueue before locking and checking the corresponding flag, so a worker delayed across freeze and restore can observe the replacement queue's running state while retaining a pointer to the deleted queue. Read each virtqueue under its mutex after checking the run flag, keeping the pointer and state in the same queue generation.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74615", "url": "https://ubuntu.com/security/CVE-2026-74615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not arm the ageing timer on a device that is down vxlan_changelink() arms vxlan->age_timer whenever the requested ageing interval differs from the configured one: \tif (conf.age_interval != vxlan->cfg.age_interval) \t\tmod_timer(&vxlan->age_timer, jiffies); There is no netif_running() test, so the timer is armed even on a device that was never brought up. The only synchronous cancel in the driver is the timer_delete_sync() in vxlan_stop(), which is .ndo_stop. netif_close_many() drops devices without IFF_UP before __dev_close_many() runs, so that cancel is skipped for such a device. vxlan_setup() sets dev->needs_free_netdev = true and age_timer is a member of struct vxlan_dev, so free_netdev() releases the allocation the timer lives in while it is still queued on a timer_base. expire_timers() unlinks the entry before it loads timer->function, so the timer core writes through the freed object's list pointers: BUG: KASAN: slab-use-after-free in __run_timers+0x208/0x654 Write of size 8 at addr ffff00001adace68 by task true/192 __asan_store8+0x84/0xac __run_timers+0x208/0x654 run_timer_softirq+0x154/0x18c Allocated by task 189: alloc_netdev_mqs+0x64/0x720 rtnl_create_link+0x4ac/0x520 rtnl_newlink+0x758/0xd00 Freed by task 191: netdev_release+0x40/0x58 netdev_run_todo+0x4a4/0x8c0 rtnl_dellink+0x200/0x4e8 The rtnl operations involved are netns-scoped, so an unprivileged user can perform them in a new user and network namespace. Arming the timer on a down device never had an effect: vxlan_cleanup() returns early on !netif_running(), and vxlan_open() arms the timer for any non-zero interval once the device is brought up. Add the missing test. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74616", "url": "https://ubuntu.com/security/CVE-2026-74616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xdp: reject clones that overrun skb_shared_info tailroom xdpf_clone() clones broadcast copies into a single page and sets frame_sz to PAGE_SIZE. __xdp_build_skb_from_frame() later treats that page like a normal XDP frame and expects the usual skb_shared_info tailroom at the end of the buffer. The current check only rejects frames whose linear xdp_frame header, headroom, and packet data exceed PAGE_SIZE. A source frame backed by a larger allocation can still satisfy that check while extending into the clone's required shared-info area. When such a clone is converted back into an skb, build_skb_around() places skb_shared_info over live packet bytes and later writes can corrupt XDP return metadata. Reject clones unless their linear area fits inside SKB_WITH_OVERHEAD(PAGE_SIZE), matching the tailroom requirement already enforced by the XDP-to-skb conversion path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74617", "url": "https://ubuntu.com/security/CVE-2026-74617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dibs: initialise dibs->lock in dibs_dev_alloc() dibs->lock is initialised by dibs_dev_add(), but a dibs device can already take interrupts before that call: ism_probe() runs ism_dev_init(), and hence request_irq(), before it calls dibs_dev_add(). No client can have registered a dmb at that point, so no dmb interrupt can occur, but a GID event interrupt can, and ism_handle_irq() takes dibs->lock unconditionally on entry, before it inspects anything else. Initialise the lock in dibs_dev_alloc() instead, so that it is valid as soon as a driver can publish the device to its interrupt handler.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74618", "url": "https://ubuntu.com/security/CVE-2026-74618", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't warn when the mount is completed from another user namespace fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in bm_fill_super(): create a user and a mount namespace in a child, call fsopen(\"binfmt_misc\") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere: WARNING: fs/binfmt_misc.c:938 at bm_fill_super+0xa2/0xc0 [binfmt_misc] CPU: 15 UID: 1000 PID: 3243382 Comm: fswarn Call Trace: get_tree_keyed+0x7d/0xb0 bm_get_tree+0x34/0x90 [binfmt_misc] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check. It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn. Keep refusing the mount and stop warning about it. Nothing in bm_fill_super() depends on the two namespaces matching, it derives everything from sb->s_user_ns.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74619", "url": "https://ubuntu.com/security/CVE-2026-74619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: don't warn when the mount is completed from another user namespace fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in ovl_fill_super(): create a user and a mount namespace in a child, call fsopen(\"overlay\") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere: WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay] CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn Call Trace: get_tree_nodev+0x71/0xa0 ovl_get_tree+0x15/0x20 [overlay] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check. It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn. Keep refusing the mount and stop warning about it. ovl_parse_param() already spells a user namespace check this way for Opt_override_creds.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74620", "url": "https://ubuntu.com/security/CVE-2026-74620", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_gact, act_police: range check the fallback control action tcf_action_check_ctrlact() range checks the primary control action: \tif (!opcode) \t\tret = action > TC_ACT_VALUE_MAX ? -EINVAL : 0; TC_ACT_VALUE_MAX is TC_ACT_TRAP, so kernel-internal verdicts above it cannot be set that way. But act_gact and act_police each carry a second, independent control action supplied by user space that never reaches that helper - TCA_GACT_PROB.paction and TCA_POLICE_RESULT. Both only reject TC_ACT_GOTO_CHAIN, so any other value is stored verbatim and returned verbatim from the action. In particular user space can store TC_ACT_CONSUMED, which is TC_ACT_VALUE_MAX + 1 and is deliberately not part of the UAPI value range. That verdict tells every caller the action took ownership of the skb, so nobody frees it: sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for it. The result is one leaked sk_buff plus its data buffer per packet traversing the filter, unbounded, for all traffic on the chain including kernel-generated packets. Both are trivially deterministic. act_gact clamps tcfg_pval to >= 1, so with pval = 1 gact_determ() returns the fallback for every packet. act_police has no mandatory rate, so rate = 0 leaves tcfp_mtu = ~0 and tcf_police_mtu_check() always passes. TC_ACT_CONSUMED was added by commit 720f22fed81b (\"net: sched: refactor reinsert action\"), after both goto-chain guards were written: commit 9469f375ab09 (\"net/sched: act_gact: disallow 'goto chain' on fallback control action\") and commit c08f5ed5d625 (\"net/sched: act_police: disallow 'goto chain' on fallback control action\"). Neither guard was widened when the new verdict appeared. Factor the existing range test out of tcf_action_check_ctrlact() as tcf_action_valid() and apply it to both fallbacks. The helper cannot call tcf_action_check_ctrlact() directly because that also allocates a goto_chain, which is exactly what these two sites must not do. Reproduced on v7.2-rc6: kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet. With this patch both configurations are rejected with -EINVAL and kmemleak reports none.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74621", "url": "https://ubuntu.com/security/CVE-2026-74621", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix sk_buff leak when the header checks reject a packet tcf_ct_handle_fragments() runs its header sanity checks before handing anything to the defragmentation engine: \tif (family == NFPROTO_IPV4) \t\terr = tcf_ct_ipv4_is_fragment(skb, &frag); \telse \t\terr = tcf_ct_ipv6_is_fragment(skb, &frag); \tif (err || !frag) \t\treturn err; tcf_ct_ipv4_is_fragment() returns -EINVAL or -ENOMEM; tcf_ct_ipv6_is_fragment() adds -EPROTO when ipv6_find_hdr() fails. None of them frees or queues the skb, so on that path the caller still owns it. tcf_ct_act() however funnels every non-zero return into the ownership-transfer exit: \terr = tcf_ct_handle_fragments(net, skb, family, p->zone, &defrag); \tif (err) \t\tgoto out_frag; \t... out_frag: \tif (err != -EINPROGRESS) \t\ttcf_action_inc_drop_qstats(&c->common); \treturn TC_ACT_CONSUMED; TC_ACT_CONSUMED means the action took ownership of the skb, so no caller frees it - sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for that verdict. The skb is therefore orphaned: one sk_buff plus its data buffer is leaked per malformed packet, unbounded. Note the drop counter is already incremented for these errors, so the statistics claim a drop that never happens. Three different ownership states reach out_frag: today - the skb may be queued by the defrag engine (-EINPROGRESS), already freed by nf_ct_handle_fragments(), or still owned by us. Tell the caller which of those it is, and free the packet ourselves in the last case, which restores the TC_ACT_SHOT behaviour that predated the Fixes: commit. Reproduced on v7.2-rc6 with a 54-byte frame carrying a 40-byte IPv6 header with nexthdr = 0 (hop-by-hop) and nothing after it, on a clsact ingress chain with \"action ct\". kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet; with this patch it reports none.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74622", "url": "https://ubuntu.com/security/CVE-2026-74622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: free RX pages of consumed but not refilled buffers aq_ring_rx_deinit() only walks [sw_head, sw_tail), the region posted to hardware. Since the page reuse strategy was added, a cleaned RX buffer keeps its page (and its DMA mapping) in the ring for reuse, and refill is batched: aq_ring_rx_fill() returns early until AQ_CFG_RX_REFILL_THRES slots are free. Slots that were consumed but not yet reposted therefore sit in the complementary [sw_tail, sw_head) gap with a live page, and the deinit walk never visits them: up to a refill batch worth of pages and DMA mappings leak on every interface down. Walk the whole ring instead and release whatever is still there. Also bail out if the buffer ring is already gone: a partial aq_ptp_ring_alloc() failure frees the ring but leaves aq_nic set, so aq_ptp_ring_deinit() still gets here on the unwind path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74623", "url": "https://ubuntu.com/security/CVE-2026-74623", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: free stranded TX buffers on ring deinit aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean() call, which frees at most AQ_CFG_TX_CLEAN_BUDGET (256) descriptors and stops at hw_head, which no longer moves once aq_vec_stop() has stopped the hardware and NAPI. Completed descriptors beyond the budget and everything still posted in [hw_head, sw_tail) keep their skb or xdp_frame when the interface goes down: aq_vec_ring_free() then frees the buffer ring and the references are lost for good. Today this is a silent memory leak on every interface down under TX/XDP_TX load. With the conversion of the RX path to page_pool posted for net-next it becomes much more visible: XDP_TX frames carry fragment references on the RX ring's page_pool, so a single stranded frame keeps the pool's inflight count above zero forever. page_pool_destroy() then never completes, the pool is leaked together with its pages, and \"page_pool_release_retry() stalled pool shutdown\" is warned every 60 seconds from that point on, on every ifdown, XDP detach or ring resize under XDP_TX load. Bring back aq_ring_tx_deinit() as it was before the removal and use it for teardown again, with one extension: TX rings can hold xdp_frames nowadays, so release those too. They are returned with xdp_return_frame() since this runs in process context.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74624", "url": "https://ubuntu.com/security/CVE-2026-74624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: defer invalid log until after unlock TCP and SCTP conntrack paths can emit invalid-packet logs while ct->lock is still held. When invalid logging is routed to nfnetlink_log and conntrack export is enabled, the log path can re-enter conntrack netlink glue and dump the same conntrack again. Protocol attribute dumping may take ct->lock, so logging while holding that lock can deadlock. Defer the TCP invalid logs by storing only the minimal log context while ct->lock is held and emitting the log after unlocking. Also make the TCP timeout-lowering invalid path return whether a log is needed, then emit that log after unlocking. Do the same for the SCTP invalid state-transition log that can be reached while ct->lock is held. Add a lockdep assertion to nf_ct_l4proto_log_invalid() so future callers that log invalid conntracks while holding ct->lock are caught outside TCP and SCTP as well.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74625", "url": "https://ubuntu.com/security/CVE-2026-74625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: release template ct on non-IP path A bridge nftables ct zone set rule can attach a conntrack template to an skb before nf_ct_bridge_pre() sees it. For non-IPv4 and non-IPv6 EtherTypes, nf_ct_bridge_pre() currently overwrites skb->_nfct with IP_CT_UNTRACKED without releasing the existing template reference. That makes the per-cpu template, and any temporary templates allocated for concurrent use, unreachable and leaks memory until the host runs out of slab. Reset the skb conntrack state before marking the frame untracked so the existing template reference is dropped on the non-IP path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74627", "url": "https://ubuntu.com/security/CVE-2026-74627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: devmem: prevent net-iov / page mixing We should either have net_iov or page backed frags in a single skb, otherwise it blows up down the stack. Don't allow mixing in zerocopy_fill_skb_from_devmem().", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74628", "url": "https://ubuntu.com/security/CVE-2026-74628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free of the socket by its timers The x25 timers are armed with mod_timer() and cancelled with timer_delete(), so a pending timer holds no reference on the socket and a cancel does not wait for a callback already running on another CPU. x25_heartbeat_expiry() also rearms unconditionally, so it can reinstall sk->sk_timer after __x25_destroy_socket() has passed its cancel point. The following __sock_put() frees the socket while the timer is still queued, and the next expiry uses freed memory. KASAN reports a slab-use-after-free on the kmalloc-2k object freed by close(). timer_delete_sync() cannot be used here: x25_heartbeat_expiry() and x25_timer_expiry() both reach the cancels from inside the timer they would wait on, through __x25_destroy_socket() and x25_disconnect(). Arm the timers with sk_reset_timer() and cancel them with sk_stop_timer() so that an armed timer owns a reference, and release it in both expiry handlers. Rearm the heartbeat only while sk_hashed(sk) is still true, since __x25_destroy_socket() unlinks the socket before dropping it. Arm the deferred destroy timer the same way and drop its reference in x25_destroy_timer(). Reproduced on net with KASAN, with the heartbeat period shortened so the window recurs. With this patch the reproducer no longer triggers a report and /proc/net/x25 drains. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74629", "url": "https://ubuntu.com/security/CVE-2026-74629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/dibs: Correct freeing of dmb_clientid_arr A dibs device interrupt handler can be active after dibs_dev_del() and may still access dmb_clientid_arr. (UAF) In case of a failure in dibs_dev_add() being called by dibs_lo_dev_probe() dmb_clientid_arr is freed twice (double free). Free dmb_clientid_arr in dibs_dev_release() after last reference is gone. Note that allocating in dibs_dev_add() instead of dibs_dev_alloc() is ok for now, because no dmbs can be registered before dibs_dev_add().", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74630", "url": "https://ubuntu.com/security/CVE-2026-74630", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent in6_dev_get() from resurrecting inet6_dev in6_dev_get() reads dev->ip6_ptr under RCU and then unconditionally increments its refcount. Device teardown can clear the pointer and drop the last reference between these operations. The increment then resurrects an object whose RCU free has already been queued, so callers can use it after it is freed. Use refcount_inc_not_zero() and return NULL when the object has already reached zero. RCU keeps the memory accessible through the attempted reference acquisition, and a successful increment pins the object for the caller. An independent run on the exact unpatched 6f5156d7a31a (v7.2-rc3) kernel reproduced the invalid reference acquisition as UID 1000: refcount_t: addition on 0; use-after-free. ip6_mc_source+0xef4/0x17e0 It was followed by the corresponding reference underflow in ip6_mc_source(). The supplied trace from the same unpatched revision additionally shows the access after the RCU read-side section ends: BUG: KASAN: slab-use-after-free in mutex_lock+0x76/0xe0 Write of size 8 at addr ffff888015b50240 by task poc/1219 Bug found and triaged by OpenAI Security Research and validated by Trail of Bits.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74631", "url": "https://ubuntu.com/security/CVE-2026-74631", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: smc: fix splice entry lifetime imbalance in smc_rx_splice smc_rx_splice() passes pages to splice_to_pipe() before taking the references that cover the lifetime of each splice entry. In the VM-backed RMB path, splice_to_pipe() may drop unqueued entries through smc_rx_spd_release(), while queued entries are released later via the pipe buffer callback. The old post-splice accounting also derives the number of queued VM pages from an offset mutated while building the descriptor, and a multi-page splice pairs one sock_hold() with multiple sock_put() calls. Take the page and socket references for every candidate entry before splice_to_pipe(), and drop the matching private state, page reference, and socket reference from smc_rx_spd_release() for entries that never get queued. This fixes a refcount imbalance that can underflow page refcounts and trigger a use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74632", "url": "https://ubuntu.com/security/CVE-2026-74632", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix huge_zero_pfn race Patch series \"mm/huge_memory: fix huge_zero_pfn race\", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn() and consequently is_huge_zero_pmd() will misidentify the huge zero folio as being an ordinary THP folio. This can result in the huge zero folio being split and otherwise treated incorrectly. The solution to this is very subtle as there is an atomic fast path, and thus ordering in weakly ordered architectures has to be treated very carefully. The first commit fixes the issue by introducing a spinlock around huge_zero_[pfn, folio, refcount] write, with careful consideration paid to load/store ordering in the fast path. It is placed first and kept as small as possible so that it can be backported on its own. The second commit is a pure cleanup which reworks the CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent logic from the dynamically allocated one. This patch (of 2): If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted by huge_zero_refcount and returned by mm_get_huge_zero_folio(). When the caller is done with the huge zero page, its reference count is decremented. Only a shrinker can set the reference count to zero. A race can unfortunately occur between a shrinker decrementing the reference count to zero and a concurrent page fault. This is because shrink_huge_zero_folio_scan() might, if very unlucky, be preempted between setting huge_zero_refcount to zero and writing an invalid value. During this time get_huge_zero_folio() could write to huge_zero_pfn before shrink_huge_zero_folio_scan() resumes. In this event the huge zero folio will be persistently misidentified causing the THP code path to be entered inappropriately for the huge zero folio: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() sets refcount to 0 | xchg() sets huge_zero_folio to NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid huge_zero_folio v | Write valid huge_zero_pfn Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite! This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly returning false for a huge zero page which could result in issues like the huge zero folio being incorrectly split. Note that the issue is with huge_zero_pfn not huge_zero_folio, as get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set huge_zero_folio. Fix the issue by introducing a spinlock, huge_zero_lock, to prevent concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount. There needs to be significant care taken here to ensure correctness: The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which is outside of the critical section, and means huge zero allocation is gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74633", "url": "https://ubuntu.com/security/CVE-2026-74633", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix NULL pointer dereference in module event cache removal A module-only event filter such as \":mod:foo\" is cached with a NULL event_mod->match when foo has not been loaded. If a later write tries to remove a specific match from the same module, remove_cache_mod() passes the NULL cached match to strcmp(), causing a NULL pointer dereference. The issue can be reproduced from userspace: echo ':mod:trace_events_kunit_missing' > /sys/kernel/tracing/set_event echo '!foo_bar:mod:trace_events_kunit_missing' >> /sys/kernel/tracing/set_event The second write must be a concatenation (\">>\") to not include O_TRUNC as that would cause ftrace_clear_events() to clear the cached modules lines. The crash was reproduced on x86_64 QEMU while KUnit workers contended on the event tracing path: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode RIP: 0010:strcmp+0x10/0x30 Call Trace: __ftrace_set_clr_event_nolock+0x373/0x4a0 ftrace_set_clr_event+0xf0/0x180 ftrace_event_write+0xdf/0x110 vfs_write+0xf6/0x440 ksys_write+0x68/0xe0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f Check event_mod->match before comparing it, consistent with the existing NULL checks for the cached system and event fields. The mismatched removal continues to return -EINVAL; a broad cached module filter is removed with \"!:mod:\".", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74634", "url": "https://ubuntu.com/security/CVE-2026-74634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Prevent subbuf order change when resizing is disabled Because ring_buffer_subbuf_order_set() frees buffer pages, we can't allow it when resizing is disabled. A non-consuming reader is at risk of use-after-free (rb_advance_iter()). Return -EBUSY on resize_disabled, matching ring_buffer_resize() behaviour.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74635", "url": "https://ubuntu.com/security/CVE-2026-74635", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: bitblit: bound-check glyph index in bit_cursor() bit_cursor() fetches the glyph under the cursor with \tc = scr_readw(vc_pos); \tsrc = vc_font.data + ((c & charmask) * w * height); where charmask is 0x1ff when vc_hi_font_mask is set. The screen buffer value comes directly from scr_readw() and may be larger than the current font's glyph count. Syzkaller triggers this via vcs_write(). The Call Trace shows vcs_write() in vc_screen.c writing an arbitrary 16-bit value with writev() to /dev/vcsa, which vcs_write_buf() in vc_screen.c stores via vcs_scr_writew() without checking charcount. The stored value is later read in bit_cursor() in bitblit.c. When the font is changed from a font with 512 glyphs to a font with 256 glyphs, the screen buffer can retain characters with the high bit set from the previous mode, which could also produce the same out-of-bounds access. BUG: KASAN: global-out-of-bounds in soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70 Read of size 16 at addr ffff800086c57970 Call Trace: soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70 bit_cursor+0xa90/0x1108 drivers/video/fbdev/core/bitblit.c:365 fbcon_cursor+0x344/0x498 drivers/video/fbdev/core/fbcon.c:1427 hide_cursor+0xdc/0x2d0 drivers/tty/vt/vt.c:883 update_region+0x100/0x18c drivers/tty/vt/vt.c:669 vcs_write+0x8ec/0xaf0 drivers/tty/vt/vc_screen.c:685 bit_putcs_aligned() and bit_putcs_unaligned() already clamp the glyph index to vc_font.charcount. Apply the same clamp in bit_cursor() after extracting the attribute and masking, before indexing fontdata. The fix completes the bounds checking started in commit 18c4ef4e765a (\"fbdev: bitblit: bound-check glyph index in bit_putcs*\"), which missed the cursor path. This change should be safe because the clamp reuses the existing contract from fbcon: charcount is maintained under console_lock in con_font_set() and fbcon_font_set(), and hi_font_mask is cleared when switching from 512 to 256 glyphs. When stale screen data with high bits remains after a font switch, or when vcs_write() stores an arbitrary value, clamping the index to 0 prevents the out-of-bounds read without changing cursor semantics — the same fallback bit_putcs uses.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74636", "url": "https://ubuntu.com/security/CVE-2026-74636", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race between update_event_fields and, event_define_fields The following sequence may leads race between event_define_fields() and update_event_fields(): CPU0 (loads module A) CPU1 (loads module B) =============================== =============================== load_module(A) load_module(B) notifier_call_chain notifier_call_chain trace_module_notify trace_module_notify mutex_lock(&event_mutex) trace_event_update_all() trace_module_add_events(A) down_write(&trace_event_sem) __register_event(call_A) __add_event_to_tracers(call_A) event_define_fields(call_A) for each f: list_for_each_entry(field, list_add(&f->link, &class->fields, link) &class->fields) field = class->fields->next; Where access to the class->fields is not protected by the event_mutex in trace_event_update_all(). This produces the following panic: Unable to handle kernel access ... at virtual address 0000000000000018 pc : update_event_fields+0xf8/0x368 Call trace: update_event_fields+0xf8/0x368 trace_event_update_all+0x7c/0x2b4 trace_module_notify+0x4c/0x1dc notifier_call_chain+0x84/0x168 blocking_notifier_call_chain_robust+0x64/0xd4 load_module+0x10c8/0x123c __arm64_sys_finit_module+0x230/0x31c Fix by taking event_mutex in trace_event_update_all() before trace_event_sem.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74637", "url": "https://ubuntu.com/security/CVE-2026-74637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix group leader use-after-free after sibling detach perf_group_detach() handles leader and sibling detach differently. When the group leader is detached, all siblings are promoted to singleton events and their group_leader pointer is reset to themselves. When a sibling is detached, it is removed from the leader's sibling_list, but its group_leader pointer is left pointing at the old leader. That is harmless when the sibling is being closed and freed immediately, as in the DETACH_DEAD path. It is not safe when the sibling is detached but kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the sibling is removed from the context, while its file descriptor can still keep it alive. A typical failing sequence is: - A group contains leader L and sibling S. - CPU hot-unplug detaches S with DETACH_GROUP, removing it from L->sibling_list but leaving S->group_leader == L. - L is later closed and freed. - A PERF_IOC_FLAG_GROUP ioctl on S follows S->group_leader and dereferences the freed leader. This was reproduced by running the perf event fuzzer, CPU hotplug, and a stress workload concurrently: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT pc : perf_ioctl+0x34c/0xc68 x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908) Call trace: perf_ioctl+0x34c/0xc68 (P) __arm64_sys_ioctl+0xa0/0xf4 invoke_syscall+0x58/0xe4 el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x40/0xc0 el0t_64_sync_handler+0x68/0xdc el0t_64_sync+0x1c4/0x1c8 The fault happened in perf_ioctl(), where perf_event_for_each() follows the stale group_leader pointer and perf_event_for_each_child() then dereferences the freed leader's context. Fix the use-after-free by promoting the detached sibling to a singleton. Also fix __event_disable() cgroup accounting and event state change.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74638", "url": "https://ubuntu.com/security/CVE-2026-74638", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Serialize the scheduler timeout handlers V3D exposes several independent hardware queues (BIN, RENDER, TFU and CSD) but has only a single, global reset. A timeout on any one queue therefore has to stop, reset and restart the schedulers of every other queue as well. That makes concurrent timeout handlers unsafe. `reset_lock` was never able to make them safe, as a driver-side lock can only cover the driver's &drm_sched_backend_ops.timedout_job callback. The scheduler handles the timed out job and its pending list around that callback, outside of the driver's control, so a global reset triggered by one queue can still interfere with another queue that is in the middle of handling a timeout of its own. Consequently, if a reset happens in the CSD queue while a CL-intensive application is running, the global reset stops and restarts the CL queue's scheduler while that queue is handling a timeout of its own. As drm_sched_stop() and drm_sched_start() subtract and add the credits of every job sitting on the pending list of the scheduler they are called on, and as the CL queue's handler concurrently takes its job off that same list and puts it back, the stop and the start no longer see the same set of jobs. The CL queue is left with more credits in flight than its limit: [ 327.302739] ------------[ cut here ]------------ [ 327.302744] WARNING: CPU: 2 PID: 43 at drivers/gpu/drm/scheduler/sched_main.c:102 drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] [ 327.302884] CPU: 2 UID: 0 PID: 43 Comm: kworker/u16:1 Not tainted 6.18.39-v8-16k+ #3 PREEMPT [ 327.302889] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [ 327.302893] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched] [ 327.302984] Call trace: [ 327.302987] drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] (P) [ 327.302997] process_scheduled_works+0x180/0x3d0 [ 327.303010] worker_thread+0x268/0x3e8 [ 327.303016] kthread+0x140/0x250 [ 327.303022] ret_from_fork+0x10/0x20 [ 327.303031] ---[ end trace 0000000000000000 ]--- From that point on, the credit count of the CL queue is broken, causing a complete GPU hang and UI freeze. The DRM scheduler already provides a mechanism to serialize the timeout handlers of different schedulers: an ordered workqueue passed as drm_sched_init()'s @timeout_wq parameter. By default, each scheduler queues its timeout work on the system workqueue, which runs the handlers concurrently. Give all of the queues a shared ordered workqueue instead, as recommended by the DRM scheduler documentation for hardware that has distinct queues but resets globally.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74639", "url": "https://ubuntu.com/security/CVE-2026-74639", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: us144mkii: re-anchor capture URBs on resubmission capture_urb_complete() resubmits each capture URB without anchoring it: \tusb_get_urb(urb); \tret = usb_submit_urb(urb, GFP_ATOMIC); Anchoring is a property of a submission, not of the URB. The giveback path calls usb_unanchor_urb() before urb->complete(), so an URB resubmitted from its own completion handler is off the anchor. The capture URBs are anchored once, at stream start, so from the first completion onward tascam->capture_anchor is empty. tascam_free_urbs(), tascam_disconnect(), tascam_suspend() and the stop-work path all call usb_kill_anchored_urbs(&tascam->capture_anchor) to reap the capture URBs before anything is freed. With the anchor empty those calls return immediately and the URBs stay queued on the host controller. tascam_free_urbs() then returns the capture transfer buffers with usb_free_coherent(), and snd_card_free() releases the snd_card allocation that embeds tascam (card->private_data). The controller completes the queued URBs afterwards, writing device-supplied data into the freed transfer buffer, and capture_urb_complete() dereferences the freed driver object. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in dummy_timer Write of size 512 at addr ffff000015b62000 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 64: usb_alloc_coherent tascam_alloc_urbs tascam_probe Freed by task 170: usb_free_coherent tascam_free_urbs tascam_disconnect usb_unbind_interface BUG: KASAN: slab-use-after-free in capture_urb_complete Read of size 4 at addr ffff0000170ee878 Freed by task 170: release_card_device snd_card_free tascam_disconnect Restore the usb_anchor_urb() between the reference count bump and the resubmission. That also makes the handler's usb_unanchor_urb() failure arm meaningful again and restores usb_kill_anchored_urbs() as a barrier on the disconnect, suspend and stop-work paths. The anchoring was removed on the premise that the URB is already anchored from the initial submission, which does not hold once the first giveback has run. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74640", "url": "https://ubuntu.com/security/CVE-2026-74640", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: FCP: fix OOB write in fcp_meter_ctl_get() fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size by the driver's own limit of 255 \tif (map.map_size < 1 || map.map_size > 255 || \t map.meter_slots < 1 || map.meter_slots > 255) \t\treturn -EINVAL; and passes it to fcp_add_new_ctl() as the control's channel count, where it is stored as elem->channels. Every control read writes into struct snd_ctl_elem_value, whose integer array is declared long value[128], so the limit is 128, not 255. fcp_meter_ctl_get() stores one 64-bit word per channel into that array with no bound of its own: \tfor (i = 0; i < elem->channels; i++) { \t\tint idx = private->meter_level_map[i]; \t\tint value = idx < 0 ? 0 : le32_to_cpu(resp[idx]); \t\tucontrol->value.integer.value[i] = value; \t} snd_ctl_elem_read_user() serves that object from memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of kmalloc-2048. offsetof(struct snd_ctl_elem_value, value) is 72, so element i is written at byte 72 + 8 * i and element 144 already lands past the allocation. At map_size 255 the last store ends at byte 2112, 888 bytes past the object and 64 bytes into the adjacent slab object. The stored words come from the device and meter_level_map[] selects which word lands in which slot, so extent and contents are both controlled. The core does not catch this. snd_ctl_check_elem_info() is reached only from __snd_ctl_elem_info(), which snd_ctl_elem_read() calls under CONFIG_SND_CTL_DEBUG; without that option snd_ctl_skip_validation() is a compile-time true. __snd_ctl_add_replace() validates kcontrol->count and never inspects elem->channels. Installing an oversized map needs CAP_SYS_RAWIO, but the control outlives the hwdep descriptor that created it, so the out-of-bounds stores are issued by any process able to read controls on /dev/snd/controlC0. KASAN on 7.2.0-rc5 (arm64), triggered by an unprivileged control read: BUG: KASAN: slab-out-of-bounds in fcp_meter_ctl_get Write of size 8 at addr ffff000017af04c8 by task fcp_trigger/185 __asan_store8 fcp_meter_ctl_get snd_ctl_elem_read snd_ctl_ioctl Allocated by task 185: memdup_user snd_ctl_ioctl The buggy address is located 0 bytes to the right of allocated 1224-byte region [ffff000017af0000, ffff000017af04c8) Bound the map size by the ABI limit rather than by 255, and bound the store loop at the sink so it cannot run past the value array whatever elem->channels holds. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74641", "url": "https://ubuntu.com/security/CVE-2026-74641", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usx2y: bound the hwdep mmap fault offset snd_us428ctls_vm_fault() turns the faulting page offset into a kernel address with no bound of any kind: \toffset = vmf->pgoff << PAGE_SHIFT; \tvaddr = (char *)(...)->us428ctls_sharedmem + offset; \tpage = virt_to_page(vaddr); \tget_page(page); \tvmf->page = page; \treturn 0; snd_us428ctls_mmap() checks only the length of the mapping, never the offset, and us428ctls_sharedmem is a single page from alloc_pages_exact(). For a character device file_mmap_size_max() returns ULONG_MAX, so the mm layer imposes no ceiling either. Every page offset above zero resolves to a struct page outside the object, and the handler installs it into the caller's address space read-write; the vma is not marked read-only. The caller picks the page frame with a single mmap() argument and gets read-write access to a page of kernel memory it does not own; an offset that lands in an unpopulated vmemmap region oopses instead. A process that can open the hwdep node of an attached US-X2Y reaches this after loading the FPGA image through the same node; no capability check is involved. On 7.2.0-rc5 (arm64), mmap() with a large offset: Unable to handle kernel paging request at virtual address fffffdffc45d5ac8 pc : snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y] Call trace: snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y] __do_fault __handle_mm_fault handle_mm_fault el0_da Reject any offset outside the shared region. The pcm hwdep handler in usx2yhwdeppcm.c computes its address the same way and needs the same bound. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74643", "url": "https://ubuntu.com/security/CVE-2026-74643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: samples/damon/mtier: error out for zero quota goal target values Patch series \"mm/damon: avoid division by zero from damos_quota_score()\". DAMON_SAMPLE_MTIER and DAMON_LRU_SORT allow the user to trigger division by zero in damos_quota_score(). Avoid it by adding parameters validation checks. This patch (of 2): damos_quota_score() can trigger division by zero if the target_value is zero. DAMON_SAMPLE_MTIER lets users set the target_value via node0_mem_{used,free}_bp parameters. It doesn't guard zero value case, though. As a result, users can trigger division by zero. Fix the issue by returning an error when the user tries to start DAMON with zero node0_mem_{used,free}_bp parameter values. DAMON_SAMPLE_MTIER is just a sample module, but the consequence is quite bad. Also the zero node0_mem_free_bp parameter might look like a reasonable setup to some users. Hence, the issue might really happen in the real world. One reliable way to reproduce the issue is like below: # cd /sys/module/damon_sample_mtier/parameters # echo 4096 > node0_start_addr # echo 8192 > node0_end_addr # echo 8192 > node1_start_addr # echo 81920 > node1_end_addr # echo 0 > node0_mem_free_bp # echo Y > enabled # dmesg -w [...] [18792.235916] Oops: divide error: 0000 [#1] SMP NOPTI [...] [18792.242787] RIP: 0010:damos_quota_score+0x6f/0x480 [...] This issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74644", "url": "https://ubuntu.com/security/CVE-2026-74644", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/ops-common: putback folios on invalid migrate nid damon_pa_migrate() and damos_va_migrate() isolate folios into a local list and then call damon_migrate_pages(). When target_nid is invalid (including the scheme default NUMA_NO_NODE / -1), damon_migrate_pages() returns early without putting the folios back to the LRU. Callers then discard the list head while those folios remain isolated with an extra reference taken by folio_isolate_lru(). The pages stay off the LRU for as long as the mapping exists (anon active+inactive counts drop while RSS does not), and the leftover references can pin the pages after the mapping is gone. Put the folios back on the invalid-nid path so ignored migration requests still return them to the LRU.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74646", "url": "https://ubuntu.com/security/CVE-2026-74646", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke When an invoke is interrupted by a signal, wait_for_completion_interruptible() returns -ERESTARTSYS and fastrpc_internal_invoke() moves every buffer from fl->mmaps onto cctx->invoke_interrupted_mmaps. This list_del()/list_add_tail() walk runs without holding fl->lock, the lock that serialises fl->mmaps in fastrpc_req_mmap() and fastrpc_req_munmap() everywhere else. Take fl->lock around the move, matching every other fl->mmaps accessor.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74647", "url": "https://ubuntu.com/security/CVE-2026-74647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Remove buffer from list prior to unmap operation fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74648", "url": "https://ubuntu.com/security/CVE-2026-74648", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: validate monitor transmit frame lengths rtw_cfg80211_monitor_if_xmit_entry() removes the radiotap header and then reads the 802.11 frame control field without checking that a base 802.11 header remains. The data path also pulls the calculated 802.11, QoS and SNAP header span before confirming that the skb contains it. A truncated frame can therefore cause out-of-bounds reads or leave insufficient data for the Ethernet address writes. Reject frames that do not contain the base 802.11 header and data frames that do not contain their complete calculated header span.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74649", "url": "https://ubuntu.com/security/CVE-2026-74649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix missing shared-key auth challenge length check The WEP shared-key authentication handler uses the challenge-text element's attacker-controlled length without checking it against the fixed 128-byte chg_txt buffer. In OnAuthClient() the length from rtw_get_ie() - up to 255 - is used to perform memcpy() into the 128-byte pmlmeinfo->chg_txt, so a malicious AP sending a malformed WLAN_EID_CHALLENGE element can overflow/underfill chg_txt by up to 127 bytes. It is reachable over the air, before association, during shared-key authentication. In the case of an overflow, the driver can write out of bounds. In the case of an underfill, the driver can echo stale buffer memory. The challenge text is defined to be exactly 128 octets, which is already provided as the WLAN_AUTH_CHALLENGE_LEN define; require the element to be exactly that length before use.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74650", "url": "https://ubuntu.com/security/CVE-2026-74650", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in WMM_param_handler() WMM_param_handler() copies a fixed-size WMM parameter element out of a received information element without checking that the element is long enough, causing an out-of-bounds read for a short WMM IE. The handler reads sizeof(struct WMM_para_element) (18) bytes at pIE->data + 6, so it requires pIE->length to be at least 24 (WLAN_WMM_LEN), but it never validates the length. Two of its three callers reach it after matching only the WMM OUI: OnAssocRsp() in rtw_mlme_ext.c matches a 6-byte OUI, and join_cmd_hdl() matches a 4-byte OUI, before calling the handler. A vendor-specific IE carrying the WMM OUI but a length between 6 and 23, placed in an association response or in the IE blob handed to join_cmd_hdl(), passes the OUI check and then makes the memcmp() and memcpy() at pIE->data + 6 read past the end of the element. OnAssocRsp() parses a frame received from the AP, so this is reachable from a remote peer. The remaining caller in rtw_wlan_util.c already guards the handler with \"pIE->length == WLAN_WMM_LEN\". Move the equivalent check into the handler itself so every caller is covered; the sibling IE handlers in the same parsing loop (HT_caps_handler(), HT_info_handler(), ERP_IE_handler()) likewise bound their accesses by pIE->length.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74651", "url": "https://ubuntu.com/security/CVE-2026-74651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_get_wpa_ie() rtw_get_wpa_ie() reads bytes at fixed offsets into a vendor-specific information element without checking that the element is long enough, causing an out-of-bounds read for a short trailing IE. The function locates a vendor-specific IE (EID 221) with rtw_get_ie() and then compares a 4-byte OUI+type at pbuf + 2 and reads a 2-byte version word at pbuf + 6. Those accesses require the IE body to be at least 6 bytes, but rtw_get_ie() only guarantees that the element fits within the buffer; it does not enforce a minimum body length. A vendor-specific IE whose length byte is 0 to 5, placed at the end of the buffer, therefore makes these reads run past the end of the IE and past the end of the buffer itself. The buffer holds information elements taken from received management frames and from the IE blob passed to rtw_cfg80211_set_wpa_ie(), which is kmemdup'd to its exact length, so the read can run off the end of the allocation. The sibling helpers rtw_get_sec_ie(), rtw_get_wapi_ie() and rtw_get_wps_ie() in this file already reject too-short vendor-specific IEs before their OUI memcmp(); rtw_get_wpa_ie() was never brought in line with them, and needs a minimum of 6 rather than 4 bytes because of the version word. Add the missing length check.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74652", "url": "https://ubuntu.com/security/CVE-2026-74652", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: amba-pl011: cancel RS485 hrtimers after freeing IRQ The RS485 trigger hrtimers are embedded in the devm-managed port and can fire after it is freed. The IRQ handler can arm a timer, so free the IRQ first and then cancel both timers. Complete the RS485 stop without arming a timer, and cancel the timers in remove() for the suspend-then-unbind path, where shutdown is not called. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74653", "url": "https://ubuntu.com/security/CVE-2026-74653", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx The NXP LPC32xx UART (PORT_LPC3220) can latch an RX character-timeout interrupt while the RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT (0x0c) but LSR.DR is clear. A character timeout is only cleared by reading RHR, but serial8250_rx_chars() reads RHR only when LSR.DR is set, so nothing ever clears the condition. The interrupt is level-triggered and re-fires immediately, so on a single-core ARM926 the resulting interrupt storm livelocks the CPU. It is reproducible when userspace repeatedly opens the front-panel port (ttyS1): serial8250_do_set_termios() re-enables interrupts on unlock and the handler then spins forever with iir=0xcc lsr=0x60 ier=0x05, tripping the soft-lockup detector in serial8250_handle_irq_locked(). LPC32xx has no dedicated 8250 glue driver, it's driven by the generic 8250_of. Add a hardware specific handle_irq for PORT_LPC3220, wired up in of_platform_serial_setup() the same way fsl8250_handle_irq is installed. The handler follows dw8250_handle_irq(): on an RX timeout with an empty FIFO (LSR.DR and LSR.BI clear) it does one throwaway RHR read to clear the condition, then calls serial8250_handle_irq_locked(). No real received data is ever discarded, and it is a no-op on healthy UARTs which never report a timeout with DR clear. This is the same class of bug already worked around in other 8250 drivers; see commit 424d79183af0 (\"serial: 8250_dw: Avoid \"too much work\" from bogus rx timeout interrupt\") which reports the identical iir=0xcc/lsr=0x60. See also UART_RX_TIMEOUT_QUIRK in 8250_omap, and the note in 8250_bcm7271.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74654", "url": "https://ubuntu.com/security/CVE-2026-74654", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dma: Clear stale RX state on shutdown serial8250_release_dma() terminates RX DMA and releases the channel, but leaves rx_running set. If the port is closed while an RX transfer is active, the stale state remains while rxchan is NULL until the channel is requested again on the next open. The DesignWare BUSY workaround added by commit a7b9ce39fbe4 (\"serial: 8250_dw: Ensure BUSY is deasserted\") calls serial8250_rx_dma_flush() from the LCR write path during startup. This happens before serial8250_request_dma() obtains a new RX channel. On reopen, the stale rx_running state therefore makes the flush path pass a NULL channel to dmaengine_pause(), causing a kernel Oops. Clear rx_running after terminating RX DMA, matching the TX cleanup. Also make the flush helper return if the DMA object or RX channel is not available so startup and teardown paths cannot pass a NULL channel to the DMAengine API.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74655", "url": "https://ubuntu.com/security/CVE-2026-74655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom-geni: fix TX DMA buffer flush When transmit flushing a qcom-geni UART during an ongoing TX DMA, the UART gets stuck infinitely repeating corrupted TX DMA frames. The DMA-mode uart_ops does not provide a flush_buffer callback, so an in-flight transfer can complete after serial core has reset the transmit kfifo, underflowing its length and resubmitting page-sized transfers indefinitely. Add one that stops the transfer and clears tx_remaining and tx_queued. The stop path was also broken: it unmapped the buffer while the serial engine could still read it, and never reset the TX DMA state machine. Cancel the main sequencer command first, then reset the state machine and wait for it before unmapping. Drop the early return so a pending mapping is also cleaned up when the main command is inactive. The bug can be triggered from userspace with a large write immediately followed by TCOFLUSH. A following tcdrain will hang forever. The bug was reproduced and this fix was validated on Arduino Uno Q (QRB2210) using /dev/ttyHS1.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74656", "url": "https://ubuntu.com/security/CVE-2026-74656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fix use-after-free in fib_nhc_update_mtu() fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but RTNL does not serialize this walk with PMTU exception updates. The walk uses rcu_dereference_protected() with a constant true condition without holding fnhe_lock. The following interleaving can therefore occur: CPU 0 CPU 1 fib_nhc_update_mtu() update_or_create_fnhe() load fnhe spin_lock_bh(&fnhe_lock) fnhe_remove_oldest() unlink fnhe kfree_rcu(fnhe, rcu) access fnhe after grace period KASAN reported: BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410 Read of size 8 at addr ffff888107d49000 by task poc/90 Call Trace: fib_nhc_update_mtu+0x3df/0x410 fib_sync_mtu+0x7a/0xd0 fib_netdev_event+0x229/0x3f0 netif_set_mtu_ext+0x33a/0x570 dev_set_mtu+0x88/0x120 The same walk updates fnhe_pmtu and fnhe_mtu_locked. These fields form a pair and other writers serialize them with fnhe_lock. RCU alone prevents reclamation, but would still allow concurrent writers to leave a mixed pair. Walk the table under RCU and acquire fnhe_lock only while updating each exception. RCU keeps the current entry alive while the short critical section serializes its paired PMTU fields. This avoids holding the global lock while scanning all 2048 buckets for every nexthop.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74657", "url": "https://ubuntu.com/security/CVE-2026-74657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops fib_nlmsg_size() still estimates nexthop space as if every gateway is encoded as an IPv4 RTA_GATEWAY attribute. IPv4 routes can also carry an IPv6 gateway, which fib_nexthop_info() dumps as RTA_VIA. As a result, route notifications can allocate an skb that is too small. fib_dump_info() then fails with -EMSGSIZE and rtmsg_fib() hits the WARN_ON() that marks such failures as a fib_nlmsg_size() bug. With panic_on_warn set, this becomes a kernel panic. Mirror the actual nexthop dump layout in fib_nlmsg_size(): account for IPv6 nexthop gateways dumped as RTA_VIA, for the no-header rtnexthop layout used inside RTA_MULTIPATH, and for RTA_FLOW only when it is actually present.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74658", "url": "https://ubuntu.com/security/CVE-2026-74658", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent robust futex exit race some more A robust futex unlock stores 0 over the whole futex value - wiping FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot notification: the protocol relies on its recipient to either acquire the futex (and eventually unlock while aware of the remaining contention) or re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed before it can do either, the kernel must jump in and wake the next task down the line. This is a known complication of the futex protocol with a previous partial fix in commit ca16d5bee598 (\"futex: Prevent robust futex exit race\"). Unfortunately, that fix is insufficient. If a third task re-acquired the futex through the uncontended fast path in the meantime, the notification is lost: robust exit processing sees that it is owned by another task and does nothing, while the new owner sees no FUTEX_WAITERS when it unlocks and wakes nobody. The remaining waiters sleep forever behind a free futex: A owns the futex, B and C sleep in FUTEX_WAIT uval == A | FUTEX_WAITERS A robust unlock: store 0, FUTEX_WAKE(1) wakes B uval == 0 D fast path acquire: cmpxchg(0 -> D) uval == D, no FUTEX_WAITERS B killed before acting on the wakeup B exit walk, pending op: owner D != B -> no action D unlock: no FUTEX_WAITERS -> no wake C sleeps forever This is clearly a shortcoming in the implementation, which fails to keep the FUTEX_WAITERS bit consistent. Work around this by augmenting the robust list exit processing to also perform the extra wakeup if the futex word is owned by another thread but FUTEX_WAITERS is not set. This does not fix the problem of a non-contended take over/release and free sequence, which has been discussed for years and has been addressed by commit 3ca9595d9fb6 (\"futex: Add support for unlocking robust futexes\") and subsequent changes, but failed to take the problem described above into account. A more complete solution which is based on the in kernel unlock of contended robust futexes has been discussed in the context of this change and should show up in mainline sooner than later. [ tglx: Amend change log slightly and fixup coding style ]", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74659", "url": "https://ubuntu.com/security/CVE-2026-74659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: mrp: fix uninitialised bytes on the wire br_mrp_alloc_test_skb() builds MRP test frames on an skb from dev_alloc_skb(), which does not clear the linear data area. On the MRA ring-role branch the sub-option TLV header is appended with \tsub_tlv = skb_put(skb, sizeof(*sub_tlv)); \tsub_tlv->type = BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR; so sub_tlv->length is never written, and the two trailing alignment bytes are appended with a bare skb_put() that does not clear them either. The neighbouring oui and sub_opt regions are explicitly zeroed, so three uninitialised bytes are left in every MRA MRP_Test frame that goes out. Put the sub-option TLV header and the alignment padding in a single skb_put_zero(), which clears both. The AUTO_MGR sub-TLV carries no payload, so the zeroed length field is already the value it should have.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74660", "url": "https://ubuntu.com/security/CVE-2026-74660", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebt_nflog: pin the NFLOG backend nf_log_unregister() runs after the per-net teardown so its final RCU grace period also drains readers that obtained the logger from a per-net binding. However, ebt_nflog passes an explicit ULOG log type to nf_log_packet() without holding a reference on the selected logger module, unlike the xt_NFLOG and nft_log frontends. An ebtables nflog rule can therefore remain callable while nfnetlink_log is unloaded. The resulting interleaving is: CPU 0 CPU 1 nfnetlink_log_fini() unregister_pernet_subsys() kfree(nfnl_log_pernet(net)) ebt_nflog_tg() nf_log_packet() nfulnl_log_packet() instance_lookup_get_rcu() The global ULOG logger is still registered at this point, so CPU 1 dereferences the per-net state after CPU 0 has freed it. KASAN reported: BUG: KASAN: slab-use-after-free in instance_lookup_get_rcu Read of size 8 at addr ff110001052e6210 by task poc/92 Call Trace: instance_lookup_get_rcu+0x1ce/0x1f0 [nfnetlink_log] nfulnl_log_packet+0x248/0x2fb0 [nfnetlink_log] nf_log_packet+0x204/0x300 ebt_nflog_tg+0x351/0x550 ebt_do_table+0xedf/0x22b0 Allocated by task 90: __kmalloc_noprof+0x186/0x470 ops_init+0x6d/0x420 register_pernet_operations+0x2f6/0x670 register_pernet_subsys+0x23/0x40 Freed by task 93: kfree+0x131/0x3c0 ops_undo_list+0x3e3/0x700 unregister_pernet_operations+0x232/0x490 unregister_pernet_subsys+0x1c/0x30 nfnetlink_log_fini+0x34/0x450 [nfnetlink_log] Acquire the ULOG logger module reference when an ebt_nflog rule is validated and release it when the rule is destroyed. Request the NFLOG backend for legacy callers when needed, matching xt_NFLOG. This prevents module teardown until all ebt_nflog rules have stopped using the logger.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74661", "url": "https://ubuntu.com/security/CVE-2026-74661", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: fix netdev use-after-free in beacon worker mac802154_beacon_worker() reads local->beacon_req under RCU and derives the sub-interface from the request, but then drops the RCU read lock and continues to use both sdata and the embedded wpan_dev. mac802154_stop_beacons_locked() cancels only pending beacon work, clears local->beacon_req and frees the request. A beacon worker that is already running can therefore continue after interface teardown and dereference the freed netdev private area. The scan worker already pins the netdev before leaving RCU. Apply the same lifetime rule to the beacon worker: take a netdev reference while the request is still protected by RCU, and release it on all paths that continue after the reference is acquired.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74662", "url": "https://ubuntu.com/security/CVE-2026-74662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: publish queues before arming timer inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74663", "url": "https://ubuntu.com/security/CVE-2026-74663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: reject overly deep qdisc hierarchies Deep qdisc hierarchies can lead to excessive recursion in qdisc tree walkers and exhaust the kernel stack. The existing loop check does not cover the create-and-graft path, so a hierarchy can still be extended by creating a new child qdisc below an already deep parent. Store the hierarchy depth in struct Qdisc and update it when qdiscs are grafted. Reject new child qdiscs once the parent is already at the maximum allowed depth.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74664", "url": "https://ubuntu.com/security/CVE-2026-74664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: reallocate update replies for mismatched IDs ovs_flow_cmd_new() preallocates the optional reply skb before it takes ovs_mutex and before it knows which existing flow will be updated. That is normally fine because the skb is sized from the request flow identifier. That identifier also becomes the inserted flow's identifier. For updates, however, a request with a UFID may miss the UFID lookup and then fall back to the flow key lookup. That lookup can legitimately find an existing key-identified flow. UFIDs are optional and the flow key is the primary identifier. For echoed replies, ovs_flow_cmd_fill_info() writes the matched flow's identifier, not the request identifier used for the preallocation. A short request UFID can therefore leave too little room for the key identifier. The fill can then fail with -EMSGSIZE and hit the BUG_ON(error < 0) in the update path. Once the update target has been resolved, reallocate the reply skb if the matched flow needs a larger reply than the request identifier allowed. Do this before replacing the actions so the request can still fail cleanly if the rare extra allocation fails.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74665", "url": "https://ubuntu.com/security/CVE-2026-74665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix skb length accounting after generic XDP frag adjustment Generic XDP exposes non-linear skb fragments through an xdp_buff. If an XDP program adjusts the fragment area, bpf_prog_run_generic_xdp() copies xdp_frags_size back to skb->data_len but leaves skb->len containing the old fragment contribution. After a fragment shrink, this makes skb_headlen() larger than the actual linear area. In the reproduced UDP receive path, __skb_datagram_iter() copied 1024 bytes past the actual linear tail to userspace, starting at struct skb_shared_info. The copied bytes included the affected skb's nr_frags, xdp_frags_size and a kernel pointer from skb_shinfo(skb)->frags[0]. Real packet data was displaced by the same amount and truncated at the end. Subtract the old data_len before replacing it and add the new data_len afterwards, keeping skb->len and skb->data_len synchronized. A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by 1024 bytes from its fragment area. Before the fix, all 10 runs produced corrupted payloads. After the fix, all 10 runs matched the expected payload exactly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74666", "url": "https://ubuntu.com/security/CVE-2026-74666", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: synchronize pressure clearing with ring reconfiguration packet_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. Move the existing receive hook assignment into the same sk_receive_queue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix. Serialize packet_recvmsg() pressure clearing with the same queue lock only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear and the socket has moved away from tpacket_rcv, packet_set_ring() has already detached the socket and waited for synchronize_net(), so no new packet input can set the flag again. packet_poll() already holds sk_receive_queue.lock, so it uses the new unlocked helper directly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74667", "url": "https://ubuntu.com/security/CVE-2026-74667", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: reset the MAC header on the packet-socket transmit path packet_parse_headers() resets the MAC header only for a SOCK_RAW frame whose socket did not bind a protocol. A protocol-bound SOCK_RAW socket, any SOCK_DGRAM frame, and the legacy SOCK_PACKET path therefore leave skb->mac_header unset here. For frames sent via __dev_queue_xmit() this is harmless: it resets the MAC header unconditionally. But the packet-socket PACKET_QDISC_BYPASS path uses dev_direct_xmit(), which does not, so the frame reaches ndo_start_xmit() with the MAC header unset. A driver that reads eth_hdr(skb) on transmit then dereferences skb->head + (u16)~0, an out-of-bounds access ~64 KiB past the head -- the same class fixed for one consumer in commit f5089008f90c (\"macsec: do not read an unset MAC header in macsec_encrypt()\"). packet_parse_headers() runs only on the transmit path, where skb->data points at the start of the L2 header for every packet-socket type regardless of its length: SOCK_RAW and SOCK_PACKET carry a user-supplied header and SOCK_DGRAM has one built by dev_hard_header(). Reset the MAC header unconditionally, mirroring __dev_queue_xmit(), so the frame is anchored on the bypass path too. Found by 0sec (https://0sec.ai) using automated source analysis; verified against source and matched to the macsec KASAN report in f5089008f90c. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74668", "url": "https://ubuntu.com/security/CVE-2026-74668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in TX_RING send path tpacket_snd() reads dev->hard_header_len independently for skb allocation and header construction in tpacket_fill_skb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hard_header_len negative. Snapshot hard_header_len once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacket_fill_skb(). The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74582", "url": "https://ubuntu.com/security/CVE-2026-74582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in non-ring send paths packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-74669", "url": "https://ubuntu.com/security/CVE-2026-74669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear IPv4 options after rebasing tunnel ICMP errors ip_vs_in_icmp() rebases an skb from the outer ICMP packet to the quoted original request before passing it to icmp_send(). However, IPCB(skb)->opt still describes the outer IPv4 header. A timestamp option in the outer header can therefore leave an offset that points into the quoted transport header after the rebase. __ip_options_echo() treats a byte at that stale location as the option length and copies it into the fixed-size option storage on the __icmp_send() stack, causing a stack out-of-bounds write. Clear the stale option metadata after resetting the network header. Keep the remaining control block fields, including the ingress interface used by the ICMP response path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74670", "url": "https://ubuntu.com/security/CVE-2026-74670", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: stop estimator after disabled calc phase IPVS estimator kthread 0 starts with zeroed chain and tick limits until its initial calculation phase completes. If network namespace teardown clears ipvs->enable during that phase, ip_vs_est_calc_phase() can return without installing positive limits. The kthread can then continue into its main loop and drain est_temp_list with zero chain_max, tick_max and est_max_count values. Each enqueue consumes one available tick row, but est_count never reaches the zero est_max_count value. After all rows are consumed, the row lookup returns IPVS_EST_NTICKS and ip_vs_enqueue_estimator() writes past the ticks and tick_len arrays. Exit kthread 0 after the calculation phase if the kthread is stopping or IPVS has been disabled. That keeps temporary estimators from being drained after the limits failed to initialize. Estimator kthreads can now self-exit before teardown or reload stops kd->task. Keep an extra task reference after creation and release it with kthread_stop_put(), so kd->task remains valid until the stop paths consume that reference.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74671", "url": "https://ubuntu.com/security/CVE-2026-74671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix out-of-bounds read in xattr_verify() The digest-length check in xattr_verify() mixes int and size_t: \tif (xattr_len - sizeof(xattr_value->type) - hash_start >= \t\t\tiint->ima_hash->length) sizeof() yields size_t, so the usual arithmetic conversions promote the whole left-hand side to unsigned 64-bit before the subtraction runs. For a truncated xattr this underflows instead of going negative: a 1-byte IMA_XATTR_DIGEST_NG xattr (xattr_len == 1, hash_start == 1) turns \"1 - 1 - 1\" into SIZE_MAX, which is trivially >= ima_hash->length. The check then passes and the following memcmp() reads iint->ima_hash->length bytes starting past the end of the buffer vfs_getxattr_alloc() allocated for it. Nothing upstream clamps xattr_len back into a safe range first: ima_get_hash_algo() only special-cases xattr_len < 2 to pick a default algorithm, and evm_verifyxattr() returns INTEGRITY_UNKNOWN rather than failing when no HMAC key is loaded, so a truncated security.ima value reaches the length check as-is. Rewrite the comparison so every operand stays a signed int and no implicit conversion to size_t can occur.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74672", "url": "https://ubuntu.com/security/CVE-2026-74672", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF Patch series \"mm: fix UAF caused by race between ptdump and vmap pgtable freeing\", v6. Kernel page table walkers fall into two broad categories - those ranges where no exclusion is required via walk_kernel_page_table_range_lockless() and those where exclusion is required via walk_kernel_page_table_range() or walk_page_range_debug(). The former category is used only by arm64 arch code operating on ranges it both wholly owns and does not concurrently write. The latter category consists of kernel page table walkers operating on ranges that are wholly owned (but which need exclusion against concurrent writers). The lock used for exclusion is the mmap lock, and for kernel ranges this is the mmap lock on init_mm. ptdump is a special case being both the only user of walk_page_range_debug(), and the only case in which it walks ranges it does not own. This presents a problem, as page tables may be freed under ptdump. And indeed there is a use-after-free bug in the kernel as a result, which this series addresses. vmap promotes page tables to huge leaf entries where possible, freeing the lower page table when it does. It does this with no meaningful locks held against concurrent ptdump walks. As a result, use-after-free can currently occur. This series addresses the issue by having the vmap huge promotion logic acquire the mmap read lock while both setting the huge page table entry and freeing the prior leaf page table. The ptdump code already acquires the mmap write lock, so by doing so we ensure that the ptdump walker only ever observes either the huge page table entry or the existing page table entry, and nothing is freed underneath it. A mitigation for this issue was already applied for arm64 in commit fa93b45fd397 (\"arm64: Enable vmalloc-huge with ptdump\"), which this series has to deal with carefully. This mitigation resolves the issue by acquiring the mmap read lock on init_mm on vmap page table free if a ptdump is in progress. However the fix in this series would cause a deadlock if we were to simply apply it for arm64 without also reverting the change. This is because vmap may acquire the read lock before ptdump attempts to acquire the write lock, which then gets queued, and rwsem starvation rules mean that the (unacknowledged) nested mmap read lock in the arm64 code would also block, meaning the original read lock is never released and thus deadlock. This series works around this by #ifndef CONFIG_ARM64'ing the mmap read lock in vmap logic, then partially reverting commit fa93b45fd397 (\"arm64: Enable vmalloc-huge with ptdump\"), keeping the enablement of huge vmap support, and removing the ifdeffery with the partial revert patch. There are related issues that are also addressed in this series: * x86 page attribute logic, specifically Change Page Attributes (CPA), implements a feature whereby huge ranges can be collapsed into huge leaf entries. This can similarly cause a UAF when done in parallel with a ptdump walk, so similarly acquire the init_mm mmap lock to avoid this. * The CPA logic allows concurrent page table manipulation and CPA collapse, meaning the former risks accessing a page table the latter frees. Fix this by acquiring mmap write lock on init_mm across the whole CPA collapse operation and read lock on the page table manipulation. * x86 and arm64 permit walks of non-kernel mm's (both allowing efi mm walks, and in x86's case arbitrary mm's), so we ensure kernel mappings remain stable by locking the init_mm as well as the mm being walked. The ordering of patches is established for both strict dependencies (the arm64 partial revert in particular has to be done after the vmap changes) and logical ones (the non-kernel mm fix only makes sense once the vmap/CPA fixes are in place). This patch (of 3): Currently there is a nasty ra ---truncated---", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74673", "url": "https://ubuntu.com/security/CVE-2026-74673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: evdev - fix information leak in evdev_pass_values() In evdev_pass_values(), the input_event structure is allocated on the kernel stack and populated field-by-field. However, it is never fully initialized. On architectures where struct input_event contains explicit or implicit padding (such as the 32-bit __pad field on SPARC64), these padding bytes are left uninitialized. When this event structure is subsequently passed to the client buffer and later copied to userspace, the uninitialized padding bytes leak kernel stack memory, potentially exposing sensitive information. Similar issues exist in __evdev_queue_syn_dropped and __pass_event. Fix this by explicitly zeroing the entire event structure with memset() before populating its fields. This ensures all padding bytes are cleared before the data crosses the security boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74675", "url": "https://ubuntu.com/security/CVE-2026-74675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: stabilize tty reference in kbd_keycode with tty_port_tty_get kbd_keycode() reads vc->port.tty without acquiring a tty reference, racing against con_shutdown() which clears port.tty under a different lock. Use tty_port_tty_get()/tty_kref_put() to hold a proper reference for the duration the tty pointer is needed.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74676", "url": "https://ubuntu.com/security/CVE-2026-74676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: add permission check for KDSKBMETA ioctl KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all other keyboard setter ioctls in vt_k_ioctl() enforce, allowing a process to change meta mode on a non-controlling console without authorization.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74677", "url": "https://ubuntu.com/security/CVE-2026-74677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: ipheth: fix carrier_work UAF on disconnect ipheth_sndbulk_callback() re-arms the carrier-check work on any non-zero URB status: \telse \t\tschedule_delayed_work(&dev->carrier_work, 0); Nothing ties that to the interface being up, so the work can be armed again after ipheth_close() has already drained it, and stay armed until the netdev whose private area embeds it is freed. On unplug with a TX URB in flight, ipheth_disconnect() drains the work through unregister_netdev() -> ipheth_close() -> cancel_delayed_work_sync() and only then calls ipheth_kill_urbs(). usb_kill_urb() completes the in-flight TX URB with -ENOENT, so ipheth_sndbulk_callback() runs after the drain and re-arms carrier_work. The same completion also re-arms the work if the interface is only brought down while a TX URB is in flight, and ipheth_carrier_check_work() then keeps re-queueing itself once a second. unregister_netdev() does not call ipheth_close() for an already-down interface, so nothing drains it on the later unplug either. In both cases free_netdev() frees the netdev while carrier_work is still pending, and ipheth_carrier_check_work() dereferences freed memory. Tie the work to the interface state instead of chasing the completion: disable it in ipheth_close() and enable it in ipheth_open(), so a schedule_delayed_work() from the URB completion is a no-op whenever the interface is not up. disable_delayed_work_sync() also waits for a running instance, so it fully replaces the cancel_delayed_work_sync() it takes the place of. The work starts out disabled in ipheth_probe() so the enable/disable counts balance from the first open. Reproduced under KASAN on linux-next (next-20260731) with dummy_hcd and raw-gadget standing in for the device, driving the second path above (the interface is already down, so unregister_netdev() does not call ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in __run_timers(), freed by ipheth_disconnect() and re-armed from ipheth_sndbulk_callback() via queue_delayed_work_on(). The same trigger on a kernel differing only by this patch reports 0 of 15, and the carrier check still functions across open/close cycles. The reproducer needs an attached USB device that stops draining bulk OUT, plus a link down and unplug, driven as root. It is not a privilege boundary crossing and no exploit primitive was developed. Found by 0sec (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74678", "url": "https://ubuntu.com/security/CVE-2026-74678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: ax88179_178a: fix skb leak in ax88179_tx_fixup() When the interface has NETIF_F_SG enabled and skb_linearize() fails in ax88179_tx_fixup(), the function returns NULL without freeing the skb. usbnet_start_xmit() treats a NULL return from tx_fixup() as a drop (info->flags does not set FLAG_MULTI_PACKET for this driver), jumping to the \"drop\" label where it does `if (skb) dev_kfree_skb_any(skb)`. Because tx_fixup() returned NULL, the local skb variable in usbnet_start_xmit() is NULL, so the original skb is never freed — a memory leak on every TX frame whose linearization fails (i.e. under memory pressure). Free the skb before returning, matching the error handling already used for the pskb_expand_head() failure path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74679", "url": "https://ubuntu.com/security/CVE-2026-74679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Use unsigned int for ndp_index The variable ndp_index is declared as a signed integer, but it stores the return value of get_ncm(), which is unsigned. A malicious host can supply a large offset that overflows the signed ndp_index, making it negative. Because ndp_index is compared against unsigned bounds, this negative value bypasses sanity checks and leads to an out-of-bounds read when calculating the address of the NDP block (ntb_ptr + ndp_index). Fix this by changing ndp_index to unsigned int to ensure consistent unsigned comparisons throughout the function.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74680", "url": "https://ubuntu.com/security/CVE-2026-74680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm() If cxacru_cm() encounters an error while submitting or waiting for snd_urb, it aborts and returns the error without killing the already submitted rcv_urb. This leaves the rcv_urb active. When this happens during initialization (e.g., in cxacru_atm_start()), the driver may ignore the error and proceed to call cxacru_poll_status(), which invokes cxacru_cm() again. Attempting to submit the still-active rcv_urb triggers a warning in usb_submit_urb(): cxacru 1-1:1.0: send of cm 0x84 failed (-104) ATM dev 0: cxacru_atm_start: CHIP_ADSL_LINE_START returned -104 ------------[ cut here ]------------ URB ffff88812658d200 submitted while active WARNING: drivers/usb/core/urb.c:379 at usb_submit_urb+0x79/0x18b0 drivers/usb/core/urb.c:379 ... Call Trace: cxacru_cm+0x21a/0xf10 drivers/usb/atm/cxacru.c:631 cxacru_cm_get_array drivers/usb/atm/cxacru.c:722 [inline] cxacru_poll_status+0x178/0x1110 drivers/usb/atm/cxacru.c:828 cxacru_atm_start+0x185/0x360 drivers/usb/atm/cxacru.c:814 usbatm_atm_init+0x144/0x3a0 drivers/usb/atm/usbatm.c:927 usbatm_usb_probe+0x15cb/0x1db0 drivers/usb/atm/usbatm.c:1178 cxacru_usb_probe+0x17f/0x220 drivers/usb/atm/cxacru.c:1370 ... To fix this, ensure that rcv_urb is properly killed if cxacru_cm() aborts early. We can safely call usb_kill_urb() on rcv_urb in the error path, as it is safe to call even if the URB is not active (e.g., if it failed to submit in the first place, or if it already completed).", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74681", "url": "https://ubuntu.com/security/CVE-2026-74681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: misc: usbio: check ibuf_len against rxbuf_len in bulk msg ibuf_len is the bulk IN (receive) buffer size, but the EMSGSIZE check in usbio_bulk_msg() compares it against txbuf_len — the bulk OUT endpoint size. Both are taken independently from different endpoints in usbio_probe(), so the check is wrong when they differ. Use rxbuf_len for the IN direction. This matches the buffer that actually holds the response data.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74682", "url": "https://ubuntu.com/security/CVE-2026-74682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write on Type II inbound URBs data_ep_set_params() sizes each URB transfer buffer before it adds the Format Type II transfer delimiter: \tu->packets = urb_packs; \tu->buffer_size = maxsize * u->packets; \tif (fmt->fmt_type == UAC_FORMAT_TYPE_II) \t\tu->packets++; /* for transfer delimiter */ \tu->urb = usb_alloc_urb(u->packets, GFP_KERNEL); buffer_size is computed from the pre-increment packet count and never recomputed, so for a Type II endpoint the buffer is one packet short of the packet count the URB is built with. prepare_inbound_urb() then lays out one iso frame per packet and never consults buffer_size: \toffs = 0; \tfor (i = 0; i < urb_ctx->packets; i++) { \t\turb->iso_frame_desc[i].offset = offs; \t\turb->iso_frame_desc[i].length = ep->curpacksize; \t\toffs += ep->curpacksize; \t} \turb->transfer_buffer_length = offs; \turb->number_of_packets = urb_ctx->packets; The last descriptor therefore points one packet past the end of the transfer buffer, where the host controller writes device data on every inbound transfer. prepare_silent_urb() and prepare_playback_urb() bound their fill loops by ctx->buffer_size, so only capture is affected. fmt_type comes from the device's audio streaming descriptors, so any device advertising a Type II capture format hits this once userspace sets hw_params on the stream. KASAN on 7.2.0-rc5 (arm64) with a dummy_hcd/raw-gadget device, one report per inbound transfer: BUG: KASAN: slab-out-of-bounds in dummy_timer Write of size 64 at addr ffff0000186171c0 by task cons02/166 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 166: usb_alloc_coherent snd_usb_endpoint_set_params The buggy address is located 0 bytes to the right of allocated 64-byte region [ffff000018617180, ffff0000186171c0) Compute buffer_size after the delimiter packet has been accounted for, and bound the fill loop by buffer_size, as prepare_silent_urb() already does on the outbound side. This grows every Type II URB allocation by one maxsize packet. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74683", "url": "https://ubuntu.com/security/CVE-2026-74683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: evdev - sanitize event type index when fetching event masks The user-supplied event type index passed to EVIOCGMASK / EVIOCSMASK ioctls is used to index the static counts array in evdev_get_mask_cnt() and client evmasks array in evdev_get_mask(). While the event type is architecturally bounded by EV_CNT, speculative execution may mispredict bounds checks and perform out-of-bounds loads. Sanitize the event type index in evdev_get_mask_cnt() branchlessly using array_index_mask_nospec(). This clamps the index to 0 for safe array access and forces the returned count to 0 speculatively when the index is out of bounds. We do not need additional array_index_nospec() calls in evdev_get_mask() because evdev_get_mask_cnt() speculatively forces the count (and resulting xfer_size) to 0 for out-of-bounds types, preventing any speculative memory access to client evmasks array.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74684", "url": "https://ubuntu.com/security/CVE-2026-74684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tap: set skb->dev before parsing virtio net header in tap_get_user_xdp() The commit 4f61f133f354 (\"net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null\") fixed a crash in tap_get_user() by assigning skb->dev before calling tun_vnet_hdr_to_skb(). This is required because virtio_net_hdr_to_skb() may invoke dev_parse_header_protocol(), which dereferences skb->dev. Without the assignment, a NULL pointer dereference can occur. However, tap_get_user_xdp() still parses the virtio-net header before assigning skb->dev. When the vhost TX path passes an XDP buffer containing a GSO virtio-net header but the protocol is set to zero on purpose, tun_vnet_hdr_to_skb() can reach dev_parse_header_protocol() while skb->dev is still NULL, resulting in a crash. Fix this by looking up the tap device and assigning skb->dev before calling tun_vnet_hdr_to_skb(), matching the ordering already used in tap_get_user(). Preserve the existing RCU read-side critical section across dev_queue_xmit().", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74685", "url": "https://ubuntu.com/security/CVE-2026-74685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (ltc4282) Clamp negative current limits When a negative value is passed to ltc4282_write_curr(), the signed long val is cast directly to u64: drivers/hwmon/ltc4282.c:ltc4282_write_curr() { /* need to pass it in millivolt */ u32 in = DIV_ROUND_CLOSEST_ULL((u64)val * st->rsense, DECA * MICRO); ... } This cast converts negative inputs into large positive values. The subsequent division result overflows the u32 in variable, truncating to a pseudo-random positive value. When this is passed to ltc4282_write_voltage_byte(), it is clamped to the maximum limit instead of zero. Clamp val to 0 and to the maximum supported upper limit before the cast and assign the result to a 64-bit temporary variable before the division to avoid the underflow and an also possible overflow.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74687", "url": "https://ubuntu.com/security/CVE-2026-74687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: at91sam9_wdt: prevent timer rearm during teardown at91_ping() rearms the watchdog timer from its callback. timer_delete() neither waits for a running callback nor prevents it from rearming the timer, so probe failure or driver removal can leave the timer accessing the devm-allocated at91wdt after it has been freed. Use timer_shutdown_sync() on both teardown paths. It waits for a running callback and rejects any attempt by the callback to rearm the timer.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74688", "url": "https://ubuntu.com/security/CVE-2026-74688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: clear control chunk transport if it is being removed sctp_make_heartbeat_ack() caches the destination transport in chunk->transport without taking a reference. When src_out_of_asoc_ok is enabled, the HEARTBEAT ACK may remain queued on control_chunk_list instead of being transmitted immediately. If the peer transport is removed while the chunk is still queued, sctp_assoc_rm_peer() drops the transport and schedules it for RCU freeing, but only clears cached transport pointers in out_chunk_list. The queued control chunk therefore retains a dangling transport pointer. Once an ASCONF_ACK clears the suppression and the queued control chunk is transmitted, SCTP dereferences the stale transport pointer, leading to a use-after-free. Fix this by also clearing chunk->transport for queued control chunks in control_chunk_list when removing the transport.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74689", "url": "https://ubuntu.com/security/CVE-2026-74689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/atm: fix slab-out-of-bounds read in vcc_setsockopt() vcc_setsockopt() contained an ineffective optlen check: if (__SO_LEVEL_MATCH(optname, level) && optlen != __SO_SIZE(optname)) return -EINVAL; If __SO_LEVEL_MATCH(optname, level) evaluated to false (e.g. if the caller passed a mismatched level), the length check optlen != __SO_SIZE(optname) was short-circuited and bypassed. Execution then fell through to switch(optname), calling copy_from_sockptr() assuming optval contained sufficient space. Furthermore, even if level matched, a cgroup BPF setsockopt filter could shrink optlen after entry. Because copy_from_sockptr() on kernel pointers uses memcpy(), this leads to a KASAN slab-out-of-bounds read when optlen is smaller than the expected structure size. Fix this by using copy_safe_from_sockptr(), which unconditionally validates that optlen is at least the expected size before copying. Also change the local 'value' variable type from 'unsigned long' to 'int' so that SO_SETCLP matches its sizeof(int) ABI encoding on 64-bit systems.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74690", "url": "https://ubuntu.com/security/CVE-2026-74690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ism: Fix UAF of sba and ieq during ism_dev_exit() A ism interrupt handler can be active in parallel with ism_dev_exit(), accessing freed data structures. No new interrupts will be generated after unregister_ieq(). Drain ongoing interrupt handlers by free_irq(), before freeing ism data structures.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74691", "url": "https://ubuntu.com/security/CVE-2026-74691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Tear down DMA paths before stopping the rings tbnet_tear_down() stops both rings and frees their frame buffers before calling tb_xdomain_disable_paths(). tb_ring_stop() zeroes the ring's descriptor base and tbnet_free_buffers() unmaps and frees the pages the frames sit in, so by the time __tb_path_deactivate_hop() polls the hop's 'pending' bit, anything still in flight has nowhere to drain to. The teardown sequence has been in this order since the driver was added. The setup path has not: commit ff7cd07f3064 (\"net: thunderbolt: Enable DMA paths only after rings are enabled\") moved the path enable to the end of tbnet_connected_work() and documented why: \t/* Both logins successful so enable the rings, high-speed DMA \t * paths and start the network device queue. \t * \t * Note we enable the DMA paths last to make sure we have primed \t * the Rx ring before any incoming packets are allowed to \t * arrive. \t */ Teardown was never updated to match, so the rings and the paths now come down in the same order they go up instead of in reverse. On an ASMedia ASM4242 host router the 'pending' bit then never clears: every teardown burns the full 500 ms timeout and __tb_path_deactivate_hop() returns -ETIMEDOUT. Raising the timeout to 5 s does not help, so the hop is not slow to drain, it never drains at all. The failure is invisible above the thunderbolt core. __tb_path_deactivate_hops() is void and only calls tb_port_warn(); tb_path_deactivate(), tb_tunnel_deactivate() and __tb_disconnect_xdomain_paths() are void as well, and tb_disconnect_xdomain_paths() ends in an unconditional \"return 0\". So tb_xdomain_disable_paths() reports success and the netdev_warn() below it never fires. Repeated teardowns eventually take the XDomain control channel down, after which the peer node is gone and only a power cycle brings the controller back. Deactivating the paths first fixes it. Measured with kretprobes on a stock v6.17 tree with no other patches applied, on a link that was up and had just carried traffic: before: __tb_path_deactivate_hop() returns 0 for the first hop, then -ETIMEDOUT for the second 500335 us later after: 0 for both, 525 us apart Alternating the two orderings ABBA over three load levels, four teardowns per arm: every teardown failed before the change (21 of 21 that ran), none failed after (0 of 24). The before arms ran short because the link died partway through. The same split shows up when the interface is enslaved to a bond instead of just brought down, which is how I ran into this in the first place. Throughput and latency after the change are unchanged. Hosts whose routers drain the hop despite the stale descriptor base see no functional difference, since the paths end up deactivated either way.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74692", "url": "https://ubuntu.com/security/CVE-2026-74692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix TOCTOU race between smc_listen_out() and listener close smc_listen_out() reads lsmc->sk.sk_state without the listener lock, then acquires lock_sock_nested() only after the check passes. This opens a window where smc_close_active() can transition the listener to SMC_CLOSED, call smc_close_cleanup_listen() to drain the accept queue, and release the lock, all between the lockless read and the delayed lock acquisition: smc_listen_work (smc_hs_wq) smc_close_active() ------------------------------- ------------------------- release_sock(child) if (sk_state == SMC_LISTEN) TRUE lock_sock(listener) sk_state = SMC_CLOSED smc_close_cleanup_listen() release_sock(listener) flush_work(tcp_listen_work) lock_sock_nested(listener) smc_accept_enqueue(listener, child) /* child enqueued on dead listener */ smc_close_active() flushes only tcp_listen_work. Work items already dispatched onto smc_hs_wq for the CLC handshake continue running unguarded. smc_accept_enqueue() takes a sock_hold() on the child that is never released, so the child smc_sock, its clcsock, and the reference all leak. A remote peer that opens TCP connections while the server calls close() can exhaust kernel memory. Move lock_sock_nested() to before the sk_state check so that the test and the enqueue are atomic under the listener lock.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74693", "url": "https://ubuntu.com/security/CVE-2026-74693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: prestera: validate firmware header length prestera_fw_hdr_parse() reads the firmware header before checking that the firmware image contains that header. Reject images shorter than struct prestera_fw_header before decoding the magic and version fields.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74694", "url": "https://ubuntu.com/security/CVE-2026-74694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: fix heap OOB read in NCSI_CMD_SEND_CMD payload length ncsi_send_cmd_nl() takes the number of bytes to copy from the attacker-controlled ncsi_pkt_hdr.length field of the in-band packet header, while the source buffer is the NCSI_ATTR_DATA netlink attribute whose readable size is nla_len() - sizeof(ncsi_pkt_hdr). The two length sources are never cross-checked: only nla_len() >= sizeof(struct ncsi_pkt_hdr) is enforced. With hdr->length set larger than the attribute payload (up to 65535 against at most 2032 readable bytes), ncsi_cmd_handler_oem() copies past the end of the netlink attribute buffer with unsafe_memcpy(), leaking up to ~64KB of kernel heap memory into the transmitted NCSI command packet. The destination skb is sized by the declared payload, so the write side does not overflow - this is a pure OOB read / information leak, reachable with CAP_NET_ADMIN on systems with a registered NCSI device (e.g. OpenBMC on Aspeed BMC SoCs, where NET_NCSI=y is standard). Reject commands whose declared payload extends past the end of the data attribute. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74695", "url": "https://ubuntu.com/security/CVE-2026-74695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_flow_table: drop existing skb dst before skb_dst_set_noref() Incoming skbs passing through netfilter flowtable offload hooks (or XFRM offload path) might already carry a ref-counted dst_entry assigned during earlier RX or routing steps. Calling skb_dst_set_noref() when skb already holds a ref-counted dst overwrites skb->_skb_refdst, leaking the previous dst_entry reference count and triggering a DEBUG_NET_WARN_ON_ONCE assertion in skb_dst_check_unset(): WARNING: at skb_dst_check_unset include/linux/skbuff.h:1170 WARNING: at skb_dst_set_noref include/linux/skbuff.h:1234 WARNING: at nf_flow_offload_ip_hook+0xf6c/0x2b60 net/netfilter/nf_flow_table_ip.c:864 Drop any existing dst_entry reference with skb_dst_drop(skb) before setting the non-referenced flowtable destination.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74696", "url": "https://ubuntu.com/security/CVE-2026-74696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TFO max_qlen accounting across reuseport migration A listener's TCP_FASTOPEN max_qlen stops being accurate and lets through far more pending Fast Open requests than it was configured for. This only shows up with SO_REUSEPORT listener migration, where closing a listener hands its still-pending TFO children over to a surviving one. fastopenq.qlen is charged in tcp_fastopen_create_child() when the child is created and uncharged in reqsk_fastopen_remove() when the handshake completes. The uncharge follows rsk_listener of the request the child points at, and inet_reqsk_clone() has repointed the child at a new request owned by the new listener, so the ++ and the -- land on two different sockets. The new listener's qlen drifts negative and its limit no longer binds. Charge the new listener during migration, like reqsk_queue_migrated() already does for queue->young and queue->qlen.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74697", "url": "https://ubuntu.com/security/CVE-2026-74697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Disable EOP for TPA on all chips to prevent data corruption EOP (End of frame padding) on the AGG ring may cause overlapping of zero padding at the end of one segment with the next segment's data. If Relaxed Ordering (RO) is enabled, the zero padding may overwrite valid data in the next segment and corrupt the data. Older chips (P5 and older) do not automatically disable RO when EOP is enabled. On some ARM systems, data corruption was reported on 57508 (P5) chips with RO enabled. Always disable EOP on all chips on the AGG rings when TPA is enabled to fix the data corruption.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74698", "url": "https://ubuntu.com/security/CVE-2026-74698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix BQL reset on SQ re-activation mlx5e_queue_start() deactivates and re-activates all channels but closes only the queue being restarted. mlx5e_activate_txqsq() then unconditionally calls netdev_tx_reset_queue(), zeroing the BQL counters of channels that kept their in-flight TX WQEs. The next completion then over-charges and trips the BUG_ON() in dql_completed(): kernel BUG at lib/dynamic_queue_limits.c:99! RIP: 0010:dql_completed+0x23d/0x280 Call Trace: mlx5e_poll_tx_cq+0x668/0xa60 mlx5e_napi_poll+0x5b/0x7b0 net_rx_action+0x15a/0x580 Reset BQL only when the SQ has no bytes in flight (sq->cc == sq->pc). In the case that reset is skipped, the outstanding WQEs will eventually complete and rebalance the dql. The dql->limit is carried across the reset.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74700", "url": "https://ubuntu.com/security/CVE-2026-74700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers Another challenge with unlocked filters. There is a short window in tc_new_tfilter where a tcf_proto can be found and briefly referenced by a totally unrelated, unlocked classifier's request and cause a race. Feng created a poc which created this race with two threads, one creating a u32 filter and other a flower filter in the same chain/prio: 1. Both threads enter tc_new_tfilter, both find the chain empty, both drop filter_chain_lock 2. u32 finishes tcf_proto_create(\"u32\") first, calls tcf_chain_tp_insert_unique() -> inserts u32_tp into the chain 3. flower finishes tcf_proto_create(\"flower\") later, calls tcf_chain_tp_insert_unique() -> tcf_chain_tp_find() now sees u32_tp already there, takes a reference on it, destroys flower's own tp_new and returns u32_tp to the caller. Flower then hits the kind mismatch check (because it requested for kind \"flower\" but tp->ops->kind is \"u32\") and goes through the errout path which calls tcf_proto_put() on u32_tp. If the u32 thread has already gone through its own errout (its change() call failed on the PoC's empty options) and dropped its create and insert refs, flower's put is the last one and drops u32_tp's refcnt to zero. At this point tp->ops->destroy() runs in a context that never took rtnl_lock. When that happens, it might cause a UAF like the following (illustrated by the PoC): [ +0.000710] BUG: KASAN: slab-use-after-free in u32_init (net/sched/cls_u32.c:393) [ +0.000281] Read of size 8 at addr ffff888120022f00 by task poc_feng_xue/524 Call Trace: u32_init (net/sched/cls_u32.c:393) tc_new_tfilter (net/sched/cls_api.c:2378) Allocated by task 526: u32_init (net/sched/cls_u32.c:378) tc_new_tfilter (net/sched/cls_api.c:2378) Freed by task 522: kfree u32_destroy (net/sched/cls_u32.c:662) tcf_proto_destroy (net/sched/cls_api.c:446) tcf_proto_put (net/sched/cls_api.c:459) tc_new_tfilter (net/sched/cls_api.c:2459) Fix this by having tcf_proto_destroy() take rtnl_lock around tp->ops->destroy() for locked classifiers whenever rtnl is not held. To explain why I used a temp variable \"not_lockless\" I'd like to point to a semi-related note on rtnl_held vs TCF_PROTO_OPS_DOIT_UNLOCKED (adding here for future cleanup if deemed necessary): The rtnl_held parameter and the TCF_PROTO_OPS_DOIT_UNLOCKED flag are redundant sources of truth for whether rtnl_lock is held. Among the nine classifier destroy(..rtnl_held..) callbacks, only flower consults the rtnl_held parameter which it propagates to tc_setup_cb_destroy() and tc_setup_cb_call(). The other eight (u32, flow, bpf, cgroup, route, basic, fw, mall) ignore it entirely;-> those that call tc_setup_cb_destroy() (u32, bpf, mall) hardcode true always instead of forwarding the parameter. A future cleanup should remove the rtnl_held parameter from the destroy callback signature entirely and have callers rely solely on their knowledge whether they are running in an unlocked context.", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74701", "url": "https://ubuntu.com/security/CVE-2026-74701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/openvswitch: check Ethernet header length in key_extract() When a packet arrives on an ARPHRD_NONE device (e.g. TUN), ovs_flow_key_extract() trusts the user-provided skb->protocol field: if it is ETH_P_TEB, the packet is classified as MAC_PROTO_ETHERNET and key_extract() is called without ensuring the skb has ETH_HLEN (14) bytes of linear data. key_extract() unconditionally pulls 2 * ETH_ALEN bytes for MAC addresses and parse_ethertype() pulls 2 more, either of which triggers a kernel BUG in __skb_pull() when the linear area is too small. kernel BUG at include/linux/skbuff.h:2848! RIP: 0010:key_extract+0xa7e/0xd90 net/openvswitch/flow.c:933 ovs_flow_key_extract+0x419/0xa70 ovs_vport_receive+0x222/0x390 netdev_frame_hook+0x3e0/0x630 tun_get_user+0x2d0c/0x38e0 Fixed by calling check_header() in key_extract() before accessing the Ethernet header.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74702", "url": "https://ubuntu.com/security/CVE-2026-74702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: reject feature changes after endpoint vhost_scsi_setup_vq_cmds() runs from VHOST_SCSI_SET_ENDPOINT and allocates each command's protection scatterlist array (prot_sgl) according to the acknowledged VIRTIO_SCSI_F_T10_PI bit. The command pools are not rebuilt when VHOST_SET_FEATURES changes that bit later. Although virtio feature bits must not change after feature negotiation, vhost_scsi_set_features() currently accepts such a request after the endpoint is active and updates acked_features. Enabling T10-PI after endpoint setup therefore leaves prot_sgl NULL while the I/O path follows the new feature bit. For a 129-page protection payload, vhost_scsi_mapal() passes the missing first chunk to sg_alloc_table_chained(): sg_alloc_table_chained(table, 129, first_chunk=NULL, nents_first_chunk=inline_sg_cnt) sg_pool_index() then hits: BUG_ON(nents > SG_CHUNK_SIZE); /* 129 > 128 */ The kernel reported the following call trace and register state: Call Trace: ? __sg_alloc_table+0x1d8/0x250 ? __pfx_vhost_run_work_list+0x10/0x10 [vhost] sg_alloc_table_chained+0x59/0xf0 ? __pfx_sg_pool_alloc+0x10/0x10 ? vhost_scsi_calc_sgls.constprop.0+0x43/0x60 [vhost_scsi] vhost_scsi_handle_vq+0xf02/0x1700 [vhost_scsi] ? __pfx_vhost_scsi_handle_vq+0x10/0x10 [vhost_scsi] vhost_scsi_handle_kick+0x37/0x50 [vhost_scsi] vhost_run_work_list+0x8e/0xd0 [vhost] vhost_task_fn+0xe1/0x210 ret_from_fork+0x348/0x540 RIP: 0010:0x4 CR2 = 0x4 RSP: 0018:ffffc90000dbf940 EFLAGS: 00010202 RAX: ffffffff82396810 RBX: ffff88811dc28b80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000081 VHOST_F_LOG_ALL is a vhost-specific runtime feature and remains the only exception. Reject changes to any feature other than VHOST_F_LOG_ALL while the endpoint is active. This preserves the existing runtime log toggle while preventing feature-dependent command resources and data-path state from becoming inconsistent. Userspace must clear the endpoint before changing any other negotiated feature and set the endpoint up again afterward.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74703", "url": "https://ubuntu.com/security/CVE-2026-74703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: Validate T10 PI scatterlist counts When T10 PI is negotiated, vhost-scsi splits protection bytes from the data iterator before mapping the request scatterlists. A malformed request can claim protection bytes that cover or exceed the full payload length. The former leaves no data bytes to map, while the latter underflows exp_data_len before advancing the iterator. Both cases can let a zero data SGL count reach sg_alloc_table_chained(), which triggers BUG_ON(!nents). Reject protection lengths that cover or exceed the payload before subtracting prot_bytes and advancing the iterator. Also propagate negative errors from the protection SGL calculation before calling the allocator, matching the data SGL path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74704", "url": "https://ubuntu.com/security/CVE-2026-74704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: drop WARN_ON(1) for malformed packets in ACK filter The sch_cake ACK filter parses packets to find the TCP header and filter duplicated ACKs if the flow is backlogged. The parsing code contains a WARN_ON(1) which can be triggered by a malformed IP header in certain cases. Depending on the system configuration, this leads either to either spamming dmesg with warnings, or a panic if panic_on_warn is set. The code already correctly skips the offending packet in the branch that triggers the warning, so the WARN_ON itself doesn't really serve any purpose. So just drop it altogether to avoid the inconvenient side effects.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74705", "url": "https://ubuntu.com/security/CVE-2026-74705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: fix potential use-after-free in tunnel segmentation __skb_udp_tunnel_segment() gets the UDP header before ensuring the tunnel header is in the skb head. If the pull reallocates skb->head, the saved UDP header pointer is no longer valid. Get the UDP header after the pull to avoid a potential use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74707", "url": "https://ubuntu.com/security/CVE-2026-74707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: validate metadata when processing requests The zero-copy path validates TX metadata while obtaining the descriptor context, then reads it again later when preparing the hardware request. User space can change the metadata between those operations and bypass the original validation. Validate the metadata in xsk_tx_metadata_request() and use the resulting flags snapshot for every feature check. Read request fields once so all zero-copy drivers process only values observed after successful validation.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74708", "url": "https://ubuntu.com/security/CVE-2026-74708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: validate launch-time metadata size Launch-time metadata extends beyond the first 16 bytes of struct xsk_tx_metadata. Reject the request when the registered metadata area does not contain the complete field. Snapshot the validated flags for the generic transmit path and use that snapshot for request and completion processing, avoiding inconsistent decisions if user space changes the flags concurrently. Note that only xsk_skb_metadata is properly using the flags, __xsk_buff_get_metadata ignores them. Next commits address that.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74709", "url": "https://ubuntu.com/security/CVE-2026-74709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: clear metadata pointer when no timestamp is requested User space can change metadata flags after request processing. Rereading them during completion can therefore make the kernel write a timestamp that was not requested when the packet was submitted. Clear the metadata pointer during request processing unless timestamp completion is requested. Completion handling can then use the pointer itself instead of rereading the flags. On the mlx5 multi-packet WQE path metadata is evaluated per batch: xsk_tx_metadata_request() runs only for the descriptor that starts a session, just like the checksum offload that is applied once through the shared WQE. Only that descriptor's pointer is reset, so completion handling can record a timestamp for the other descriptors of the session regardless of their own XDP_TXMD_FLAGS_TIMESTAMP bit. The write stays inside the metadata area; the single-WQE, other zero-copy, and generic paths reset the pointer per descriptor and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74710", "url": "https://ubuntu.com/security/CVE-2026-74710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: require at least 16 bytes of TX metadata AF_XDP accepts a TX metadata length as small as eight bytes, but every supported request needs the flags plus at least one eight-byte request field. Such short metadata also lets the kernel read beyond the registered area. Require 16 bytes rather than sizeof(struct xsk_tx_metadata) to preserve compatibility with applications that do not use launch-time metadata.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74711", "url": "https://ubuntu.com/security/CVE-2026-74711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus) Fix type confusion in notification logic Sashiko reports: At the start of the loop in pmbus_notify(), the code unconditionally casts every attribute to a struct sensor_device_attribute: drivers/hwmon/pmbus/pmbus_core.c:pmbus_notify() { for (i = 0; i < data->num_attributes; i++) { struct device_attribute *da = to_dev_attr(data->group.attrs[i]); struct sensor_device_attribute *attr = to_sensor_dev_attr(da); int index = attr->index; ... } However, data->group.attrs can contain other types like struct pmbus_samples_reg or struct pmbus_sensor, which only embed a base struct device_attribute. If da is a struct pmbus_samples_reg, dev_attr is the last member. Casting it to struct sensor_device_attribute and reading the index field appears to access memory past the end of the allocation, which might trigger a slab-out-of-bounds read. Additionally, if da is a struct pmbus_sensor, casting it causes the index field to overlap with the page, phase, and reg fields. Could this produce a garbage mask on little-endian systems that spuriously matches the target reg, page, and flags during an alert? Fix the problem by using struct sensor_device_attr in struct pmbus_sensor and struct pmbus_label. Since those attributes never trigger a notification, set the value of attr->index to -1 for them. Use this value to distinguish from boolean attributes which _can_ trigger a notification and use the index field to encode mask, page, and register values.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74712", "url": "https://ubuntu.com/security/CVE-2026-74712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix buffer length in create_direct_keys() We have seen in our CI the following KASAN message: BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core] Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764 [...] [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core] [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core] [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa] [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa] [...] The buggy address is located 4128 bytes inside of allocated 4384-byte region [0000000176794000, 0000000176795120) So in essence we read 16 bytes beyond 4384-byte allocation. create_direct_keys calculates the pointer and length for in and out buffers. The size calculation for in includes the entire structure size (out + in + mtt[]) but the pointer passed to cmd_exec points only to the 'in' field, skipping the 'out' field. This causes mlx5_copy_to_msg() to read beyond the allocated buffer by sizeof(out) bytes when copying command data. Properly calculate the input size to match the pointer and allocation size.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74714", "url": "https://ubuntu.com/security/CVE-2026-74714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch() reqsk_queue_hash_req() publishes a TCP_NEW_SYN_RECV request_sock onto the ehash chain, drops the bucket lock, and only afterwards sets rsk_refcnt to 3. Lockless readers such as __inet_lookup_established() handle this with refcount_inc_not_zero(), but bpf_iter_tcp_established_batch() uses plain sock_hold() while holding the bucket lock, on the assumption that the lock guarantees sk_refcnt > 0. That assumption does not hold for request_sock: CPU 0 CPU 1 ----- ----- tcp_conn_request() reqsk_queue_hash_req() inet_ehash_insert(req) spin_lock(bucket) __sk_nulls_add_node_rcu(req) // rsk_refcnt == 0 spin_unlock(bucket) bpf_iter_tcp_established_batch() spin_lock(bucket) sock_hold(req) <-- addition on 0 spin_unlock(bucket) refcount_set(&req->rsk_refcnt, 3) // clobbers saturated value which surfaces as: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x48/0x90, CPU#1 Call Trace: bpf_iter_tcp_established_batch+0x14e/0x170 bpf_iter_tcp_batch+0x53/0x200 bpf_iter_tcp_seq_next+0x27/0x70 bpf_seq_read+0x107/0x410 vfs_read+0xb9/0x380 The iterator's stolen reference is lost when the publishing CPU's refcount_set() overwrites the count, leaving the socket one reference short. When the last legitimate owner drops its reference the reqsk is freed while still reachable, leading to use-after-free. This reproduces in seconds with tcp_syncookies=0, a handful of threads doing connect()/close() to a local listener while others read an iter/tcp link in a tight loop. Use refcount_inc_not_zero() and skip the socket on failure. A skipped socket is still part of the bucket, so keep counting it in expected. The reallocations are sized from expected, and a request sock whose refcount gets published while the lock is held across the last realloc must already have room. A skipped socket is counted in expected but never batched, so end_sk can be short of expected on a batch that is actually complete. Decide completeness by whether the walk left any socket behind instead. The WARN after the locked realloc checks the same, replacing an end_sk == expected check that could not hold on that path since commit cdec67a489d4 (\"bpf: tcp: Make sure iter->batch always contains a full bucket snapshot\"). If every matching socket in a bucket is mid-init (refcount 0), end_sk stays 0. Advance to the next bucket rather than returning a batch entry that was never filled this round.", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74717", "url": "https://ubuntu.com/security/CVE-2026-74717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fw_tracer, return NULL on create error Tracer creation can fail by returning either NULL or ERR_PTR. The return value is stored without a check on the device, and users treat ERR_PTR and NULL the same way. This also causes a crash in the core dump logic, which is missing the ERR_PTR check and ends up dereferencing it, as shown in the trace below. Switch tracer creation to return NULL on failure only, so callers only need a single NULL check. Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: mlx5_ib ib_uverbs ib_core ipv6 mlx5_core CPU: 1 UID: 0 PID: 12 Comm: kworker/u16:0 Not tainted 6.19.7 #1 PREEMPT(none) Workqueue: mlx5_health0001:01:00.0 mlx5_fw_reporter_err_work [mlx5_core] pstate: a3400009 (NzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] lr : mlx5_fw_tracer_trigger_core_dump_general+0x40/0xe0 [mlx5_core] sp : ffff800081cf3c40 x29: ffff800081cf3c90 x28: 0000000000000000 x27: 0000000000000000 x26: ffff000080018828 x25: 0000000000000000 x24: ffff000080304a05 x23: ffff800081cf3d80 x22: ffff0000847e01a0 x21: 0000000000000000 x20: ffff0000847e01a0 x19: ffffffffffffffa1 x18: ffff80008310bbf0 x17: ffff800080119650 x16: ffff80008010df54 x15: ffff80008010d4ac x14: ffff800079c202e4 x13: ffff80008002fe60 x12: ffff800080119650 x11: ffff80008010df54 x10: ffff80008010d4ac x9 : ffff800079c203d8 x8 : ffff800081cf3c88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000008 x3 : 0000000000000030 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 00000000c5c4000e Call trace: mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] (P) mlx5_fw_reporter_dump+0x30/0x2e0 [mlx5_core] devlink_health_do_dump+0x9c/0x160 devlink_health_report+0x1c0/0x288 mlx5_fw_reporter_err_work+0xac/0xc0 [mlx5_core] process_one_work+0x15c/0x3d8 worker_thread+0x18c/0x320 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: b9400000 5ac00800 7a401800 540003ca (3940a260) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x000000,00078031,75fce5a1,35fffe67 Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception ]---", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74718", "url": "https://ubuntu.com/security/CVE-2026-74718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: fix net namespace reference leak in reload devlink_nl_reload_doit() calls devlink_netns_get(), which returns a net with a held reference. When the requested namespace differs from the current one and the reload action is not DRIVER_REINIT, the function returns -EOPNOTSUPP without releasing the reference. Add the missing put_net() on this error path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74583", "url": "https://ubuntu.com/security/CVE-2026-74583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_route: fix fastmap use-after-free on filter The route4 classifier maintains a 16-slot fastmap cache that stores raw struct route4_filter pointers indexed by (id, iif). The reader (route4_classify) populates this cache via route4_set_fastmap() for every classified packet that hits a filter. The writer (route4_delete, route4_change) clears the cache via route4_reset_fastmap() before RCU-deferred kfree of the filter. This creates a UAF race: 1. Reader walks the RCU-protected bucket chain, finds filter f 2. Writer unlinks f, calls route4_reset_fastmap(), then tcf_queue_work() 3. Reader calls route4_set_fastmap() and writes f into the cache *after* the writer's reset, caching a pointer about to be freed 4. After the RCU grace period, kfree(f) executes 5. Next classified packet on the same (id, iif) tuple hits the stale fastmap entry and reads f->res from freed memory Reproduced with an mdelay(100) accelerator in route4_set_fastmap() and a concurrent add/delete stress test (provided by both zdi and Santosh). Both triggered KASAN slab-use-after-free reports in the route4 fastmap paths. Fix: Introduce a per-filter boolean dying flag to suppress stale fastmap republishing by in-flight readers.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-74719", "url": "https://ubuntu.com/security/CVE-2026-74719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler() The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in smc_llc_event_handler() stores an incoming qentry into the local LLC flow without first checking whether a qentry is already pending. If a malicious or buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is active and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message. The sibling SMC_LLC_DELETE_LINK branch already has the correct !flow->qentry guard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a duplicate message when qentry is already occupied falls through to break and is freed by the kfree(qentry) at the out: label, rather than silently leaking the existing allocation. The response direction (smc_llc_rx_response()) is unaffected: it already guards with flow->qentry at the equivalent site and drops duplicate responses correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74720", "url": "https://ubuntu.com/security/CVE-2026-74720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve pointer state for commuted arithmetic When scalar += pointer is handled in adjust_ptr_min_max_vals(), the destination register inherits the pointer state from the source pointer. Copying only selected fields is fragile because pointer provenance is tracked by several bpf_reg_state fields. Use the caller's temporary offset register to preserve the scalar operand while replacing the destination with the full pointer state. This preserves the frame number for PTR_TO_STACK registers and keeps parent identity fields consistent.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74722", "url": "https://ubuntu.com/security/CVE-2026-74722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leak in btrfs_do_encoded_write() Local fuzzing of 6.12.94 has found the following memory leak: Unreferenced object 0xffff888018050a80 (size 64): comm \"syz.0.17\", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 10 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 10 0a 05 18 80 88 ff ff 10 0a 05 18 80 88 ff ff ................ backtrace (crc a8a6fc29): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] extent_changeset_alloc fs/btrfs/extent_io.h:207 [inline] qgroup_reserve_data+0x1c5/0x7d0 fs/btrfs/qgroup.c:4305 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Unreferenced object 0xffff888018050a00 (size 64): comm \"syz.0.17\", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 ff 0f 00 00 00 00 00 00 ................ 90 0a 05 18 80 88 ff ff 90 0a 05 18 80 88 ff ff ................ backtrace (crc cb5c9580): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ulist_prealloc+0x9c/0x110 fs/btrfs/ulist.c:114 extent_changeset_prealloc fs/btrfs/extent_io.h:217 [inline] __set_extent_bit+0x16b/0x1a70 fs/btrfs/extent-io-tree.c:1086 set_record_extent_bits+0x50/0x90 fs/btrfs/extent-io-tree.c:1821 qgroup_reserve_data+0x274/0x7d0 fs/btrfs/qgroup.c:4312 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by freeing an extent changeset before returning from btrfs_do_encoded_write().", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74724", "url": "https://ubuntu.com/security/CVE-2026-74724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: avoid out-of-bounds write in ip_vs_nat_icmp Sashiko warns that local attacker can modify the packet while it is processed by IPVS. Some places read the IP ihl field multiple times which can cause out-of-bounds access. One such place is ip_vs_nat_icmp where we can write after the validated area. Fix it by providing ciph argument just like it is done for IPv6 and use ciph->len as offset to the embedded transport header. Modify some IPv4 header checks by reading the ihl field only once.", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74725", "url": "https://ubuntu.com/security/CVE-2026-74725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: enic: fix tx_hang_reset use-after-free on device removal enic_remove() cancels the reset and change_mtu_work items but does not cancel tx_hang_reset. A TX timeout that fires while the device is being removed can schedule enic_tx_hang_reset() so that it runs after free_netdev(), resulting in a use-after-free. cancel_work_sync() alone is not sufficient here: the still-live watchdog and notify paths can re-schedule these work items in the window between the cancel and unregister_netdev(). Use disable_work_sync(), which cancels the work and blocks any subsequent schedule_work() from requeuing it, and apply it to the reset and change_mtu_work items as well so the same requeue race is closed for all teardown work.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74726", "url": "https://ubuntu.com/security/CVE-2026-74726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor bond_alb_monitor() reads primary_is_promisc under RCU, then drops RCU and takes RTNL via rtnl_trylock() before undoing the promiscuity it set on the active slave. In that window the active slave can change under RTNL (RTM_DELLINK -> __bond_release_one() -> bond_alb_handle_active_change()), which already drops the promiscuity and clears primary_is_promisc. The monitor still acts on the stale decision: if the slave was removed with no failover, curr_active_slave is now NULL and the deref faults; if it failed over, the stale dev_set_promiscuity(-1) underflows the new slave's promiscuity counter and pins it in IFF_PROMISC. Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: b42 bond_alb_monitor RIP: 0010:bond_alb_monitor (drivers/net/bonding/bond_alb.c:1600) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) Kernel panic - not syncing: Fatal exception Re-check primary_is_promisc (and curr_active_slave) after taking RTNL so the monitor only undoes an increment it still owns. The other bonding monitors already re-read state under RTNL in their commit phase (bond_miimon_commit/bond_ab_arp_commit); bond_alb_monitor() was the only one acting on the pre-trylock decision.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74727", "url": "https://ubuntu.com/security/CVE-2026-74727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: skip rehash for peers already removed from by_id ovpn_nl_peer_set_doit() resolves the target peer via ovpn_peer_get_by_id() before taking ovpn->lock. In the window between the lookup (which only takes a refcount) and the subsequent spin_lock_bh(&ovpn->lock), a concurrent OVPN_CMD_PEER_DEL, keepalive expiry, or socket teardown can take ovpn->lock first, run ovpn_peer_remove() to unhash the peer from all four tables (by_id, by_vpn_addr4/6, by_transp_addr) and release the lock. set_doit then acquires ovpn->lock and calls ovpn_peer_hash_vpn_ip(), which re-inserts the now-removed peer back into the rehashing tables. The same race affects the float path: ovpn_peer_endpoints_update() holds only a refcount and acquires ovpn->lock very late (after async AEAD decrypt and a netlink notification), then rehashes the peer in the by_transp_addr table. The resurrected peer becomes reachable again from the RX lookup (ovpn_peer_get_by_transp_addr) and the TX VPN-IP lookup, even though userspace believes it is gone. Once the data-path refcount drops the peer is freed via call_rcu while the hash entries embedded in it remain linked, opening a UAF window. Bail out of the rehash when hash_entry_id is unhashed, mirroring the sentinel already used by ovpn_peer_remove() to detect the already-removed state. The check is safe under ovpn->lock, which serializes every mutation of hash_entry_id, and is a no-op for the add path because ovpn_peer_add_mp() inserts hash_entry_id before calling ovpn_peer_hash_vpn_ip().", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74728", "url": "https://ubuntu.com/security/CVE-2026-74728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: handle NULL b_addr in xfs_buf_free When xfs_buf_alloc_backing_mem() fails, xfs_buf_free() is called with bp->b_addr still NULL. The code falls through to the folio_put path which calls virt_to_folio(NULL), dereferencing an invalid address and causing a kernel crash. Call Trace: xfs_buf_free+0x25f/0x510 xfs_buf_alloc+0xc98/0x19b0 xfs_buf_find_insert+0x55/0x14d0 xfs_buf_get_map+0x122b/0x17c0 xfbtree_init_leaf_block+0x11c/0x4a0 xfbtree_init+0x1bb/0x460 xrep_rmap_setup_scan+0x100/0x1f0 xrep_rmapbt+0x41/0xc0 Fix this by skipping folio_put() when bp->b_addr is NULL.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74730", "url": "https://ubuntu.com/security/CVE-2026-74730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Pin the 'struct nfs_server' during a FREE_STATEID call Dan Aloni reports that he was able to hit a use-after-free bug if a FREE_STATEID operation gets delayed for whatever reason. Fix this by bumping the refcount of the 'struct nfs_server' object for the duration of the FREE_STATEID so it doesn't get cleaned up from underneath us while operations are still in flight.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74449", "url": "https://ubuntu.com/security/CVE-2026-74449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix divide-by-zero in calculate_mcache_setting on zero viewport If a plane reaches calculate_mcache_setting with a zero-area viewport, calculate_mcache_setting exits early with num_mcaches == 0 and mvmpg_width/height == 0. This will cause a divide-by-zero panic and can also cause an underflow on num_mcaches. Fix this by changing calculate_mcache_setting to bool and adding guards after each calculate_mcache_row_bytes call. If num_mcaches or mvmpg_width/height is zero, return a false. Callers will propagate the failure as a rejected mode, which prevents the panic. (cherry picked from commit 29c0f7c655f47bcbd575ff75e58480df6ec3c9da)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74450", "url": "https://ubuntu.com/security/CVE-2026-74450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix pptable use-after-free amdgpu_dpm_get_pp_table() returns a pointer to a driver-owned power table after dropping adev->pm.mutex. The sysfs path then copies from that pointer. A concurrent pp_table write can replace and free the allocation during the copy, causing a use-after-free. Change the DPM interface to copy into caller-provided storage while the mutex is held. Keep the size-only query for attribute discovery without exposing the driver-owned pointer. (cherry picked from commit f6eed7acfd30099ef7baeb6ba45bb59daad80631)", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74466", "url": "https://ubuntu.com/security/CVE-2026-74466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Close speculative mem read possibility The domain value is extracted from a given CCA or EP11 ioctl struct when a CPRB is about to be sent. Thus this is a user controlled value. Under some special conditions (custom device node used, administrative load) this value is used as an array index after bounds checking, but without speculation barrier. Add the missing array_index_nospec() call to prevent speculative execution where this domain value is used.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74483", "url": "https://ubuntu.com/security/CVE-2026-74483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't leak the user namespace when the mount fails bm_get_tree() takes a reference to the user namespace and hands it to get_tree_keyed() as the sget key. sget_fc() moves that reference into sb->s_fs_info and clears fc->s_fs_info, so from that point on the superblock owns it and bm_free() doesn't see it anymore. The superblock drops it in ->put_super(). But generic_shutdown_super() only calls ->put_super() from inside the if (sb->s_root) branch, so nothing releases it when bm_fill_super() fails: - The kzalloc_obj() failure leaves s_root NULL and the whole branch is skipped. - A simple_fill_super() failure in the file loop leaves s_root set, but s_op still points at simple_super_operations, which has no ->put_super(). bm_fill_super() installs s_ops only once simple_fill_super() returned success, and installing it earlier wouldn't help either because simple_fill_super() overwrites s_op. Either way vfs_get_super() calls deactivate_locked_super() and the reference is gone for good. binfmt_misc mounts are available in a user namespace and both the inode and the dentry cache are SLAB_ACCOUNT, so an unprivileged caller under a tight memory cgroup can fail simple_fill_super() on demand and leak one user namespace per attempt. Drop the reference in ->kill_sb() instead, which runs unconditionally, the same way nfsd and rpc_pipefs release their keyed s_fs_info. That also stops ->put_super() from clearing s_fs_info while the superblock is still on @fs_supers. generic_shutdown_super() leaves it there on purpose so that sget_fc() keeps finding it until kill_sb() has run, but a NULL s_fs_info makes test_keyed_super() miss it, so a concurrent mount for the same user namespace skips the grab_super() wait and creates a second superblock for a namespace that is still being torn down.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74496", "url": "https://ubuntu.com/security/CVE-2026-74496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Fix use-after-free in fou_create() fou_create() publishes struct fou through sk_user_data before adding the new FOU port to the per-netns list. If fou_add_to_port_list() fails, the error path frees fou while it is still reachable through sk_user_data. A concurrent receive can then dereference the freed object in fou_from_sock(). This ordering issue was previously noted in the linked discussion. The failure is reachable when local port 0 is requested. Each socket binds to a different ephemeral port, but fou_cfg_cmp() compares the requested port 0 and reports -EALREADY once an entry already exists. Release the tunnel socket before freeing fou so sk_user_data is cleared first, and defer reclamation with kfree_rcu() to protect concurrent RCU readers. This matches the lifetime handling in fou_release().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74517", "url": "https://ubuntu.com/security/CVE-2026-74517", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUs Cancel (and flush) the I/O APIC's delayed EOI handling work during the \"pre VM destroy\" phase, before vCPUs are destroyed, as processing the EOI broadcast will inject another IRQ if the line is asserted, i.e. will try to deliver an IRQ to the target vCPU(s). Canceling the work after vCPUs are destroyed leads to UAF if the delayed work is processed after vCPUs are destroyed. BUG: KASAN: slab-use-after-free in __kvm_irq_delivery_to_apic_fast+0x9bf/0xa20 arch/x86/kvm/lapic.c:1250 Read of size 8 at addr ffff8880499abea0 by task kworker/1:2/1218 CPU: 1 UID: 0 PID: 1218 Comm: kworker/1:2 Not tainted 7.1.0-rc7 #5 PREEMPT(lazy) Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: events kvm_ioapic_eoi_inject_work Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 __kvm_irq_delivery_to_apic_fast+0x9bf/0xa20 arch/x86/kvm/lapic.c:1250 __kvm_irq_delivery_to_apic+0xd8/0xbf0 arch/x86/kvm/lapic.c:1345 kvm_irq_delivery_to_apic arch/x86/kvm/lapic.h:129 ioapic_service+0x308/0x590 arch/x86/kvm/ioapic.c:492 kvm_ioapic_eoi_inject_work+0x13c/0x190 arch/x86/kvm/ioapic.c:532 process_one_work+0xa59/0x19a0 kernel/workqueue.c:3314 process_scheduled_works kernel/workqueue.c:3397 worker_thread+0x5eb/0xe50 kernel/workqueue.c:3478 kthread+0x370/0x450 kernel/kthread.c:436 ret_from_fork+0x72b/0xd30 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Note, the VM is unreachable once kvm_destroy_vm() starts, and scheduling new work via kvm_ioapic_send_eoi() can only be done via KVM_RUN, i.e. requires a live vCPU. Alternatively, KVM could simply destroy the I/O APIC during the \"pre\" phase of VM destruction, but that gets more than a bit sketchy as KVM expects the I/O APIC to exist if ioapic_in_kernel() is true, and nested virtualization in particular has a bad habit of touching VM-scope state during vCPU destruction. E.g. attempting to free the PIC during the pre phase would lead to a NULL pointer dereference in kvm_cpu_has_extint(), and it's not hard to imagine the I/O APIC having a similar flaw.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74521", "url": "https://ubuntu.com/security/CVE-2026-74521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use memcmp() to compare ClientGUIDs ClientGUID is a fixed-size binary value and can contain embedded NUL bytes. strncmp() stops comparing at the first NUL byte, so different ClientGUID values can incorrectly be treated as equal. Use memcmp() in SMB3 multichannel session binding and FSCTL_VALIDATE_NEGOTIATE_INFO to compare all SMB2_CLIENT_GUID_SIZE bytes.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74526", "url": "https://ubuntu.com/security/CVE-2026-74526", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix potential deadlock in mpi3mr_fault_uevent_emit mpi3mr_fault_uevent_emit() runs from the fault watchdog and reset paths where host I/O may already be blocked. GFP_KERNEL allocations here, both the local kzalloc_obj() and the ones inside kobject_uevent_env() itself, can trigger reclaim that waits on that blocked I/O and deadlock. Use memalloc_noio_save()/restore() to cover the whole call instead of just the local allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74528", "url": "https://ubuntu.com/security/CVE-2026-74528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold conn in hci_past_sync() callback Avoids giving freed pointers to hci_conn_valid(), which kmalloc may have reused. Hold refcount to avoid that.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74529", "url": "https://ubuntu.com/security/CVE-2026-74529", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold conn in hci_connect_pa_sync() callback There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74530", "url": "https://ubuntu.com/security/CVE-2026-74530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that. Handle NULL hcon, return 0 + do nothing to match the previous behavior.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74533", "url": "https://ubuntu.com/security/CVE-2026-74533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix race of kfree vs kref_get_unless_zero hci_conn::iso_data is accessed and modified without lock or RCU. This leads to a race [Task hdev->workqueue] \t[Task 2] iso_recv iso_conn_put(conn) conn = LOAD hcon->iso_data iso_conn_free(conn) iso_conn_hold_unless_zero(conn) hcon->iso_data = NULL kfree(conn) kref_get_unless_zero(&conn->ref) /* UAF */ and also to races in iso_conn_add() vs. iso_conn_free(). Fix by adding spinlock hci_conn::proto_lock and using it to guard hci_conn::iso_data.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74542", "url": "https://ubuntu.com/security/CVE-2026-74542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix folio_queue ENOMEM in writeback by adding a mempool Fix the handling of folio_queue allocation failure in writeback by adding a mempool and passing in gfp_t flags to the rolling buffer functions that allocate memory, using the mempool if gfp != GFP_KERNEL. This is then extended upwards and the gfp to be used for a request is stored in the netfs_io_request struct and is then used for both requests and subrequests, eliminating the sleeping loops there. The failure caused: folio != NULL WARNING: fs/netfs/write_issue.c:603 at netfs_writepages+0x883/0xa10 fs/netfs/write_issue.c:603, CPU#3: syz.0.17/5919", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74544", "url": "https://ubuntu.com/security/CVE-2026-74544", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: validate offshift to prevent shift-out-of-bounds u32_change() copies the user-provided tc_u32_sel.offshift (unsigned char, 0-255) into the kernel knode object without bounds validation. When a packet later hits u32_classify() with TC_U32_VAROFFSET set, it evaluates `ntohs(offmask & *data) >> offshift` where the left operand is a 16-bit value promoted to a 32-bit int. Any offshift >= 32 is undefined behavior per C11 6.5.7p3, triggerable by an unprivileged user via user/network namespaces. UBSAN: shift-out-of-bounds in net/sched/cls_u32.c:236:43 shift exponent 32 is too large for 32-bit type int Fix this by rejecting offshift >= 16 during filter creation in u32_change().", "cve_priority": "negligible", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74554", "url": "https://ubuntu.com/security/CVE-2026-74554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix out-of-bounds clear_bit in ath12k_mac_dp_peer_cleanup() ath12k_mac_dp_peer_cleanup() clears the ML peer ID slot on the free_ml_peer_id_map bitmap by indexing it with dp_peer->peer_id. That is wrong: dp_peer->peer_id for an MLO peer always carries the ATH12K_PEER_ML_ID_VALID bit (BIT(13)), so clear_bit() is invoked with index >= 0x2000, which is far outside the bitmap of ATH12K_MAX_MLO_PEERS (256) bits and corrupts memory adjacent to ah->free_ml_peer_id_map. The intended bitmap entry also never gets cleared, so subsequent ath12k_peer_ml_alloc() calls eventually run out of IDs. The ID without the VALID bit is what ath12k_peer_ml_alloc() returned and is stored in ahsta->ml_peer_id. Use that instead. While there, also reset ahsta->ml_peer_id to ATH12K_MLO_PEER_ID_INVALID so the bitmap and ahsta->ml_peer_id stay in sync. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3", "cve_priority": "low", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74558", "url": "https://ubuntu.com/security/CVE-2026-74558", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: reclaim invalid Tx descriptors in ZC batch path The zero-copy Tx batch parser stops when it encounters an invalid descriptor. If this happens after one or more continuation descriptors, the Tx consumer can be advanced past fragments that are neither submitted to the driver nor returned to userspace through the completion ring. A similar problem occurs when a packet exceeds xdp_zc_max_segs. The descriptors consumed up to the limit are released without completion, and the remaining continuation descriptors can subsequently be interpreted as the beginning of another packet. Parse Tx batches in packet units and distinguish descriptors belonging to complete valid packets from descriptors consumed while draining an invalid or oversized packet. Return the former to the driver and append the latter to the CQ address area so userspace can reclaim their UMEM frames. Treat a standalone invalid descriptor as a one-descriptor reclaim-only packet. Advancing the Tx-ring consumer releases the ring slot, but does not by itself return ownership of the referenced UMEM frame to userspace. Once draining starts, continue until the packet's end-of-packet descriptor is consumed. Preserve the drain state on the socket when EOP has not yet been supplied, so draining can continue during a later call. Leave incomplete but otherwise valid packets on the Tx ring. Shared-UMEM pools using multi-buffer Tx also need packet-framed parsing. Walk their Tx sockets one packet at a time, preserving the existing per-socket fairness scheme, instead of using the legacy one-descriptor fallback. Keep that fallback for shared pools that do not use multi-buffer Tx. Since the drain state is maintained per socket and both the singular and shared paths can resume an interrupted drain, changing the socket list from singular to shared requires no special bind-time transition. CQ entries are positional, and drivers may complete only part of the Tx work returned by xsk_tx_peek_release_desc_batch(). Therefore, reclaim-only entries cannot be published immediately when earlier driver-visible descriptors are still outstanding. Track the number of driver-visible CQ entries preceding the reclaim entries. Let xsk_tx_completed() publish partial hardware Tx completions, and publish the reclaim entries only after every earlier Tx descriptor has completed. Complete a reclaim-only batch immediately when there is no driver-visible work in front of it, and prevent another Tx batch from being appended while reclaim entries remain pending. Also cap batch processing by the size of the pool's temporary descriptor array, as Tx rings belonging to sockets sharing a UMEM may have different sizes. This ensures that every invalid Tx descriptor consumed by the ZC batch path is either submitted to the driver as part of a valid packet or returned to userspace without violating CQ completion ordering.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74561", "url": "https://ubuntu.com/security/CVE-2026-74561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: avoid unlocked f6i_list walk in nh_rt_cache_flush nh_rt_cache_flush() walks nh->f6i_list during an RTNL-serialized nexthop replace without holding nh->lock, racing the unlocked IPv6 route add/delete that mutate the list under nh->lock and free fib6_info entries (nh_rt_cache_flush() is inlined into rtm_new_nexthop()): BUG: KASAN: slab-use-after-free in nh_rt_cache_flush (net/ipv4/nexthop.c:2243) Read of size 8 at addr ffff888012953e18 by task exploit/146 nh_rt_cache_flush (net/ipv4/nexthop.c:2243) replace_nexthop (net/ipv4/nexthop.c:2610) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) Unlike the other f6i_list walks, this one bumps each route's sernum via fib6_update_sernum_upto_root(), which needs tb6_lock; taking nh->lock around it would invert the established tb6_lock -> nh->lock order and deadlock. As the only purpose is to invalidate cached dsts, bump the IPv6 sernum for the whole netns with rt_genid_bump_ipv6() instead, mirroring the rt_cache_flush() already done for IPv4 just above.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74562", "url": "https://ubuntu.com/security/CVE-2026-74562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: take nh->lock for f6i_list walks in replace check and notify fib6_check_nh_list() and __nexthop_replace_notify() walk nh->f6i_list during an RTNL-serialized nexthop replace without holding nh->lock. IPv6 RTM_NEWROUTE/RTM_DELROUTE run without RTNL and mutate that list under nh->lock (fib6_add_rt2node_nh(), fib6_purge_rt()), so both walks race a concurrent route delete that unlinks and frees a fib6_info: BUG: KASAN: slab-use-after-free in rt6_fill_node.isra.0 (net/ipv6/route.c:5799) Read of size 4 at addr ffff888014607e64 by task exploit/143 rt6_fill_node.isra.0 (net/ipv6/route.c:5799) fib6_rt_update (net/ipv6/route.c:6412) __nexthop_replace_notify (net/ipv4/nexthop.c:2542) rtm_new_nexthop (net/ipv4/nexthop.c:2554) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) BUG: KASAN: slab-use-after-free in fib6_check_nh_list (net/ipv4/nexthop.c:1605) Read of size 8 at addr ffff888014a7d068 by task exploit/142 fib6_check_nh_list (net/ipv4/nexthop.c:1605) rtm_new_nexthop (net/ipv4/nexthop.c:2575) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) Both walks only read the entries and take no tb6_lock, so protect them with nh->lock; fib6_rt_update() uses gfp_any(), which returns GFP_ATOMIC under the lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74571", "url": "https://ubuntu.com/security/CVE-2026-74571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: skip global block reserve accounting for rescue mounts [BUG] Mounting with rescue=ibadroots after corrupting the block group tree root triggers a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000100 RIP: 0010:btrfs_update_global_block_rsv+0x9d/0x1c0 [btrfs] Call Trace: fill_dummy_bgs+0xd4/0x120 [btrfs] open_ctree+0xc6e/0x1ca0 [btrfs] btrfs_get_tree+0x50d/0xa40 [btrfs] The same crash occurs with a corrupted raid stripe tree root, via btrfs_read_block_groups() instead of fill_dummy_bgs(). [CAUSE] With rescue=ibadroots, btrfs_read_roots() allows the mount to continue when either root cannot be read, leaving the corresponding root pointer NULL while its on-disk feature bit remains set. btrfs_update_global_block_rsv() then dereferences the missing root based on the feature bit alone. [FIX] Rescue mounts are fully read-only and cannot start transactions, so the global reserve is never consumed. Under btrfs_is_full_ro(), mark the reserve as full and return before performing the accounting. And since we need to check if the fs is mount fully RO, export fs_is_full_ro() as btrfs_is_full_ro(), and move it to fs.h. [ Squash the fs_is_full_ro() export commit into this one. ]", "cve_priority": "low", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74440", "url": "https://ubuntu.com/security/CVE-2026-74440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Wait on external BO kernel fences in exec IOCTL Before arming a user job, xe_exec_ioctl() only added the VM's dma-resv KERNEL slot as a dependency. That slot covers rebinds and the kernel operations of the VM's private BOs, but not external BOs (bo->vm == NULL), which carry their kernel operations (evictions, moves, ...) in their own dma-resv KERNEL slot. The DMA_RESV_USAGE_KERNEL slot is the cross-driver contract for memory management operations that must complete before the BO or its backing store may be used: any accessor is required to wait on the KERNEL fences before touching the resv. By skipping the external BOs' KERNEL slots, the exec path violated that contract and could schedule a user job while a kernel operation on an external BO mapped by the VM was still in flight, racing against it and potentially reading or writing memory that was being moved. Replace the VM-only dependency with an iteration over every object locked by the exec, adding each object's KERNEL slot as a job dependency. This covers the VM resv (rebinds and private BOs) as well as every external BO, mirroring the drm_gpuvm_resv_add_fence() call that later publishes the job fence to the same set of objects. Long-running mode continues to skip this, as before. (cherry picked from commit a6b842acf3ddd1efc53a56de9260cfa718fb35e7)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74441", "url": "https://ubuntu.com/security/CVE-2026-74441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Fix race condition and ordering in port unregistration A synchronization issue exists during port unregistration where pending partner work items can race against workqueue destruction, leading to use-after-free conditions: cros_ec_ucsi cros_ec_ucsi.3.auto: error -ETIMEDOUT: PPM init failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:__queue_work+0x83/0x4a0 Call Trace: __cfi_delayed_work_timer_fn+0x10/0x10 run_timer_softirq+0x3b6/0xbd0 sched_clock_cpu+0xc/0x110 irq_exit_rcu+0x18d/0x330 fred_sysvec_apic_timer_interrupt+0x5e/0x80 Fix this by ensuring strict ordering and proper serialization during teardown: 1. Move ucsi_unregister_partner() to the beginning of the teardown sequence and protect it under the connector mutex lock. 2. Ensure all pending partner tasks are explicitly flushed and finished before the workqueue is destroyed. 3. Switch from mod_delayed_work() to a cancel_delayed_work() and queue_delayed_work() sequence. This guarantees that items currently marked as pending won't be scheduled an additional time, preventing a double release of resources which leads to the following crash: Oops: general protection fault, probably for non-canonical address 0xdead000000000122: 0000 [#1] SMP NOPTI Workqueue: cros_ec_ucsi.3.auto-con2 ucsi_poll_worker RIP: 0010:ucsi_poll_worker+0x65/0x1e0 Call Trace: process_scheduled_works+0x218/0x6d0 worker_thread+0x188/0x3f0 __cfi_worker_thread+0x10/0x10 kthread+0x226/0x2a0 To ensure these rules are applied identically across both the normal teardown and the ucsi_init() error paths, consolidate the cleanup logic into a new helper, ucsi_unregister_port().", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74482", "url": "https://ubuntu.com/security/CVE-2026-74482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios __folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed. Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure() passes when splitting a poisoned tail of a shmem THP that reaches past i_size during truncation, it too is gone from the page cache; so once @folio is unlocked no locked, in-cache folio pins the inode, and a concurrent final iput() can evict and RCU-free it before i_mmap_unlock_read() touches i_mmap_rwsem: BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h:537 [inline] __folio_split+0x732/0x1640 mm/huge_memory.c:4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470 Freed by task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870 Do every mapping dereference while @folio still pins the inode: drop i_mmap_rwsem right after remap_page(), before the loop that unlocks and frees the after-split folios, and clear @mapping so the exit path does not unlock it again. shmem_uncharge() and remap_page() already run before that point, so after this nothing past the unlock loop touches the inode or the mapping. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74442", "url": "https://ubuntu.com/security/CVE-2026-74442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid destroy_workqueue(NULL) on vkms init failure Two paths through vmw_vkms_init() can leave vmw->crc_workq NULL while still leaving the rest of the driver in a state that calls vmw_vkms_cleanup() at module unload: 1. vmw_host_get_guestinfo(GUESTINFO_VBLANK, ...) failing or returning an oversized buffer -- the common case on hosts without a VBLANK guestinfo entry -- early-returned before the workqueue allocation. 2. alloc_ordered_workqueue() returning NULL on memory pressure. vmw_vkms_cleanup() then calls destroy_workqueue(NULL), which dereferences wq->name and panics. Fix the first case by removing the early return: vmw->vkms_enabled is already false on the rpci-failure path so no work will ever be queued, and allocating the workqueue unconditionally keeps the control flow simple. Fix the second case by guarding the cleanup with a NULL check, since alloc_ordered_workqueue() can still fail under low memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74443", "url": "https://ubuntu.com/security/CVE-2026-74443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: bound DMA command body size against suffix pointer vmw_cmd_dma() locates the DMA suffix at \t(unsigned long) &cmd->body + header->size - sizeof(*suffix) without checking that header->size is large enough to contain both cmd->body and the suffix. An undersized header makes the suffix pointer underflow back into the previous command in the bounce buffer. The verifier later writes suffix->maximumOffset, clobbering verified fields of an already-relocated earlier command -- a TOCTOU on the device-visible command stream that lets one command rewrite another's GMR id, surface id, or other authenticated fields. Reject the command if the body is too small for the suffix to fit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74444", "url": "https://ubuntu.com/security/CVE-2026-74444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate DRAW_PRIMITIVES header size before division vmw_cmd_draw() computes \tmaxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl); where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory. Reject undersized headers up front.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74445", "url": "https://ubuntu.com/security/CVE-2026-74445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: reject DX_BIND_QUERY without a DX context vmw_cmd_dx_bind_query() unconditionally dereferences sw_context->dx_ctx_node->ctx. Userspace can trigger a NULL pointer dereference from any render-node fd by submitting an execbuf with dx_context_handle == SVGA3D_INVALID_ID and a SVGA_3D_CMD_DX_BIND_QUERY opcode in the command stream: dx_ctx_node is left NULL and the kernel oopses on the assignment. The same NULL is then re-read in vmw_resources_reserve() via vmw_context_get_dx_query_mob(). All sibling DX handlers fail-close on a missing dx_ctx_node using VMW_GET_CTX_NODE(). Use the same pattern here, returning -EINVAL up front before any relocation state is published.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74446", "url": "https://ubuntu.com/security/CVE-2026-74446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: hold event_mutex while checkpointing CRIU events kfd_criu_checkpoint_events() counts the entries in p->event_idr via kfd_get_num_events(), allocates an array sized to that count, and then walks the same IDR to fill it. Neither the count nor the walk holds p->event_mutex. The CRIU checkpoint caller holds only p->mutex. Event create and destroy (kfd_event_create()/kfd_event_destroy()) take p->event_mutex and do not take p->mutex, so a second thread in the same process can insert or remove events between the count and the walk. If an event is inserted, the walk iterates more entries than were counted and writes past the end of the ev_privs allocation; if an event is removed, the walk dereferences an entry that is being freed. Hold p->event_mutex across the count and the walk so both observe a consistent view of p->event_idr. The lock is released before copy_to_user(), which only touches the local buffer. The caller already holds p->mutex and the create/destroy paths never take p->mutex, so the p->mutex -> p->event_mutex order is not inverted and no deadlock is introduced. (cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa)", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74447", "url": "https://ubuntu.com/security/CVE-2026-74447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix uint32_t overflow in EOP ring buffer size alignment eop_ring_buffer_size in struct queue_properties is a u32. In kfd_queue_acquire_buffers() the expected EOP buffer size is computed as ALIGN(eop_ring_buffer_size, PAGE_SIZE); ALIGN uses typeof(x), so the addition is done in 32-bit. A user-supplied size of 0xFFFFF001 wraps to 0, causing kfd_queue_buffer_get() to skip its exact-size check (gated on size != 0) and accept any BO mapped at the address. On GFX8/GFX9 the MQD cp_hqd_eop_control is then programmed for an 8KB EOP ring backed by a 4KB BO, so CP EOP writes can land past the buffer and fault the GPU. Cast the operand to u64 so the alignment is computed in 64-bit; the size check in kfd_queue_buffer_get() then rejects the oversized request. (cherry picked from commit ae443117b742c357bfef3a7bddabf76fcf86e9ef)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74448", "url": "https://ubuntu.com/security/CVE-2026-74448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix QID bit leak in pqm_create_queue() When MES is enabled and amdgpu_amdkfd_alloc_kernel_mem() fails during the first queue creation for a process, pqm_create_queue() returns early via 'return retval' without going through the err_create_queue cleanup label. This means clear_bit(*qid, pqm->queue_slot_bitmap) is never called, leaving the reserved QID bit permanently set in queue_slot_bitmap. Over time this leaks QID slots, potentially exhausting all available queue slots. Fix this by replacing 'return retval' with 'goto err_allocate_pqn' so that clear_bit() is always called on the error path without touching the uninitialized pqn pointer. AILIKFD-813 (cherry picked from commit a107f74c38edbb80d6ab64dcaeeb292c14e9779f)", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74451", "url": "https://ubuntu.com/security/CVE-2026-74451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: validate firmware interface structure sizes iface_fw_to_cpu_addr() only checks that the firmware-provided MCU virtual address points inside the shared section. The returned pointer is later used as a full firmware interface structure, so accepting an address near the end of the shared section can still lead to out-of-bounds accesses. Pass the expected object size to iface_fw_to_cpu_addr() and reject ranges that do not fit entirely in the shared section.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74452", "url": "https://ubuntu.com/security/CVE-2026-74452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: reject firmware sections with oversized data In panthor_fw_load_section_entry(), the data size to copy is calculated without validating it against the allocated section_size: section->data.size = hdr.data.end - hdr.data.start; If a crafted firmware sets data.size larger than the allocated memory, this could cause a heap buffer overflow in panthor_fw_init_section_mem() memcpy(section->mem->kmap, section->data.buf, section->data.size); Additionally, if the section->data.size exceeds the BO size, could this memset underflow the size calculation, leading to a massive out-of-bounds zeroing of kernel memory? memset(section->mem->kmap + section->data.size, 0, panthor_kernel_bo_size(section->mem) - section->data.size); Reject section entries whose initial data is larger than the section size.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74453", "url": "https://ubuntu.com/security/CVE-2026-74453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Zero the tile state data array before each BIN job The binner BO is a single 16MB buffer split into 512KB slots that are handed out to jobs at submission time and recycled as jobs complete, without ever being cleared. Each slot holds the job's Tile State Data Array (TSDA) at its start, followed by the tile allocation pool. While the tile allocation pool is only walked by the render thread through branches the binner generated during the current job, the TSDA is the PTB's own per-tile bookkeeping and is consumed by the hardware itself. Although the kernel sets the \"Auto-initialise Tile State Data Array\" flag in the tile binning mode configuration, the PTB demonstrably still acts on stale tile state left by the slot's previous user: the binner ends up creating invalid command streams with invalid primitive streams and branches, which can cause GPU hangs as observed in [1][2]. Zero the TSDA when the job's binning slot is configured. This clears 48 bytes per tile (~24KB for a 1080p frame) in the submission path, and guarantees the PTB never sees another job's tile state. The tile count is only checked for being non-zero today, so the 8-bit fields it comes from can describe a tile state array almost six times larger than the slot it has to live in. Bound it before the slot is handed out, since such size decides how much of the slot is left for the tile alloc pool.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74454", "url": "https://ubuntu.com/security/CVE-2026-74454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Supply the overflow slot size in BPOS, not the whole bin BO size vc4_overflow_mem_work() points BPOA at a 512KB slot inside the 16MB binner BO, but writes the size of the whole BO to BPOS. On every binner out-of-memory event the PTB is therefore authorized to write tile lists across all the other slots (which may hold the tile state, tile alloc and overflow memory of in-flight jobs) and, for any slot but the first, past the end of the binner BO into unrelated CMA memory. Since CMA pages are recycled into page cache and user allocations, this is arbitrary memory corruption by GPU DMA. In practice it shows up as GPU hangs with corrupted control list pointers, userspace heap corruption, a GPU that stays permanently wedged after the first hang, and occasional full system crashes, whenever a job overflows the initial binner slot. The bug dates back to the conversion from a dedicated overflow BO (where writing the full BO size was correct) to the slotted binner BO.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74455", "url": "https://ubuntu.com/security/CVE-2026-74455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: validate uCAN receive record lengths pcan_usb_fd_decode_buf() walks uCAN records packed in one USB receive buffer. Require each record to contain the fixed header for its type, and verify CAN payload bytes before copying them into the skb.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74456", "url": "https://ubuntu.com/security/CVE-2026-74456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc() and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also frees the transfer buffer. If usb_submit_urb() fails, the error path frees the buffer explicitly with kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set, usb_free_urb() -> urb_destroy() frees the same buffer a second time, a double free of the transfer buffer. BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0 Free of addr ffff8881069ccb80 by task trigger.sh/285 Call Trace: kfree+0x113/0x3c0 usb_free_urb.part.0+0x91/0xb0 Drop the redundant kfree(buf); usb_free_urb() already releases the transfer buffer. This mirrors commit 03819abbeb11 (\"net: usb: lan78xx: Fix double free issue with interrupt buffer allocation\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74457", "url": "https://ubuntu.com/security/CVE-2026-74457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: add bounds check for USB channel index The channel control index ctrl_idx is derived from rx->len which comes directly from a device USB payload. The mask 0x0f allows values 0-15, but the array size of usb_if->dev[] is only 2. Values 2-15 cause heap out-of-bounds read, eventually causing kernel panic in the IRQ context. Add bounds checking for ctrl_idx before the array access in both pcan_usb_pro_handle_canmsg() and pcan_usb_pro_handle_error().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74458", "url": "https://ubuntu.com/security/CVE-2026-74458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents The wait and bulk receive paths walk variable-length commands from a USB buffer. A nonzero command shorter than CMD_HEADER_LEN can still be dispatched, and the wait path copies a matching command into a fixed caller-owned struct kvaser_cmd using the device-provided length. Reject nonzero commands that do not contain the fixed header or that extend beyond the current USB buffer item. In the wait path, also reject a matching command that exceeds the destination before copying it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74459", "url": "https://ubuntu.com/security/CVE-2026-74459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure es58x_read_bulk_callback() resubmits the RX URB after processing a received packet. If the resubmit succeeds, the URB remains anchored and will be handled by the normal RX path or by teardown. However, if usb_submit_urb() fails, the callback unanchors the URB and then returns directly. This skips the existing free_urb path, so the coherent transfer buffer allocated with usb_alloc_coherent() is not released. Reuse the existing free_urb path after a resubmit failure so that the RX coherent buffer is freed before leaving the callback.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74460", "url": "https://ubuntu.com/security/CVE-2026-74460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: validate CPC message lengths ems_usb_read_bulk_callback() walks CPC messages packed in one USB receive buffer. Check that each declared message fits in the URB payload. Also require the type-specific payload to cover the fields used by the CAN, state, error and overrun handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74461", "url": "https://ubuntu.com/security/CVE-2026-74461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: Cancel hrtimer before clearing slave pointer In i2c_imx_unreg_slave(), the slave pointer is set to NULL after disabling interrupts. However, a pending interrupt might already have started the hrtimer (i2c_imx_slave_timeout) before the pointer was cleared. If the hrtimer fires after i2c_imx->slave is set to NULL, the timer callback i2c_imx_slave_finish_op() will call i2c_imx_slave_event() with a NULL slave pointer, which results in a use-after-free / NULL pointer dereference. Fix by canceling the hrtimer and waiting for it to complete after disabling interrupts, before clearing the slave pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74462", "url": "https://ubuntu.com/security/CVE-2026-74462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: mark I2C adapter when hardware is powered down On some i.MX platforms, certain I2C client drivers keep a periodic workqueue which continues to trigger I2C transfers. During system suspend/resume, there exists a time window between: - suspend_noirq and the system entering suspend - the system starting to resume and resume_noirq In this window, the I2C controller resources such as clock and pinctrl may already be disabled or not yet restored. If a workqueue triggers an I2C transfer in this period, the driver attempts to access I2C registers while the hardware resources are unavailable, which may lead to system hang. Mark the I2C adapter as suspended during noirq suspend and block new transfers until resume, ensuring that I2C transfers are only issued when hardware resources are available.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74463", "url": "https://ubuntu.com/security/CVE-2026-74463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock Fix a severe AB/BA deadlock between the Common Clock Framework (CCF) and the I2C adapter lock, which triggers when an I2C-controlled clock generator client (like the Si5351) is registered or modified under the CCF. During an i2c client clock (generator) frequency change, the CCF acquires its global 'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's chip registers, stalling for the adapter's I2C bus lock. Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO expander handling LEDs) can hold the I2C adapter lock. Inside this parallel transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host controller's input clock to calculate bus timings. This call attempts to acquire the blocked CCF 'prepare_lock', creating a circular dependency that freezes the system. The jz4780 host controller clock itself is static and never changes at runtime. However, calling clk_get_rate() inside the active transfer path introduces an unnecessary dependency on the CCF internal locks. Eliminate this synchronous clk_get_rate() call from the active transfer path by caching the static host peripheral clock rate once - inside the private jz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed() to use this cached value, safely decoupling active I2C transactions from the CCF internal locks without any risk of stale timings. Assisted-by web based Google AI (pinpointing the bug and writing the message).", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74464", "url": "https://ubuntu.com/security/CVE-2026-74464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix skb leak on flow key update failure during ct ovs_ct_execute() always steals or frees the skb on failure while ovs_flow_key_update() does not. So, if it fails and we return right away, the skb ends up leaked. Fix that by breaking instead and letting the common error handling code at the bottom of the loop to free the skb properly. This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless. Reported by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74465", "url": "https://ubuntu.com/security/CVE-2026-74465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix potential UAF on meter attach failure While attaching a newly created meter attach_meter() function makes the new meter visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter) on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508 Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584) ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ... netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible until all the checks are done and the function can't fail anymore. This also makes sure the \"hash\" value is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-31642.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68451", "url": "https://ubuntu.com/security/CVE-2026-68451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA ECC private key requests cca_ecc2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "high", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-68452", "url": "https://ubuntu.com/security/CVE-2026-68452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA AES cipher key requests cca_cipher2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "medium", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-68453", "url": "https://ubuntu.com/security/CVE-2026-68453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix buffer over-read in cca_cipher2protkey Add validation of both the actual key buffer size and token length fields in all the cca_check_sec*token() functions. Additionally check in cca_gencipherkey() for possible underflow with returned key size. The CCA token structures contain user-controlled len fields that were used in operations without proper validation against both the actual buffer size and minimum token structure size. An attacker could set this field larger than the actual buffer size, leading to reading beyond buffer boundaries. This may result in a kernel crash or exposure of memory via sending this as part of a request down to the crypto card. Also an attacker could have used a very small len value and thus enforce a buffer under-run which may produce similar effects as a over-read. So now a key must - key buf length must be at least sizeof the token struct - the key len field inside the token must fit into the range of sizeof key token struct ... key buf length", "cve_priority": "medium", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-74467", "url": "https://ubuntu.com/security/CVE-2026-74467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/qeth: Check CAP_NET_ADMIN for private ioctls Gate the SIOCDEVPRIVATE ioctl commands SIOC_QETH_ADP_SET_SNMP_CONTROL, SIOC_QETH_GET_CARD_TYPE and SIOC_QETH_QUERY_OAT with CAP_NET_ADMIN capable check to ensure unprivileged users cannot invoke them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74468", "url": "https://ubuntu.com/security/CVE-2026-74468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: pch: use raw_spinlock_t for the register lock pch_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. This was confirmed on a PREEMPT_RT kernel with lockdep (PROVE_RAW_LOCK_NESTING and DEBUG_ATOMIC_SLEEP). A grounded PoC mirrored pch_irq_type()'s locking and drove it through the real genirq carrier irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), i.e. the same __irq_set_trigger() edge that __setup_irq() takes for a requested IRQ. With the original spin_lock_irqsave() edge lockdep reported an invalid wait context, immediately followed by: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro] __irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0 Switching the mirrored lock to raw_spinlock_t made both splats go away. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, but all of those critical sections only perform MMIO register accesses (ioread32()/iowrite32()) and irq_set_handler_locked(); none of them contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same class of issue and fix as recently addressed for other GPIO controllers, e.g. commit 286533cb14a3 (\"gpio: sch: use raw_spinlock_t in the irq startup path\") and commit 90f0109019e6 (\"gpio: eic-sprd: use raw_spinlock_t in the irq startup path\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74469", "url": "https://ubuntu.com/security/CVE-2026-74469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: prevent peer transport count overflow sctp_assoc_add_peer() increments the association's 16-bit transport_count for every new unique peer. Adding the 65,536th transport wraps the count to zero. SCTP sock_diag uses transport_count to reserve the INET_DIAG_PEERS payload, then copies one sockaddr_storage for every entry in transport_addr_list. After the wrap, a diagnostic dump reserves an empty payload and writes 8 MiB of peer addresses past the skb tail. Reject a new unique peer when transport_count has reached U16_MAX. Perform the check after the existing-peer lookup so a duplicate address continues to return its existing transport at the limit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74470", "url": "https://ubuntu.com/security/CVE-2026-74470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write resp_report_zones() sizes the reply buffer from the CDB allocation length. The v3 fix rounds alloc_len up with ALIGN() before deriving the descriptor count: \trep_max_zones = (ALIGN((u64)alloc_len, RZONES_DESC_HD) - \t\t\t RZONES_DESC_HD) >> ilog2(RZONES_DESC_HD); \tarr_len = (u64)RZONES_DESC_HD * (rep_max_zones + 1); For alloc_len in 0xFFFFFFC1..0xFFFFFFFF, ALIGN() rounds up to 0x100000000, so arr_len is 4 GB. On 32-bit, kzalloc()'s size_t is 32-bit and truncates 0x100000000 to 0; kzalloc(0) returns ZERO_SIZE_PTR, which passes the !arr check, and desc = arr + 64 is then dereferenced in the loop -> out-of-bounds write / panic. Clamp rep_max_zones to devip->nr_zones. The loop already stops at sdebug_capacity (after nr_zones zones), so a report can never hold more than nr_zones descriptors; the clamp does not change the report, it only bounds arr_len to (nr_zones + 1) * RZONES_DESC_HD, a real device property that can never reach 0x100000000.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74471", "url": "https://ubuntu.com/security/CVE-2026-74471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Check return value of __register_event() in trace_module_add_events() trace_module_add_events() ignores the return value of __register_event() and unconditionally calls __add_event_to_tracers() for each event. If __register_event() fails (for example, if event_init() fails), the trace_event_call is not added to ftrace_events list, but __add_event_to_tracers() still creates a trace_event_file pointing to it. If module loading subsequently fails and module memory is freed, tracing state retains a stale trace_event_call pointer in trace_event_file, leading to a use-after-free when tracefs or tracing subsystem operations are later executed. Fix this by checking the return value of __register_event() and only calling __add_event_to_tracers() if event registration succeeded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74472", "url": "https://ubuntu.com/security/CVE-2026-74472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: reset kernel-owned dev_info fields in ublk_ctrl_add_dev() ublk_ctrl_add_dev() memcpy()s the userspace ublksrv_ctrl_dev_info into ub->dev_info and then fixes up the fields the driver owns, but misses ->state and ->ublksrv_pid. A device added with ->state = UBLK_S_DEV_LIVE passes the \"->state != UBLK_S_DEV_DEAD\" test that ublk_stop_dev_unlocked() uses as its proxy for \"a disk is attached\", while ->ub_disk is still NULL, so DEL_DEV right after ADD_DEV oopses in del_gendisk(). UBLK_S_DEV_QUIESCED plus UBLK_F_USER_RECOVERY dies one step earlier, in ublk_force_abort_dev(). A poisoned ->state also gets START_USER_RECOVERY and the char device read/write path onto a device that was never started, and wedges START_DEV at -EEXIST. A poisoned ->ublksrv_pid just makes GET_DEV_INFO report an unrelated task as the ublk server. Reset both after the memcpy(), as ublk_detach_disk() does. Userspace only ever reads these back, so correcting them silently breaks nothing. ADD_DEV has copied ->state in unsanitized since ublk was merged, but back then it was harmless: the gendisk was allocated during ADD_DEV, and both teardown and the START_DEV -EEXIST check keyed off disk_live() rather than ->state. The oops became reachable once the disk allocation moved to START_DEV and those checks switched to ->state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74473", "url": "https://ubuntu.com/security/CVE-2026-74473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use pskb_network_may_pull() in route_shortcircuit() route_shortcircuit() currently calls pskb_may_pull(skb, sizeof(struct iphdr)) (or ipv6hdr), which checks if bytes are available starting from skb->data. However, in vxlan_xmit(), skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, 20) only checks 20 bytes from skb->data (which is 14 bytes MAC header + 6 bytes of IP header), leaving the rest of the IP header potentially un-pulled in non-linear frags. Subsequent dereferences of ip_hdr(skb)->daddr can read beyond the pulled linear buffer length. Fix this by using pskb_network_may_pull(), which adds skb_network_offset(skb) to the length check to ensure the full network header is present in the linear buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74474", "url": "https://ubuntu.com/security/CVE-2026-74474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use pskb_network_may_pull() for transmit path header pulls In vxlan_xmit(), arp_reduce(), and vxlan_mdb_entry_skb_get(), pskb_may_pull() was being called to verify the availability of network layer headers (ARP, IPv6/ND, IP/IPv6 MDB keys). However, during transmit skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, len) only checks len bytes from skb->data rather than skb_network_offset(skb) + len, which can leave part of the network header in non-linear frags. Replace these remaining pskb_may_pull() calls with pskb_network_may_pull() to properly account for the MAC header offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74475", "url": "https://ubuntu.com/security/CVE-2026-74475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use neigh_ha_snapshot() in route_shortcircuit() The neighbour hardware address n->ha can be updated asynchronously by the neighbour subsystem, protected by n->ha_lock seqlock. Reading n->ha without holding the seqlock loop can lead to torn reads or reading a partially updated MAC address. Use neigh_ha_snapshot() in route_shortcircuit() to safely copy n->ha under read_seqbegin()/read_seqretry() lock protection before using it. Note that arp_reduce() and neigh_reduce() seem to have the same issue left for future patches.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74476", "url": "https://ubuntu.com/security/CVE-2026-74476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: convert frag_list skbs before running XDP A frag_list skb can reach veth with data_len set but nr_frags zero. veth_convert_skb_to_xdp_buff() only converts skbs that are shared, locked, have frags[], or do not have enough headroom. It later uses skb_is_nonlinear() to decide whether to set XDP_FLAGS_HAS_FRAGS and xdp_frags_size. That exposes frag_list data to XDP as if it were stored in frags[], but frags[] is empty. AF_XDP copy mode can then trust the bogus XDP fragment metadata, walk an empty fragment entry, and crash in memcpy() from __xsk_rcv(). Route non-linear skbs through skb_pp_cow_data() before exposing them to XDP, and only advertise XDP frags when the resulting skb has frags[]. skb_copy_bits() already handles frag_list input, and skb_pp_cow_data() builds frags[] output with skb_add_rx_frag(), which is the representation XDP multi-buffer expects.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74477", "url": "https://ubuntu.com/security/CVE-2026-74477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: Fix NULL pointer dereference in hprobe_expire() Forking a task that has a pending uretprobe can oops the kernel with a NULL pointer dereference in the clone() path: BUG: kernel NULL pointer dereference, address: 0000000000000018 Oops: 0002 [#1] SMP NOPTI RIP: 0010:hprobe_expire CR2: 0000000000000018 Call Trace: uprobe_copy_process copy_process kernel_clone __x64_sys_clone do_syscall_64 entry_SYSCALL_64_after_hwframe This was found on real hosts on Meta fleet. I've got the impression that this is what is happening: CPU 1 CPU 2 (traced task) ----- ------------------- hit uprobe, prepare_uretprobe(): hprobe LEASED, refcount >= 1 uprobe_unregister() put_uprobe(): refcount -> 0 fork() -> dup_utask() hprobe_expire(hprobe, true) try_get_uprobe() -> NULL get_uprobe(NULL) <-- Oops Only take the extra reference when the uprobe is non-NULL; a NULL means it is gone and is the correct value to return.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74478", "url": "https://ubuntu.com/security/CVE-2026-74478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: vector: fix use-after-free in vector_mmsg_rx() When vector_mmsg_rx() discards a packet whose overlay header fails verify_header(), it frees the skb and continues the loop: \tif (header_check < 0) { \t\tdev_kfree_skb_irq(skb); \t\tvp->estats.rx_encaps_errors++; \t\tcontinue; \t} The normal and short-packet paths fall through to the bottom of the loop body, which clears the consumed slot and advances the cursors: \t(*skbuff_vector) = NULL; \tmmsg_vector++; \tskbuff_vector++; The verify_header() < 0 path skips that via continue, so the freed skb is left in skbuff_vector[] and the cursors do not advance. The next iteration reads the same slot, gets the freed skb, and frees it again, producing a refcount underflow / use-after-free in the RX path. Discard the slot the same way the other paths do before continuing. Only transports whose verify_header() can return negative are affected: GRE and L2TPv3 do so on a cookie/session-id mismatch (raw/tap do not), so any peer on such a transport can trigger it without authentication.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74479", "url": "https://ubuntu.com/security/CVE-2026-74479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: pktgen: fix proc entry use-after-free pktgen_change_name() replaces pkt_dev->entry while holding t->if_lock. pktgen_remove_device() removes the same entry before _rem_dev_from_if_list() takes that lock. This allows the following interleaving: CPU 0 (NETDEV_CHANGENAME) CPU 1 (kpktgend) if_lock(t) proc_remove(pkt_dev->entry) proc_remove(pkt_dev->entry) pkt_dev->entry = proc_create_data(...) if_unlock(t) The kthread can pass the stale proc_dir_entry to proc_remove() after the rename path has freed it. A reproducer with a widened race window reports: BUG: KASAN: slab-use-after-free in proc_remove+0x78/0x80 Read of size 8 at addr ffff8881478fea70 by task kpktgend_0/67 Call Trace: proc_remove+0x78/0x80 pktgen_remove_device.isra.0+0x11c/0x4c0 pktgen_thread_worker+0x1214/0x6bc0 kthread+0x2c6/0x3b0 Allocated by task 95: __proc_create+0x204/0x790 proc_create_data+0x72/0xe0 pktgen_thread_write+0xd61/0x1510 Freed by task 28: kmem_cache_free+0xcb/0x3d0 proc_free_inode+0x5b/0x80 rcu_core+0x50a/0x1850 The buggy address belongs to the object at ffff8881478fea00 which belongs to the cache proc_dir_entry of size 192 Move proc_remove() into the if_lock-protected list removal helper. Keep it before list_del_rcu() to preserve the ordering required by add_device(). The rename path must then finish replacing the entry before removal, or it observes that the device is no longer on the list.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74480", "url": "https://ubuntu.com/security/CVE-2026-74480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: stop fast-leave after deleting a port group br_multicast_leave_group() iterates mp->ports with pp = &p->next in its fast-leave path. After br_multicast_del_pg() removes p, continuing the loop advances pp through the deleted entry. If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, br_port_group_equal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group. Fast leave only needs to remove one matching port group. Break after br_multicast_del_pg() so the loop stops before dereferencing the removed entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74481", "url": "https://ubuntu.com/security/CVE-2026-74481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_reporting: use system_freezable_wq to fix UAF during suspend During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free / General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0 Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM during freeze without triggering unfrozen reporting work on deleted virtqueues. This aligns with the driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen by the PM core before this * function is called. */ Testing: I have verified these fixes using Google’s virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are no longer reproducible.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74484", "url": "https://ubuntu.com/security/CVE-2026-74484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't let an 'F' entry pin its own instance An entry registered with 'F' opens its interpreter at registration time and holds that file until the entry is freed. Any entry nobody removes by hand only gets closed once the binfmt_misc superblock is shut down. If the interpreter lives on a mount that keeps that superblock alive the two pin each other: binfmt_misc sb -> inode -> entry -> interp_file -> vfsmount -> binfmt_misc sb TL;DR the file is never closed. Once the mount namespace is gone there is nothing left to unregister through either. There are two ways to trigger this bug: - Point the interpreter at the instance itself. Its files are regular files owned by the mounter and both bm_get_inode() and simple_fill_super() leave i_op at empty_iops. So notify_change() falls back to simple_setattr() and chmod +x works. We never set SB_I_NOEXEC and so open_exec() accepts it. - Use the instance as an overlayfs lower layer. The overlay superblock holds a clone_private_mount() of every layer until it is destroyed and that clone is in no namespace. So umount_tree() never reaches it. That's a DoS. And it isn't only the superblock that leaks. It pins the user namespace it was mounted in, so every iteration permanently eats one of the caller's user namespace charges. So let's just do the sane thing. SB_I_NOEXEC makes open_exec() fail on the instance's own files and s_stack_depth makes overlayfs reject the layer before it ever takes a clone. That also covers the ecryptfs and fuse passthrough variants. What 'F' promises is unchanged. The stable tag is narrower than the Fixes tags on purpose. Before sandboxed mounts this needed global root against the single instance everyone shares, and the change doesn't apply to those trees anyway. Note that SB_I_NODEV is implicitly raised for userns mounts but raise it explicitly here as well.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74485", "url": "https://ubuntu.com/security/CVE-2026-74485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: reject a flag character as the field delimiter The registration string starts with a user chosen delimiter that separates the individual fields. So that the field parsers terminate even on a truncated string create_entry() pads the buffer with that same delimiter: \tmemset(buf + count, del, 8); Most fields are scanned for the delimiter with strchr()/scanarg() and happily stop on the padding. The flags field is different: instead of scanning for the delimiter check_special_flags() consumes the flag characters 'P', 'O', 'C' and 'F' and stops at the first byte that is none of them, relying on the trailing delimiter to end the scan. If the delimiter is itself a flag character the padding no longer acts as a terminator. The scan swallows all eight padding bytes and keeps reading past the end of the allocation until it hits a byte that is not a flag character. For example registering \tPaPEPPxPPiP with 'P' as the delimiter (name \"a\", type extension, magic \"x\", interpreter \"i\", empty flags) leaves the flag scan running off the end of the buffer. The registration is rejected in the end because the parser does not stop exactly at buf + count, but only after the out of bounds read has already happened. With an unlucky allocation layout the scan can walk into an unmapped page; under KASAN it is reported as a slab out of bounds read. binfmt_misc mounts are available to unprivileged users in a user namespace so the read is reachable without privileges. Reject a delimiter that is one of the flag characters up front. Such a registration was always rejected anyway, only after the out of bounds read, so no valid registration string changes meaning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74486", "url": "https://ubuntu.com/security/CVE-2026-74486", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: use exe_file_deny_write_access() for the interpreter clone For MISC_FMT_OPEN_FILE entries load_misc_binary() clones the registered interpreter file and denies write access to the clone via plain deny_write_access(). The clone is installed as bprm->interpreter and later released by the exec machinery through exe_file_allow_write_access() which skips the i_writecount increment for files with FMODE_FSNOTIFY_HSM set. The deny and allow side can therefore come to different conclusions when pre-content watches are in play: if a pre-content watch is added to the interpreter after registration every subsequent exec through that entry takes a write denial on the clone that is never paired with a write allowance, driving the interpreter inode's i_writecount further down with each exec and leaving the interpreter unwritable even after the entry and all its users are gone. Take the write denial via exe_file_deny_write_access() so both sides of the pairing base their decision on the same file mode, and propagate failure instead of silently ignoring it: an interpreter that is concurrently open for writing now fails the exec with ETXTBSY, exactly like an interpreter freshly opened via open_exec() would.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74487", "url": "https://ubuntu.com/security/CVE-2026-74487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: restore write access when removing an entry Registering an entry with the MISC_FMT_OPEN_FILE flag opens the interpreter via open_exec() which denies write access to it for as long as the entry exists. Removing the entry closes the interpreter file via filp_close() but never restores write access, leaving the inode's i_writecount permanently negative. Opening the interpreter for writing keeps failing with ETXTBSY long after the entry is gone until the inode is evicted from the inode cache. Commit 90f601b497d7 (\"binfmt_misc: restore write access before closing files opened by open_exec()\") fixed the same imbalance in the error path of bm_register_write() but the actual removal path has been leaking the write denial since the introduction of the flag. Restore write access in put_binfmt_handler() before closing the interpreter file.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74488", "url": "https://ubuntu.com/security/CVE-2026-74488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames mwifiex_11n_dispatch_amsdu_pkt() splits an A-MSDU with ieee80211_amsdu_to_8023s() and walks the resulting subframes. For each subframe it passes the subframe data pointer to mwifiex_process_tdls_action_frame(), but pairs it with skb->len, the length of the A-MSDU parent, instead of rx_skb->len: \trx_skb = __skb_dequeue(&list); \trx_hdr = (struct rx_packet_hdr *)rx_skb->data; \tif (ISSUPP_TDLS_ENABLED(priv->adapter->fw_cap_info) && \t ntohs(rx_hdr->eth803_hdr.h_proto) == ETH_P_TDLS) { \t\tmwifiex_process_tdls_action_frame(priv, (u8 *)rx_hdr, \t\t\t\t\t\t skb->len); \t} The parent is not a valid description of that buffer, and may not be valid memory at all. ieee80211_amsdu_to_8023s() ends with \tif (!reuse_skb) \t\tdev_kfree_skb(skb); and it only sets reuse_skb when the parent is linear, is not a head_frag, and is being consumed as the *last* subframe. So when the parent does not qualify for reuse it has already been freed, and the read of skb->len is a use-after-free. When it is reused, skb->len is the length of the last subframe, applied to every earlier subframe, which over-states the buffer whenever an earlier subframe is shorter. The callee cannot absorb a wrong length, because it derives its own ceiling from the value it is given. Each frame type computes \ties_len = len - sizeof(struct ethhdr) - TDLS_*_FIX_LEN; and the element walk is then bounded entirely against that ceiling, \tfor (end = pos + ies_len; pos + 1 < end; pos += 2 + pos[1]) { \t\tu8 ie_len = pos[1]; \t\tif (pos + 2 + ie_len > end) \t\t\tbreak; so a too-large len moves end past the end of the subframe and the walk reads and copies beyond it. The A-MSDU layout is chosen by the sender, which makes the difference between the last subframe and a shorter earlier one remotely selectable. Reaching this requires TDLS support in firmware and the TDLS ethertype on the subframe. The other caller, mwifiex_process_rx_packet(), is correct: it passes a pointer and a length that describe the same region of the RX buffer. Pass rx_skb->len, the length of the subframe actually being parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74490", "url": "https://ubuntu.com/security/CVE-2026-74490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: avoid use-after-free in poll trace queue dumps TIPC socket tracepoints dump queue state through tipc_sk_dump(). Most queue-dump callsites already serialize that walk under the socket lock or sk->sk_lock.slock, but tipc_poll() calls trace_tipc_sk_poll(..., TIPC_DUMP_ALL, ...) without holding either lock. That lets the poll trace path reach tipc_list_dump() and backlog head/tail dumping while another context dequeues and frees an skb, leaving the trace helper dereferencing a stale queue entry. Stop the unlocked poll trace site from requesting queue dumps. Other queue dump trace callsites keep their existing output under the locking they already provide, while poll still emits the event itself without walking live queue members from an unlocked context.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74491", "url": "https://ubuntu.com/security/CVE-2026-74491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: of/address: Fix NULL bus dereference in of_pci_range_parser_one() The bus matching rework made of_match_bus() return NULL for nodes with ranges/dma-ranges but no local #address-cells. parser_init() stored that NULL bus, and the range iterator later dereferenced it. Reject such nodes in parser_init(), leaving an explicit empty iterator for callers that ignore the init return, and make of_dma_get_max_cpu_address() honour the init failure so a rejected node cannot clamp the DMA limit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74492", "url": "https://ubuntu.com/security/CVE-2026-74492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: do not update comments from kernel-side hash adds mtype_resize() copies comment pointers with memcpy(), not the comment objects themselves. During the window after an entry has been copied but before the table swap and backlog replay, the old table is still published for packet-side updates while the replacement-table entry already holds the same ip_set_comment_rcu pointer. If xt_SET --add-set ... --exist hits that old entry in this window, mtype_add() calls ip_set_init_comment() even though packet-side adds carry no comment payload. That call frees the shared comment through the old entry, so the replacement-table entry now holds a stale pointer. When the queued add is replayed on the new table, mtype_add() calls ip_set_init_comment() again and strlen() dereferences the stale pointer. Fix this in mtype_add() by skipping ip_set_init_comment() when ext->target marks a packet-side add. Userspace adds still update comments, while packet-side adds can no longer free comment storage shared with a resize copy.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74493", "url": "https://ubuntu.com/security/CVE-2026-74493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket use-after-free during link group termination __smc_lgr_terminate() drops conns_lock after finding a connection in lgr->conns_all, but before taking a reference on its socket. The connection is embedded in the socket, and its registration reference protects it only while the connection remains in the tree. A concurrent close can unregister the connection and drop that reference, freeing the socket before the termination worker reaches sock_hold(). The race is reachable when close overlaps link group termination. Local stress testing reproduced the use-after-free and KASAN reported: BUG: KASAN: slab-use-after-free in __smc_lgr_terminate.part.0 [smc] Write of size 4 by task kworker/3:3 Workqueue: events smc_lgr_terminate_work [smc] __smc_lgr_terminate.part.0 [smc] The socket was allocated by smc_create(), freed through slab_free_after_rcu_debug(), and was followed by: refcount_t: addition on 0; use-after-free. __smc_lgr_terminate.part.0 [smc] Take the socket reference while conns_lock still protects the tree entry. The unregister path then cannot drop the last reference until termination has finished using the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74494", "url": "https://ubuntu.com/security/CVE-2026-74494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject repeated SMB2 NEGOTIATE requests Unauthenticated client can send multiple successful SMB2 NEGOTIATE requests on one connection before SESSION_SETUP. While the connection is in KSMBD_SESS_NEED_SETUP, smb2_handle_negotiate() accepts another SMB3.1.1 NEGOTIATE and overwrites conn->preauth_info with a new allocation. Only the final allocation is freed when the connection is released, leaking one object for every additional successful request. A repeated SMB2 NEGOTIATE after a dialect has been selected is a protocol violation. MS-SMB2 section 3.3.5.4 requires the server to disconnect without replying in this case. Set the connection exiting when rejecting the request, in addition to suppressing the response. Reject SMB2 NEGOTIATE unless the connection is new or is waiting for the SMB2 NEGOTIATE that follows an SMB1 multi-protocol negotiate. Serialize both SMB1 and SMB2 negotiation paths under conn->srv_mutex, since they update connection-wide dialect and negotiation state. Move the locking contract to ksmbd_smb_negotiate_common(), where the state and dialect are selected, and add ksmbd_conn_new() for consistent state access.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74495", "url": "https://ubuntu.com/security/CVE-2026-74495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igbvf: Fix leak in TX DMA error cleanup If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb. Because count is incremented before each frag mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping (the head) would leak. This bug was introduced by a 2010 fix for an endless loop in dma_error. All other affected drivers have already been fixed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74497", "url": "https://ubuntu.com/security/CVE-2026-74497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Clamp frame size in implicit-feedback mode snd_usb_handle_sync_urb() scales received sync packet sizes by the sender's stride and stores the result directly in out_packet->packet_size[i]. If a connected USB device sends an oversized sync packet, this frame count can exceed ep->maxframesize. The un-clamped frame count then propagates to the playback endpoint queue, potentially driving packet transfers beyond the endpoint's hardware frame limits. Cap the calculated frame count against ep->maxframesize in snd_usb_handle_sync_urb() to prevent oversized packets from entering the playback queue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74498", "url": "https://ubuntu.com/security/CVE-2026-74498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set When a USB audio endpoint requests full packet transfers via the fill_max descriptor flag, data_ep_set_params() promotes ep->curpacksize to ep->maxpacksize. However, maxsize is left at the original sample-rate derived value. Since u->buffer_size is allocated as maxsize * packets, the resulting DMA buffer is far too small for the requested transfer length. When the USB host controller streams up to curpacksize bytes per packet, it writes past the end of the buffer via DMA, corrupting kernel heap memory. Update maxsize to curpacksize when fill_max is set so that the allocated DMA buffer size matches the actual transfer request size. [ changed to reassign maxsize only when ep->fill_max is set -- tiwai ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74499", "url": "https://ubuntu.com/security/CVE-2026-74499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output() snd_usbmidi_akai_output() computes its fill-loop bound \tbuf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1; as a signed int, so a small device-advertised bulk-OUT max_transfer makes buf_end negative. The loop guard then compares the u32 urb->transfer_buffer_length against that negative int: the usual arithmetic conversion turns buf_end into a large unsigned value, so the guard stays true and each iteration keeps appending SysEx framing and payload bytes past the end of the URB transfer buffer, which is only max_transfer bytes long. A USB device that advertises a tiny bulk-OUT endpoint can therefore trigger an attacker-length- and content-controlled heap out-of-bounds write when a process writes to the created /dev/snd/midiC*D* node. Return early when there is no room for even one SysEx, so the loop is never entered with a bound that would wrap. The loop is the last statement of the function, so bailing out is equivalent to it not running. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74500", "url": "https://ubuntu.com/security/CVE-2026-74500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix stack info leak in RME Digiface status snd_rme_digiface_read_status() reads a four-word status block from the device into an uninitialised on-stack __le32 buf[4] and, whenever the vendor control-IN transfer does not return a negative error, copies all four words into the caller's status[]. snd_usb_ctl_msg() copies the full requested size back into the caller's buffer regardless of how many bytes the data stage actually delivered: \tbuf = kmemdup(data, size, GFP_KERNEL); \terr = usb_control_msg(dev, pipe, request, requesttype, \t\t\t value, index, buf, size, timeout); \tmemcpy(data, buf, size); usb_control_msg() returns the transferred length on a short control-IN, which is a non-negative value, and writes only that many bytes. The remainder of the copy back is the kmemdup()ed image of the caller's buffer, so a device answering with a short data stage leaves the trailing words of buf[] holding leftover kernel stack. The only guard in the caller is err < 0, so those words are stored into status[]. They then reach user space: snd_rme_digiface_get_status_val() selects a 16-bit halfword of status[] per the control's reg/mask, and the eight Digiface status controls together expose the whole 16-byte frame to an unprivileged reader of /dev/snd/controlC*. Zero-initialise the buffer so a short read yields zeros instead of stack residue. This mirrors snd_rme_get_status1(), which already clears its output word before the same kind of vendor read. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74501", "url": "https://ubuntu.com/security/CVE-2026-74501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix use-after-free in ump_to_endpoint() create_midi2_ump() registers a card-owned snd_ump_endpoint and stores a back-pointer to its per-interface snd_usb_midi2_ump object in ump->private_data, but it never installs an ump->private_free hook and never clears that pointer. If a later step of snd_usb_midi_v2_create() fails, its error path calls free_all_midi2_umps(), which kfree()s the snd_usb_midi2_ump object while the already-registered endpoint keeps pointing at it. The created /dev/snd/umpC*D* node stays exposed, so the first operation of any UMP open, ump_to_endpoint(), dereferences the dangling ump->private_data and reads rmidi->eps[dir] out of freed memory. A malicious USB MIDI 2.0 device that makes creation fail after the endpoint is registered can thus trigger a slab use-after-free read on a subsequent open of the UMP node. Clear the endpoint's back-pointer before freeing the object, and let ump_to_endpoint() tolerate a NULL private_data so the open/close/trigger callbacks fail cleanly (their callers already handle a NULL endpoint) instead of dereferencing a stale pointer. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74502", "url": "https://ubuntu.com/security/CVE-2026-74502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ump: fix double free of out_cvts on rawmidi error snd_ump_attach_legacy_rawmidi() allocates the legacy conversion array ump->out_cvts and, on the snd_rawmidi_new() error path, frees it with kfree() but leaves ump->out_cvts pointing at the freed memory. When the endpoint is later torn down, snd_ump_endpoint_free() frees ump->out_cvts a second time, resulting in a double free. The host snd-usb-audio driver attaches the legacy rawmidi for any USB MIDI 2.0 (UMP) device, so a device that makes snd_rawmidi_new() fail reaches this path on enumeration. Clear ump->out_cvts after freeing it on the error path so it is not freed again during teardown. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74503", "url": "https://ubuntu.com/security/CVE-2026-74503", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: Clear SNDRV_TIMER_IFLG_DEAD once the close completes snd_timer_close_locked() marks an instance with SNDRV_TIMER_IFLG_DEAD and returns early when the flag is already set, but the flag is never cleared again. A completed close ends in remove_slave_links(), which leaves timeri->timer NULL, so a second close is already harmless through the timer == NULL path; the early return can only be reached by an instance that was opened again in between. For such an instance the close unlinks nothing, so snd_timer_instance_free() frees an object that is still on timer->open_list_head, still on snd_timer_master_list if it was opened with a slave key, still owns any adopted slaves, and still holds its timer and module references. snd_seq_timer_open() reopens an instance exactly like that: it retries its fallback open on the same object after a failure that has already run snd_timer_close_locked() internally. An unprivileged user with access to /dev/snd/timer and /dev/snd/seq can force that failure, since snd_timer_check_master() returns -EBUSY when a pending slave matches the new master's (slave_class, slave_id) key and the target timer has reached max_instances, and SNDRV_TIMER_IOCTL_SELECT with dev_class = SNDRV_TIMER_CLASS_SLAVE keeps the caller-supplied dev_sclass, so a sequencer queue's key can be forged. The freed instance is afterwards dereferenced by any further snd_timer_open() on that timer, by snd_timer_check_slave(), and by /proc/asound/timers, which faults on the stale ti->owner pointer. The flag only has to be visible while the close is in progress, which is all its other users need. Clear it in remove_slave_links(), under the same timer->lock that sets it, once the instance is off every list.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74504", "url": "https://ubuntu.com/security/CVE-2026-74504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix division by zero in initialize_timer() A userspace-driven ALSA timer (SND_UTIMER) lets an unprivileged user set the backing snd_timer's hardware resolution to an arbitrary 64-bit value via SNDRV_TIMER_IOCTL_CREATE. snd_utimer_create() only rejects zero. When such a timer is bound to a sequencer queue, initialize_timer() computes the tick period as \ttmr->ticks = 1000000000 / (r * freq); where r is that user-controlled resolution and freq is the sequencer update rate in Hz, clamped to MIN_FREQUENCY..MAX_FREQUENCY (10..6250). A resolution of 2^63 makes the 64-bit product r * freq wrap to zero for any even freq, including DEFAULT_FREQUENCY (1000), so the division faults with a divide-by-zero. The division runs under tmr->lock with interrupts disabled, so the oops leaves the spinlock held and hangs the CPU. It is reachable by an unprivileged user with access to /dev/snd/timer and /dev/snd/seq. Oops: divide error: 0000 [#1] SMP KASAN PTI CPU: 7 UID: 1000 PID: 456 Comm: alsa_seq_utimer Not tainted 7.2.0-rc4+ RIP: 0010:initialize_timer.constprop.0+0x20a/0x2d0 snd_seq_timer_start+0x15e/0x2b0 snd_seq_control_queue+0x56f/0xba0 snd_seq_write+0x3e0/0x730 Reject an overflowing product with check_mul_overflow() and fall back to a single tick, which also avoids feeding a wrapped-but-nonzero divisor (e.g. 2^63 * 1000 mod 2^64 == 0, or other resolutions wrapping to a small value) into the period computation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74505", "url": "https://ubuntu.com/security/CVE-2026-74505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Fix UAF at error handling during probe Although 6fire driver had a few fixes for dealing with the early error handling during the probe phase, it forgot a pending URB before freeing the resources, which may lead to a UAF. This patch addresses it by doing the almost same cleanup procedure like the normal disconnect phase at the error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74506", "url": "https://ubuntu.com/security/CVE-2026-74506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix UAF when sending a message In afs_make_call(), there's a race with async call reception and destruction. If a call is dispatched that doesn't have call->write_iter set (used to specify the data content for FS.StoreData), then the first rxrpc_kernel_send_data() will not set MSG_MORE in the msghdr. Once rxrpc_send_data() queues the last request packet, the response could come in at any time and cause the call to be completed and put. However, afs_make_call() will look at the call again to see it ->write_iter should be handled - something it's only allowed to do if it has its own ref on the call. Whilst this is the case for synchronous calls, it isn't true for async calls such as FS.FetchData. There's also a potential UAF in afs_make_call() in the event that an asynchronous call is being sent, but the call fails in some way (e.g. it gets aborted from the server). The problem there is that afs_make_call() tries to abort a call if the rxrpc send fails, but the asynchronous notification from rxrpc may have caused the afs_call to be torn down. generic/650 plays games with randomly taking CPUs offline, and can interject a significant delay such that the call is deallocated before afs_make_call() gets to check call->write_iter - and a UAF ensues (caught by KASAN). BUG: KASAN: slab-use-after-free in afs_make_call+0x1c90/0x2210 [kafs] Read of size 8 at addr ffff888035e050e8 by task fsstress/1409 Fix this by making afs_make_op_call() give the op->call its own ref rather than transferring the caller's ref to it and then dropping the ref when afs_make_call() returns. This also means that the afs_make_call() func never loses its ref on the call now.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74507", "url": "https://ubuntu.com/security/CVE-2026-74507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: validate numbered report payloads When hidp_get_raw_report() waits for a numbered report, hidp_process_data() compares the expected report number with skb->data[0]. A connected HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is removed. KMSAN reports an uninitialized-value use in hidp_session_run(), with the value originating in __alloc_skb() through vhci_write(). The transaction header checks remove the empty-frame reports, but this report remains until the payload check is added. The comparison can also consume a peer-controlled byte beyond the declared L2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made the current code accept that byte as report ID 1 and complete HIDIOCGFEATURE with a zero-byte result. With this change the malformed response is rejected with -EIO, while a subsequent valid response still succeeds. Require a payload byte before comparing a numbered report ID. Unnumbered reports continue to accept an empty payload.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74508", "url": "https://ubuntu.com/security/CVE-2026-74508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: reject frames without a transaction header hidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom. KMSAN reports the use in hidp_session_run(), with the uninitialized value originating in __alloc_skb() through vhci_write(). The control path produces two reports and the interrupt path produces one. The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDP_TRANS_HID_CONTROL | HIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds. Pull the transaction header with skb_pull_data() and discard frames that do not contain it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74509", "url": "https://ubuntu.com/security/CVE-2026-74509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Fix advertising data UAFs hci_find_adv_instance() returns an adv_info pointer that is valid only while hdev->lock is held. The advertising command-sync paths perform instance lookups without that lock and, in some cases, retain the pointer while waiting for a controller response. An advertising termination event can therefore interleave as follows: hci_cmd_sync_work hci_rx_work hci_find_adv_instance() __hci_cmd_sync_status() wait for controller reply hci_dev_lock() hci_remove_adv_instance() kfree(adv) adv->scan_rsp_changed = false KASAN reported: BUG: KASAN: slab-use-after-free in hci_set_ext_scan_rsp_data_sync+0x2e1/0x300 Write of size 1 at addr ffff88810a45d21d by task kworker/u17:0/88 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_set_ext_scan_rsp_data_sync+0x2e1/0x300 hci_schedule_adv_instance_sync+0x390/0x4c0 hci_cmd_sync_work+0x173/0x300 Allocated by task 87: hci_add_adv_instance+0x538/0xac0 add_advertising+0x885/0x1160 Freed by task 89: kfree+0x131/0x3c0 hci_remove_adv_instance+0x1d8/0x3b0 hci_le_ext_adv_term_evt+0x17b/0x730 Protect the instance lookup and payload construction in the extended advertising, scan response, and periodic advertising data paths. Snapshot the advertising parameters under hdev->lock, but release the lock before waiting for the controller. Clear advertising-data dirty bits before issuing their commands and restore them after a failure using a fresh lookup. Likewise, update the reported transmit power through a fresh lookup after the parameter command completes. No adv_info pointer then survives an HCI command wait.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74510", "url": "https://ubuntu.com/security/CVE-2026-74510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix UAF in pair command cancellation The pairing completion and authentication failure callbacks look up the pending MGMT_OP_PAIR_DEVICE command by walking hdev->mgmt_pending. The lookup returned a command that was still linked on the shared pending list, without keeping mgmt_pending_lock held for the later dereference and removal. A concurrent MGMT_OP_CANCEL_PAIR_DEVICE request can remove and free the same pending command before the callback uses it. The reverse race is also possible when cancel_pair_device() gets a command from pending_find() and a callback removes it before the cancel path dereferences it. This can lead to a use-after-free and a second list_del(). Make the pairing lookup helpers transfer ownership of the pending command by removing it from hdev->mgmt_pending while holding mgmt_pending_lock. The callbacks and cancel path then complete the command and free it directly, so racing paths cannot find or free the same command again. Take a temporary hci_conn reference in cancel_pair_device() because the command completion drops the reference stored in the pending command.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74511", "url": "https://ubuntu.com/security/CVE-2026-74511", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74512", "url": "https://ubuntu.com/security/CVE-2026-74512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix potential use-after-free in audit_del_rule() `audit_del_rule()` destroys `e->rule.exe` via `audit_remove_mark_rule()` before unlinking the rule from RCU-visible filter lists and waiting for a grace period. Concurrent readers in `audit_filter()` and `audit_filter_rules()` still dereference `e->rule.exe`, while the fsnotify mark can be freed on an independent lifetime path. This creates a use-after-free window during rule deletion. Fix this by unlinking the rule from the RCU-visible lists and invoking `synchronize_rcu()` before calling `audit_remove_mark_rule()` (and other rule removal helpers). This ensures that all existing RCU readers have exited the critical section before any underlying resources are destroyed.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74513", "url": "https://ubuntu.com/security/CVE-2026-74513", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dibs: fix use-after-free of dmb_node in loopback attach/detach/unregister dibs_lo_attach_dmb(), dibs_lo_detach_dmb() and dibs_lo_unregister_dmb() look up the dmb_node under dmb_ht_lock, drop the lock and only then operate on the node's refcount. Nothing keeps the node alive across that window: __dibs_lo_unregister_dmb() removes the node from the hash table under the write lock and immediately frees it. A concurrent final put can therefore free the node between the lookup and the refcount operation: CPU0 (attach) CPU1 (owner unregisters) read_lock_bh(&dmb_ht_lock) find dmb_node (refcnt == 1) read_unlock_bh(&dmb_ht_lock) refcount_dec_and_test() 1 -> 0 write_lock_bh(&dmb_ht_lock) hash_del(&dmb_node->list) write_unlock_bh(&dmb_ht_lock) kfree(dmb_node) refcount_inc_not_zero(&dmb_node->refcnt) <-- use-after-free The same window exists for the refcount_dec_and_test() calls in the detach and unregister paths. Close the race structurally by making hash table membership and the refcount transitions atomic with respect to each other: - Perform the final refcount_dec_and_test() and hash_del() in a single dmb_ht_lock write-side critical section, in both the unregister and the detach path. Freeing the node still happens after the lock is dropped, which is safe because a node whose refcount reached zero has left the hash table and can no longer be found. - This establishes the invariant that any node found in the hash table holds at least one reference, and that the final reference can only be dropped under the write lock. dibs_lo_attach_dmb() can thus take its reference with a plain refcount_inc() while still holding the read lock; refcount_inc_not_zero() is no longer needed. __dibs_lo_unregister_dmb() no longer touches the hash table and is renamed to dibs_lo_free_dmb() accordingly. Note: commit cc21191b584c (\"dibs: Move data path to dibs layer\") moved the code to its current location; the race was introduced earlier by commit c3a910f2380f (\"net/smc: implement DMB-merged operations of loopback-ism\"). Tested SMC-D via ISM and dibs loopback.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74514", "url": "https://ubuntu.com/security/CVE-2026-74514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Fix memory accounting for pinned/unpinned pages The account_mem() and unaccount_mem() functions call get_uid() which increments the reference count of struct user_struct on every invocation. But we don't decrement the count by calling free_uid(). It also accounted/unaccounted the pages against the current->mm. But its possible the unaccount_mem() can be called from a different process context than the one that originally pinned the pages. Let's fix this by storing the pinning process user_struct and mm_struct when accounting for pinned pages, and subsequently free these resources when the pages are unpinned. [borntraeger@linux.ibm.com: Fixed whitespace]", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74515", "url": "https://ubuntu.com/security/CVE-2026-74515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Reject adapter interrupt forwarding if already enabled The MPCIFC instruction doesn't allow registering adapter interrupts without first unregistering. So reject any request to enable interrupt forwarding if its already enabled for the zPCI device. This also fixes overwriting and thus leaking resources when the ioctl is called multiple times for the same device.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74516", "url": "https://ubuntu.com/security/CVE-2026-74516", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Update x2APIC MSR intercepts if AVIC is inhibited while L2 is active Always update x2APIC MSR intercepts for L1 when AVIC is deactivated, even if L2 is active and KVM is using a separate MSR bitmap to run L2. If AVIC is fully enabled prior to running L2, and is then inhibited while L2 is active (for a VM-scoped inhibit), then KVM will run L1 with AVIC disabled, but with x2APIC MSR intercepts disabled, i.e. will allow L1 to read most of the host's APIC state, send arbitrary interrupts, change task priority, and ultimately trivially DoS the host. E.g. sending a self-IPI in L1 on HYPERV_REENLIGHTENMENT_VECTOR, 0xee, with CONFIG_HYPERV=n in the host kernel as a \"safe\" PoC, yields: Spurious interrupt (vector 0xee) on CPU#425. Acked And hacking KVM to abuse kvm_set_posted_intr_wakeup_handler() to register a handler and WARN on POSTED_INTR_WAKEUP_VECTOR yields: ------------[ cut here ]------------ WARNING: arch/x86/kvm/svm/svm.c:5594 at pi_wakeup_handler+0x9/0x10 [kvm_amd], CPU#156: nested_x2apic_t/316940 CPU: 156 UID: 0 PID: 316940 Comm: nested_x2apic_t Tainted: G S U Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20260209.0-0 02/09/2026 RIP: 0010:pi_wakeup_handler+0x9/0x10 [kvm_amd] Call Trace: sysvec_kvm_posted_intr_wakeup_ipi+0x64/0x80 asm_sysvec_kvm_posted_intr_wakeup_ipi+0x1a/0x20 RIP: 0010:vcpu_run+0x1430/0x1e40 [kvm] kvm_arch_vcpu_ioctl_run+0x2c1/0x600 [kvm] kvm_vcpu_ioctl+0x580/0x6b0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46ff4b ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74518", "url": "https://ubuntu.com/security/CVE-2026-74518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix list corruption in allocate_file_region_entries() allocate_file_region_entries() tops up resv->region_cache with freshly allocated file_region descriptors. The allocation uses GFP_KERNEL, so resv->lock is dropped around it: the new entries are gathered on a stack-local list head, allocated_regions, and spliced into resv->region_cache once the lock is re-acquired. The splice used list_splice(), which moves the entries but does not re-initialize the source head, so allocated_regions is left pointing at an entry that now lives on resv->region_cache. The top-up runs in a while loop that re-checks the cache deficit after re-acquiring the lock. For a shared mapping the resv_map is shared by every mapper of the hugetlbfs inode, so a concurrent region_chg()/region_add()/region_del() on the same resv_map can consume cache entries during the unlocked window and force a second iteration. That iteration calls list_add() on the stale head and corrupts the list; with CONFIG_DEBUG_LIST the __list_add_valid() check trips: list_add corruption. next->prev should be prev (ffffc900011ff7f8), but was ffff88814c281460. (next=ffff88814c545640). kernel BUG at lib/list_debug.c:31! allocate_file_region_entries+0x191/0x420 region_chg+0x267/0x300 hugetlb_reserve_pages+0x387/0xc80 hugetlbfs_file_mmap+0x2ce/0x3f0 mmap_region+0x1348/0x1a80 do_mmap+0x85e/0xb90 vm_mmap_pgoff+0x18c/0x330 ksys_mmap_pgoff+0x2a1/0x3e0 do_syscall_64+0xd7/0x420 Without CONFIG_DEBUG_LIST the bad list_add() silently links a kernel-stack address into resv->region_cache, leading to later use-after-free. This was observed as a real host panic on a dense KVM host where a QEMU guest-RAM hugetlbfs file was mapped MAP_SHARED by both QEMU and a separate SPDK/DPDK vhost-user target, generating concurrent region_* traffic on one shared resv_map. Use list_splice_init() so the source head is re-initialized empty after each splice, making the retry loop safe.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74519", "url": "https://ubuntu.com/security/CVE-2026-74519", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: don't free uninitialized dev_name on error path dt_remember_or_free_map() duplicates dev_name for each map entry. If kstrdup_const() fails, dt_free_map() frees dev_name in all num_maps entries, including entries that have not been initialized. Some pinctrl drivers, including pinctrl-imx, allocate the map with kmalloc() and leave dev_name for the core to initialize. The untouched entries therefore contain uninitialized data which is passed to kfree_const(). Reproduced on qemu's mcimx6ul-evk (pinctrl-imx) with failslab injection while binding the pinctrl-consuming device, under KASAN: BUG: KASAN: double-free in dt_free_map+0x34/0xa4 Free of addr c425a900 by task init/1 kfree from dt_free_map+0x34/0xa4 dt_free_map from dt_remember_or_free_map+0x184/0x198 dt_remember_or_free_map from pinctrl_dt_to_map+0x33c/0x4c8 pinctrl_dt_to_map from create_pinctrl+0x9c/0x5c0 Initialize all dev_name fields to NULL before duplicating the device name, making the full-map cleanup safe after a partial failure.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74520", "url": "https://ubuntu.com/security/CVE-2026-74520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/iommufd: Fix IOPF group ownership UAF iopf_group_alloc() links each last-page IOPF group into the generic IOPF pending list before invoking the domain fault handler. iommufd_fault_iopf_handler() also queued an accepted group in the IOMMUFD deliver list without removing it from the generic pending list. When detach or HWPT replacement drops the device's IOPF reference count to zero, an IOMMU driver may call iopf_queue_remove_device(). That function responds to and frees groups through the generic pending list without removing the same groups from IOMMUFD's deliver list or response xarray. A later read, response, or cleanup can then access the freed group and cause a UAF. Fix this by dequeuing an accepted group from the generic pending list before IOMMUFD queues it for userspace response. Make iopf_group_response() send a response regardless of pending-list membership, so the dequeued group can still be completed by IOMMUFD.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74522", "url": "https://ubuntu.com/security/CVE-2026-74522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __close_file_table_ids() A ksmbd_file can remain alive after logical close while another session holds a temporary reference obtained through ksmbd_lookup_fd_inode(). ksmbd_close_fd() currently marks the file closed and drops the idr-owned reference, but leaves the pointer published in the closing session's idr until the final reference is dropped. If the foreign holder performs the final ksmbd_fd_put(), __put_fd_final() supplies the foreign session's file table to __ksmbd_close_fd(). The object is then freed without being removed from its owner's idr, and the owner session later dereferences the stale pointer during file-table teardown. Remove the volatile id from the owner's idr while ksmbd_close_fd() still holds that table's lock, and clear volatile_id before dropping the idr-owned reference. A later foreign final put then only performs physical destruction and cannot remove the object from the wrong table.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74523", "url": "https://ubuntu.com/security/CVE-2026-74523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: sync udp_tunnel ports outside qede_lock in the recovery path A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports configured wedges the rtnetlink control plane of the whole machine: NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2! [qede_recovery_handler:2665(ens6f0)]Starting a recovery process The recovery path deadlocks on the driver's own mutex: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- taken qede_recovery_handler qede_load udp_tunnel_nic_reset_ntf __udp_tunnel_nic_device_sync info->sync_table == qede_udp_tunnel_sync mutex_lock(&edev->qede_lock) <- same task: deadlock The mutex is not recursive, so the kworker blocks on itself with rtnl_lock held, and neither lock is ever released. Every task that calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnl_mutex.owner decodes to the very kworker blocked at the innermost mutex_lock() above. Re-sync the tunnel ports from qede_sp_task() after the internal lock is dropped, still under rtnl_lock as the udp_tunnel API requires. This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf() under rtnl without the internal lock. qede_recovery_handler() now returns whether it has successfully reloaded an open device, and the caller re-syncs the ports only in that case. This keeps the old gating exactly: a device that was down or a failed recovery returns false, as those paths never reached the udp_tunnel_nic_reset_ntf() call before either. This was the only user of the qede_lock()/qede_unlock() helpers, so remove them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74524", "url": "https://ubuntu.com/security/CVE-2026-74524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove remove_pud_mapping() and remove_p4d_mapping() obtain a child table base with pud_offset(p4dp, 0) and p4d_offset(pgd, 0), then add the index for addr. RISC-V folds page-table levels at runtime. When a level is folded, its offset helper returns the parent entry itself, but the index can still be nonzero. Adding it walks past the parent table. Sv48 folds P4D, while Sv39 folds both P4D and PUD, so memory hot-remove can descend into unrelated memory and pass an invalid page to __free_pages(). This can trigger: kernel BUG at include/linux/mm.h:1810! VM_BUG_ON_PAGE(page_ref_count(page) == 0) arch_remove_memory+0x1e/0x5c try_remove_memory+0x15e/0x200 remove_memory+0x24/0x3c Only add the index when the corresponding page-table level is enabled, matching p4d_offset() and pud_offset().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74525", "url": "https://ubuntu.com/security/CVE-2026-74525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: free TX rings on RX allocation failure When RX descriptor ring allocation fails, init_dma_desc_rings() only frees the partially allocated RX rings and returns. The TX rings that were allocated earlier in the same function are leaked. Rearrange error labels to clean up TX rings upon RX failures.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74531", "url": "https://ubuntu.com/security/CVE-2026-74531", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: hold conn reference in abort_conn_sync() There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74532", "url": "https://ubuntu.com/security/CVE-2026-74532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: Validate length before parsing diagnostics TLV btintel_diagnostics() accesses tlv->val[0] without first validating that the diagnostics VSE is long enough to contain that field, so may cause reading data beyond the received frame. Fix by validating the length before access.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74534", "url": "https://ubuntu.com/security/CVE-2026-74534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix refcounting of iso_conn iso_conn_del() and iso_chan_del() have a race that results to double-put of iso_conn: [Task hdev->workqueue] [Task 2] iso_conn_del iso_chan_del iso_conn_hold_unless_zero iso_conn_lock iso_conn_lock conn->sk = NULL iso_conn_unlock sk = iso_sock_hold(conn) <---------´ if (!sk) iso_conn_put iso_conn_put iso_conn_put /* UAF */ The extra put for !sk in iso_conn_del() is currently required since failing iso_chan_add() may leave iso_conn not associated with any sk. Fix by having iso_pi(sk)->conn own refcount when non-NULL, so iso_conn_del does not need to put it. Adjust the iso_conn_add() refcounting so that conn is put if it does not get associated with an sk.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74535", "url": "https://ubuntu.com/security/CVE-2026-74535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: avoid deadlocks in iso_sock_timeout iso_sock_timeout() takes lock_sock, so sync disabling the timer while holding that lock may deadlock. iso_sock_timeout() may also run concurrently with iso_conn_del(), which leads to UAF [Task 1] [Task hdev->workqueue] iso_sock_timeout iso_conn_del iso_conn_hold_unless_zero iso_chan_del `------------> iso_conn_put caller frees hcon iso_conn_put iso_conn_free conn->hcon->iso_data = NULL; /* UAF */ Fix the deadlock by removing the disable from the lock_sock sections. Move the timer from iso_conn to iso_pinfo to decouple it from iso_conn which may need to be freed in lock_sock section. Convert some of the clear_timer to disable_timer.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74536", "url": "https://ubuntu.com/security/CVE-2026-74536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix leaking sk after socket release iso_sock_kill() tests !sock_flag(sk, SOCK_ZAPPED) || sk->sk_socket || sock_flag(sk, SOCK_DEAD) for early return, but this is always true since sock_orphan(sk) sets SOCK_DEAD, so the sk reference released by socket always leaks, iso_sock_destruct is never called. The socket reference also leaks when __iso_sock_close() does not set SOCK_ZAPPED, since iso_conn_del() does not call iso_sock_kill() after zapping. Fix by replacing SOCK_DEAD by BT_SK_KILLED flag that is not used for something else, and lock_sock to ensure iso_sock_kill() puts sk only after socket release only once. Release and iso_conn_del may run concurrently. Call iso_sock_kill() from iso_conn_del() to clean sk up after zapping. Remove call to iso_sock_kill() from iso_sock_close(), as it's generally no-op there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74537", "url": "https://ubuntu.com/security/CVE-2026-74537", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: hold sk properly in iso_conn_ready sk deref in iso_conn_ready must be done either under conn->lock, or holding a refcount, to avoid concurrent close. conn->sk is currently accessed without either: [Task 1] [Task 2] iso_sock_release iso_conn_ready sk = conn->sk lock_sock(sk) conn->sk = NULL lock_sock(sk) release_sock(sk) iso_sock_kill(sk) UAF on sk deref Fix possible UAF by holding sk refcount in iso_conn_ready(). Also recheck after lock_sock that the socket is still valid. Adjust locking so conn->sk is cleared only under lock_sock.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74538", "url": "https://ubuntu.com/security/CVE-2026-74538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: lock sk in iso_connect_ind Accessing iso_pi(sk)->conn requires lock_sock, which is not taken in the \"ev3\" part of iso_connect_ind. It may also be NULL if socket has transitioned away from the LISTEN/CONNECT states before locking. Fix by adding lock/release. Recheck hcon is valid after lock acquire where needed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74539", "url": "https://ubuntu.com/security/CVE-2026-74539", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: lock sk in iso_sock_getname Accessing iso_pi(sk)->conn requires lock_sock, which is not held here. Fix by adding the lock/release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74540", "url": "https://ubuntu.com/security/CVE-2026-74540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74541", "url": "https://ubuntu.com/security/CVE-2026-74541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: clear iso_data always when detaching conn from hcon When setting conn->hcon = NULL, also conn->hcon->iso_data = NULL is necessary, otherwise later iso_conn_free() will UAF. Fix clearing of iso_data in iso_sock_disconn() Fixes KASAN: slab-use-after-free in iso_conn_hold_unless_zero on iso_sock_release() followed by hci_abort_conn_sync().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74543", "url": "https://ubuntu.com/security/CVE-2026-74543", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: udp_tunnel: fix memory leak in udp_tunnel_nic_unregister() syzbot reported a memory leak [1] in the UDP tunnel NIC offload code. When device registration fails (e.g. in register_netdevice()), netdev core unwinds by sending a single NETDEV_UNREGISTER notification. If work was queued during NETDEV_REGISTER (utn->work_pending is set), udp_tunnel_nic_unregister() returns early: \tif (utn->work_pending) \t\treturn; Because failed registrations do not enter netdev_wait_allrefs_any(), no subsequent NETDEV_UNREGISTER rebroadcast will ever occur. As a result, the struct udp_tunnel_nic allocated in udp_tunnel_nic_alloc() is leaked permanently. Fix this by removing the early return. Instead, synchronously cancel any pending work with cancel_delayed_work_sync() before freeing @utn. To be able to call cancel_delayed_work_sync() while holding RTNL (the work also needs RTNL), switch udp_tunnel_nic_device_sync_work() to rtnl_trylock(). If RTNL is contended, requeue the work with a 1 jiffy delay (via queue_delayed_work()) to prevent high CPU contention while waiting for RTNL lock. The utn->work_pending bookkeeping is no longer needed and is removed, as the workqueue core already tracks the pending/running state of the work. [1] BUG: memory leak unreferenced object 0xffff888127d5f840 (size 96): comm \"syz-executor\", pid 5806, jiffies 4294942188 backtrace (crc 99fdb6c8): __kmalloc_noprof+0x3bf/0x550 udp_tunnel_nic_alloc net/ipv4/udp_tunnel_nic.c:756 [inline] udp_tunnel_nic_register net/ipv4/udp_tunnel_nic.c:833 [inline] udp_tunnel_nic_netdevice_event+0x804/0xab0 net/ipv4/udp_tunnel_nic.c:931 notifier_call_chain+0x59/0x160 kernel/notifier.c:85 call_netdevice_notifiers_info+0x7d/0xb0 net/core/dev.c:2250 register_netdevice+0xc10/0xeb0 net/core/dev.c:11478", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74545", "url": "https://ubuntu.com/security/CVE-2026-74545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: fix double free of multi-frag skb on DMA map failure In rtase_start_xmit(), when the head buffer DMA mapping fails after rtase_xmit_frags() has mapped all fragments, the error path clears the fragment descriptors with rtase_tx_clear_range(), which frees the skb through the last-frag slot and accounts tx_dropped. Control then falls through to the common error label, which frees the same skb a second time and counts it again. Return right after clearing the fragments when the skb owns frags; the no-frag case still drops through and frees the head skb once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74546", "url": "https://ubuntu.com/security/CVE-2026-74546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read If the fan data becomes 0 between the FAN_DATA_VALID() check and the FAN_PERIOD_TO_RPM() conversion, it will result in a divide-by-zero crash due to a race with a concurrent update of the cached fan value. Fix a TOCTOU issue by reading fan data once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74547", "url": "https://ubuntu.com/security/CVE-2026-74547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread When userspace configures 'auto_update_interval' to 0 via sysfs, the background kthread executes schedule_timeout_interruptible(0), which returns immediately. If 'num_temp_sensors' is concurrently or previously set to 0, the msleep_interruptible() delay inside adt7470_read_temperatures() also becomes 0. This combination forces the background thread into a tight, unbounded busy-loop, hogging the CPU and flooding the I2C bus with a continuous stream of transactions. Fix this vulnerability by raising the lower limit of the clamp_val in auto_update_interval_store() from 0 to 500 milliseconds. This guarantees a reasonable minimum sleep window between sensor updates, protecting the system from intentional or accidental I2C bus denial of service.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74548", "url": "https://ubuntu.com/security/CVE-2026-74548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix UAF of txrx_stats in nv_remove nv_remove() frees the per-CPU txrx_stats before unregister_netdev(). Until unregister completes, ndo_get_stats64, the NAPI/xmit data path, and nv_close()/drain may still access txrx_stats, leading to a use-after-free. Free the stats only after unregister_netdev().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74549", "url": "https://ubuntu.com/security/CVE-2026-74549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Prevent access to unsupported weight registers Sashiko reports: During initialization of the nct6116 chip, the driver sets data->pwm_num to 5. However, it assigns several NCT6106 register arrays (such as NCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and NCT6106_REG_WEIGHT_TEMP_*) to data->REG_PWM and data->REG_WEIGHT_TEMP. These arrays only contain 3 elements. In nct6775_update_pwm(), the driver iterates up to data->pwm_num. If data->has_pwm has bits 3 or 4 set (which is structurally possible for nct6116), the loop attempts to read elements at index 3 and 4 from these 3-element arrays. This results in a global out-of-bounds read, which can be caught by KASAN. Furthermore, the driver uses these garbage out-of-bounds values as hardware register addresses for subsequent read and write operations. This leads to invalid hardware register access, potentially causing hardware misconfiguration or system crashes. The underlying problem is that the chip does support up to five fan control channels, but only the first three support weight control. Fix the problem by extending the affected weight register arrays with zeroed fields. The driver uses zeroed register addresses to determine if a register is supported or not, and skips accesses for unsupported registers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74550", "url": "https://ubuntu.com/security/CVE-2026-74550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not send ICMP/NDISC Redirects when peer allocation fails When inet_getpeer_v4() or inet_getpeer_v6() fails to allocate a peer entry under memory pressure or tree size caps, redirect handlers previously fell back to sending un-rate-limited ICMP/NDISC Redirect messages. In IPv4, ip_rt_send_redirect() called icmp_send() directly when peer == NULL. In IPv6, ip6_forward() and ndisc_send_redirect() passed a NULL peer into inet_peer_xrlim_allow(), which returned true when peer == NULL. Because ICMP/NDISC Redirects are not part of the default global rate limit mask (sysctl_icmp_ratemask), sending redirects when peer == NULL creates an un-rate-limited ICMP packet storm. Fix this by failing closed in ip_rt_send_redirect(), ip6_forward(), and ndisc_send_redirect() when peer is NULL.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74551", "url": "https://ubuntu.com/security/CVE-2026-74551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) DMA-align output buffer Sashiko reports: When send_output_report() calls hid_hw_output_report(), the underlying USB HID core calls usb_interrupt_msg() which maps this buffer directly for DMA. When the DMA mapping flushes or invalidates the cacheline, it will corrupt the adjacent variables (mutex, update_interval) that were modified concurrently by the CPU. This causes memory corruption due to cacheline sharing on non-coherent CPU architectures (such as ARM or MIPS). The DMA API debugging tool (CONFIG_DMA_API_DEBUG) will trigger runtime warnings for this violation. Any operation that triggers send_output_report() (like setting a fan speed or updating the interval) causes the USB DMA mapping. On systems with non-coherent caches, this structural bug causes immediate and deterministic memory corruption. Align the output buffer to ARCH_DMA_MINALIGN to fix the problem.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74552", "url": "https://ubuntu.com/security/CVE-2026-74552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm90) Only report alarms if driver is ready Userspace can read sysfs attributes before driver registration is complete, immediately after devm_hwmon_device_register_with_info() has been called. At that time, data->hwmon_dev is not yet initialized. This can trigger a NULL pointer access since lm90_update_device() and with it lm90_update_alarms_locked() will be called. This call schedules report_work and lm90_report_alarms(), which passes the still-NULL data->hwmon_dev to hwmon_notify_event() and triggers a NULL pointer dereference. Fix the problem by only scheduling the report and alert workers data->hwmon_dev is set.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74553", "url": "https://ubuntu.com/security/CVE-2026-74553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Fix number of temperature registers for NCT6116 Unlike NCT6106, NCT6116 only has three temperature registers, and with it only three temperature source and temperature source configuration registers. The register addresses match those of NCT6106 and can be re-used. The code used a separate array to list the temperature source registers for NCT6116, but used the size of the NCT6106 register array to set the number of registers. The NCT6106 register array provides six addresses, while the temperature source register array for NCT6116 only provides three addresses. This causes a KASAN report. BUG: KASAN: global-out-of-bounds in nct6775_probe+0x936/0x46f0 [nct6775] Read of size 2 at addr ffffffffc19561a6 by task modprobe/954 ... Call Trace: dump_stack+0x7d/0xa7 print_address_description.constprop.0+0x1c/0x220 ? __kasan_kmalloc.constprop.0+0xc9/0xd0 ? __kmalloc_node_track_caller+0x194/0x5b0 ? nct6775_probe+0x936/0x46f0 [nct6775] ? nct6775_probe+0x936/0x46f0 [nct6775] ... Fix the problem by hard-coding the number of temperature and temperature configuration registers to three for NCT6116. Drop the unnecessary NCT6116_REG_TEMP_SOURCE array and re-use NCT6106_REG_TEMP_SOURCE.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74555", "url": "https://ubuntu.com/security/CVE-2026-74555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race Commit fbefe22811c3 (\"scsi: libsas: Don't always drain event workqueue for HA resume\") introduced sas_resume_ha_no_sync() to avoid a deadlock: the PHYE_RESUME_TIMEOUT handler, running on the HA event workqueue, calls sas_deform_port() -> sas_destruct_devices(), which removes SCSI devices and waits for the host to become runtime-active. But the host cannot resume until sas_resume_ha() -> sas_drain_work() returns, and the drain is blocked on that very handler. However skipping the drain reintroduces a race: hisi_sas returns from resume before all PHY UP work and libsas discovery work finish. The controller may then autosuspend while disks are still waking up. The disks issue IO to a suspended controller, the IO fails, and the disks get disabled. Fix the deadlock at its source by moving the PHYE_RESUME_TIMEOUT notification to after sas_drain_work(). By then the host resume is about to complete, so device removal through device_link no longer blocks on the resume and the cycle is broken. With the deadlock gone, restore sas_resume_ha() (the draining variant) in hisi_sas and remove sas_resume_ha_no_sync(). The reorder is safe for the other libsas consumers (isci, pm8001, aic94xx, mvsas). During suspend, sas_suspend_devices() calls sas_notify_lldd_dev_gone() for each device, which sets dev->lldd_dev to NULL. When scsi_unblock_requests re-enables I/O in resume, any I/O to a timed-out phy's disk is immediately rejected by the LLDD before reaching hardware: isci returns SAS_DEVICE_UNKNOWN (mapped to DID_BAD_TARGET), and pm8001 returns SAS_PHY_DOWN (mapped to DID_NO_CONNECT). Both complete directly via scsi_done() without entering SCSI EH. This is identical in both the old and new ordering since lldd_dev_gone runs during suspend, before resume. The reorder only affects when the PHYE_RESUME_TIMEOUT handler runs (synchronized by sas_drain_work() vs. asynchronous after resume returns), not whether I/O can reach the device. aic94xx and mvsas do not register any PM ops and never reach this code path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74556", "url": "https://ubuntu.com/security/CVE-2026-74556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer iscsi_tcp_hdr_dissect() receives the data segment of several PDU types into the fixed-size conn->data buffer, which is allocated for ISCSI_DEF_MAX_RECV_SEG_LEN (8192) bytes. For the LOGIN_RSP, TEXT_RSP, REJECT and ASYNC_EVENT opcodes the dissect path already rejects a PDU whose DataSegmentLength exceeds that buffer. The SCSI Command Response (ISCSI_OP_SCSI_CMD_RSP) path also copies its data segment (sense/response data) into conn->data via iscsi_tcp_data_recv_prep(), but it does so without the same check. The only upstream bound on in.datalen is conn->max_recv_dlength, the initiator's advertised MaxRecvDataSegmentLength, which is commonly negotiated well above 8192 (open-iscsi defaults to 262144). A target that returns a SCSI Response with a DataSegmentLength between 8193 and max_recv_dlength therefore overflows the 8192-byte conn->data buffer. Once the same bound applies, ISCSI_OP_SCSI_CMD_RSP is handled exactly like those responses: bound the data segment, receive it into conn->data when present, and otherwise complete the PDU with no data. Fold the opcode into that case group rather than duplicating the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74557", "url": "https://ubuntu.com/security/CVE-2026-74557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer iscsi_scsi_cmd_rsp() copies the sense data of a SCSI Response from the target-supplied data segment. The segment carries a 2-byte sense length followed by the sense bytes, so it must hold 2 + senselen bytes, but the bounds check only requires datalen >= senselen: \tsenselen = get_unaligned_be16(data); \tif (datalen < senselen) \t\tgoto invalid_datalen; \tmemcpy(sc->sense_buffer, data + 2, \t min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE)); A target that returns a SCSI Response whose datalen equals senselen (with senselen <= SCSI_SENSE_BUFFERSIZE) makes the memcpy() from data + 2 read up to two bytes past the received data. Those bytes are stale conn->data contents and end up in the command's sense buffer, which is returned to userspace. Account for the 2-byte sense length prefix in the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74559", "url": "https://ubuntu.com/security/CVE-2026-74559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: drain continuation descs after overflow in xsk_build_skb() Fix generic xmit path multi-buffer logic when packets are either too big (count of descriptors exceed MAX_SKB_FRAGS) or an invalid descriptor is included in fragmented packet. Introduce xdp_sock::drain_cont and act upon this flag - when it is set, keep on consuming descriptors from AF_XDP Tx ring and put them directly onto Cq. Previously these descriptors were silently lost and could never be reached again.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74560", "url": "https://ubuntu.com/security/CVE-2026-74560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: fix buffer leak in xsk_drop_skb() for AF_XDP multi-buffer Tx This patch is inspired by the check[1] from sashiko. It says when overflow happens, the address of cq to be published is invalid. Actually the severer thing is the whole process of publishing the address of cq in this particular case is not right: it should truely publish the address and advance the cached_prod in cq as long as it reads descriptors from txq. The following is the full analysis. xsk_drop_skb() is called in three places, which all discard a partially built multi-buffer skb: 1) xsk_build_skb() -EOVERFLOW error path: packet exceeds MAX_SKB_FRAGS 2) __xsk_generic_xmit() post-loop cleanup: an invalid descriptor in the TX ring prevents the partial packet from completing 3) xsk_release(): socket close while xs->skb holds an incomplete packet In all three cases, the TX descriptors for the already-processed frags have been consumed from the TX ring (xskq_cons_release), and CQ slots have been reserved. However, xsk_drop_skb() calls xsk_consume_skb() which cancels the CQ reservations via xsk_cq_cancel_locked(). Since the buffer addresses never appear in the completion queue, userspace permanently loses track of these buffers. Fix this by letting consume_skb() trigger the existing xsk_destruct_skb destructor, which already submits buffer addresses to the CQ via xsk_cq_submit_addr_locked(). Note that cancelling the descriptors back to the TX ring (via xskq_cons_cancel_n) is not a appropriate option because an oversized packet that always exceeds MAX_SKB_FRAGS would be retried indefinitely, which is an obviously deadlock bug in the TX path. Also move the desc->addr assignment in xsk_build_skb() above the overflow check so that the current descriptor's address is recorded before a potential -EOVERFLOW jump to free_err, consistent with the zerocopy path in xsk_build_skb_zerocopy(). [1]: https://lore.kernel.org/all/20260425041726.85FB3C2BCB2@smtp.kernel.org/", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74563", "url": "https://ubuntu.com/security/CVE-2026-74563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: hold the RCU lock across ipv6_chk_addr() in rds_tcp_laddr_check() rds_tcp_laddr_check() looks up a scoped IPv6 interface with dev_get_by_index_rcu(), drops the RCU read-side lock, and only then passes the bare struct net_device * into ipv6_chk_addr(). dev_get_by_index_rcu() only keeps the device alive within the same RCU read-side section. After rcu_read_unlock(), a concurrent RTM_DELLINK can free the net_device; ipv6_chk_addr() then dereferences the stale pointer in __ipv6_chk_addr_and_flags() (e.g. l3mdev_master_dev_rcu(dev)), reading freed memory. Keep the RCU read-side lock held across the ipv6_chk_addr() call instead of dropping it right after the lookup, so the device cannot be freed while it is in use. BUG: KASAN: slab-use-after-free in __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) Read of size 8 at addr ffff8880106ec000 by task exploit/153 Call Trace: ... kasan_report (mm/kasan/report.c:595) __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) ipv6_chk_addr (net/ipv6/addrconf.c:2031 net/ipv6/addrconf.c:1972) rds_tcp_laddr_check (net/rds/tcp.c:370) rds_bind (net/rds/bind.c:248) __sys_bind (net/socket.c:1920) __x64_sys_bind (net/socket.c:1956) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74579", "url": "https://ubuntu.com/security/CVE-2026-74579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: fix mask build for partial field offload nft_payload_offload_mask() builds the offload match mask for a payload expression that covers only part of a header field. For a partial IPv6 address match (field_len = 16, priv_len = 1) that shift is 1 << 120, which is undefined on the 32-bit int operand. It also trims only one word, so the remaining words stay 0xffffffff (and when priv_len is a multiple of 4 the trim is skipped entirely), leaving the mask covering more bytes than the rule matches. UBSAN: shift-out-of-bounds in net/netfilter/nft_payload.c:278:20 shift exponent 120 is too large for 32-bit type 'int' ... The match is byte-granular and struct nft_data is zero-initialised, so the correct mask is simply the first priv_len bytes set to 0xff. Set those bytes directly and drop the word/shift trimming; this removes the undefined shift and no longer over-masks the trailing bytes.", "cve_priority": "medium", "cve_public_date": "2026-08-17 06:19:00 UTC" }, { "cve": "CVE-2026-74564", "url": "https://ubuntu.com/security/CVE-2026-74564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_hashlimit: validate hashtable supports XT_HASHLIMIT_RATE_MATCH The XT_HASHLIMIT_RATE_MATCH flag mode changes the semantics of the dsthash_ent structure which represents an entry in the hashtable. There is a union area which uses a different layout to express the rate match mode. Update .checkentry path to validate the XT_HASHLIMIT_RATE_MATCH mode flag is requested by two or more different rules that refer to the same hashtable. Otherwise, uninitialized access to the burst field in the union is possible. Reject the use of the XT_HASHLIMIT_RATE_MATCH mode flag if set on by revision less than 3 too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74565", "url": "https://ubuntu.com/security/CVE-2026-74565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: make nft_object rhltable per table The nft_object rhltable is global, this allows for accessing objects that are being dismangled from lookup path by other existing netns. Given the nft_obj_destroy() releases the object inmediately, this might lead to use-after-free of these objects that are being released. Make the existing rhltable per table to address this issue to deal with with the nft_rcv_nl_event() path too. Update nft_obj_lookup() to take the table as non-const, otherwise, compiler complains when passing the objname_ht to rhltable_lookup().", "cve_priority": "high", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74566", "url": "https://ubuntu.com/security/CVE-2026-74566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: make keyring key-chunk byte order agree with keyring_diff_objects() keyring_get_key_chunk() loads description bytes into the index chunk low address first, while keyring_diff_objects() numbers the first differing bit from the low end and folds the absolute byte index into the level without removing the inline-prefix offset the level already carries. The two disagree on byte order and bit position, so the array can be told two keys first differ at a bit that does not differ in the chunk the walker uses, letting crafted descriptions collide into one node. Load the chunk in the order keyring_diff_objects() assumes and drop the inline-prefix length when folding the byte index into the level. This only changes the in-memory ordering used to place keys within a keyring; add, search and read of non-colliding keys are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74567", "url": "https://ubuntu.com/security/CVE-2026-74567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: fix out-of-bounds read in keyring_get_key_chunk() For description-level chunks keyring_get_key_chunk() advances the read pointer by level * sizeof(long) past the inline prefix but only bounds-checks the prefix, so a long enough key description is read past its kmemdup(desc, desc_len + 1) allocation. Compute the full byte offset and bounds-check the description against it before reading. The walk only reaches a description-level chunk when two keys collide through the hash, x, type and domain_tag chunks, so this is reached from an unprivileged add_key(2) with a crafted pair of same-type keys whose index hashes collide; KASAN reports a slab-out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74569", "url": "https://ubuntu.com/security/CVE-2026-74569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in sip_help_tcp() sip_help_tcp() stores the size change of each NAT-rewritten SIP message in s16 diff and accumulates it in s16 tdiff, but a single message can grow by more than S16_MAX while the packet stays under the 65535 enlarge_skb() limit: nf_nat_sip() rewrites every matching URI, and a long Contact list expands the message by tens of kilobytes. diff then wraps, and \"datalen = datalen + diff - msglen\" yields a huge unsigned datalen, so the next iteration's ct_sip_get_header() reads past the linearized skb tail. Widen diff, tdiff and the seq_adjust hook to s32. Both are bounded by the 65535 byte packet limit, and the seqadj core is already s32 (nf_ct_seqadj_set() takes s32), so no previously accepted input is rejected. BUG: KASAN: use-after-free in ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) Read of size 1 at addr ffff888010800000 by task ksoftirqd/1/25 ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) sip_help_tcp (net/netfilter/nf_conntrack_sip.c:1694) nf_confirm (net/netfilter/nf_conntrack_proto.c:183) nf_hook_slow (net/netfilter/core.c:619) ip6_output (net/ipv6/ip6_output.c:246) ip6_forward (net/ipv6/ip6_output.c:690) ipv6_rcv (net/ipv6/ip6_input.c:351) __netif_receive_skb_one_core (net/core/dev.c:6212) process_backlog (net/core/dev.c:6676) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ...", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74572", "url": "https://ubuntu.com/security/CVE-2026-74572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix deadlock between metadata writeback and transaction commit When writing out metadata extent buffers in a zoned filesystem, btree_writepages() holds fs_info->zoned_meta_io_lock across the whole writeback loop, including the call to btrfs_check_meta_write_pointer() -> check_bg_is_active(). For the tree-log block group, check_bg_is_active() may fail to activate the zone and fall back to btrfs_zone_finish_one_bg() to free an active zone. That path waits for the running transaction to commit while still holding zoned_meta_io_lock, but the committer needs that same lock to write out the tree extents, so the two tasks deadlock: Task A (kworker, metadata writeback) Task B (fsstress, transaction commit) ------------------------------------ ------------------------------------- wb_workfn() btrfs_commit_transaction(T) btree_writepages() btrfs_write_and_wait_transaction() btrfs_zoned_meta_io_lock() btrfs_write_marked_extents() btrfs_check_meta_write_pointer() btree_writepages() check_bg_is_active() [treelog_bg] btrfs_zoned_meta_io_lock() btrfs_zone_finish_one_bg() do_zone_finish() btrfs_inc_block_group_ro() btrfs_wait_for_commit() The sibling branch in check_bg_is_active() already drops zoned_meta_io_lock around do_zone_finish() for this exact reason. Do the same in the tree-log branch: release the lock around btrfs_zone_finish_one_bg() and re-acquire it afterwards. The lock only protects fs_info->active_{meta,system}_bg, which this branch does not touch, and ctx->zoned_bg keeps a reference to the block group across the unlock, so nothing is lost while the lock is dropped. This hang occasionally reproduces with fstests generic/475 on a zoned btrfs filesystem.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74573", "url": "https://ubuntu.com/security/CVE-2026-74573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3-iommufd: Require exactly one Stream ID for a vDEVICE arm_vsmmu_vsid_to_sid() maps a guest's vSID to a single physical Stream ID taken from master->streams[0], assuming a device has exactly one stream. A device with several streams gets only its first one mapped, so a guest vSID invalidation cannot reach the others' ATC and IOTLB entries; a device with none makes master->streams a ZERO_SIZE_PTR, read out of bounds. Add an arm_vsmmu_vdevice_init() op to reject the vDEVICE with -EOPNOTSUPP when master->num_streams is not one, rather than mapping it silently.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74574", "url": "https://ubuntu.com/security/CVE-2026-74574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix fdev setup failure cleanup in idxd_cdev_open() The failed_dev_add and failed_dev_name paths drop the file-device reference while wq->wq_lock is still held. If put_device(fdev) drops the last reference, idxd_file_dev_release() runs synchronously and tries to take wq->wq_lock again, deadlocking. Those paths also fall through into the later ctx cleanup labels even though idxd_file_dev_release() owns that cleanup and frees ctx. This can make idxd_xa_pasid_remove(ctx) and kfree(ctx) operate on a freed context. Move idxd_wq_get() before file-device setup can fail, since the release callback always calls idxd_wq_put(). Then unlock wq->wq_lock before put_device(fdev) and return directly from the file-device setup failure path, leaving ctx cleanup to the release callback.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74575", "url": "https://ubuntu.com/security/CVE-2026-74575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Prevent XDomain delayed work use-after-free on disconnect tb_xdp_handle_request() runs on system_wq and queues xd->state_work via queue_delayed_work() in three request handlers: PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake), and LINK_STATE_CHANGE_REQUEST. Similarly, update_xdomain() queues xd->properties_changed_work when local properties change. Concurrently, tb_xdomain_remove() calls stop_handshake() which does cancel_delayed_work_sync() on both delayed works. Later, tb_xdomain_unregister() calls device_unregister() which eventually frees the xdomain. Since commit 559c1e1e0134 (\"thunderbolt: Run tb_xdp_handle_request() in system workqueue\") moved the request handler off tb->wq, the handler and the remove path are no longer serialized. If queue_delayed_work() executes after cancel_delayed_work_sync() but before the xdomain is freed, the delayed work fires on a freed object. Add xd->removing that tb_xdomain_remove() sets under xd->lock before calling stop_handshake(). Each external queue site holds the same lock and checks removing before calling queue_delayed_work(). This provides the mutual exclusion needed: either the queue site acquires the lock first and queues work that the subsequent cancel will see, or the remove path acquires the lock first and the queue site observes removing == true and skips the queue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74576", "url": "https://ubuntu.com/security/CVE-2026-74576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: prevent unbounded recursion in free path with new kmalloc type Commit 280ea9c3154b (\"mm/slab: avoid allocating slabobj_ext array from its own slab\") avoided recursive allocation of obj_exts from kmalloc caches of the same size, by bumping the obj_exts array's allocation size whenever the array size equals the size of the object being allocated. However, as reported by Danielle Costantino and Shakeel Butt, even slabs from kmalloc caches of different sizes can form a cycle by allocating obj_exts arrays from each other [1]: What happened: a KMALLOC_NORMAL slab's obj_exts array (used by allocation profiling / memcg accounting) is itself kmalloc()'d from a KMALLOC_NORMAL cache, so the \"slab holds another slab's obj_exts array\" relation can form cycles. With sizeof(struct slabobj_ext) == 16 and the host's geometry: - kmalloc-512 has 64 objects/slab -> array is 64*16 == 1024 bytes, served from kmalloc-1k; - kmalloc-1k has 32 objects/slab -> array is 32*16 == 512 bytes, served from kmalloc-512. A kmalloc-512 slab and a kmalloc-1k slab therefore hold each other's obj_exts array. Discarding one frees the other's array, which empties and discards that slab, which frees the first's array, and so on: __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() -> __free_slab() recurses along the cycle until the stack is exhausted. With memory allocation profiling, this allows unbounded recursion in the free path and led to a stack overflow on a production host in the Meta fleet [1]: BUG: TASK stack guard page was hit Oops: stack guard page RIP: 0010:kfree+0x8/0x5d0 Call Trace: __free_slab+0x66/0xc0 kfree+0x3f0/0x5d0 ... ( ~125x __free_slab <-> kfree ) ... do_syscall_64 It is proposed [1] to resolve this issue by always serving the obj_exts array allocation from kmalloc caches (or large kmalloc) of sizes larger than the object size. However, as pointed out by Vlastimil Babka [2], this can waste an excessive amount of memory as slabs from large kmalloc sizes (e.g. kmalloc-8k) generally need obj_exts arrays much smaller than the object size. Therefore, rather than bumping the size, let us take a different approach; disallow formation of cycles between kmalloc types when allocating obj_exts arrays. Currently, all obj_exts arrays are served from normal kmalloc caches. Cycles cannot be created if obj_exts arrays of normal kmalloc caches are served from a special kmalloc type that can never have obj_exts arrays. To achieve this, create a new kmalloc type called KMALLOC_NO_OBJ_EXT. KMALLOC_NO_OBJ_EXT caches are created with SLAB_NO_OBJ_EXT flag when either 1) memory allocation profiling is not permanently disabled, or 2) kmalloc types with a priority higher than KMALLOC_CGROUP are aliased with KMALLOC_NORMAL. Sheaf bootstrapping for KMALLOC_NO_OBJ_EXT caches now must be deferred because allocation of a barn can trigger obj_exts array allocation of normal kmalloc caches when the KMALLOC_NO_OBJ_EXT cache for that size is not ready yet. For simplicity, perform bootstrapping of sheaves for all kmalloc caches later. Introduce a new slab alloc flag, SLAB_ALLOC_NO_OBJ_EXT, to prevent allocation of obj_exts arrays, and let kmalloc_slab() override the type to KMALLOC_NO_OBJ_EXT when specified. Note that kmalloc_type() remains unchanged because kmalloc_flags() bypasses the kmalloc fastpath. Do not pass SLAB_ALLOC_NO_RECURSE to kmalloc_flags() in alloc_slab_obj_exts() and instead use SLAB_ALLOC_NO_OBJ_EXT only when the objects are allocated from normal kmalloc caches. While this prevents unbounded recursive allocation of obj_exts, it allows KMALLOC_NO_OBJ_EXT caches to have sheaves. Since sheaf allocations specify SLAB_ALLOC_NO_RECURSE that prevents allocation of both sheaves and obj_exts arrays, the recursion depth is bounded. obj_exts arrays for non- ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74577", "url": "https://ubuntu.com/security/CVE-2026-74577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: initialize rtm_tos in mpls_getroute() mpls_getroute() builds the RTM_NEWROUTE reply to an RTM_GETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (alloc_skb(NLMSG_GOODSIZE, ...)). It sets every field of the header except rtm_tos: \tr = nlmsg_data(nlh); \tr->rtm_family\t = AF_MPLS; \tr->rtm_dst_len\t= 20; \tr->rtm_src_len\t= 0; \tr->rtm_table\t= RT_TABLE_MAIN; \tr->rtm_type\t= RTN_UNICAST; \tr->rtm_scope\t= RT_SCOPE_UNIVERSE; \tr->rtm_protocol = rt->rt_protocol; \tr->rtm_flags\t= 0; struct rtmsg has no padding, so the one uninitialised byte rtm_tos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mpls_dump_route(), which fills the very same header and does set rtm_tos = 0. Initialize rtm_tos to 0, matching mpls_dump_route(). Reproduced with KMSAN by adding an MPLS route and issuing a non-RTM_F_FIB_MATCH RTM_GETROUTE for its label: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x36c/0x33f0 _copy_to_iter+0x36c/0x33f0 __skb_datagram_iter+0x196/0x12c0 skb_copy_datagram_iter+0x5b/0x210 netlink_recvmsg+0x37b/0xef0 ... Uninit was created at: __alloc_skb+0x8ca/0x10e0 mpls_getroute+0x1280/0x3a40 rtnetlink_rcv_msg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized (byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtm_tos)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" } ], "log": [ "", " * resolute/linux: 7.0.0-39.39 -proposed tracker (LP: #2168074)", "", " * Include v4l2loopback in default modules set for 26.04 (LP: #2168012)", " - [Packaging] Add dependency for v4l2loopback", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950)", " - fsnotify: inotify: pass mark connector to fsnotify_recalc_mask()", " - clk: qcom: gcc-mdm9607: Increase delay for USB PHY reset", " - usb: f_mass_storage: Bump local buffer size in fsg_common_create_luns()", " - usb: typec: qcom-pmic-typec: drain cc_debounce_dwork if port_start()", " fails", " - usb: typec: tcpm: constrain TCPM_SOURCING_VBUS event handling", " - usb: typec: tipd: Fix Thunderbolt altmode VDOs for cd321x", " - thermal/drivers/imx: Disable clock on runtime resume failure", " - thermal/drivers/qoriq: Disable clock on resume failure", " - userfaultfd: reset err to be 0 when move_pages_ptes succeeded", " - soc: qcom: geni-se: Use HW PROG_RAM_DEPTH to validate firmware size", " - spi: bcm63xx-hsspi: disable clocks on resume failure", " - spi: bcm63xx: disable clock on resume failure", " - spi: bcmbca-hsspi: disable clocks on resume failure", " - mm/damon/vaddr-kunit: check region count in three_regions test", " - samples/damon/mtier: handle damon_start() failure", " - samples/damon/prcl: handle damon_start() failure", " - samples/damon/prcl: stop and free damon ctx when damon_call() fails", " - samples/damon/wsse: stop and free damon ctx when damon_call() fails", " - mm/damon/sysfs-schemes: kobject_del() scheme action destination dirs", " - mm/damon/sysfs-schemes: kobject_del() scheme dirs", " - mm/damon/sysfs-schemes: kobject_del() scheme filter dirs", " - mm/damon/sysfs-schemes: kobject_del() scheme quota goal dirs", " - mm/damon/sysfs-schemes: kobject_del() scheme region dirs", " - mm/damon/sysfs: kobject_del() region and target (error) dirs", " - mm/damon/sysfs: kobject_del() target (normal), context and kdamond dirs", " - mm/damon/core-kunit: check region count before testing in split_at()", " - ftrace: Synchronize the initialization of ftrace_ops", " - dmaengine: dw-edma: Fix HDMA channel status register access", " - dmaengine: dw-edma: Complete descriptors before pausing", " - cpuidle: psci: Fix support for probe deferral by dropping the faux", " device", " - block: flag zoned disks with GENHD_FL_NO_PART", " - ata: ahci: work around lost interrupts on Marvell 88SE61xx", " - irqchip/stm32mp-exti: Fix the unit of the hwspinlock timeout", " - Input: aiptek - validate raw macro indices before updating state", " - memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper", " is done", " - memcg: make the v1 soft limit knob inert", " - rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt", " - rtc: rzn1: Fix weekday underflow when alarm crosses month boundary", " - rtc: rzn1: Handle unset alarm weekday in rzn1_rtc_read_alarm", " - rtc: rzn1: Disable alarm interrupt before reprogramming alarm registers", " - perf trace: Factor out BPF loop body", " - perf trace: Refactor augmented_raw_syscalls using bpf_for", " - perf hisi-ptt: Fix PTT trace TLP header parsing", " - i2c: designware: Enable interrupt mask workaround for HJMC3001", " - i2c: qcom-geni: update frequency table to fix timing parameters", " - arm64: mm: Fix the lockless page-table walk in show_pte()", " - arm64: errata: pass REVIDR when matching target implementation CPUs", " - ALSA: rawmidi: Return the error from snd_rawmidi_input_params()", " - pmdomain: airoha: fix unselectable AIROHA_CPU_PM_DOMAIN kconfig", " - Revert \"irqchip/mbigen: Fix mbigen node address layout\"", " - mm/hugetlb: fix missing migratable flag on same-node hugetlb migration", " - mm/hugetlb: keep max_huge_pages when dissolving surplus folios", " - mm/hugetlb_cgroup: call page_counter_set_max() outside VM_BUG_ON()", " - parisc: Fix alignment of asm statements in head.S", " - powerpc/pseries: Handle and log pseries-wdt registration failures", " - powerpc/pseries: Move H_WATCHDOG definitions to a common header", " - powerpc/crash: stop watchdogs before booting kdump kernel", " - s390/vfio-ap: Fix stale do_remove flag across iterations in", " vfio_ap_mdev_cfg_remove", " - s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap", " - s390/vfio-ap: Fix required lock not held during update of ap_matrix_mdev", " object", " - mtd: nand: realtek-ecc: add missing MODULE_DEVICE_TABLE()", " - batman-adv: mcast: ensure unshared skb for multicast packets", " - batman-adv: bla: prevent CRC corruptions after claim flush", " - clk: clocking-wizard: fix integer overflow in rate calculation", " - clk: mediatek: mt8196: Select REGMAP_MMIO for vlpckgen", " - clk: qcom: gcc-msm8916: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: qcom: gcc-msm8939: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: rockchip: rk3588: Don't change PLL rates when setting dclk_vop2_src", " - clk: qcom: gcc-mdm9607: Drop incorrect apss_tcu_clk_src", " - clk: qcom: gcc-mdm9607: Drop incorrect system_noc_bfdcd_clk_src", " - clk: qcom: gcc-mdm9607: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: qcom: gcc-mdm9607: Fix halt_reg for gcc_apss_axi_clk", " - clk: qcom: gcc-mdm9607: Drop incorrect BIMC PLL and related clocks", " - i2c: mux: demux-pinctrl: fix OF node leak on kstrdup failure", " - ASoC: fsl: mpc5200-i2s: Free DMA resources on probe failure", " - ASoC: fsl_easrc: Use div64_u64 for 64-by-64 division", " - AsoC: intel: sst: fix PCI device reference leak on probe failure", " - ASoC: samsung: aries_audio_probe: double of_node_put due to direct", " assignment without of_node_get", " - iio: adc: adi-axi-adc: add data size support for AD408X backend", " - iio: adc: max34408: add missing 'select REGMAP_I2C' to Kconfig", " - iio: adc: pac1921: fix wrong channel used in trigger handler read", " - iio: dac: ad3552r-hs: fix scnprintf() buffer bound in data source show", " - iio: gyro: mpu3050: fix sign of raw angular velocity readings", " - iio: light: cm32181: return zero after writing calibscale", " - iio: light: gp2ap002: Disable regulators on resume failure", " - iio: pressure: mpl115: Fix runtime PM cleanup", " - iio: srf04: fix pm_runtime handling on probe error path", " - iio: temperature: hid-sensor-temperature: switch to non-devm", " iio_device_register()", " - iio: ti-ads7138: Disable STATS_EN bit while reading conversion results", " - iio: light: opt4060: Reject integration times with a non-zero seconds", " part", " - iio: light: opt4060: Fix incorrect register name in threshold read error", " message", " - iio: light: opt4001: Fix power down clearing bits of the wrong register", " - iio: light: opt4001: Fix incompatible pointer type passed to", " div_u64_rem()", " - iio: light: opt4001: Reject integration times with a non-zero seconds", " part", " - iio: light: opt4001: Fix reversed GENMASK() arguments in fault count", " mask", " - KVM: PPC: Book3S HV: Validate arch_compat against host compatibility", " mode", " - KVM: nVMX: Decouple INVVPID operand checks from flushing of vpid02", " - KVM: x86/mmu: Fold kvm_mmu_zap_memslot() into", " kvm_arch_flush_shadow_memslot()", " - KVM: x86/mmu: Split kvm_mmu_zap_all_fast() into \"front\" and \"back\"", " halves", " - KVM: x86/mmu: Use CMPXCHG when clearing Accessed bit in TDP MMU", " - KVM: x86/mmu: Use split \"zap all fast\" helpers when invalidating memslot", " - KVM: x86: Serialize writes to disabled_quirks using kvm->lock", " - KVM: x86: Ensure runtime reads of disabled_quirks are resolved once", " - KVM: s390: Zero initialize irq in reinject_machine_check", " - KVM: s390: pv: Fix rc/rrc offset for PVM_DUMP", " - KVM: s390: Restore sigset on error path", " - KVM: arm64: Consider SCTLR_EL2.M when mapping the L1 VNCR page", " - KVM: arm64: vgic: Fix detection of MI on no pending LR", " - KVM: arm64: vgic: Reset in_kernel on private IRQ allocation failure", " - LoongArch: KVM: Fix PC double advance in kernel MMIO read fast path", " - LoongArch: KVM: Fix TOCTOU race on pv_features", " - LoongArch: Add DIRECT_MAP_PHYSMEM_END definition", " - LoongArch: BPF: Optimize redundant TCC loads in epilogue", " - LoongArch: Do not select HAVE_RUST when KASAN is enabled", " - rust: drm: ioctl: fix unbounded lifetimes in ioctl handler arguments", " - media: amphion: Remove obsolete frame_count check in venc_start_session", " - media: cec: meson: ao-cec-g12a: name the CEC core regmap to avoid", " debugfs clash", " - media: i2c: alvium: Fix: Correct name of register in", " alvium_set_ctrl_auto_exposure", " - media: i2c: imx415: Return test pattern write errors", " - media: imx355: Avoid calling imx355_power_off twice in error path", " - media: iris: Enumerate cap->bus_info to differentiate between encoder", " and decoder", " - media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common", " - media: nxp: imx8-isi: Fix stream ID validation bypass in crossbar", " routing", " - media: nxp: imx8-isi: Correct color map between V4L2 and ISI", " - media: nxp: imx8-isi: Use BIT_ULL() for 64-bit stream masks", " - media: rkvdec: Propagate platform_get_irq() errors", " - media: rzg2l-cru: Align bytesperline to hardware DMA stride requirement", " - media: v4l2-ctrls: Allow unknown HDR10 white point and luminance", " - media: venus: fix payload size returned by parse_caps() and", " parse_alloc_mode()", " - media: venus: fix payload size calculation in parse_raw_formats()", " - media: vimc: fix pixel format lookup in enum_framesizes", " - media: qcom: iris: fix state-change debug log printing stale value", " - media: chips-media: wave5: Guard bit depth check with", " initial_info_obtained", " - media: chips-media: wave5: Set inst->std during default format", " initialization", " - scsi: qla2xxx: Fix Name Server logout detection on FWI2 adapters", " - scsi: qla2xxx: Check entry_status in qla24xx_modify_vp_config()", " - scsi: qla2xxx: Fix response queue over-consumption in", " __qla_consume_iocb()", " - scsi: qla2xxx: Fix NVMe abort reference leak on repeated abort", " - scsi: qla2xxx: Drop vport reference under lock in report ID acquisition", " - scsi: qla2xxx: Use coherent DMA buffer for D_Port diagnostics", " - f2fs: return symlink writeback errors", " - f2fs: reject overlapping move range after len expansion", " - f2fs: fix to avoid move_range and defragment on device_alias file", " - f2fs: dirty directory inodes on mtime/ctime update", " - f2fs: return writeback error from collapse range", " - f2fs: fix to avoid potential section-unaligned pinfile", " - f2fs: fix i_size when pinned fallocate partially fails", " - f2fs: fix to off-by-one issue in f2fs_zero_post_eof_page()", " - f2fs: fix to zero post-EOF data when extending file size", " - drm/xe/vram: report FLAT_CCS base misalignment", " - drm/bridge: dw-hdmi: fix i2c adapter leak on probe failure", " - drm/ssd130x: fix column and row end address in partial updates for", " ssd132x", " - drm/sun4i: fix refcount leak in sun4i_backend_init_sat()", " - drm/ssd130x: fix column and row end address in partial updates in", " ssd133x", " - drm/nouveau/disp/r535: Add scanline position support + head state", " support", " - drm/hibmc: Fix list of formats on the primary plane", " - drm/hibmc: Use drm_atomic_helper_check_plane_state()", " - drm/gud: validate TV mode names before creating enum property", " - drm/msm/dsi: round 6G byte clock rate to the PLL-achievable value", " - drm/amdgpu: check thunderbolt before switcheroo registration", " - drm/amdgpu: Disable runtime PM for externally attached dGPUs", " - drm/amdgpu: fix autosuspend cleanup during removal", " - drm/amdgpu: Skip accessing psp rum time db for APUs", " - drm/amdgpu: update the fw version for gfx11 userqueues", " - drm/amdgpu: update the fw version for gfx12 userqueues", " - drm/amdgpu: use AMDGPU_GPU_PAGE_SHIFT instead of PAGE_SHIFT", " - drm/amdkfd: Reject zero-sized AQL queue allocations after size halving", " - drm/sysfb: simpledrm: Improve framebuffer-size validation", " - drm/sysfb: simpledrm: Improve panel-size validation", " - drm/sysfb: simpledrm: Improve stride validation", " - drm/sysfb: ofdrm: Fix is_avivo() constant comparison bug", " - drm/nouveau/gsp: use per-version DP_CONFIG_STREAM params on r570", " firmware", " - drm/nouveau: Use write-combined maps for coherent", " - drm/nouveau/disp: move GSP head-timing ISR and vblank helpers to tu102.c", " - drm/nouveau/disp: move the GSP HDMI GCP AVMute write to engine/disp", " - drm/nouveau/disp: route GSP-RM display MMIO through nvkm_disp_func hooks", " - drm/nouveau/disp: fix HDMI vendor infoframes on GB20x", " - drm/nouveau/disp: fix HDMI GCP AVMute register offsets on GB20x", " - drm/nouveau/disp: fix head state readback on GB20x", " - drm/nouveau/gsp: fix vblank interrupts on GB20x", " - fuse: split off fuse_args and related definitions into a separate header", " - fuse: remove fm arg of args->end callback", " - crypto: atmel-ecc - replace min_t with min", " - mm/hugetlb: defer vmemmap population for bootmem hugepages", " - mm/hugetlb: refactor code around vmemmap_walk", " - HID: sony: use guard() and scoped_guard()", " - ACPI: CPPC: Reject desired_perf reads on _CPC revision 4+", " - ACPI: x86: cmos_rtc: Create a CMOS RTC platform device", " - ACPI: TAD: Rearrange RT data validation checking", " - ACPI: TAD: Add locking around AML evaluations", " - bpf: Factor stackid_init function from __bpf_get_stackid", " - bpf: Factor stackid_fastpath function from __bpf_get_stackid", " - bpf: Factor stackid_new_bucket from __bpf_get_stackid", " - bpf: Use stack id functions instead of __bpf_get_stackid", " - sched: Add assert_balance_callbacks_empty helper", " - sched: Rework prev_balance() to avoid stale prev references", " - remoteproc: qcom: pas: Guard dtb metadata release with dtb_pas_id check", " - NFSD: Consolidate the revocation-path client unpin", " - mm: rework compound_head() for power-of-2 sizeof(struct page)", " - hugetlb: remove VMEMMAP_SYNCHRONIZE_RCU", " - Docs/ABI/damon: fix typo in intervals_goal sysfs path", " - power: supply: ab8500_fg: Remove redundant dev_err()/dev_err_probe()", " - mm/damon/tests/core-kunit: catch test failure in test_merge_regions_of()", " - mm/damon/vaddr: drop last same folio access check optimization", " - mm/damon/paddr: drop last same folio access check reuse optimization", " - mm/damon/ops-common: use nr_accesses moving sum for quota score", " - mm/damon/core: skip aging from repeated aggressive merging", " - mm/damon/sysfs: read addr_unit only once in damon_sysfs_apply_inputs()", " - mm/damon/core-kunit: handle region split failure in filter_out()", " - mm/damon/core: initialize damos->last_applied", " - mm/hugetlb_vmemmap: fix incorrect vmemmap restore in rollback", " - zram: move lockmap to be per-zram instead per table", " - ACPI: battery: Use kstrtoul() over sscanf(\"%lu\\n\")", " - ACPI: battery: Protect all properties with a separated mutex", " - NFSD: Annotate caller preconditions for the state-table walkers", " - usb: cdnsp: fix wakeup from S3 after controller context loss", " - usb: dwc3: google: Initialise probe properties with", " DWC3_DEFAULT_PROPERTIES", " - tracing/probes: Fix anon_stack check for unnamed bitfields in", " btf_find_struct_member", " - tracing: Remove the backup instance automatically after read", " - soc: fsl: qe: Add chained_irq_{enter,exit}() calls in cascade handler", " - mm/damon/sysfs: read ops_id only once in damon_sysfs_apply_inputs()", " - mm/damon/core-kunit: skip wrong dest walk in commit_dests_for()", " - mm/damon/core-kunit: skip wrong quota goal walk in commit_quota_goals()", " - mm/damon/core-kunit: skip wrong region walk in commit_target_regions()", " - mm/secretmem: properly account locked pages", " - futex: Provide rt_mutex_.*_schedule() equivalents for futex scheduling", " - bpf, riscv: Make arena support depend on ZACAS", " - misc: fastrpc: don't publish fd before copy_to_user() succeeds", " - perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities", " - perf build: Add clang and rust target flags for LoongArch", " - perf/core: Fix deadlock in perf_mmap() failure path", " - i2c: qcom-cci: Do not check return value of cci_init()", " - i2c: qcom-cci: Remove overcautious disable_irq() calls", " - i2c: qcom-cci: fix autosuspend cleanup", " - ring-buffer: Show persistent buffer dropped events in trace_pipe file", " - ring-buffer: Allow splice reads on static buffers", " - dma-buf: add dma_fence_was_initialized function v2", " - nvme: fold nvme_config_discard() into nvme_update_disk_info()", " - Revert \"once: don't use a work queue to reset sleepable static key\"", " - mm: fix incorrect vm_flags usage when checking allowable orders for", " tmpfs", " - mtd: rawnand: pl353: Make sure we use the monolithic helpers for raw", " accesses", " - mtd: rawnand: sunxi: group controller delay tables", " - mtd: rawnand: sunxi: describe tADL and tWHR delays", " - mtd: rawnand: sunxi: fix H6/H616 controller timings", " - batman-adv: fix TX priority extraction for BATADV_FORW_MCAST", " - clk: microchip: mpfs: fix regmap_update_bits() mask/val order", " - ASoC: adau1761: sort the register default table", " - ASoC: cx2072x: sort the register default table", " - ASoC: fsl_easrc: sort the register default table", " - ASoC: max9860: sort the register default table", " - ASoC: ml26124: sort the register default table", " - ASoC: pcm512x: sort the register default table", " - ASoC: pm4125-sdw: sort the register default table", " - ASoC: rt1017-sdca-sdw: sort the register default table", " - ASoC: rt1316-sdw: sort the register default table", " - ASoC: rt1318-sdw: sort the register default table", " - ASoC: rt1318: sort the register default table", " - ASoC: rt274: sort the register default table", " - ASoC: rt286: sort the register default table", " - ASoC: rt298: sort the register default table", " - ASoC: rt700: drop duplicate reg_default entry", " - ASoC: rt700: sort the register default table", " - ASoC: rt711-sdca: sort the register default tables", " - ASoC: rt711: sort the register default table", " - ASoC: rt712-sdca-dmic: sort the register default table", " - ASoC: rt712-sdca-sdw: sort the register default table", " - ASoC: rt715-sdca: drop duplicate reg_default entries", " - ASoC: rt715-sdca: sort the register default tables", " - ASoC: rt715: sort the register default table", " - ASoC: rt721-sdca-sdw: sort the register default table", " - ASoC: sgtl5000: sort the register default table", " - ASoC: sti-sas: sort the register default table", " - ASoC: tas2552: sort the register default table", " - ASoC: tas2764: sort the register default table", " - ASoC: tas2780: sort the register default table", " - ASoC: tas2783-sdw: drop duplicate reg_default entry", " - ASoC: tas2783-sdw: sort the register default table", " - iio: adc: ad4080: configure backend data size", " - iio: adc: max14001: add missing 'select REGMAP' to Kconfig", " - iio: dac: ad5446: fix OF module device table", " - iio: dac: mcp47feb02: add missing 'select REGMAP_I2C' to Kconfig", " - KVM: x86: Move some EFER bits enablement to common code", " - KVM: x86: Move enabling EFER.SVME and EFER.LMSLE to generic EFER setup", " - KVM: arm64: nv: Fully update VNCR fixmap state in kvm_translate_vncr()", " - LoongArch: Expand module virtual address space to 2GB", " - LoongArch: BPF: Fix off-by-one error for insn_is_cast_user()", " - media: dt-bindings: nxp,imx8-isi: Drop fsl,blk-ctrl requirement for", " i.MX8ULP", " - media: i2c: vd55g1: Fix manual digital gain on color variant", " - media: i2c: vd55g1: Fix media bus code initialization", " - media: mali-c55: fix dropped last AEC histogram zone weight", " - media: mali-c55: Fix clock leak on reset deassert failure", " - media: mali-c55: Fix AEXP IHIST disable bit shift", " - media: mali-c55: Fix scaler factor overflow for large crop sizes", " - media: rkvdec: hevc: tighten EXT SPS RPS control dimensions", " - media: chips-media: wave5: avoid skipping device_run while VPU has work", " - media: chips-media: wave5: Fix pipeline stall when queuing fails", " - f2fs: embed f2fs_gc_kthread in f2fs_sb_info", " - f2fs: fix to return -EFSCORRUPTED in f2fs_get_node_info() correctly", " - f2fs: fix to reclaim space in f2fs_allocate_pinning_section()", " - drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disable", " - drm/amd/display: Fix HPD consideration for VGA/LVDS connectors on DCE", " - drm/amd/display: Set gpuvm min page size to 4K on dcn35/36", " - drm/nouveau/dmem: fix callocated underflow on large folio split", " - PCI: Introduce PCI_SLOT_PLACEHOLDER constant for slot_nr placeholder", " value", " - Upstream stable to v6.18.51, v7.2.5", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89795", " - PCI: Allow per function PCI slots to fix slot reset on s390", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89796", " - mm/damon/core: avoid infinite kdamond_merge_regions() internal loop", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89804", " - drm/nouveau/dmem: fix mismatched DMA unmap size for large folios", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89809", " - drm/amdkfd: fix scope of mqd_mgr dereference in pqm_debugfs_mqds", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89812", " - drm/amdgpu: force complete the MES ring fences on reset", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89813", " - drm/amdgpu: force complete the KIQ ring fences on reset", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89815", " - drm/ttm: Drop tt->restore after successful restore", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89827", " - drm/amdgpu: avoid force-completing uninitialized UVD rings", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89831", " - f2fs: protect critical_task_priority updates with s_umount", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89836", " - f2fs: fix folio_nr_pages() race after put in large folio invalidate", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89838", " - f2fs: limit recovery filename logging to stored length", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89840", " - f2fs: validate MOVE_RANGE destination size", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89859", " - scsi: qla2xxx: Zero dport diagnostics buffer to avoid info leak", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89862", " - scsi: qla2xxx: Fix BSG job leak on validate flash image error path", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89866", " - media: chips-media: wave5: Resume device before setting EOS flag", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89867", " - media: chips-media: wave5: Defer job_finish() only when a DEC_PIC was", " queued", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89868", " - media: chips-media: wave5: Add timeout while stop_streaming", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89873", " - media: v4l2-ctrls: validate HEVC EXT SPS RPS counts", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89875", " - media: ti: vpe: quiesce overflow recovery before freeing streams", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89882", " - media: rkvdec: hevc: guard INTER_REF_PIC_SET_PRED index underflow", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89905", " - LoongArch: BPF: Move arena register slot below TCC context", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89915", " - KVM: arm64: Remove VM-wide VNCR mapping counter", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89917", " - KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR", " unmapping", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89919", " - KVM: s390: keyop: use mmu_lock to read gmap->asce", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89921", " - KVM: s390: Zero initialize data structures for inject_pfault_token", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89935", " - iio: light: apds9306: fix PM reference leak in apds9306_read_data()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89966", " - mm/hugetlb_cma: fix null nodemask dereference in", " hugetlb_cma_alloc_frozen_folio", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89967", " - mm/migrate_device: avoid out-of-bounds writes for compound folios", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89971", " - nvme: skip the zoned limits update if the zone info query failed", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89976", " - accel/ethosu: fix job completion fence cleanup", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89977", " - accel/ethosu: check MMIO mapping errors in probe", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89978", " - accel/amdxdna: return early from a zero-length flush", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89981", " - arm64: Don't read GMID_EL1 when MTE is disabled", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89791", " - perf: Fix use-after-free when perf mmap() revival races with the last", " munmap()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89987", " - mm/huge_memory: transfer the pmd dirty bit to the folio on zap", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89996", " - dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90002", " - ftrace: Take trace_array reference before accessing its ftrace_ops", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90013", " - tracing: Take trace_array reference when opening options file", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90014", " - tracing: Have show_event_filters/triggers files take trace array ref", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90016", " - staging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90023", " - usb: gadget: f_mass_storage: fix null pointer dereference in", " fsg_common_set_num_buffers()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90028", " - usb: typec: hd3ss3220: track VBUS enable state per consumer", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90040", " - KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is", " zapped", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90043", " - zram: fix slot lock bit position on big-endian 64-bit", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89794", " - ksmbd: zero pipe read compound padding", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89797", " - power: supply: ab8500_fg: fix use-after-free on remove", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90037", " - NFSD: Prevent client use-after-free during close_lru reaping", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90036", " - NFSD: Prevent client use-after-free during blocked-lock reaping", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89520", " - sched/core: Make core-sched flips wait for in-flight selections", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89798", " - rpcrdma: arm rn_done before publishing the notification", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89799", " - bpf: Disable preemption in bpf_get_stackid", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90041", " - HID: sony: clean up device list on probe failure", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90042", " - ceph: properly decrypt filenames in vmalloc() buffers", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90039", " - NFSD: Guard admin state-revocation walks with NFSD_NET_UP", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90044", " - usb: gadget: f_fs: Fix Use-After-Free in AIO error path", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90045", " - USB: gadget: ffs: fix mm lifetime handling", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90046", " - mm/page_alloc: don't spin_trylock() in NMI on UP", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-80926", " - ksmbd: fix use-after-free in oplock break notification", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89800", " - drm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSE", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89801", " - drm/nouveau/uvmm: fix premature region free on failed OP_UNMAP_SPARSE", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89802", " - drm/nouveau/uvmm: fix NULL deref unwinding an OP_MAP_SPARSE op", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89803", " - drm/nouveau: unsubscribe the channel-kill event before the fence context", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89806", " - drm/sysfb: ofdrm: Fix integer overflow in fb_size calculation", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89807", " - drm/amdkfd: guard against NULL restore_mqd in CRIU queue restore", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89808", " - drm/amdkfd: Fix the case that vm range is hole at", " svm_migrate_copy_to_vram", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89810", " - drm/amdkfd: Fix error path at svm_migrate_copy_to_ram", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89811", " - drm/amdkfd: Add TLB flush after MES queue eviction/suspension", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89814", " - drm/amdgpu: clamp the isolation index for rings outside a partition", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89816", " - drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89817", " - drm/gud: NUL-terminate TV mode names read from the device", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89818", " - drm/amdgpu/vcn: fix integer overflow in dec_msg buffer count check", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89819", " - drm/amd/display: validate plane degamma LUT size for private color prop", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89820", " - drm/amd/display: fix dc_lock leak on GPU reset error paths", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89821", " - drm/amd/display: avoid divide-by-zero in __is_lut_linear()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89822", " - drm/i915: Guard against NULL driver_data in i915_pci_probe()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89823", " - drm: fix race between partial drm_dev_register() failure and ioctl", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89824", " - drm/panel-edp: fix i2c adapter leak on probe failure", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89825", " - drm/panthor: fix firmware control interface bounds checks", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89826", " - drm/panthor: harden firmware build-info bounds checks", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89828", " - drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89829", " - f2fs: fix to pass folio->index to f2fs_sanity_check_node_footer()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89830", " - f2fs: fix valid block count leak on data block allocation failure", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89832", " - f2fs: fix to clear dirty flag on folio in error path", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89833", " - f2fs: fix to avoid potential deadloop in f2fs_fsync_node_pages()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89834", " - f2fs: fix to migrate all curseg types during free_segment_range", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89835", " - f2fs: avoid NULL checkpoint thread access in sysfs", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89837", " - f2fs: fix dentry folio leak in find_in_level", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89839", " - f2fs: use the mount idmap for the owner check in f2fs_xattr_advise_set()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89841", " - f2fs: only redirty pinned folios in redirty_blocks", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89842", " - scsi: qla2xxx: Skip NVMe LS reject IOCB when FW not started", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89843", " - scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89844", " - scsi: qla2xxx: Hold vport_slock for host map update in report ID", " acquisition", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89845", " - scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89846", " - scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89847", " - scsi: qla2xxx: Avoid double completion in async IOCB timeout", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89848", " - scsi: qla2xxx: Quiesce response IRQ before freeing request queue", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89849", " - scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89850", " - scsi: qla2xxx: Don't query firmware state while chip is down", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89851", " - scsi: qla2xxx: Fix FCE trace enable parsing in debugfs", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89852", " - scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89853", " - scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89854", " - scsi: qla2xxx: Fix cs84xx use-after-free on host teardown", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89855", " - scsi: qla2xxx: Serialize flash version read in reset handler", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89856", " - scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89857", " - scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89858", " - scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89860", " - scsi: qla2xxx: Initialize NVMe abort_work once at submission", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89861", " - scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89863", " - scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89864", " - scsi: qla2xxx: Bound i2c->length in I2C bsg handlers", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89865", " - scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89869", " - media: qcom: iris: use disable_irq() during power-off", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89870", " - media: zoran: Avoid freeing a registered video_device twice", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89871", " - media: video-i2c: fix kthread error pointer left in kthread_vid_cap on", " failure", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89872", " - media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89874", " - media: v4l2-async: avoid deleting unlinked ASC entry on link error", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89876", " - media: tda18250: fix possible integer overflow", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89877", " - media: saa7164: fix cleanup on resource allocation failure", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89878", " - media: s2255: check firmware size before reading trailing marker", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89879", " - media: s2255: bound JPEG frame size before copying into the buffer", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89880", " - media: rtl2832_sdr: release URBs and stream buffers on start_streaming()", " failure", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89881", " - media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix", " DMA leak", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89883", " - media: rc: sunxi-cir: Unregister rc device on probe failure", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89884", " - media: platform: mtk-mdp3: fix NULL deref on failed SCP lookup", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89885", " - media: platform: mtk-mdp3: Fix SCP device refcounting", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89886", " - media: intel/ipu6: fix async notifier cleanup leak on parse error", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89887", " - media: i2c: ov7740: fix use-after-destroy in remove", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89888", " - media: i2c: ov02a10: fix endpoint parsing use-after-free", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89889", " - media: i2c: imx415: Release runtime PM reference on VBLANK error", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89890", " - media: go7007: defer the ALSA v4l2 put until card release", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89891", " - media: em28xx: fix use-after-free of dev_next->devlist on disconnect", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89892", " - media: em28xx: defer audio-only extension registration", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89893", " - media: cx23885: cancel NetUP CI work before teardown", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89894", " - media: cx231xx: reject geometry changes while the VBI queue is busy", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89895", " - media: cobalt: Avoid freeing ALSA private data twice", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89896", " - media: cedrus: fix memory leak in cedrus_init_ctrls()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89897", " - media: cec: Serialize exclusive follower delivery", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89898", " - media: cec: extron-da-hd-4k-plus: add sanity check", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89899", " - media: cec: disable delayed work before freeing an interrupted transmit", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89901", " - media: airspy: use vb2_video_unregister_device() on disconnect to fix", " NULL deref", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89902", " - LoongArch: Avoid preempt count underflow without probe", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89903", " - LoongArch: Do not save/restore percpu base register in rethook", " trampoline", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89904", " - LoongArch: Fix acpi_package_ids[] array overflow", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89906", " - LoongArch: BPF: Refactor jump offset calculation in tail call", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89908", " - LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89909", " - LoongArch: KVM: Free init resources if kvm_init() fails", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89911", " - KVM: arm64: Correctly cap TLBI Range to the architural limit", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89912", " - KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89913", " - KVM: arm64: vgic-v3: take an LPI reference in", " vgic_v3_save_pending_tables", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89914", " - KVM: arm64: Sign-extend VA for range-based TLBI invalidation", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89916", " - KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89918", " - KVM: arm64: Correctly handle end of VA space TLBI invalidation", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89775", " - KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89920", " - KVM: s390: Fix memory corruption by not reinjecting CK machine checks", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89922", " - KVM: s390: Take srcu when importing watchpoint data", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89923", " - KVM: s390: Free guest debug data on vcpu destroy", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89924", " - KVM: s390: Fix old_data leak in guest debug error path", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89925", " - KVM: s390: Fix memory leak in guest debug handling", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89926", " - KVM: s390: Fix length check __import_wp_info()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89927", " - KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89928", " - KVM: x86/mmu: Consume the locked rmap value in the lockless rmap walk", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89929", " - KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89930", " - KVM: nVMX: Service local TLB flushes on failed nested VM-Enter", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89931", " - KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89932", " - KVM: nVMX: Always flush vpid02 on first use", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89933", " - iio: pressure: dps310: fix NULL pointer dereference on ACPI probe", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89934", " - iio: light: ltrf216a: fix runtime PM reference leak in error path", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89936", " - iio: dac: m62332: Fix regulator reference count imbalance", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89937", " - iio: chemical: sgp30: Handle IAQ thread creation failure", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89938", " - iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove", " UAF", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89939", " - iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89940", " - iio: buffer: Tie IIO dma fence lock lifetime to the fence", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89941", " - iio: buffer: Make IIO DMA fence release RCU-safe", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89942", " - iio: buffer: Fix potential use-after-free in anonymous buffer release", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89943", " - ASoC: loongson: Fix error handling in ACPI property parsing", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89944", " - ASoC: hdac_hda: Fix hlink refcount leak on component registration", " failure", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89945", " - ASoC: cs35l34: drain threaded IRQ before runtime suspend", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89946", " - ASoC: cs35l33: drain threaded IRQ before runtime suspend", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89947", " - clk: meson: align gxbb_32k_clk_sel number of parents with actual count", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89948", " - batman-adv: bla: fix freeing of claims on meshif deletion", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89949", " - batman-adv: dat: avoid unaligned fault in IP extraction", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89950", " - batman-adv: mcast: linearize skbuff for packet generation", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89951", " - batman-adv: fix stale receive device on merged fragments", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89952", " - mtd: rawnand: validate ONFI extended parameter page sections", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89953", " - mtd: mtdoops: free page bitmap when the backing MTD is removed", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89954", " - mtd: afs: validate v2 image info bounds", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89955", " - s390/vfio-ap: Fix NULL deref in status_show() during queue probe", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89956", " - s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev", " objects", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89957", " - s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain", " removed", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89958", " - s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89959", " - s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89960", " - s390/vfio-ap: fix stale pqap_hook pointer on error in", " vfio_ap_mdev_set_kvm()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89961", " - powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89962", " - powerpc/kexec_file: Prevent kexec range truncation", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89963", " - powerpc/kexec_file: Fix null-ptr-def in extra size calculation", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89964", " - parisc: eisa: Fix infinite loop when parsing invalid IRQ value", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89965", " - nvdimm/btt: reject an arena whose nfree is below the lane count", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89968", " - nvmet-tcp: reject unsolicited H2CData PDUs", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89969", " - nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89970", " - nvmet-auth: Synchronize timeout work during SQ teardown", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89972", " - nvme: add missing SRCU grace period in error path", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89973", " - nvme-tcp: check the data direction of a C2HData PDU", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89974", " - nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89975", " - nvme-fabrics: fix DHCHAP secret leak on parse failure", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89979", " - ALSA: pcm: Fix race between non-atomic ops and trigger-start", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89980", " - ALSA: harmony: initialize locks before requesting IRQ", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89982", " - i2c: mux: Fix channel node leak on adapter add failure", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89983", " - i2c: core: fix debugfs UAF on adapter removal", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89984", " - perf/x86/intel: Fix kernel address leakages in LBR stack", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90048", " - fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89986", " - mm/mempolicy: fix sleeping allocation in", " alloc_pages_bulk_weighted_interleave()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89988", " - kprobes: Protect kprobe_blacklist with RCU", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89989", " - ima: Check for ERR_PTR from dentry_path() in validate_hash_algo()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89990", " - ceph: lock mutex in ceph_mds_check_access()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89991", " - bpf: Fix infinite loop in pcpu_freelist push with one possible CPU", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89992", " - cpuidle: dt_idle_genpd: kfree() the original name allocation", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89993", " - dmaengine: dw-edma: Initialize IRQ data before requesting IRQs", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89994", " - dmaengine: fsl-edma: tracing: no ptr dereference during log output", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89995", " - dma-direct: return struct page from dma_direct_alloc_from_pool()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89997", " - dm: fix resume-vs-remove race", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89998", " - dm: fix race when loading and unloading a table", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89999", " - HID: wacom: validate report length in wacom_intuos_pro2_bt_irq", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90000", " - HID: rmi: fix OOB access with undersized RMI reports", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90001", " - HID: bpf: serialize device reference release in struct_ops destroy path", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90003", " - futex: Prevent rcuwait use-after-free during requeue PI", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90005", " - samples/damon/wsse: handle damon_start() failure", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90006", " - samples/damon/mtier: handle damon_stop() failure", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90007", " - scsi: pm8001: Use rollback index when freeing MSI-X vectors", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90011", " - scsi: target: iscsi: Reserve a terminator byte for the login payload", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90012", " - spi: Fix DMA mapping ownership on partial map failure", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-89793", " - ublk: clear VM_MAYWRITE on read-only ublk char device mmap", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90015", " - xhci: fix lost bounce buffers on TDs spanning several ring segments", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90017", " - staging: rtl8723bs: fix OOB read in rtw_action_frame_parse()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90018", " - staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90019", " - usb: gadget: fix null pointer dereference in usb_put_function_instance()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90020", " - USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90021", " - usb: gadget: f_midi: initialize work in f_midi_alloc()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90022", " - usb: gadget: f_midi2: fix use-after-free in string attribute show path", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90024", " - usb: gadget: midi2: Fix null-pointer dereference in f_midi2_free_ep_reqs", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90025", " - usb: typec: ucsi: displayport: Fix OOB altmode array index", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90026", " - usb: typec: qcom-pmic: cancel reset_work on stop", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90027", " - usb: typec: qcom-pmic-typec: disable cc_debounce_dwork on stop", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90029", " - usb: storage: realtek_cr: fix use-after-free on disconnect", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90030", " - usb: dwc3: clear forceRM when issuing EndTransfer", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90031", " - usb-storage: ene_ub6250: fix race between scan work and probe", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90032", " - media: usbtv: keep device alive while ALSA card exists", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90033", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90034", " - usb: image: mdc800: change kmalloc() to kzalloc()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90035", " - drm/amd/display: fix division by zero in get_estimated_bw()", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90047", " - drm/xe: Don't hand out the flat CCS storage as usable VRAM", "", " * Resolute update: upstream stable patchset 2026-09-22 (LP: #2167950) //", " CVE-2026-90049", " - net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy()", "", " * Resolute update: upstream stable patchset 2026-09-17 (LP: #2167609)", " - [Config] Remove CONFIG_CRYPTO_DEV_SUN8I_CE_PRNG", " - [Config] Remove CONFIG_CRYPTO_DEV_SUN8I_SS_PRNG", " - ASoC: tegra210_i2s: sort the register default table", " - ASoC: tegra210_i2s: sort the Tegra264 register default table", " - ASoC: tegra210_mixer: sort the register default table", " - ASoC: tegra: Fix the I2S enable default value", " - ASoC: tegra: Fix the MIXER enable default value", " - ASoC: tegra: Sort ADMAIF register defaults", " - ASoC: tegra: Sort MBDRC register defaults", " - ring-buffer: Fix subbuf resize race with ring buffer readers", " - drm/amd/display: hide Apple Studio Display secondary tile", " - drm/amd/display: Prune per-tile Timing from Apple Studio Display Primary", " Tile", " - alpha: fix ieee_swcr_to_fpcr setting FPCR_DNOD unconditionally", " - rust: time: fix as_micros_ceil() rounding near i64::MAX", " - alpha: don't leak hardware-fabricated FP exception bits to user space", " - clocksource/drivers/nxp-pit: Fix IRQ leak on cpuhp_setup_state error", " path", " - clocksource/drivers/timer-sun4i: Advertise a real minimum delta", " - fs: fix user path of nested backing files", " - ovl: fix double end_creating() on the casefold-mismatch path", " - pidfd: hold exec_update_lock around namespace ioctl", " - powerpc/pseries/iommu: switch to Default DMA window during kdump", " - rust: fmt: fix {:p} printing stack addresses", " - timers/itimer: Zero-init old itimerval before copy to userspace", " - objtool/rust: add one more `noreturn` Rust function for Rust 1.99.0", " - rust: bug: skip arch-specific asm in `testlib` builds", " - rust: bug: fix warn_on macro build error on UML", " - rust: bug: prevent dead_code warning from warn_on!'s flags constant", " - rust: rust_is_available: warn for `bindgen` < 0.72.1 && libclang >= 22", " - rust: kernel: list: fix incorrect pop_back example comment", " - objtool/rust: add one more `noreturn` Rust function", " - rust: num: restrict bool conversion to unsigned Bounded", " - rust: cfi: disable function merging if CFI is enabled", " - KEYS: trusted: Fix TPM teardown ordering", " - apparmor: fix cred UAF caused by begin_current_label_crit_section()", " - apparmor: fix out-of-bounds write when null terminating a label vec", " - include/linux/list.h: mark list_add and __list_add as __always_inline", " - mm, swap: ratelimit bad swap entry reports", " - mm/gup: fix always draining LRU caches in", " collect_longterm_unpinnable_folios()", " - mm/huge_memory: skip device-private PMDs in madvise_free_huge_pmd", " - mm/huge_memory: use folio's memcg inside __folio_split()", " - mm/hugetlb: initialize gigantic bootmem hugepage struct pages earlier", " - mm/hugetlb_vmemmap: fix __hugetlb_vmemmap_optimize_folios()", " - mm/kmemleak: avoid soft lockup when scanning task stacks", " - mm/madvise: skip device-private PMDs in cold and pageout walks", " - mm/mempolicy: skip non-present PMDs when queueing folios", " - mm/mglru: use the common routine for dirty/writeback reactivation", " - mm/mglru: fix and remove redundant unevictable folio handling", " - mm/migrate: report RCU-tasks quiescent states in migrate_pages_batch()", " - mm/migrate: use huge_ptep_get() in remove_migration_pte()", " - mm/migrate_device: clear stale mapping after freeing swapcache", " - mm/mm_init: deferred_grow_zone(): fix out-of-range first_deferred_pfn", " - mm/page_owner: use memcg_data snapshot to avoid TOCTOU in", " print_page_owner_memcg()", " - mm/page_vma_mapped: use huge_ptep_get() for hugetlb", " - mm/pagewalk: fix stale walk->action escaping walk_pmd_range()", " - mm/rmap: use huge_ptep_get() in try_to_unmap_one()", " - mm/rmap: use huge_ptep_get() in try_to_migrate_one()", " - mm/slub: fix missing debugfs entries for caches created before sysfs", " init", " - mm/slub: prevent pfmemalloc objects from entering the barn", " - mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec()", " - mm/zswap: fix global shrinker when memory cgroup is disabled", " - mm: compaction: support non-movable compaction for pageblock requests", " - mm: memcg-v1: fix wrong linux-mm list address in deprecation warnings", " - mm: memcg-v1: fix memsw and TCP failcnt accounting", " - mm: memcg: stop reclaim when a limit update is superseded", " - mm: memcontrol: update state_local when flushing NMI stats", " - mm: mempolicy: fix automatic numa balancing for shmem", " - mm: page_alloc: __GFP_FS lockdep annotation for direct compaction", " - mm: page_alloc: move capture_control to the page allocator", " - mm: page_alloc: fix non-movable reclaim storm in defrag_mode", " - mm: vmscan: fix node reclaim ignoring swappiness parameter", " - tools/compiler: match glibc 2.42 definition of __attribute_const__", " - x86/locking: Use sfence for wmb() if SSE is available", " - x86/insn-eval: Move assign_register() out of KVM as insn_assign_reg()", " - x86/tdx: Fix off-by-one in port I/O handling", " - x86/tdx: Fix zero-extension for 32-bit port I/O", " - x86/xen: fix init of balloon stats again", " - hwtracing: hisi_ptt: Propagate DMA reset timeout in trace_start()", " - tracing/user_events: Clear copied tracing state before fork duplication", " - tracing: Fix crash passing ERR_PTR to kthread_stop()", " - tracing: Fix logged instance name on creation failure", " - tracing: Fix use-after-free in trace_pipe read on sub-buffer order", " change", " - tracing: Fix use-after-free with same-name named triggers", " - cdx: Fix double free when sysfs file creation fails", " - debugfs: Fix lockdown check for mmap_prepare", " - device property: fix infinite loop in fwnode_for_each_child_node()", " - misc: nsm: bound the device-reported response length", " - powerpc/powermac: fix OF node refcount", " - rapidio: mport_cdev: fix use-after-free in dma_req_free()", " - Revert \"media: v4l2-dev: fix error handling in", " __video_register_device()\"", " - serial: imx: serialize imx_uart_ports[] lifetime", " - staging: greybus: hid: fix SET_REPORT return value", " - usb: dwc2: gadget: Exit partial power down state when changing USB pull-", " up", " - usb: dwc3: gadget: Fix use-after-free in dwc3_gadget_free_endpoints due", " to race condition", " - usb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed", " - USB: phy: fsl-usb: fix missing static keywords", " - usb: typec: hd3ss3220: fix VBUS regulator error message", " - usb: typec: tcpci: pass correct rx_type to tcpm_pd_receive()", " - usb: typec: thunderbolt: Disable work before freeing tbt on remove", " - usb: typec: ucsi: use UCSI_TIMEOUT_MS for sync command completion", " - usb: gadget: u_audio: Fix use-after-free on sound card disconnect", " - usb: gadget: snps_udc_plat: clean up PHY on probe deferral", " - usb: gadget: midi2: remove default configfs groups on teardown", " - usb: gadget: f_tcm: fix deadlock in usbg_make_tpg()", " - usb: gadget: uvc: Fix null pointer dereference in uvcg_video_init()", " - usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and", " uvc_function_unbind()", " - usb: gadget: f_fs: Prevent deadlock during ep0 read loop", " - cxl/ras: Fix cxl_rch_get_aer_info() out-of-bounds AER register read", " - fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write", " - HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature", " - i3c: renesas: Fix out-of-bounds access for newdevs mask", " - KVM: arm64: GICv2: Don't WARN on out-of-range GICV_DIR INTID", " - lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()", " - media: cec: stm32: prevent out-of-bounds write on RX overflow", " - media: vicodec: fix out-of-bounds write in FWHT encoder", " - nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after", " truncation", " - of: fix out-of-bounds read in of_alias_scan() stem parser", " - PCI/sysfs: Fix out-of-bounds read in pci_write_legacy_io()", " - phy: rockchip-samsung-dcphy: fix out-of-range max_register", " - ubifs: fix out-of-bounds read in signature length check", " - zram: fix out-of-bounds access in read_block_state()", " - zram: fix out-of-bounds access in writeback_store()", " - zram: set default primary compressor in zram_destroy_comps()", " - zram: validate deflate params", " - zsmalloc: account for handle size in class lookup", " - NFS/localio: fix ref leak on nfs_uuid_add_file failure", " - NFS: fix delegation_hash_table leak when nfs4_server_common_setup()", " fails", " - NFSD: check truncate permission under inode lock", " - NFSD: Encode only the status in NFS-ACL v2 GETACL error replies", " - NFSD: Fix off-by-one in DRC bucket pruning limit", " - NFSD: fix up error returned by write_threads()", " - NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock", " - NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check", " - nfsd: guard nfsd_serv deref in nfsd_file_net_dispose", " - NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget", " path", " - pNFS: Fix EBUSY check in pnfs_layout_need_return", " - lockd, nfsd: RCU-protect nlmsvc_ops dispatch", " - nfsd: RCU-protect cl_cb_session to fix use-after-free on session", " teardown", " - nfsd: release path refs on follow_down() error", " - nfsd: Reset write verifier when async COPY writeback fails", " - nfsd: restore rq_status_counter to even on all nfsd_dispatch() exit", " paths", " - nfsd: return NFS4ERR_NOTSUPP for unsupported netloc4 types", " - nfsd: sample writeback error cursor before async COPY loop", " - nfsd: set SC_STATUS_FREED in nfsd4_drop_revoked_stid for delegations", " - nfsd: size fh_verify server sockaddr slot by xpt_locallen", " - nfsd: validate nseconds in TIME_DELEG decode paths", " - nfsd: validate sockaddr length per family in listener_set", " - nfsd: validate symlink target length in NFSv4 CREATE", " - nfsd: move struct nfsd_genl_rqstp to nfsctl.c", " - nfsd: widen nfsd_genl_rqstp address fields to sockaddr_storage", " - nfsd: add fh_want_write() for early-verified SETATTR in", " nfsd_proc_setattr()", " - nfsd: add filehandle match check to nfsd4_delegreturn()", " - nfsd: add missing read barrier to rpc_status_get dumpit seqcount retry", " - nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref", " - nfsd: cap decoded POSIX ACL count to bound sort cost", " - nfsd: check client ownership when cancelling a copy-notify stateid", " - nfsd: check nfsd4_acl_to_attr() return value in nfsd4_create()", " - nfsd: clear CALLBACK_RUNNING on failed delegation recall queue", " - nfsd: clear opcnt on compound arg release to prevent OOB read", " - nfsd: convert nfsd_net boolean flags to unsigned long flags word", " - nfsd: dedup nfs4_client_to_reclaim inserts", " - nfsd: defer setting NFSD4_CALLBACK_RUNNING in deleg_reaper", " - nfsd: defer vfree of compound ops to fix rpc_status UAF", " - nfsd: don't free session slots that are still in use", " - nfsd: drop the stateid, not the stateowner, on seqid_op replay retry", " - nfsd: ensure nfsd_file_do_acquire() does not use a non-opened file", " - nfsd: fix BUG_ON in nfsd4_alloc_layout_stateid on racing delegation", " revoke", " - nfsd: fix clock domain mismatch in clients_still_reclaiming()", " - nfsd: fix cpntf publish race in nfs4_init_cp_state", " - nfsd: fix dentry ref leak on V4ROOT export filehandle lookup", " - nfsd: fix fcache_disposal UAF by inlining dispose state into nfsd_net", " - nfsd: fix FL_SLEEP being set unconditionally for all LOCK types", " - nfsd: fix netlink dumpit error handling for rpc_status_get", " - nfsd: fix nfsd_file leak on inter-server COPY setup failure", " - nfsd: fix null dereference in nfsd4_setattr for deleg timestamp attrs", " - nfsd: fix partial-write detection in nfsd_direct_write", " - nfsd: fix possible fh_compose of wrong dentry in nfsd4_create_file()", " - nfsd: fix refcount leak in nfsd_file_lru_add on insertion failure", " - nfsd: fix reply size estimate for GET_DIR_DELEGATION", " - nfsd: fix stale s2s_cp_stateids IDR entry for async COPY", " - nfsd: fix UAF in async copy cancel and shutdown", " - nfsd: fix version mismatch loops in nfsd_acl_init_request()", " - nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget", " - nfsd: fix XDR padding calculation in ff_encode_getdeviceinfo", " - nfsd: gate nfs2 setacl by argp->mask", " - nfsd: gate nfs3 setacl by argp->mask", " - nfsd: hold rcu across localio cmpxchg retry", " - nfsd: initialize copy-notify stateid before publishing it", " - nfsd: initialize DRC hash table before registering shrinker", " - nfsd: move nfsd_debugfs_init() after nfsd4_init_slabs() in init_nfsd()", " - nfsd: close shrinker/GC/fsnotify vs per-net shutdown race in filecache", " - nfsd: reject out-of-range nseconds in NFSv3 SETATTR and create ops", " - nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE", " - nfsd: reject reclaim LOCK after RECLAIM_COMPLETE", " - nfsd: release OPEN-decoded posix ACLs via op_release", " - nfsd: revoke copy-notify stateids before dropping their reference", " - NFSD: Prevent lock owner use-after-free during client teardown", " - NFSD: Prevent post-shutdown use-after-free in unlock_filesystem", " - NFSD: Prevent client use-after-free during admin state revocation", " - nfsd: convert global state_lock to per-net deleg_lock", " - NFSD: Prevent client use-after-free during delegation revoke", " - NFSD: Prevent client use-after-free during NFSv4.0 revoked-state cleanup", " - nfsd: use test_and_clear_bit for somebody_reclaimed to prevent lost", " update", " - libceph: validate OSD extent maps before cursor advance", " - libceph: reject buckets with mismatched CRUSH ids", " - ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock", " - ceph: fix UAF in check_new_map() on session freed during unlock", " - ceph: force a cap message when a deferred revoke can't be acked", " immediately", " - ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode", " - ceph: bound copied dentry name length in NFS export get_name", " - ceph: bound MDSCapAuth path and fs_name decode in handle_session()", " - ceph: bound num_export_targets array for mds info v2/v3", " - ceph: bound xattr value length in __build_xattrs()", " - ceph: cap delegated inode count in ceph_parse_deleg_inos()", " - ceph: do not repeat ceph_trim_dentries() if no progress possible", " - ceph: fix leaked inode reference on writeback abort at umount", " - btrfs: drop recovered reloc root refs on recovery failure", " - btrfs: fix extent map leak in NOCOW direct I/O write", " - btrfs: do not overwrite NODATASUM flag when removing NODATACOW flag", " - audit: avoid dropping live tree ref on fsnotify rule autoremove", " - smb: move some definitions from common/smb2pdu.h into common/fscc.h", " - smb/client: reduce fallocate zero buffer allocation", " - smb/client: emulate small EOF-extending mode 0 fallocate ranges", " - cifs: add cifs_resize_file_locked() to guard fscache_resize_cookie()", " under i_rwsem", " - smb/client: do not account EOF extension as allocation", " - cifs: call pagecache_isize_extended() in cifs_setsize() when extending", " - cifs: clear tcon after cifsFileInfo_put() in cifs_file_set_size()", " - cifs: fix loff_t underflow in cifs_remap_file_range() when len == 0", " - cifs: use cifs_invalidate_cache() in cifs_do_truncate() for O_TRUNC", " - smb: client: clear setuid/setgid bit on write with", " cifsacl/modefromsid/posix extensions", " - smb: client: fix UAF and buffer leak in cifs_check_trans2() for", " malformed secondary T2", " - smb: client: clear ce->tgthint in free_tgts()", " - smb: client: fix ALIGN() overflow in symlink_data() error context loop", " - smb: client: fix copy-paste error in WSL EA length accounting for $LXDEV", " - smb: client: fix OOB read/write from unvalidated DataOffset in", " coalesce_t2()", " - smb: client: fix use-before-check of ReparseDataLength in", " reparse_buf_ptr()", " - smb: client: harden DFS cache against invalid target hints", " - smb: client: reject a tree connect response whose byte count is too", " small", " - smb: client: restore the data_offset bound in is_valid_oplock_break()", " - HID: apple: preserve keyboard backlight across T2 resume", " - HID: corsair-void: Check size of status and firmware events before", " reading them", " - HID: picolcd: clamp eeprom debugfs read to bytes actually received", " - HID: roccat: free buffered reports when destroying device", " - HID: sensor: custom: Fix field sysfs group cleanup on failure", " - HID: sony: fix UAF of ghl_poke_timer / ghl_urb at driver unbind", " - HID: universal-pidff: stop the device when force-feedback init fails", " - HID: mcp2221: stop device IO before hid_hw_stop", " - HID: mcp2221: fix OOB write in mcp2221_raw_event()", " - HID: mcp2221: clear rxbuf after I2C/SMBus transfer completes", " - HID: mcp2221: validate report size in mcp2221_raw_event()", " - HID: intel-thc-hid: intel-quickspi: validate report size before copy", " - HID: intel-thc-hid: intel-quickspi: bound GET_REPORT response to the", " caller buffer", " - HID: intel-thc-hid: intel-quicki2c: fix autosuspend cleanup during", " teardown", " - HID: intel-thc-hid: intel-quickspi: fix autosuspend cleanup during", " teardown", " - eventfs: Initialize ei->children and ei->list in init_ei()", " - fs/ntfs3: validate dirty page table on log replay", " - fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame()", " - fs/ntfs3: bound page_lcns[] index by the log record", " - eCryptfs: bound the packet-length peek to the user buffer", " - ecryptfs: fix tag 11 packet exact-fit size check", " - ecryptfs: hold msg ctx list lock when cleaning daemon queue", " - ecryptfs: pass packet set buffer size to parser", " - ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet", " - ecryptfs: reject too-small tag 70 packets", " - ecryptfs: release message context on send failure", " - ecryptfs: show filename encryption options", " - efivarfs: Rate limit statfs() handler", " - entry: Fix seccomp bypass after ptrace with TSYNC", " - erofs: skip sufficiently large global buffers when resizing", " - ext2: Fix lost inode updates for IS_SYNC inodes", " - fanotify: fix use-after-free of file range info", " - fat: restore original value when fat_ent_write failed", " - fbdev: omapfb: panel-dsi-cm: initialize lock before registering display", " - fbdev: pvr2fb: correct user pointer annotation and sentinel initializer", " - fbdev: ssd1307fb: defer I2C transfers from damage callbacks", " - fbdev: uvesafb: unregister connector callback on init failure", " - forcedeth: fix off-by-one when saving/restoring non-PCI config space", " - fpga: stratix10-soc: Fix SVC mailbox handling during reconfiguration", " - fsnotify: Fix stale object mask after concurrent mark updates", " - hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device", " - hugetlb: only adjust reservation during unmapping if mapcount is 0", " - accel/rocket: fix NULL dereference and integer overflow in", " rocket_job_push()", " - accel/rocket: initialize job domain before cleanup paths", " - accel/rocket: Fix error path handling in rocket_job_run()", " - acpi/apei/ghes: Use raw_spinlock_t for CXL CPER work locks", " - ACPI: APEI: Fix ERST timeout unit conversion", " - ACPI: APEI: GHES: fix ARM section length accounting after header", " - ACPI: pfr_update: fix stack buffer overflow in query_capability()", " - ACPI: scan: Avoid registering platform devices with resource overlaps", " - alpha/PCI: Fix I/O port accessor argument order in pci_legacy_write()", " - alpha: marvel: Fix irq_set_status_flags to use correct IRQ number", " - alpha: marvel: Fix lock ordering in init_io7_irqs()", " - ARM: 9477/1: Disable broken eBPF JIT on the Risc PC", " - ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes", " - auxdisplay: charlcd: cancel backlight work on registration failure", " - backlight: aw99706: Fix DT property names to match binding", " - backlight: aw99706: Honor the core blank state in update_status()", " - block: validate user space vectors during extraction", " - block: set QUEUE_FLAG_DYING unconditionally in blk_mark_disk_dead()", " - Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU", " - Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU", " - Bluetooth: btusb: limit RTL8761B BROKEN_EXT_SCAN quirk to 0bda:a728", " - Bluetooth: eir: Fix OOB read in eir_get_service_data()", " - bnx2x: fix double free in bnx2x_init_firmware() error path", " - bnxt_en: Write doorbell when linearizing skb fails", " - bpf, x86: Fix per-CPU address resolution into an extended register", " - bpf: Disable preemption in __bpf_get_stack", " - buffer: avoid tail commit walk for uptodate folios", " - bpf: Harden bloom filter sizing and indexing on 32-bit kernels", " - dm-io: clone the source bio instead of copying its biovec", " - dm-io: report non-retryable errors separatedly", " - dm-era: fix shadowed superblock leak on take-snap failure", " - dm raid1: reserve space for NUL-terminator in build_constructor_string()", " - dm array: validate array block headers on read", " - dm array: reject an array block whose value size is not the caller's", " - coresight: etm3x: Fix cntr_val_show() to match cntr_val_store() behavior", " - cpufreq: apple-soc: Fix OPP table cleanup", " - cpufreq: schedutil: Fix rate limit overflow", " - cxl/features: bound fwctl command payload to the input buffer", " - dax/cxl, hmem: Initialize hmem early and defer dax_cxl binding", " - cxl/region: Add helper to check Soft Reserved containment by CXL regions", " - cxl/mce: Make the MCE notifier per-region", " - cxl/pmem: Format the nvdimm serial number as unsigned decimal", " - cxl/ras: Fix cxl_rch_get_aer_severity() wrong severity register", " - Bluetooth: hci_bcm4377: Ignore reserved PHY in ext adv reports on", " BCM4378", " - Bluetooth: hci_bcm: fix usage_count leak when autosuspend_delay is", " negative", " - Bluetooth: hci_uart: Fix false success return in hci_uart_setup()", " - Bluetooth: RFCOMM: serialize security confirmation handling", " - Bluetooth: hci_conn: re-enable advertising only for peripheral role", " - Bluetooth: hci_core: use skb_get() instead of skb_clone() for req_skb", " - Bluetooth: hci_event: clear HCI_LE_ADV only on a created connection", " - Bluetooth: hci_h5: fix usage_count leak when autosuspend_delay is", " negative", " - Bluetooth: hci_intel: fix usage_count leak when autosuspend_delay is", " negative", " - Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last", " request", " - kasan: fix cache shrink race with CPU hotplug", " - jbd2: bound shrinker scans by examined checkpoint buffers", " - jbd2: check need_resched() when skipping busy checkpoint buffers", " - ipip: fix skb leak in collect_md mode when metadata_dst allocation fails", " - ip: orphan prefetched skbs before multicast forwarding", " - ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit()", " - ip6_gre: fix hardware header length for NBMA tunnels", " - ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv()", " - ipv6: use RCU iterator to dump route exceptions", " - landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation", " - libnvdimm/labels: Prevent integer overflow in __nd_label_validate()", " - mailbox: qcom-ipcc: fix duplicate channel allocation across holes", " - md/raid10: fix still_degraded being inverted in raid10_sync_request()", " - md: do overflow check for sb->bblog_shift in super_1_load()", " - module: validate string table section types", " - mpls: reload header after pskb_may_pull()", " - mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction", " - module/kallsyms: fix nextval for data symbol lookup", " - nouveau/gem: reserve the bo in the info ioctl around the vma lookup", " - params: fix charp corruption on allocation failure", " - phy: fsl-imx8mq-usb: fix typec switch leak on probe error path", " - SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow", " - SUNRPC: Zero rpc_gss_wire_cred at svcauth_gss_decode_credbody() entry", " - SUNRPC: svcauth_gss: enforce krb5 token minimum length", " - sunrpc: route to a populated pool in svc_pool_for_cpu()", " - SUNRPC: Restore NUMA_NO_NODE for svc thread allocations in global mode", " - SUNRPC: always drain cache_cleaner before destroying a cache_detail", " - SUNRPC: Check svc pool percpu counter allocation", " - SUNRPC: close backchannel before destroying callback service", " - sunrpc: defer rq_argp and rq_resp free until after RCU grace period", " - SUNRPC: fix gssx_dec_option_array error path bugs", " - sunrpc: fix use-after-free in __rpc_clnt_handle_event and", " __rpc_clnt_remove_pipedir", " - SUNRPC: Guard svcauth_gss_release() dispatch on rq_auth_stat", " - SUNRPC: harden gss_krb5_unwrap_v2 against short tokens", " - SUNRPC: harden gss_unwrap_resp_priv length checks", " - sunrpc: init gssp_lock before publishing proc entry", " - SUNRPC: reject duplicate CREDS_VALUE options", " - SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field", " - SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2", " - SUNRPC: wait for in-flight client TLS handshake callback", " - svcrdma: Reorder rpcrdma_rn_unregister before rdma_destroy_id", " - svcrdma: Clear sc_cm_id when ADDR_CHANGE replacement fails", " - svcrdma: Fix offset arithmetic in read_chunk_range", " - svcrdma: Fix pcl_for_each_segment for empty chunks", " - svcrdma: Fix unmatched rn_unregister on failed accept", " - svcrdma: Reject connection when transport allocation fails", " - svcrdma: Reject inline replies that overflow the pull-up buffer", " - svcrdma: Reject oversized Read segments at decode time", " - svcrdma: Reject Read lists that exceed the page budget", " - svcrdma: Reject Write/Reply chunks with segcount 0", " - svcrdma: Use svc_xprt_put to free listener on create failure", " - svcrdma: Validate Read chunk positions before reconstruction", " - udf: reject VAT indexes equal to the entry count", " - wifi: ath6kl: clamp assoc request/response lengths before subtracting IE", " offsets", " - wifi: mt76: mt7925: cancel pending mlo_pm_work", " - staging: media: tegra-video: fix of_node_put() on VIP parse errors", " - staging: media: tegra-video: vi: fix probe failure on skipped last port", " - media: staging/ipu7: fix async notifier UAF on probe error path", " - sched/core: Handle pick_task() releasing the rq lock", " - sched_ext: Fix exit_task leak on fork failure during enable", " - sched_ext: Fix inverted ops.core_sched_before() invocation", " - sched_ext: Keep kick_sync waiting on the rq's own CPU", " - scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables()", " - scsi: fnic: Use GFP_ATOMIC for VLAN alloc under spinlock", " - rpmsg: glink: smem: order FIFO read after availability check", " - Revert \"arm64: dts: rockchip: Further describe the WiFi for the", " Pinephone Pro\"", " - arm64: dts: qcom: kodiak: avoid EFI overlap for ADSP remote heap", " - arm64: dts: qcom: sm6115-pro1x: Correct touchscreen GPIO flags", " - arm64: dts: qcom: x1-dell-thena: mark l12b and l15b always-on", " - arm64: dts: rockchip: fix eMMC reset polarity on PP-1516", " - arm64: dts: rockchip: fix eMMC reset polarity on PX30 Ringneck", " - arm64: dts: rockchip: fix emmc reset polarity on px30-cobra", " - arm64: dts: rockchip: Fix rk3399-roc-pc-plus analog audio", " - arm64: dts: rockchip: Fix rk3588s-roc-pc audio description", " - riscv: dts: spacemit: k1-bananapi-f3: fix maximum CPU core voltage", " - riscv: dts: spacemit: k1-milkv-jupiter: fix maximum CPU core voltage", " - RISC-V: KVM: Fix PMU event info array size overflow", " - riscv: acpi: Handle LPI architectural context loss flags", " - riscv: unaligned: stop using kthread for check_vector_unaligned_access()", " - remoteproc: scp: Fix device reference leak on failed lookup", " - qede: Fix NULL pointer dereference in TPA fragment processing", " - RDMA/cxgb4: Cancel reg_work before freeing device on remove", " - RDMA/ionic: Cap eq_count to the eth driver's interrupt vector budget", " - RDMA/ionic: Embed counter driver data in rdma_counter allocation", " - RDMA/ucma: Lock the handler in ucma_set_ib_path()", " - RDMA/ucma: Lock the handler in ucma_write_cm_event()", " - RDMA/uverbs: Add UVERBS_ATTR_UHW to UVERBS_METHOD_REG_MR", " - regulator: as3722_get_regulator_dt_data: fix premature of_node_put", " leaving dangling of_node pointer", " - regulator: max8998_pmic_dt_parse_pdata: of_node_put on reg_np after", " ownership transferred to rdata", " - regulator: qcom-refgen: correct the regulator type to CURRENT", " - ring-buffer: Fix subbuf resize race with ring_buffer_alloc_read_page()", " - ring-buffer: Free cpu_buffer::free_page with subbuf_order", " - ring-buffer: Hold cpu_buffer::lock when resizing a subbuf", " - ring-buffer: Make cpu_buffer::free_page a buffer_data_read_page", " - PM: sleep: Unblock runtime PM when device prepare fails", " - orangefs: fix double-free of trailer_buf on readdir copy failure", " - orangefs: skip leading spaces before parsing client debug masks", " - ocfs2: always run deallocs on copy-on-write completion", " - ocfs2: bound namelen in dlm_migrate_request_handler", " - ocfs2: validate lengths in dlm_mig_lockres_handler", " - ocfs2: validate rl_used against rl_count in refcount block validator", " - ocfs2: validate dx_root extent list fields during block read", " - ocfs2: validate directory-index entry counts when reading metadata", " - ocfs2: cluster: don't sleep while holding o2hb_live_lock in", " o2hb_region_pin()", " - ocfs2: cluster: avoid lock order inversion in o2hb_region_pin() from", " drop_item", " - ocfs2: cluster: fix o2hb_dependent_users leak on pin failure", " - ocfs2: fix cached cluster count after suballocator reclaim", " - ocfs2: fix readdir position truncation on 32-bit kernels", " - openrisc: fix arbitrary kernel memory access via or1k_atomic syscall", " - openvswitch: Fix CT limit teardown use-after-free", " - openvswitch: only skb_tx_error() a packet we are about to drop", " - ALSA: ump: Fix corrupted data bytes at MIDI 1.0 SysEx to UMP conversion", " - arm64: compat: Fix decrementing LDM/STM alignment emulation", " - arm64: proton-pack: Restore the nospectre_bhb command-line option", " - ASoC: amd: yc: Add DMI entry for MSI Thin A15 B7UC", " - ASoC: codecs: aw88261: reduce log spam", " - ASoC: codecs: aw88261: only check PLL and clock state at power-up", " - hwmon: (max6621) fix negative temperature offset and crit readings", " - hwmon: (max6621) fix temperature clamp range", " - i2c: mxs: fix DMA channel leak on probe error", " - ipmi: Fix use-after-free of cmd_rcvr in _ipmi_destroy_user()", " - lockd: pin next file across nlm_inspect_file lock-drop", " - lockd: fix NULL dereference on lockowner allocation failure", " - lockd: fix swapped arguments in nlmsvc_match_ip()", " - nvme: nvme-fc: Fix nvme_fc_create_hw_io_queues() queue deletion in error", " path", " - nvme: zero the discard fallback page", " - nvme-pci: disable controller on admin queue IRQ setup failure", " - nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone", " - nvme-tcp: fix host memory disclosure on R2T for a read command", " - nvme-tcp: reject a read that transferred too few bytes", " - sctp: stop processing a packet once its association is deleted", " - sctp: drop a chunk if its transport was removed", " - sctp: fix NULL deref on untransmitted RECONF completion", " - sctp: distinguish sequence zero from wildcard in reconf lookup", " - sctp: fix stream->outcnt underflow on duplicate RECONF responses", " - power: supply: bq24257: fix use-after-free on remove", " - power: supply: bq256xx: drain usb_work before freeing the charger", " - power: supply: bq25890: Fix power_supply reference leak", " - power: supply: charger-manager: register regulators before exposing", " sysfs", " - power: supply: cros_usbpd-charger: bound the EC-reported port count", " - power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS", " - power: supply: lp8727: fix use-after-free in lp8727_release_irq()", " - power: supply: lp8788-charger: fix use-after-free on remove", " - power: supply: pf1550: enable charging when battery profile exists", " - power: supply: qcom_battmgr: fix use-after-free", " - power: supply: qcom_battmgr: terminate the strings from firmware", " - power: supply: rt9455: quiesce delayed work before teardown", " - power: supply: twl4030_charger: cancel workers via devm", " - power: supply: ucs1002: fix use-after-free on remove", " - power: supply: max17040: propagate register read errors", " - power: supply: max17040: drop incorrect I2C functionality check", " - power: supply: max17040: synchronize work cancellation on suspend", " - s390/dasd: Do not complete a failed ESE read as successful", " - s390/dasd: Guard sysfs discipline callbacks against unallocated private", " data", " - s390/dasd: Propagate partial completion length across ERP recovery", " - PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip", " - PCI: Fix 32-bit config write in Intel PCH Root Port MPC ACS quirk", " - PCI: meson: Fix GPIO state while requesting PERST#", " - PCI: starfive: Fix resource leaks on error paths in host_init()", " - PCI: plda: Fix use-after-free of event IRQs during teardown", " - PCI: plda: Fix IRQ domain leaks in the error paths of", " plda_init_interrupts()", " - PCI: Add ACS quirk for Pericom PI7C9X2G608 switches [12d8:2608]", " - PCI/sysfs: Fix read byte order in pci_read_legacy_io()", " - PCI/sysfs: Avoid spurious runtime PM wakeup on config space accesses", " - PCI/AER: Emit TLP Log only for unmasked errors", " - PCI/AER: Fix mapping of errors to agent & layer", " - PCI/MSI: Enable memory decoding before restoring MSI-X messages", " - PCI/proc: Avoid spurious runtime PM wakeup on config space accesses", " - PCI/proc: Use file_ns_capable() when checking config space read access", " - PCI/proc: Warn on writes to kernel-exclusive config space regions", " - iommu/amd: Put PCI device after handling PPR faults", " - iommu/msm: Unwind probe state on registration failure", " - iommu/sva: Set handle->dev before the SVA handle is visible", " - iommu/tegra241-cmdqv: Reject a vSID wider than the SID_MATCH field", " - iommu/arm-smmu-v3: Add HAFT support for SVA", " - iommu/arm-smmu-v3: Manage teardown with devm", " - iommu: Fix dev_iommu memory leak when device_add fails in", " iommu_mock_device_add", " - iommu/vt-d: Fix no_iommu to disable platform opt-in", " - iommu/vt-d: Force requesting ACS when tboot is enabled", " - iommupt: Return zero for invalid iova_to_phys() ranges", " - iommufd: Avoid locking internal accesses during unmap", " - iommufd: Release current IOAS on xa_store() failure", " - iommufd: Fix UAF in selftest IOPF reporting", " - platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer", " - platform/x86: ISST: Validate level in perf mask ioctls", " - platform/x86: ISST: Validate socket ID in clos_assoc ioctl", " - mmc: via-sdmmc: cancel card-detect work on remove", " - mmc: via-sdmmc: stop card-detect handling on probe failure", " - platform/x86: ISST: Add a NULL check for sst_inst[]", " - platform/x86: ISST: Just allow 2 bits for SST feature enable", " - platform/x86: ISST: Use PP level enable mask", " - platform/x86: ISST: Validate logical CPU id and clos id", " - platform/x86: ISST: Validate max level for set feature", " - platform/x86: ISST: Validate parameter for core power state", " - platform/x86: ISST: Validate parameter for frequency and priority", " - platform/x86: ISST: Return error during profile addition", " - platform/x86: int1092: Fix potential memory leak in sar_probe()", " - platform/x86: ishtp_eclite: Fix ACPI device reference leak in probe", " error path", " - platform/x86: lenovo/ymc: Only match lower byte in WMI lid switch query", " response", " - platform/x86: think-lmi: Fix certificate thumbprint sysfs output", " - platform/x86: think-lmi: Free system certificate signatures", " - platform/x86: think-lmi: Fix current password length check", " - platform/chrome: sensorhub: Bound the EC-reported sensor number", " - platform/x86/amd/pmc: Restore msg_port on amd_stb_s2d_init() error paths", " - platform/x86/amd/pmc: Propagate SMU errors and validate S2D address", " - platform/x86/amd/pmc: Fix LPS0 and debugfs leaks when STB init fails", " - platform/x86/amd/pmc: Fix msg_port restoration in", " amd_stb_debugfs_open_v2()", " - platform/x86: hp-bioscfg: accept reduced ACPI packages from older HP", " BIOS", " - platform/x86: hp-bioscfg: advance elem past consumed array elements", " - platform/x86: hp-bioscfg: bound ordered-list parsing by the package", " count", " - platform/x86: hp-bioscfg: fix heap OOB read in sk_store() and", " kek_store()", " - platform/x86: hp-bioscfg: fix heap OOB read on empty password write", " - platform/x86: hp-bioscfg: fix new_password_store() overwriting", " current_password", " - platform/x86: hp-bioscfg: fix off-by-one write in", " hp_get_string_from_buffer()", " - platform/x86: hp-bioscfg: fix ORD_LIST_ELEMENTS never being parsed", " - platform/x86: hp-bioscfg: pass validated element count to package", " parsers", " - platform/x86: hp-bioscfg: warn on element type mismatch instead of", " failing", " - io_uring/waitid: honor task_work cancellation", " - io_uring/waitid: avoid siginfo copy during ring teardown", " - io_uring/query: cap user size passed to copy_struct_to_user", " - interconnect: Fix use after free in icc_get() and of_icc_get_by_index()", " - ipmi: ipmb: validate write message length", " - ipmi: Remove all sysfs files on registration failure", " - ipmi: si: Fix NULL pointer dereference after failed registration", " - ipmi:msghandler: Cancel work cleanly on an error", " - net/iucv: filter frames in afiucv_hs_rcv() by ingress device", " - xdp: fix zero-copy frame layout", " - slip: fix use-after-free in sl_sync()", " - net: usb: qmi_wwan: add Telit Cinterion FE990D50 composition", " - net: tun: bound receive headroom", " - net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO", " - net: ibm: emac: mal: fix NAPI locking", " - net: ipa: fix stalled modem TX queue after runtime resume", " - net: l2tp: do not propagate multicast notification errors", " - net: openvswitch: fix flow mask use-after-free on flow deletion", " - net: openvswitch: fix nf_connlabels leak in ovs_ct_init", " - net: phylink: correctly validate returned PCS in phylink_inband_caps", " - net: ravb: avoid dereferencing an invalid PTP clock", " - net: ravb: serialize PTP clock teardown", " - net: thunderbolt: Release the Rx HopID that was handed out on mismatch", " - net: thunderbolt: Mark the connection down when bringing it up fails", " - NTB: ntb_transport: Recycle TX entries before client callbacks", " - NTB: ntb_transport: Fail TX enqueue when the QP link is down", " - NTB: ntb_transport: Reject oversized TX buffers", " - net: ntb_netdev: Fix TX busy and drop handling", " - net: ntb_netdev: Avoid double-accounting netif_rx() drops", " - net: ntb_netdev: Count packets dropped on RX refill failure", " - net/mlx5e: SHAMPO, Always calculate page size", " - net/mlx5e: do not HW-GRO coalesce small frames", " - net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages", " - net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry", " - net/smc: do not dereference an unset send buffer on the SMC-D teardown", " path", " - net/smc: fix socket refcount leak in smc_switch_conns()", " - net/smc: fix use-after-free in smc_rx_pipe_buf_release()", " - net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link()", " - net/smc: stop killed, freed and out_of_sync sharing a byte", " - net/smc: unregister the connection before draining the rx tasklet", " - net: cap advertised IP tunnel headroom", " - net: fix spurious TX timeout after dev_activate()", " - net: skbuff: don't touch shared zerocopy state in skb_tx_error()", " - seg6: reset IP6CB after IPv6 decapsulation", " - hwrng: stm32 - Fix runtime PM cleanup on registration failure", " - mfd: cgbc: Fix teardown ordering in cgbc_remove()", " - mfd: qnap-mcu: keep the reply buffer alive past a command timeout", " - mfd: sm501: Fix potential memory leaks during remove", " - ALSA: 6fire: bound the MIDI event length from the device", " - ALSA: aloop: Check card index validity at probe", " - ALSA: bcd2000: clear the URB pointers on disconnect", " - ALSA: FCP: do not copy out an uninitialised init response", " - ALSA: hda/ext: preserve PPLCCTL bits when clearing reset", " - ALSA: mpu401: Check card index validity at probe", " - ALSA: mts64: Check card index validity at probe", " - ALSA: pcxhr: initialize mutexes before requesting threaded IRQ", " - ALSA: portman2x4: Check card index validity at probe", " - ALSA: serial-u16550: Check card index validity at probe", " - ALSA: virmidi: Check card index validity at probe", " - ALSA: hda/realtek: Add quirk for TongFang XxAF5xxx", " - ALSA: hda/realtek: Enable micmute LED on HP EliteBook 6 G1a p/n:", " AD3Q9ET#UUG", " - ALSA: hda/realtek: Fix Lenovo Yoga Slim 7 14AKP10 quirk ordering", " - arch_numa: avoid false positive fortify warning in", " setup_node_to_cpumask_map()", " - dm-stats: fix a crash if allocation of per-cpu data fails", " - dm-switch: use WRITE_ONCE() in switch_region_table_write()", " - dm-pcache: validate geometry fields from on-disk cache_info", " - dm-pcache: validate kset key_num and intra-segment bounds", " - dm-pcache: validate on-media seg_num against the cache device size", " - dm-pcache: bound the persisted tail-position offset", " - dm-pcache: clamp the tail kset read to the segment data region", " - dm-pcache: detect a cycle in the last-kset chain during replay", " - dm-pcache: only hand out initialized cache segments", " - dm-pcache: fix implicit u8 truncation of gc_percent in message handler", " - dm-pcache: fix use-after-free and invalid seg operations in", " kset_replay()", " - i3c: Fix unlocked dereference of dev->desc in", " i3c_device_get_supported_xfer_mode()", " - i3c: master: adi: initialize the lock before enabling interrupts", " - i3c: master: Fix info leak and UAF in device unregister path", " - i3c: master: svc: bound IBI payload to the requested max_payload_len", " - i3c: renesas: Check that the transfer is valid before accessing it", " - i3c: renesas: Clean DATBAS register on detach", " - i3c: renesas: Follow the reset deassert order used in probe", " - i3c: renesas: Reconfigure the DATBAS register on re-attach", " - i3c: renesas: Reset the controller on resume", " - i3c: renesas: Restore STDBR and EXTBR registers on resume", " - i3c: renesas: Perform Dynamic Address Assignment on resume", " - wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control()", " - wifi: iwlwifi: dvm: fix memory leak in iwl_op_mode_dvm_start()", " - wifi: rtl8xxxu: fix use-after-free from rx_urb_wq on stop", " - fuse-uring: refactor io-uring header copying to ring", " - fuse-uring: refactor io-uring header copying from ring", " - fuse-uring: use enum types for header copying", " - fuse-uring: refactor setting up copy state for payload copying", " - fuse-uring: use named constants for io-uring iovec indices", " - fuse: copy request headers via a stack buffer for io-uring", " - crypto: iaa - unmap dst before software fallback on decompress", " - crypto: atmel-ecc - clean up and improve ECDH comments", " - crypto: atmel-ecc - avoid stale fallback key after set_secret failure", " - mm/kmemleak: stop the task stack scan early when interrupted", " - mm/kmemleak: report RCU-tasks quiescent states during the scan", " - wifi: mwifiex: Detach sync cmd buffer on interrupted wait", " - wifi: rtl818x: initialize eeprom_93cx6 struct to zero", " - wifi: rtlwifi: rtl8192du: check QoS TID before indexing tids", " - wifi: rtlwifi: rtl8192du: Fix possible memory leak in", " rtl92du_init_sw_vars()", " - wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb()", " - wifi: rtw88: pci: fix resource leak on failed NAPI setup", " - wifi: rtw89: pci: add .shutdown callback to stop rfkill polling on", " reboot", " - wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex", " - wifi: mt76: mt7915: bound the device EEPROM address before the EFUSE", " copy", " - wifi: mt76: mt7925: cancel mlo_pm_work on stop", " - wifi: mt76: add external EEPROM support for mt799x chipsets", " - wifi: mt76: mt7996: bound the device EEPROM address before the EFUSE", " copy", " - wifi: mt76: mt7996: fix TX DMA mapping leak for AddBA req frames", " - wifi: mt76: mt7996: validate default EEPROM firmware size", " - vsock/virtio: flush works in dependency order", " - w1: ds28e17: reject an oversize length on an I2C block read", " - xarray: honor XA_FLAGS_ACCOUNT in xas_split_alloc()", " - zloop: truncate finished zones to zone capacity", " - tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout", " - sysctl: move the \"cad_pid\" entry from pid_table[] to kern_reboot_table[]", " - sticon/parisc: Detect default STI graphics card for console output", " - signal: avoid shared siginfo namespace rewrites", " - smack: fix cred UAF in smack_file_send_sigiotask()", " - taskstats: fix cpumask parsing cutting off the last character", " - timekeeping: Check the return value of tk_get_aux_ts64 in", " __do_adjtimex()", " - timer: Keep debugobjects state consistent in migrate_timer_list()", " - udf: Fix i_lenExtents truncation on 32-bit kernels", " - selftests/mm: fix on-fault-limit false failure under sudo-rs", " - resource: Add __resource_contains_unbound() for internal contains checks", " - ACPI: scan: Do not combine resources that overlap completely", " - platform/chrome: sensorhub: Fix dropped timestamp events and log spam", " - Upstream stable to v6.18.49, v6.18.50, v7.2.2, v7.2.3, v7.2.4", "", " * Resolute update: upstream stable patchset 2026-09-17 (LP: #2167609) //", " CVE-2026-80724", " - ptp: vmclock: prevent read-only mappings from becoming writable", "", " * Resolute update: upstream stable patchset 2026-09-17 (LP: #2167609) //", " CVE-2026-80914", " - Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready", "", " * Resolute update: upstream stable patchset 2026-09-17 (LP: #2167609) //", " CVE-2026-80833", " - crypto: sun8i-ss - Remove crypto_rng interface", "", " * Resolute update: upstream stable patchset 2026-09-17 (LP: #2167609) //", " CVE-2026-80834", " - crypto: sun8i-ce - Remove crypto_rng interface", "", " * Resolute update: upstream stable patchset 2026-09-17 (LP: #2167609) //", " CVE-2026-80925", " - vlan: fix skb_under_panic and races when toggling HW VLAN offload", "", " * Resolute update: upstream stable patchset 2026-09-17 (LP: #2167609) //", " CVE-2026-80857", " - fuse: wait for FR_FINISHED on abort_on_kill to prevent use-after-free", "", " * Resolute update: upstream stable patchset 2026-09-17 (LP: #2167609) //", " CVE-2026-80858", " - fuse: publish io-uring queues with release semantics", "", " * Resolute update: upstream stable patchset 2026-09-17 (LP: #2167609) //", " CVE-2026-80859", " - fuse: fix missing barrier when checking io-uring readiness", "", " * Resolute update: upstream stable patchset 2026-09-17 (LP: #2167609) //", " CVE-2026-80860", " - fuse: fix race between interrupt and resend", "", " * [SRU] Add support for amd-pmf AMDI0112 ID (LP: #2165251)", " - SAUCE: platform/x86/amd/pmf: Add AMDI0112 ACPI ID", "", " * Backport: \"mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios\"", " (LP: #2162917)", " - mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios", "", " * Bluetooth: btmtk: Declare MT7920 (MT7961 1a) Bluetooth firmware", " (LP: #2166944)", " - Bluetooth: btmtk: Declare MT7920 (MT7961 1a) Bluetooth firmware", "", " * System cannot enter s0ix suspend on Dell with RTL8116AF ethernet", " (LP: #2160475)", " - Revert \"UBUNTU: SAUCE: r8169: add quirk for RTL8116af SerDes\"", " - SAUCE: r8169: add speed in private struct", " - SAUCE: net: phy: phylink: add helper to modify pause", " - SAUCE: r8169: add support for phylink", " - SAUCE: r8169: add support for RTL8116af", " - SAUCE: r8169: add support for RTL8127atf", " - SAUCE: r8169: add ltr support for RTL8117 series", " - SAUCE: r8169: fix RTL8116af can not enter s0idle and c10", "", " * net:rtnetlink.sh in ubuntu_kselftests_net failed with ipsec_offload on", " resolute (7.0.0-38.38) generic s390x (LP: #2166631)", " - SAUCE: Fix selftest/net/rtnetlink.sh for Big Endian", "", " * [UBUNTU 24.04] kernel: CPU hotplug unsupported by CPUMF (LP: #2165732)", " - s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks", "", " * [Ubuntu 26.04] Failed install OS onto JBOD disk on B540d-2HS M.2", " controller (LP: #2148534)", " - scsi: megaraid_sas: Limit NVMe request size to the PRP chain frame", "", " * New 7.0 ubuntu_kselftests_net/net:tun tests flaky (LP: #2158217)", " - SAUCE: selftests/net: Run tun tests in a dedicated network namespace", "", " * ThinkPad X9-15 Gen 1: IPU7 camera probe fails — duplicate software_node", " SONY471A-0 (-EEXIST), bridge init failed (LP: #2158540)", " - SAUCE: media: ipu-bridge: drop duplicate IMX471 sensor config", "", " * append bpf to CONFIG_LSM (LP: #2166235)", " - [Config] append bpf to CONFIG_LSM", "", " * Add a linux-main-modules dependency toggle to kernel build process", " (LP: #2166181)", " - [packaging] Create a linux-main-modules dependency toggle", "", " * Resolute update: upstream stable patchset 2026-09-04 (LP: #2166517)", " - RDMA/rxe: Fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp", " - RDMA/rxe: Fix OOB in free_rd_atomic_resources()", " - KVM: x86/mmu: Check write tracking in all address spaces", " - nvme-tcp: fix usage of page_frag_cache", " - Revert \"selinux: reject a permission value exceeding the class", " permission count\"", " - selinux: use u16 for security classes", " - selinux: more strict policy parsing", " - selinux: reject a permission value exceeding the class permission count", " - selinux: require a class's permission values to cover its permission", " count", " - selinux: switch two allocations to use kzalloc_objs()", " - veth: fix OOB txq access in veth_poll() with asymmetric queue counts", " - ksmbd: harden file lifetime during session teardown", " - fpga: dfl: fme: add error handling", " - accessibility: speakup: unregister tty ldisc on later init failures", " - usb: xhci: Handle bogus TRB pointers in Missed Service Error events", " - usb: xhci: Handle USB3 port events when there is one roothub", " - xhci: dbgtty: Fix unregister on tty_register_driver() failure", " - xhci: dbgtty: Fix unregister on tty_alloc_driver() failure", " - fuse: fix invalidate lock leak on setattr writeback failure", " - fuse: fix invalidate lock leak on open O_TRUNC DAX failure", " - usb: usbtest: disable dynamic ID support", " - usb: gadget: f_tcm: keep port count until LUN teardown completes", " - KVM: SEV: Drop FOLL_WRITE for encrypted region registration", " - KVM: SEV: Track the GPA of the guest-controlled VMSA used for SNP guests", " - KVM: SEV: Extract loading of guest-provided VMSA to a separate helper", " - KVM: SEV: Mark vCPU RUNNABLE after AP_CREATE, even if VMSA is unusable", " - KVM: SEV: Wire up kvm_x86_ops.gmem_xxx() if and only if", " CONFIG_KVM_AMD_SEV=y", " - tls: device: fix out-of-bounds write in tls_append_frag()", " - gtp: serialize PDP context updates", " - x86/CPU/AMD: Carve out a Zen5 models range", " - net/tcp: fix TCP-AO key deletion in VRFs", " - tcp: fix AO info use-after-free in tcp_ao_connect_init()", " - net/tcp-ao: fix use-after-free of current_key on reconnect to another", " peer", " - xfrm: espintcp: fix UAF during close", " - xfrm: drop ESP-in-TCP packets with no ingress device", " - xfrm: avoid lock inversion in nat keepalive work", " - xfrm: ah6: validate routing header segments_left", " - xfrm: fix xfrm_state_construct() auth-trunc leak", " - xfrm: bound nat keepalive state collection", " - net: bridge: mcast: fix use-after-free of a master VLAN's multicast", " context", " - ipv6: seg6: clear IPv4 control block on IPIP decapsulation", " - batman-adv: reject unrepresentable multicast TVLV offsets", " - vxlan: keep the last remote linked during FDB flush", " - netfilter: nft_set_pipapo_avx2: add missing vzeroupper", " - netfilter: nf_tables: don't queue packet path object notifications", " - mm/swap: reject swapon() on filesystem-level encrypted files", " - kunit: irq: Continue increasing hrtimer interval for longer", " - crypto: virtio - bound the akcipher result length", " - crypto: qcom-rng - Enable clock in hwrng case", " - crypto: qcom-rng - Remove crypto_rng interface", " - crypto: qcom-rng - Allow zero as a random number", " - crypto: atmel-tdes - use scatterlist length before DMA mapping", " - crypto: krb5 - use kfree_sensitive() for derived key buffers", " - crypto: qce - fix CCM AAD buffer underallocation", " - crypto: mxs-dcp - fix source scatterlist length access", " - crypto: qce - Remove unsafe/deprecated algorithms", " - KVM: s390: vsie: zero stale crypto bits", " - usb: core: Add lock to usb_wakeup_notification()", " - usb: core: Strengthen error handling in hub_hub_status()", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output()", " - ALSA: usb-audio: Complete cleanup after system-resume errors", " - USB: serial: option: fix slab OOB read in interrupt URB callback", " - USB: serial: spcp8x5: drop broken carrier detect support", " - USB: c67x00: fix use-after-free in c67x00_add_iso_urb()", " - wifi: mt76: mt7925: ensure tx headroom in usb_sdio_tx_prepare_skb", " - usb: usbfs: fix use-after-free of usb_device in usbdev_release()", " - usb: xhci: bail out of setup if the controller is inaccessible", " - net: advertise TCP MSS from the configured MTU, not the learned PMTU", " - tcp: clamp route advmss to TCP_MIN_MSS", " - net/packet: defer vmalloc TX_RING free until skbs finish", " - crypto: iaa - fall back to software for multi-entry scatterlists", " - Upstream stable to v6.18.49, v7.1.13", "", " * Resolute update: upstream stable patchset 2026-09-03 (LP: #2166363)", " - xfs: add a xchk_ip_set_corrupt helper", " - xfs: rtsummary scrub should treat rtbitmap corruption errors as an xref", " error", " - xfs: hoist per-bucket unlinked list check to helper", " - xfs: don't livelock in scrub on a circular unlinked list", " - PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems", " - Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept", " - iommu/tegra241-cmdqv: Fix CMD_SYNC use-after-free on teardown", " - iommu/iommufd: Fix NULL pointer deref in iommufd_ioas_change_process", " when racing with iopt_map_file_pages", " - ALSA: FCP: Use a private URB for the notification endpoint", " - ALSA: scarlett2: Use a private URB for the notification endpoint", " - rndis_host: add overflow check in rndis_rx_fixup()", " - nvmet: fix NULL pointer dereference in nvmet_execute_identify_nslist()", " - io_uring/futex: don't mark futex wake requests as inflight", " - ALSA: dummy: Check card index validity at probe", " - io_uring/cmd: fix iovec leak when the async cmd is not recycled", " - io_uring/io-wq: fix worker accounting when canceling creation callbacks", " - io_uring/rsrc: fix folio size overflow in io_vec_fill_bvec()", " - io_uring/uring_cmd: don't skip completion for a synchronous multishot", " cmd", " - ocfs2: fix missing metadata reservation for large xattrs", " - kcov: fix data corruption and race conditions on PREEMPT_RT", " - ext4: stop retrying saturated xattr cache entries", " - nilfs2: reject invalid block index in GC ioctl", " - ext4: clear error before retrying inode xattr space fallback", " - ext4: avoid tail write_begin walk for uptodate folios", " - ext4: propagate errors from fast commit range replay", " - ext4: don't enable DAX on new encrypted files", " - ext4: fix incorrect function call when initializing s_resgid", " - xfs: validate attr entry pointer before field access", " - nfc: digital: clamp SENSF_RES length to the destination buffer", " - nfc: fdp: bound the device-reported read length and fix an skb leak", " - nfc: microread: validate target discovery payload lengths", " - nfc: llcp: bound the connect_sn TLV walk to the skb", " - nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers", " - nfc: llcp: reject PDUs shorter than the LLCP header", " - nfc: pn533: purge fragmented skbs during cleanup", " - nfc: st21nfca: validate ATR_REQ length against the received frame", " - nfc: nci: add data_len bound checks to activation parameter extractors", " - nfc: nci: fix out-of-bounds write in nci_target_auto_activated()", " - nfc: nci: fix uninit-value in the RF discover/activated NTF handlers", " - nfc: nci: free destination parameters when closing a connection", " - drm/xe: Fix DPT allocation paths.", " - ipv4: reject undersized MTUs in ip_do_fragment()", " - ipv6: fix use-after-free in ip6_finish_output2()", " - mailbox: mchp-ipc-sbi: Add null check for devm_kasprintf()", " - dmaengine: fsl-edma: Add error handling for devm_kasprintf", " - nvmet-auth: zero the AUTH_RECEIVE response buffer", " - nvmet-fc: fix invalid free in LS IOD error path", " - nvmet-tcp: bound SGL data length before allocating command buffers", " - nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations", " - nvmet: pci-epf: fix use-after-free in nvmet_pci_epf_exec_iod_work()", " - nvmet: pci-epf: put CQ ref on create_cq mapping failure", " - mptcp: pm: use for_each_subflow helper", " - mptcp: pm: rename add_entry structure to add_addr", " - mptcp: pm: uniform announced addresses helpers", " - mptcp: pm: fix memory leak from alloc-during-teardown race", " - HID: magicmouse: fix battery reporting for Bluetooth Magic Trackpad", " USB-C", " - HID: magicmouse: re-enable multitouch after reset-resume", " - HID: magicmouse: do not keep a stale msc->input if no input is claimed", " - HID: magicmouse: Prevent out-of-bounds (OOB) read during", " DOUBLE_REPORT_ID", " - HID: core: fix OOB read of field->usage in hid_set_field()", " - HID: pidff: fix OOB write when hid->inputs is empty", " - net/ionic: avoid OOB TX partner lookup for hwstamp RXQ", " - futex/pi: Reject cross-mm private futex owners", " - futex: Sanitize and document task_struct::futex::state transitions", " - futex/pi: Plug private futex exec() race", " - futex: Fix race on the initial mm->futex.phash.ref allocation", " - futex: Fix might_sleep() warning in futex_pivot_pending()", " - HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler()", " - HID: nintendo: register input device after capabilities are set", " - HID: nintendo: stop device IO before hid_hw_stop on probe failure", " - HID: core: fix number/pointer type confusion on long items", " - HID: sensor: custom: Fix use-after-free in enable_sensor", " - HID: uclogic: fix use-after-free of inrange_timer on remove", " - HID: hyperv: validate initial device info bounds", " - Bluetooth: hci_event: fix LE list UAF on reset", " - Bluetooth: hci_event: validate LE Set CIG Parameters response", " - Bluetooth: hci_sync: Fix accept list UAF during suspend", " - Bluetooth: ISO: do not force BT_LISTEN after a failed BIG sync", " - Bluetooth: ISO: zero the sockaddr before returning it in getname", " - Bluetooth: MGMT: reject HCI_CMD_SYNC params_len above 255", " - Bluetooth: hci_aml: validate firmware segment lengths", " - futex: Avoid private hash use-after-free on final put", " - io_uring/futex: only mark private futex waits as inflight", " - io_uring: switch struct io_ring_ctx internal bitfields to flags", " - io_uring: defer eventfd signaling when queued from a wakeup handler", " - xfs: restore nofs context unconditionally in xfs_trans_roll", " - fbdev: Wrap user-invoked calls to fb_set_var() in helper", " - fbdev: serialize mode sysfs access with lock_fb_info()", " - HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event()", " - HID: asus: fix missing hid_is_usb() check", " - HID: rapoo: fix missing hid_is_usb() check", " - HID: ft260: fix stack-use-after-return write in I2C read race", " - HID: input: read battery capacity from its actual report offset", " - Upstream stable to v6.18.47, v6.18.48, v7.1.11, v7.1.12", "", " * Resolute update: upstream stable patchset 2026-09-03 (LP: #2166363) //", " CVE-2026-80590", " - inet: frags: strip GSO state from fragments before reassembly", "", " * Resolute update: upstream stable patchset 2026-09-03 (LP: #2166363) //", " CVE-2026-80724", " - ptp: vmclock: prevent read-only mappings from becoming writable", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029)", " - mount: honour SB_NOUSER in the new mount API", " - sched/fair: Revert 6d71a9c61604 (\"sched/fair: Fix EEVDF entity placement", " bug causing scheduling lag\")", " - selftests/bpf: Fail unbound UDP on sockmap update", " - drm/amd/display: Add AV mute wait frames to dce110_set_avmute", " - drm/amd/display: Check for tg ops in dce110_set_avmute", " - arm64: dts: qcom: purwa: Fix GPU IOMMU property", " - arm64: dts: qcom: sdm850-lenovo-yoga-c630: lower PSCI cluster idle", " - arm64: dts: broadcom: bcm2712: Remove non-functional EL2 virtual timer", " - ARM: npcm: Fix OF node refcount leaks in SMP setup", " - selftests/sched_ext: Handle sleeping task affinity changes in numa test", " - pinctrl: qcom: ipq806x: mark gpio as a GPIO pin function", " - pinctrl: qcom: ipq806x: mark pci reset as a GPIO pin function", " - ovpn: add missing rtnl_link_ops->get_size callback", " - ARM: dts: BCM5301X: fix PCIe controller 2 second interrupt", " - ovpn: rehash peer in by_transp_addr table on CMD_PEER_SET", " - ovpn: ensure socket is owned by ovpn before deref sk_user_data", " - ovpn: zero-initialize sockaddr before learning a floated endpoint", " - ovpn: hash floated peer by transport identity only", " - ovpn: disable IPv4 redirects on MP interfaces", " - ovpn: ensure TCP vars are initialized first", " - ovpn: fix incorrect use of rcu_access_pointer()", " - drm/bridge: ps8640: propagate AUX transfer register errors", " - net: hns3: fix speed configuration residue after driver reload", " - Revert \"net: thunderbolt: Enable end-to-end flow control also in", " transmit\"", " - net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock", " - pds_core: keep the health thread stopped during reset", " - pds_core: cancel pending PCI reset work on AER recovery", " - netfilter: ipset: switch ext_size to atomic64_t", " - ipvs: return the csum validation for forward hook", " - watchdog: bd96801_wdt: Fix timeout for enabled WDG", " - bpf: split check_reg_sane_offset() in two parts", " - bpf: Propagate untrusted pointer state in commuted arithmetic", " - net: hisilicon: hix5hd2_gmac: remove redundant NAPI delete", " - counter: microchip-tcb-capture: Fix DT channel validation", " - vhost/vdpa: reject overflowing PA map page counts on 32-bit", " - hwmon: (pmbus_core) Use guard() for mutex protection", " - tcp: do not change rcv_ssthresh in tcp_measure_rcv_mss()", " - bnxt: fix memory leak in bnxt_queue_mem_alloc error cases", " - xsk: pass TX metadata pointer by reference", " - xsk: move xsk_tx_metadata_request() to xdp_sock_drv.h", " - drm/xe/uc: Apply RCS/CCS yield policy to SR-IOV VFs", " - hwmon: (nzxt-smart2) Check return value of init_device() in probe", " - hwmon: (pmbus/lm25066) Fix PMBus coefficient calculations", " - selftests/ftrace: refactor eprobes test to fix argument checks", " - net: stmmac: resume PHY before hardware setup when opening the interface", " - bnge: use int for bnge_fix_rings_count() return value", " - bnxt_en: Move RSS table fill outside __bnxt_hwrm_vnic_set_rss()", " - bnxt_en: Determine and store default RX ring in vnic structure", " - bnxt_en: Refresh VNIC default ring on queue restart if needed", " - bnxt_en: Fix PTP PPS setting bug", " - sctp: fix addip_serial increment on ASCONF_ACK allocation failure", " - net: remove WARN_ON_ONCE() from sk_mc_loop()", " - ata: pata_sl82c105: fix bridge revision use-after-free", " - bnge: Fix resource leak in bnge_init_nic() error path", " - tls: don't abort the connection on signal-interrupted sends", " - hwmon: (corsair-psu) fix possible out-of-bounds access on missing string", " termination", " - hwmon: (ads7828) Fix external VREF regulator handling", " - hwmon: (ltc4282) Avoid overflow in maximum power calculation", " - hwmon: (ltc4282) Fix parsing adi,current-limit-sense-microvolt", " - usb: core: Add quirk for 255-bytes initial config read", " - usb: quirks: Add ShanWan gamepad to quirk list", " - thunderbolt: icm: Preserve USB4 proxy data-valid bit", " - usb: cdnsp: fix incorrect endian conversions for APB timeout register", " - ipvs: add totalconns for dest", " - ipvs: properly update the overload flag on dest edit", " - net: octeontx2-pf: Fix UB in shift operation", " - net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header", " - KVM: s390: pci: Fix aisb calculation", " - dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk", " - Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan", " - Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV", " - selftests/bpf: Ensure UDP sockets are bound", " - selftests/bpf: Adapt sockmap update error handling", " - mei: pull kvfree out of spinlock", " - nvmem: apple-spmi-nvmem: wrap regmap calls to satisfy CFI", " - nvmem: layouts: Add fixed-layout driver", " - rust_binder: do not query current thread for all ioctls", " - serial: amba-pl011: fix indefinite RS485 post-send delay", " - serial: amba-pl011: synchronize DMA teardown", " - misc: fastrpc: Fix initial memory allocation for Audio PD memory pool", " - misc: fastrpc: fix channel ctx ref leak when session alloc fails", " - misc: fastrpc: fix memory leak in fastrpc_channel_ctx_free", " - ring-buffer: Fix crash passing ERR_PTR to kthread_stop()", " - mm/damon: adjust isolated pages stat for DAMOS_MIGRATE_{HOT,COLD}", " - ALSA: usb: Fix UAF at delayed release of MIDI2 EPs", " - ALSA: hda/tas2781: fix ACPI reference handling", " - net: phy: mediatek: fix TX blink masks using the RX bits", " - arm64: remove redundant concurrent ptdump UAF mitigation", " - x86/CPU: Add a tlbi= cmdline switch", " - x86/mce: Set up the polling timer before CMCI discovery", " - KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow", " page", " - sched/psi: Create the psimon kthread outside of cgroup_mutex", " - fsverity: Fix silent truncation in bpf_get_fsverity_digest()", " - scsi: scsi_debug: Negate wrapped memcmp() result", " - thunderbolt: Fix bandwidth group reservation indexing", " - netfilter: flowtable: ensure sufficient headroom in xmit path", " - arm64: dts: qcom: monaco: Add default GIC address cells", " - NFS: Decrement refcounts if allocating nfs_free_stateid_data fails", " - btrfs: lzo: add error message for invalid headers", " - btrfs: initialize inode mapping flags for cached inodes", " - hwmon: (pmbus/core) Avoid race condition during probe", " - bpf: Check sk_state before sk_protocol in bpf_tcp_*_syncookie", " - net: qrtr: ns: Raise lookup limit to 128", " - hwmon: Support guard() and scoped_guard for subsystem locks", " - hwmon: (corsair-psu) serialize debugfs access against hwmon", " - usbnet: cap max_mtu for drivers without bind callback", " - ipvs: separate destination availability state", " - selftests/xsk: fix too-many-frags multi-buffer Tx test", " - selftests/xsk: account reclaimed invalid Tx descriptors", " - serial: sc16is7xx: enable THRI before filling TX FIFO", " - mm/huge_memory: initialise workingset state before folio split", " - net: ntb_netdev: Introduce per-queue context", " - smb: client: fix SMB1 TRANS2 multi-response truncation in SendReceive()", " - ring-buffer: Prevent resizing of persistent ring buffer", " - Revert \"thermal: hwmon: Register a hwmon device for each thermal zone\"", " - selinux: require every boolean value to be defined", " - selinux: reject a class permission count below its inherited common", " - selinux: do not cancel a policy conversion that never started", " - selinux: reject an unclaimed class value in security_get_classes()", " - selinux: reject a permission value exceeding the class permission count", " - selftests: mptcp: join: mark tests with data corruption as failed", " - mptcp: pm: fix data race in add_addr timer callback", " - ASoC: SOF: sof-audio: Fix error path in sof_widget_setup_unlocked()", " - ASoC: cs4265: sort the register default table", " - ASoC: cs35l45: sort the register default table", " - ASoC: cs35l41: sort the register default table", " - ASoC: codecs: lpass-wsa-macro: Fix enum kcontrol accesses", " - drm/amdgpu: read TRUNCATE_COORD_MODE on gfx12", " - drm/amdgpu: fix JPEG v5.0.0 queue reset failure in DPG mode", " - drm/amdgpu: fix JPEG v4.0.5 queue reset failure in DPG mode", " - drm/amdgpu: fix aperture iounmap skipped on device removal", " - ASoC: SOF: topology: Use acpi mach from the machine driver", " - Input: xpad - add support for ZENAIM LEVERLESS", " - powerpc/pseries: pci - logic bug", " - Input: synaptics-rmi4 - fix F55 transmitter electrode count typo", " - Input: psxpad-spi - set driver data before use", " - Input: atkbd - skip deactivate for Xiaomi Book Pro 14's internal", " keyboard", " - powerpc/pseries: lparcfg - fix kbuf[] underflow", " - crypto: starfive - use scatterlist length before DMA mapping", " - selftests/ftrace: Convert ELF entry point to file offset in uprobe test", " - gve: fix zero-length skb frag with header-split", " - pmdomain: arm: Fix -EINVAL from scmi_pd_set_perf_state() on state 0", " - ftrace: Protect direct_functions in ftrace_find_rec_direct", " - ftrace: Fix off-by-one fentry site disable in ftrace_free_mem()", " - Input: sur40 - fix V4L error path cleanup", " - ceph: fix MDS random selection readiness predicate", " - libceph: tolerate addrvecs with multiple entries of the same type", " - mmc: omap_hsmmc: fix busy_timeout overflow in ns conversion on 32-bit", " - mmc: sdhci: unmap the bounce buffer before device release", " - pmdomain: mediatek: fix remaining %pOF after of_node_put()", " - mmc: sdhci: make tuning_err a signed int", " - pmdomains: mediatek: Avoid setting RTFF's CLK_DIS before NRESTORE", " - drm/connector/hdmi: Fix out of bounds memory read", " - mmc: loongson2: Fix sg iteration in data reorder functions", " - pmdomain: mediatek: Fix mt8183 hang on boot", " - drm/xe: Order ring writes before ring tail updates", " - drm/xe: Fix xe_device_probe() failure", " - drm/radeon: fix autosuspend cleanup during teardown", " - s390/vfio_ccw: Calculate idal length based on idaw type", " - s390/zcrypt: Fix CPRB memory allocation in zcrypt misc code", " - drm/amd/display: fix BT.2020 YCbCr limited output CSC matrix", " - drm/amd/display: fix BT.2020 YCbCr output CSC matrices for DCE", " - drm/amdgpu: Reject UVD message with invalid number of h265 refs", " - drm/amdgpu: fix nbif 6.3.1 l1 low power not functional", " - drm/amdgpu: check ASPM on the dGPU host link", " - drm/amdgpu: Reject UVD message with dimensions above 4096", " - drm/amdgpu: Fix UVD min buffer sizes", " - drm/amdgpu: Fix UVD dpb min size calculation for H264", " - xfs: mark nonzero sb_gquotino as corrupt on metadir filesystems", " - xfs: clear zapped attr fork state when bmap repair finds no attr fork", " - xfs: check cowextsize in xrep_inode_cowextsize", " - xfs: fix transaction block reservation in xrep_rtbitmap", " - xfs: zero i_nlink before repair puts inode on unlinked list", " - xfs: only check mergeability of bnobt records", " - xfs: set the prev pointer when reinserting an inode on the unlinked list", " - xfs: pass runtime errors from xrep_iunlink_mark_ondisk_rec up to callers", " - xfs: nlink scrub must take IOLOCK before determining ILOCK state", " - xfs: load next_agino from the correct xfarray in", " xrep_iunlink_relink_prev", " - xfs: don't zap the attr fork on repair when there are queued pptr", " updates", " - xfs: fix allocated inodes that show up in the unlinked list", " - xfs: don't return EFSCORRUPTED when scrubbing corrupt parent pointers", " - xfs: don't ignore runtime errors in xrep_iunlink_reload_next", " - xfs: check xfarray iteration errors when committing unlinked inode lists", " - xfs: check v5 superblock features early", " - futex: Fix race in futex_pivot_pending() during private hash resize", " - sched_ext: Update p->scx.disallow warning in scx_init_task()", " - sched_ext: Reorganize enable/disable path for multi-scheduler support", " - ring-buffer: Store bpage pointers into subbuf_ids", " - arm64: tegra: Add EL2 virtual timer interrupt for Tegra194", " - crypto: ccm - Set rfc4309 maxauthsize from child", " - riscv: ftrace: Fix ftrace_modify_call failure on kprobed functions", " - gpio: ml-ioh: share the register lock across channels", " - ASoC: tas2781: fix clang build error for goto bypassing cleanup variable", " - netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort", " path", " - netfilter: ipset: fix list type element drift bug", " - netfilter: ipset: let destroy callbacks adjust ext mem size", " - eth: bnxt: cancel IRQ notifier before freeing affinity mask", " - eth: bnxt: keep the aRFS rmap updated when TPH is enabled", " - tcp: fix icsk_ack.ato bitfield overflow", " - net: phy: realtek: fix EEE advertisement write on the internal PHY MMD", " path", " - net: packet: fix wrong transport_header when sending VLAN-tagged frame", " - net: tap: fix wrong transport_header when sending VLAN-tagged frame", " - net/tls: Fail tls_sw_splice_read() after a failed async decrypt", " - ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers", " - regmap: sdw-mbq: Fix swap of timeout and retry times", " - af_packet: Don't send zero-byte data in tpacket_snd().", " - m68k: Define NR_CPUS to 1", " - accel/amdxdna: Skip unmapped range in aie2_populate_range()", " - drm/xe/oa: Fix sync entry leak on OA config emit failure", " - drm/log: Fix out-of-bounds read on empty message length", " - drm/log: Fix infinite loop when scale is too large for display", " - spi: virtio: mark device ready before registering the controller", " - erofs: fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms", " - ALSA: hda/realtek: Enable headset mic on F+ FLAPTOP r", " - drm/amdgpu/userq: serialize queue map against GPU reset", " - drm/amd: Disable DP audio spread spectrum for Cyan Skillfish", " - drm/radeon: restore hardware polling in fence_is_signaled to fix", " performance regression", " - drm/amdgpu: fix JPEG v5.3.0 queue reset failure in DPG mode", " - drm/amdgpu/gmc12.1: implement tlb inv semaphore", " - drm/amdgpu/gmc12.1: fix MMHUB0 check in pasid tlb flush", " - Input: atkbd - skip deactivate for HONOR ZQC-P", " - pmdomain: mediatek: mfg: initialize prev_o in mtk_mfg_attach_dev()", " - ftrace: Protect direct_functions in update_ftrace_direct_del", " - ftrace: Protect direct_functions in update_ftrace_direct_mod", " - drm/xe/guc_ads: allocate UM queues in a separate BO", " - drm/xe/guc_ads: allocate UM queues in VRAM on dGFX", " - drm/xe/guc_ads: use uncached mapping for UM queue BO", " - drm/amdgpu: fix missing check in vm_flush()", " - drm/amdkfd: Add bounds check for CRAT subtype length", " - net: rename netdev_ops_assert_locked()", " - clk: spacemit: k3: fix USB2 bus clock", " - gpiolib: Check gc->get_direction() before calling gpiod_get_direction()", " - regulator: fp9931: Fix VPOS/VNEG voltage selector table", " - ovpn: run deferred work on a module-owned workqueue", " - tick: Include ktime.h and jiffies.h in linux/tick.h", " - eth: bnxt: decrease indent in bnxt_request_irq()", " - drm/xe/pxp: add termination on resume", " - drm/xe/oa: Check managed mutex initialization errors", " - drm/xe: Set GT rp min frequency as 1.2GHz default for BMG/CRI", " - drm/xe: Fix a bug in pc_adjust_freq_bounds()", " - drm/log: Fix division by zero when scale module parameter is 0", " - Upstream stable to v6.18.45, v6.18.46, v7.1.9, v7.1.10", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74735", " - l2tp: fix tunnel and session refcount leak on seq_file release", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74745", " - eth: bnxt: avoid deadlock when canceling IRQ affinity notifier", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74747", " - ipvs: revalidate ihl to prevent out-of-bounds access", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74750", " - ovpn: defer key slot crypto freeing to workqueue", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74752", " - sctp: validate cookie AUTH state before use", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74754", " - scsi: core: pair EH runtime PM get and put", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80521", " - af_unix: Unlink scc_entry in unix_del_edge().", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80523", " - clk: spacemit: k3: set hdma clock as critical", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80524", " - optee: ffa: Add NULL check in optee_ffa_lend_protmem", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80557", " - libceph: fix OOB read in decode_watchers() via missing bounds check", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80579", " - fbdev: clear fb_info->mode before deleting a videomode", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80580", " - fbdev: bound mode sysfs output to the sysfs buffer", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80582", " - drm/shmem_helper: Check VMA boundaries for PMD mappings", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80583", " - ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74734", " - firewire: ohci: fix NULL pointer dereference in ar_context_release", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74736", " - net/sched: cls_bpf: reject dev-bound programs bound to a different", " device", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74737", " - net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74738", " - regmap: sdw-mbq: don't call an unset readable_reg callback", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74739", " - net/sched: cls_u32: skip hash tables in u32_bind_class()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74740", " - net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74741", " - net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74742", " - veth: fix queue index used to wake the peer txq in veth_poll", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74743", " - macvlan: inherit needed_headroom and needed_tailroom from lowerdev", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74744", " - ipvlan: inherit needed_headroom and needed_tailroom from phy_dev", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74746", " - netfilter: flowtable: publish GC-visible tuple last", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74748", " - netfilter: ipset: fix refcount race between list:set GC and swap", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74753", " - perf: Reject exited events as group leaders", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80519", " - ovpn: finish crypto callback cleanup before peer release", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80520", " - ovpn: fix NULL dereference when killing missing key", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80522", " - crypto: tegra - fix rctx->cryptlen calculation in tegra_gcm_do_one_req()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80525", " - ASoC: SOF: ipc4-topology: Refresh copier IPC payload before widget setup", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80526", " - ASoC: tas2562: Validate values for volume writes", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80527", " - ceph: fix hanging __ceph_get_caps() with stale mds_wanted", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80528", " - ceph: avoid fs reclaim while using current->journal_info", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80529", " - xfs: don't swallow dquot recovery verification errors", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80530", " - xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80531", " - xfs: avoid UAF on sc->tempip in xrep_tempfile_create", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80532", " - xfs: fix another iunlink infinite loop bug in online fsck", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80533", " - xfs: don't walk off the end of a null sc->sa.agi_bp in AGI repair", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80534", " - xfs: fix ilock leak on error in xfs_dq_get_next_id", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80535", " - xfs: don't double-lock when deleting a self-referential directory", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80536", " - xfs: bounds-check buffer log item's dirty bitmap", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80537", " - xfs: fix off-by-one in rtrefcount btree root level validation", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80538", " - xfs: propagate errors from xfs_rtginode_load", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80539", " - drm/amdgpu: disallow multiple FENCE chunks in one submit", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80540", " - drm/amdgpu: Fix UVD decode image min size calculation", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80541", " - drm/amdgpu: validate GEM_CREATE domain combinations", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80542", " - drm/amd/display: Fix NULL pointer dereference in", " amdgpu_dm_crtc_set_vblank()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80547", " - s390/vfio_ccw: Implement a crw lock", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80548", " - s390/vfio_ccw: Selectively expand io_mutex", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80549", " - s390/vfio_ccw: Move cp cleanup out of not operational", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80550", " - s390/vfio_ccw: Fix out of bounds check on CCW array", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80551", " - s390/vfio_ccw: Ensure first IDAW remains constant", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80552", " - s390/vfio_ccw: Ensure index for read/write regions are within range", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80553", " - s390/vfio_ccw: Cancel existing workqueues", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80554", " - s390/vfio_ccw: Limit the number of channel program segments", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80555", " - s390/vfio_ccw: Free all memory if cp_init() fails", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80556", " - mmc: atmel-mci: Fix use-after-free in atmci_remove due to race condition", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80558", " - libceph: Avoid using invalid osd indices from primary_temp", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80559", " - Input: sur40 - fix input device registration ordering", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80560", " - openrisc: signal: do not restore privileged SR bits on sigreturn", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80561", " - libceph: fix multiple unsafe decodes in decode_locker()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80562", " - gpio: ml-ioh: use raw_spinlock_t for the register lock", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80563", " - gpio: sloppy-logic-analyzer: fix use-after-free via debugfs trigger on", " unbind", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80564", " - gve: fix NULL dereference due to missing ptp adjfine", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80565", " - crypto: qce - fix error path in devm_qce_register_algs", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80566", " - Input: hynitron_cstxxx - validate touch count and finger IDs", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80567", " - Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80568", " - Input: synaptics-rmi4 - block s_input when F54 queue is busy", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80569", " - Input: synaptics-rmi4 - bound the F54 report size to the allocated", " buffer", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80570", " - Input: synaptics-rmi4 - zero report size on F54 work error", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80571", " - powerpc/pseries: papr-phy-attest - validate cmd.length, plug mem leak", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80572", " - Input: byd - synchronize timer deletion before freeing private data", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80573", " - Input: iforce - validate input packet lengths", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80574", " - Input: focaltech - fix array out-of-bounds in", " focaltech_process_rel_packet", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80575", " - Input: cs40l50-vibra - validate custom data from user space", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80576", " - drm/amdgpu: reject oversized IBs with per-ring packet limits", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80577", " - drm/panthor: skip zero-sized firmware sections", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80578", " - fbdev: core: Fix pointer desynchronization in fb_io_read()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80581", " - ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC", " timeout", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80584", " - s390/qeth: validate user buffer length in SNMP and ARP query ioctls", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80585", " - mptcp: fastopen: only mark MPTFO subflows with SYN data", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80586", " - mptcp: options: reset DSS fields in case of unexpected size", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80587", " - mptcp: avoid combining some incoming suboptions", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80588", " - mptcp: reclaim forward-allocated memory on RX path errors", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-80589", " - block: stop the timeout timer when releasing a never added disk", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74593", " - sched_ext: Take cgroup_lock() first in scx_cgroup_lock()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74596", " - fs,fsverity: remove check for fsverity being enabled in", " setattr_prepare()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74600", " - mm/page_table_check: skip special zero mappings", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74605", " - eventfs: Use children field for rcu head and add memory barriers", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74626", " - NTB: ntb_netdev: Preserve RX queue depth on allocation failure", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74645", " - mm/damon/lru_sort: error out for >10000 active_mem_bp", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74674", " - mm: fix incorrect flush address in direct page table reclaim", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74686", " - rqspinlock: Reset tail when preserving queue on deadlock", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74699", " - drm/xe: Fix memory leak in exec_queue_set_hang_replay_state()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74706", " - bnge: Fix NULL pointer dereference in aux device release", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74713", " - vhost_iotlb: bound map allocation in add_range", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74715", " - bpf: Fix netns reference imbalance in conntrack kfuncs", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74716", " - accel/amdxdna: Fix locally exploitable BUG_ON in amdxdna_insert_pages()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74721", " - accel/amxdna: Fix page-insertion errors in amdxdna_insert_pages()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74723", " - btrfs: lzo: reject inline extents without valid headers", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74729", " - soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74733", " - gpio: pca953x: fix pca953x_irq_bus_sync_unlock regmap lock", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74585", " - thunderbolt: Bound the DROM dual link port number before indexing", " sw->ports", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74586", " - sctp: clear new_transport when removing a peer", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74587", " - sctp: fix use-after-free of cached ASCONF chunk", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74588", " - sctp: keep chunk->transport in step with the list it is queued on", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74589", " - bpf, sockmap: Fix sk_redir use-after-free in send verdict", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74590", " - fsverity: Fix bpf_get_fsverity_digest() dynptr assumptions", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74591", " - mm/filemap: __filemap_add_folio() restore index before retrying", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74592", " - ima: Instantiate file_truncate and path_truncate hooks", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74594", " - sched/psi: Shut down rtpoll_timer in psi_cgroup_free()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74595", " - fscrypt: use the mount idmap for the owner check in", " fscrypt_ioctl_set_policy()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74597", " - ip6_tunnel: clear skb2->cb[] in ip6ip6_err()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74598", " - ipv6: fix Route Information option length validation", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74599", " - mm/ptdump: always stabilise against page table freeing using init_mm", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74601", " - ring-buffer: Use current_context for safe per-CPU buffer swap", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74602", " - ring-buffer: Initialise reader page order in rb_allocate_cpu_buffer()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74603", " - ptp: ocp: Fix board ID over-read", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74604", " - Revert \"thermal/drivers/hwmon: Cleanup coding style a bit\"", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74606", " - eventfs: Fix use-after-free in eventfs_remove_rec()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74607", " - KVM: SVM: Serialize accesses to the owner and mirror list with separate", " lock", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74608", " - smb: client: Fix use-after-free in cifs_try_adding_channels()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74609", " - tipc: read le->link under the node lock in tipc_node_link_down()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74610", " - tls: don't leave a full plaintext sk_msg ring unpushed", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74611", " - tls: rx: restore msg_iter before TLS 1.3 optimistic retry", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74580", " - vhost: reset the vring metadata cache on vring reconfiguration", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74612", " - veth: fix skb length accounting after XDP frag adjustment", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74613", " - vsock/virtio: avoid refilling the RX queue after teardown", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74614", " - vsock/virtio: read virtqueues under worker locks", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74615", " - vxlan: do not arm the ageing timer on a device that is down", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74616", " - xdp: reject clones that overrun skb_shared_info tailroom", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74617", " - dibs: initialise dibs->lock in dibs_dev_alloc()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74618", " - binfmt_misc: don't warn when the mount is completed from another user", " namespace", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74619", " - ovl: don't warn when the mount is completed from another user namespace", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74620", " - net/sched: act_gact, act_police: range check the fallback control action", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74621", " - net/sched: act_ct: fix sk_buff leak when the header checks reject a", " packet", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74622", " - net: atlantic: free RX pages of consumed but not refilled buffers", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74623", " - net: atlantic: free stranded TX buffers on ring deinit", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74624", " - netfilter: nf_conntrack: defer invalid log until after unlock", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74625", " - netfilter: bridge: release template ct on non-IP path", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74627", " - net: devmem: prevent net-iov / page mixing", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74628", " - net/x25: fix use-after-free of the socket by its timers", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74629", " - net/dibs: Correct freeing of dmb_clientid_arr", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74630", " - ipv6: prevent in6_dev_get() from resurrecting inet6_dev", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74631", " - net: smc: fix splice entry lifetime imbalance in smc_rx_splice", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74632", " - mm/huge_memory: fix huge_zero_pfn race", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74633", " - tracing: Fix NULL pointer dereference in module event cache removal", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74634", " - ring-buffer: Prevent subbuf order change when resizing is disabled", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74635", " - fbdev: bitblit: bound-check glyph index in bit_cursor()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74636", " - tracing: Fix race between update_event_fields and, event_define_fields", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74637", " - perf/core: Fix group leader use-after-free after sibling detach", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74638", " - drm/v3d: Serialize the scheduler timeout handlers", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74639", " - ALSA: us144mkii: re-anchor capture URBs on resubmission", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74640", " - ALSA: FCP: fix OOB write in fcp_meter_ctl_get()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74641", " - ALSA: usx2y: bound the hwdep mmap fault offset", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74643", " - samples/damon/mtier: error out for zero quota goal target values", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74644", " - mm/damon/ops-common: putback folios on invalid migrate nid", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74646", " - misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74647", " - misc: fastrpc: Remove buffer from list prior to unmap operation", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74648", " - staging: rtl8723bs: validate monitor transmit frame lengths", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74649", " - staging: rtl8723bs: fix missing shared-key auth challenge length check", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74650", " - staging: rtl8723bs: fix OOB read in WMM_param_handler()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74651", " - staging: rtl8723bs: fix OOB read in rtw_get_wpa_ie()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74652", " - serial: amba-pl011: cancel RS485 hrtimers after freeing IRQ", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74653", " - serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74654", " - serial: 8250_dma: Clear stale RX state on shutdown", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74655", " - serial: qcom-geni: fix TX DMA buffer flush", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74656", " - ipv4: fix use-after-free in fib_nhc_update_mtu()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74657", " - ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74658", " - futex: Prevent robust futex exit race some more", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74659", " - net: bridge: mrp: fix uninitialised bytes on the wire", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74660", " - netfilter: ebt_nflog: pin the NFLOG backend", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74661", " - mac802154: fix netdev use-after-free in beacon worker", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74662", " - inet: frags: publish queues before arming timer", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74663", " - net/sched: reject overly deep qdisc hierarchies", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74664", " - net: openvswitch: reallocate update replies for mismatched IDs", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74665", " - net: fix skb length accounting after generic XDP frag adjustment", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74666", " - packet: synchronize pressure clearing with ring reconfiguration", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74667", " - net/packet: reset the MAC header on the packet-socket transmit path", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74668", " - packet: use consistent hard_header_len in TX_RING send path", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74582", " - packet: use consistent hard_header_len in non-ring send paths", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74669", " - ipvs: clear IPv4 options after rebasing tunnel ICMP errors", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74670", " - ipvs: stop estimator after disabled calc phase", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74671", " - ima: fix out-of-bounds read in xattr_verify()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74672", " - mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74673", " - Input: evdev - fix information leak in evdev_pass_values()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74675", " - vt: stabilize tty reference in kbd_keycode with tty_port_tty_get", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74676", " - vt: add permission check for KDSKBMETA ioctl", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74677", " - net: usb: ipheth: fix carrier_work UAF on disconnect", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74678", " - net: usb: ax88179_178a: fix skb leak in ax88179_tx_fixup()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74679", " - usb: gadget: f_ncm: Use unsigned int for ndp_index", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74680", " - usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74681", " - usb: misc: usbio: check ibuf_len against rxbuf_len in bulk msg", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74682", " - ALSA: usb-audio: fix OOB write on Type II inbound URBs", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74683", " - Input: evdev - sanitize event type index when fetching event masks", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74684", " - net: tap: set skb->dev before parsing virtio net header in", " tap_get_user_xdp()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74685", " - hwmon: (ltc4282) Clamp negative current limits", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74687", " - watchdog: at91sam9_wdt: prevent timer rearm during teardown", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74688", " - sctp: clear control chunk transport if it is being removed", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74689", " - net/atm: fix slab-out-of-bounds read in vcc_setsockopt()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74690", " - s390/ism: Fix UAF of sba and ieq during ism_dev_exit()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74691", " - net: thunderbolt: Tear down DMA paths before stopping the rings", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74692", " - net/smc: fix TOCTOU race between smc_listen_out() and listener close", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74693", " - net: prestera: validate firmware header length", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74694", " - net/ncsi: fix heap OOB read in NCSI_CMD_SEND_CMD payload length", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74695", " - netfilter: nf_flow_table: drop existing skb dst before", " skb_dst_set_noref()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74696", " - tcp: fix TFO max_qlen accounting across reuseport migration", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74697", " - bnxt_en: Disable EOP for TPA on all chips to prevent data corruption", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74698", " - net/mlx5e: fix BQL reset on SQ re-activation", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74700", " - net/sched: cls_api: Always acquire rtnl_lock when destroying locked", " classifiers", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74701", " - net/openvswitch: check Ethernet header length in key_extract()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74702", " - vhost-scsi: reject feature changes after endpoint", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74703", " - vhost-scsi: Validate T10 PI scatterlist counts", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74704", " - net/sched: sch_cake: drop WARN_ON(1) for malformed packets in ACK filter", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74705", " - udp: fix potential use-after-free in tunnel segmentation", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74707", " - xsk: validate metadata when processing requests", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74708", " - xsk: validate launch-time metadata size", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74709", " - xsk: clear metadata pointer when no timestamp is requested", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74710", " - xsk: require at least 16 bytes of TX metadata", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74711", " - hwmon: (pmbus) Fix type confusion in notification logic", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74712", " - vdpa/mlx5: Fix buffer length in create_direct_keys()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74714", " - bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74717", " - net/mlx5: fw_tracer, return NULL on create error", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74718", " - devlink: fix net namespace reference leak in reload", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74583", " - net/sched: cls_route: fix fastmap use-after-free on filter", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74719", " - net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in", " smc_llc_event_handler()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74720", " - bpf: Preserve pointer state for commuted arithmetic", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74722", " - btrfs: fix memory leak in btrfs_do_encoded_write()", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74724", " - ipvs: avoid out-of-bounds write in ip_vs_nat_icmp", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74725", " - enic: fix tx_hang_reset use-after-free on device removal", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74726", " - bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74727", " - ovpn: skip rehash for peers already removed from by_id", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74728", " - xfs: handle NULL b_addr in xfs_buf_free", "", " * Resolute update: upstream stable patchset 2026-09-01 (LP: #2166029) //", " CVE-2026-74730", " - NFS: Pin the 'struct nfs_server' during a FREE_STATEID call", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942)", " - kunit: tool: skip stty when stdin is not a tty", " - kunit: tool: Terminate kernel under test on SIGINT", " - netfilter: br_netfilter: Reallocate headroom if necessary in", " neigh_hh_bridge()", " - ALSA: hda/realtek: add quirk for HP Dragonfly Folio G3 2-in-1", " - HID: logitech-dj: Standardise hid_report_enum variable nomenclature", " - HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB", " write", " - HID: logitech-dj: fix wrong detection of bad DJ_SHORT output report", " - lib/alloc_tag: introduce mem_alloc_profiling_permanently_disabled()", " - pinctrl: qcom: Unconditionally mark gpio as wakeup enable", " - pinctrl: qcom: sc8280xp: Add missing wakeup entries for GPIO143/151", " - dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA", " - gpio: sloppy-logic-analyzer: Fix memory leak in gpio_la_poll_probe()", " - selftests/lkdtm: rename STACKLEAK_ERASING to KSTACK_ERASE", " - Revert \"UBUNTU: SAUCE: selftests/seccomp fix compilation issue for", " amd64\"", " - selftests/seccomp: Fix pointer type mismatch build error", " - ata: sata_mv: accept 1 or 2 resources in platform probe", " - ata: ahci_ceva: fix error paths in ceva_ahci_platform_enable_resources()", " - phy: qcom: m31-eusb2: Fix return value of init call", " - ASoC: max98095: fix missing IS_ERR() before PTR_ERR() on mclk lookup", " - ASoC: max98090: fix missing IS_ERR() before PTR_ERR() on mclk lookup", " - of: reserved_mem: prevent OOB when too many dynamic regions are defined", " - btrfs: fix leaking BTRFS_FS_STATE_REMOUNTING flag", " - btrfs: zoned: reset meta_write_pointer on zone reset", " - btrfs: raid56: fix an incorrect csum skip during scrub", " - phy: zynqmp: fix clock error handling in xpsgtr_phy_init()", " - phy: zynqmp: fix runtime PM leak on probe allocation failure", " - drm/mediatek: Check CRTC state before freeing", " - Drivers: hv: vmbus: Replace lockdep_hardirq_threaded() with lockdep", " annotation", " - mshv: Fix duplicate GSI detection for GSI 0", " - mshv: Fix sleeping under spinlock in mshv_portid_alloc", " - KVM: arm64: Reject guest_memfd memslots when the VM has MTE", " - KEYS: trusted: dcp: fix key_len validation and calc_blob_len() return", " type", " - assoc_array: trim the final shortcut word using the current chunk end", " - ipvs: fix the checksum validations", " - ipvs: fix places with wrong packet offsets", " - ipvs: do not mangle ICMP replies for non-first fragments", " - ASoC: SDCA: Ensure that Control Range is large enough for header", " - af_unix: fix listen() succeeding on sockets in the wrong state", " - selftests/net/af_unix: test listen() rejects wrong socket states", " - pinctrl-amd: Don't clear S4 wake bits at probe", " - smb: client: fix buffer leaks in SMB1 read and write", " - ASoC: tas2781: Use correct calibration data for SINEGAIN2 register", " - spi: spi-cadence: Move TX FIFO full busy-wait into FIFO", " - hwmon: (ina2xx) Make it easier to add more devices", " - hwmon: (ina2xx) Add support for INA234", " - hwmon: (ina2xx) Shift INA234 shunt and current registers", " - hwmon: (ina2xx) Fix various overflow issues", " - hwmon: (ltc4282) Fix reading the minimum alarm voltage", " - hwmon: (sht3x) Fix unaligned accesses", " - net: bridge: mrp: fix Option TLV length in MRP_Test frames", " - hwmon: (adt7470) Fix fans stuck in manual mode on I2C errors", " - hwmon: (adt7470) Fix cache updated before hardware write on I2C error", " - hwmon: (adt7470) Fix temperature alarm logic in hwmon_temp_read()", " - hwmon: (adt7470) Fix swapped PWM3 and PWM4 auto mode masks", " - hwmon: (adt7470) Use cached PWM frequency value", " - hwmon: (adt7470) Fix PWM auto temp state array and bounds check", " - powerpc/boot: Fix simpleboot CPU node lookup check", " - powerpc/boot: Fix treeboot-currituck CPU node lookup check", " - powerpc/boot: Fix treeboot-akebono CPU node lookup check", " - wifi: mac80211: validate individual TWT params before driver setup", " - netfs: clear PG_private_2 on copy-to-cache append failure", " - netfs: handle single writeback rolling buffer allocation failure", " - netfs: release readahead folios on iterator preparation failure", " - net: ethernet: mtk_eth_soc: pass eth to mtk_handle_irq_rx in", " poll_controller", " - hwmon: (pmbus) Fix return value from pmbus_update_byte_data()", " - idpf: adjust TxQ ring count minimum", " - idpf: Fix mailbox IRQ name leak on request failure", " - ice: suppress DPLL errors during reset recovery", " - Bluetooth: ISO: Fix data-race on iso_pi(sk) in socket and HCI event", " paths", " - Bluetooth: ISO: fix timeout vs sync_timeout typo in check_bcast_qos", " - Bluetooth: ISO: validate sockaddr_iso first in iso_sock_rebind_bis()", " - Bluetooth: ISO: fix CONNECTED -> CLOSED transition on shutdown/release", " - Bluetooth: ISO: ensure no dangling hcon references in iso_conn", " - Bluetooth: hci_sync: make hci_cmd_sync_run_once return -EEXIST if exists", " - Bluetooth: hci_sync: fix hci_conn_del() use in hci_le_create_conn_sync", " - x86/boot: Add volatile, clobbers and zero-length test in memcmp()", " - net: phylink: put link_gpio if phylink_create fails", " - scsi: target: iblock: Fix wrong PR ops NULL check for PREEMPT/RELEASE", " - scsi: ufs: core: Cancel RTC work in active-active suspend", " - scsi: ufs: core: Avoid IRQ thread wakeup during active UIC command", " - scsi: ufs: core: Revert \"Delegate the interrupt service routine to a", " threaded IRQ handler\"", " - scsi: zfcp: Fix memory leak during adapter release by destroying", " gid_pn_req", " - scsi: target: Clear cmd_cnt when initial counter enrollment fails", " - net: sxgbe: check descriptor ring allocation failures", " - can: isotp: check register_netdevice_notifier() error in module init", " - drm/i915/dp: Ignore the sink's DSC max FRL rate without a PCON DSC", " encoder", " - fprobe: Fix module reference count leak on error in register_fprobe()", " - tracing/mmiotrace: Reset dropped_count in mmio_reset_data()", " - tracing/mmiotrace: Add NULL check for mmio_trace_array in logging", " functions", " - riscv: drop __init from vec_check_unaligned_access_speed_all_cpus", " - accel/qaic: use sizeof(*trans_hdr) for transaction length check", " - net: dsa: mt7530: check bus->read() errors in the MDIO regmap backend", " - net: dsa: mt7530: error out on failed reads in MT7531 PHY polling", " - ptp: netc: fix potential interrupt storm caused by incorrect unbind", " order", " - net: libwx: fix FDIR ATR queue mismatch for software VLAN packets", " - octeontx2-pf: Set correct sequence for carrier off and tx queue stop", " - sched/deadline: Use revised wakeup rule only for running dl_server", " - spi: spi-nxp-fspi: add per-SoC SDR/DTR clock rate limits for all", " supported SoCs", " - drm/i915/hdmi: Poll for 200 msec for TMDS_Scrambler_Status", " - ksmbd: return success for deferred final close", " - iomap: add a separate bio_set for iomap_split_ioend", " - mshv: Fix race in mshv_irqfd_deassign", " - mshv: Fix level-triggered check on uninitialized data", " - mshv: Order pt_vp_array publish against irqfd assertion path", " - iommufd/viommu: Release the igroup lock on the vdevice_size error path", " - iommufd/viommu: Publish a vDEVICE only after vdevice_init() succeeds", " - iommufd: Fix wrong hwpt passed to iommufd_auto_response_faults on", " replace", " - pinctrl: microchip-sgpio: add missing select REGMAP_MMIO", " - erofs: cap LZMA stream pool size", " - [Config] Add EROFS_FS_LZMA_DEFAULT_MAX_STREAMS", " - pinctrl: bm1880: add missing select GENERIC_PINCONF", " - fortify: Disable -Wstringop-overread in tests", " - mm: migrate_device: fix pte_pfn/pte_dirty called on non-present PTE", " - mm/util: don't read __page_2 for order-1 folios in snapshot_page()", " - selftest: fix headers in fclog.c", " - fs/proc/task_mmu: fix PAGEMAP_SCAN written state for PMD holes", " - mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk()", " - mm/vmstat: fold stranded per-cpu node stats when a node comes online", " - tracing/probes: Reject $arg0 in meta argument expansion", " - tracing/fprobe: Roll back on enable_trace_fprobe() failure", " - KVM: VMX: add memory clobber to asm for VMX instructions", " - KVM: s390: pci: Fix missing error codes and memory unaccounting", " - KVM: s390: pci: Fix NULL dereference on AIBV allocation failure", " - KVM: s390: pci: Validate AIBV and AISB before pinning guest pages", " - sctp: validate Adaptation Indication parameter length", " - audit: fix potential integer overflow in audit_log_n_string()", " - Bluetooth: btusb: Fix short read errors in btusb_qca_send_vendor_req()", " - Bluetooth: btmtk: Fix short read errors in btmtk_usb_uhw_reg_read()", " - Bluetooth: SCO: give the socket its own sco_conn reference", " - bpf: lwt: Fix dst reference leak on reroute failure", " - afs: Fix afs_fs_fetch_data() to set call->async", " - afs: Fix afs_fs_fetch_data() to subtract transferred from len", " - ALSA: hda/realtek: Add quirk for TongFang X6SP45xU", " - ALSA: lx6464es: fix period byte count for 16-bit streams", " - ALSA: pcm: wake linked drain waiters on unlink", " - ASoC: fsl_asrc: fix m2m_init error path to use goto instead of bare", " return", " - ASoC: fsl_easrc: fix m2m_init error path to use goto instead of bare", " return", " - ASoC: tas2562: fix DVC coefficient write order", " - ASoC: tas2562: fix broken entries in the volume lookup table", " - ata: libata-eh: Increase STANDBY IMMEDIATE timeout", " - ata: libata-sata: fix ata_scsi_lpm_supported() iteration", " - dmaengine: qcom: bam_dma: Fix command element mask field for BAM v1.6.0+", " - e1000: fix memory leak in e1000_probe()", " - igc: remove napi_synchronize() in igc_down()", " - ipvs: do not propagate one-packet flag to synced conns", " - mshv: fix hv_input_get_system_property struct", " - io_uring/net: initialize mshot_len for send", " - mm: memcg: initialize *locked in memcg1_oom_prepare() stub", " - net: ipv6: clear suppressed fib6 rule result", " - powerpc/ps3: Fix map failure path in dma_ioc0_map_pages()", " - vxlan: re-fetch eth header after route_shortcircuit()", " - vxlan: unclone skb head before modifying eth header in", " route_shortcircuit()", " - tracing/filters: Fix false positive match in regex_match_full()", " - spi: spi-qpic-snand: write the feature value before executing", " SET_FEATURE", " - spi: qcom-qspi: Correct max DMA length to avoid 64K boundary failure", " - selftests/mm: fix potential wild pointer access of getline due to", " missing init", " - selftests/clone3: fix wild pointer access of getline due to missing init", " - sctp: reject stale cookies with mismatched verification tags", " - hwmon: (npcm750-pwm-fan): stop fan timer on device detach", " - hwmon: (pmbus/core) notify on the hwmon device, not the i2c client", " - i2c: amd-mp2: Unregister callback on adapter add failure", " - gpio: pca953x: fix cache_only and IRQ state on restore_context() failure", " - cifs: add fscache_resize_cookie() to cifs_setsize()", " - cpufreq: powernow-k8: Fix possible memory leak in powernowk8_cpu_init()", " - cpufreq: schedutil: Publish util hooks only after all sg_cpu are", " initialized", " - power: supply: bq25890: fix the -10 C NTC lookup entry", " - power: supply: max17040: handle missing status supplier", " - s390/pci: Fix s390_pci_mmio_write syscall error return without MIO", " - s390/dasd: Fix potential NULL pointer dereference", " - s390/dasd: Fix undersized format-check buffer", " - s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs", " - s390/zcrypt: Fix missing mem scrub at clear key import in", " cca_clr2cipherkey()", " - phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask", " - phy: zynqmp: use read-modify-write for SERDES scrambler bypass", " - phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB", " - net: openvswitch: fix skb leak on flow key update failure during", " recirculation", " - ice: fix VF interrupts cleanup", " - ice: fix memory leak in ice_lbtest_prepare_rings()", " - i2c: spacemit: request IRQ after controller initialization", " - i2c: qcom-cci: drop custom suspend/resume and rely on runtime PM helpers", " - i2c: iproc: reset bus after timeout if START_BUSY is stuck", " - i2c: imx: Fix slave registration race and error handling", " - can: c_can: c_can_chip_config(): keep controller in init mode until", " bittiming is configured", " - can: gs_usb: gs_usb_receive_bulk_callback(): resubmit URB on skb", " allocation failure", " - can: j1939: transport: j1939_session_fresh_new(): initialize receive", " buffer", " - can: j1939: use netdevice_tracker for j1939_{priv,session,ecu} tracking", " - can: kvaser_usb: kvaser_usb_hydra_get_busparams(): fix memory leak in", " kvaser_usb_hydra_get_busparams()", " - can: softing: fw_parse(): validate firmware record spans", " - can: ctucanfd: add missing MODULE_DEVICE_TABLE()", " - can: ctucanfd: use self-test mode for PRESUME_ACK", " - can: ctucanfd: unmap BAR0 using base address", " - can: ctucanfd: handle bus error interrupts", " - can: ctucanfd: mark error-active controller status valid", " - drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs", " - drm/bridge: display-connector: Fix I2C adapter resource leak", " - drm/mediatek: ovl_adaptor: balance component registrations", " - drm/amdgpu: move debug_vm handling to amdgpu_cs_parser_fini", " - drm/amdgpu: restore UMD profile pstate after runtime resume", " - drm/amd/pm: fix torn gpu metrics reads", " - drm/amd/display: Increase HDMI AV mute wait from 2 to 3 frames", " - drm/amd/display: use proper context for logging", " - drm/amdkfd: Fix missing authorization check in KFD_IOC_DBG_TRAP_DISABLE", " - drm/amdkfd: Handle invalid event type in CRIU event restore", " - drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size", " - drm/vmwgfx: clamp dirty-page range with min, not max", " - drm/vmwgfx: take fman->lock around fence list mutation in fifo_down", " - drm/vmwgfx: drop dma_buf reference on foreign-fd prime import", " - drm/vmwgfx: enforce cursor size limits for MOB cursors", " - drm/vmwgfx: use check_add_overflow for shader size+offset bound", " - drm/vmwgfx: validate external BO copy bounds for both stride paths", " - HID: logitech-dj: Fix maxfield check in DJ short report validation", " - drm/xe/rtp: Maintain OA whitelists separately", " - drm/xe/rtp: Keep track of non-OA nonpriv slots", " - drm/xe/rtp: Generalize whitelist_apply_to_hwe", " - drm/xe/rtp: Toggle 'deny' bit to (de-)whitelist OA regs", " - drm/xe/rtp: (De-)whitelist OA registers for all hwe's for a gt", " - drm/xe/oa: (De-)whitelist OA registers on OA stream open/release", " - drm/xe/rtp: Ensure locking/ref counting for OA whitelists", " - mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork()", " - fs/proc/task_mmu: fix PAGEMAP_SCAN written state for unpopulated ptes", " - net/handshake: Close the submit-side sock_hold race", " - usb: typec: ucsi: split connector lock classes", " - media: chips-media: wave5: Support CBP profile", " - drm/xe: add xe_migrate_resolve wrapper and is_vram_resolve support", " - drm/xe/bo: Add purgeable bo state tracking and field madv to xe_bo", " - drm/xe/vm: Prevent binding of purged buffer objects", " - drm/exec: Remove the index parameter from", " drm_exec_for_each_locked_obj[_reverse]", " - can: isotp: fix timer drain order, wakeup handling and tx_gen ordering", " - usb: typec: ucsi: Correct teardown ordering in ucsi_init() error path", " - mm/slab: decouple SLAB_NO_SHEAVES from SLAB_NO_OBJ_EXT", " - ALSA: hda/realtek: Add quirk for HP Dragonfly Folio G3 2-in-1", " (103c:8a05)", " - KVM: arm64: vgic: Avoid double-deactivate of IRQs in the nested context", " - dmaengine: idxd: fix double free of wq, engine, and group structs", " - btrfs: warn about extent buffer that can not be released", " - btrfs: zoned: skip fully truncated ordered extents at zone finish", " - rtla/timerlat_top: Fix on-threshold actions firing on signal", " - selftests: netfilter: nft_flowtable.sh: fix offload counter verification", " for tunnel tests", " - netfilter: nf_conntrack_expect: add and use nf_ct_expect_related_pair()", " - mshv_vtl: fix fd leak in mshv_ioctl_create_vtl()", " - ipvs: clear the nfct flag under lock", " - ASoC: SDCA: Correct pointer passed to devm_acpi_table_put", " - ASoC: SDCA: Always free firmware in FDL path", " - ASoC: SDCA: Make UMP message size check more robust", " - xsk: provide sufficient space in pool->tx_descs", " - net/sched: sch_cake: skip clearing unused tins during rate adjustment", " - erofs: clean up erofs_ishare_fill_inode()", " - erofs: remove fscache backend entirely", " - [Config] Remove EROFS_FS_ONDEMAND", " - erofs: ensure valid f_path for page cache sharing", " - ASoC: sophgo: return 1 on volume change in cv1800b_adc_volume_set()", " - ethtool: Embed FEC hist ranges as buffer in struct", " - idpf: bound interrupt-vector register fill to the allocated array", " - Bluetooth: hci_sync: hold conn in hci_connect_acl/le_sync() callbacks", " - Bluetooth: hci_sync: remove unnecessary hci_conn_get in create_conn_sync", " - scsi: ufs: core: Initialize hba->rpmbs list in ufshcd", " - drm/xe/pt: check no-DMA huge-pte cases before DMA segment test", " - ipv6: release fib6_null_entry on subtree failure", " - riscv: vdso: Only try to install vDSO when present", " - net: dsa: mt7530: error out on failed reads in ATC/VTCR command polling", " - net: stmmac: Fix E2E delay mechanism", " - net: mana: Create separate EQs for each vPort", " - net: mana: Return error code from mana_create_rxq()", " - mshv: Fix missing error code on VP allocation failure", " - mshv: Publish VP to pt_vp_array before installing the file descriptor", " - iommufd: Reject DMABUF pages from the access pin path", " - btrfs: raid56: fix scrub read assembly submitting no reads", " - btrfs: zoned: fix missing chunk metadata reservation", " - ocfs2: fix boundary check in ocfs2_check_dir_entry() to use buffer", " offset", " - userfaultfd: wait on source PMD during UFFDIO_MOVE", " - KVM: s390: pci: Fix resource leak on IRQ registration failure", " - Bluetooth: btmtk: Fix short read errors in btmtk_usb_reg_read()", " - ata: libata-scsi: terminate deferred commands on time out", " - ata: libata-scsi: schedule deferred atapi command", " - PCI: imx6: Keep i.MX6 Root Port MSI/MSI-X Capabilities with iMSI-RX to", " work around hardware bug", " - io_uring: preserve task restrictions across exec", " - scsi: libsas: terminate deferred commands on time out", " - scsi: ufs: dt-bindings: Add missing mcq reg for qcom,sa8255p-ufshc", " - can: rcar_canfd: change the initializing flow for clocks and resets", " - drm/mediatek: mtk_hdmi: Fix DDC adapter double put in v2", " - drm/amd/pm: hide pp_table sysfs on APUs", " - drm/amd/pm: use milliwatts for GPU power sensors", " - drm/amd/display: check if dml21_add_phantom_plane() is successful", " - drm/xe: Drop unused param from xe_device_create()", " - drm/xe: Move xe->info.force_execlist initialization", " - drm/xe: Move xe->info.devid|revid initialization", " - drm/xe: Drop unnecessary goto in xe_device_create", " - drm/xe: Separate early xe_device initialization", " - drm/xe: Set TTM device beneficial_order to 9 (2M)", " - Upstream stable to v6.18.44, v7.1.8", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74449", " - drm/amd/display: Fix divide-by-zero in calculate_mcache_setting on zero", " viewport", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74450", " - drm/amd/pm: fix pptable use-after-free", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74466", " - s390/zcrypt: Close speculative mem read possibility", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74483", " - binfmt_misc: don't leak the user namespace when the mount fails", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74496", " - fou: Fix use-after-free in fou_create()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74517", " - KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUs", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74521", " - ksmbd: use memcmp() to compare ClientGUIDs", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74526", " - scsi: mpi3mr: Fix potential deadlock in mpi3mr_fault_uevent_emit", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74528", " - Bluetooth: hci_sync: hold conn in hci_past_sync() callback", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74529", " - Bluetooth: hci_sync: hold conn in hci_connect_pa_sync() callback", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74530", " - Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74533", " - Bluetooth: ISO: fix race of kfree vs kref_get_unless_zero", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74542", " - netfs: Fix folio_queue ENOMEM in writeback by adding a mempool", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74544", " - net/sched: cls_u32: validate offshift to prevent shift-out-of-bounds", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74554", " - wifi: ath12k: fix out-of-bounds clear_bit in", " ath12k_mac_dp_peer_cleanup()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74558", " - xsk: reclaim invalid Tx descriptors in ZC batch path", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74561", " - nexthop: avoid unlocked f6i_list walk in nh_rt_cache_flush", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74562", " - nexthop: take nh->lock for f6i_list walks in replace check and notify", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74571", " - btrfs: skip global block reserve accounting for rescue mounts", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74440", " - drm/xe: Wait on external BO kernel fences in exec IOCTL", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " [SRU] amdgpu: Fix garbled display when switching workspaces (LP: #2166730)", " - drm/amd/display: check GRPH_FLIP status before sending event", " - drm/amd/display: Exit idle optimizations before programming", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74441", " - usb: typec: ucsi: Fix race condition and ordering in port unregistration", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74482", " - mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74442", " - drm/vmwgfx: avoid destroy_workqueue(NULL) on vkms init failure", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74443", " - drm/vmwgfx: bound DMA command body size against suffix pointer", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74444", " - drm/vmwgfx: validate DRAW_PRIMITIVES header size before division", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74445", " - drm/vmwgfx: reject DX_BIND_QUERY without a DX context", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74446", " - drm/amdkfd: hold event_mutex while checkpointing CRIU events", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74447", " - drm/amdkfd: fix uint32_t overflow in EOP ring buffer size alignment", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74448", " - drm/amdkfd: fix QID bit leak in pqm_create_queue()", "", " * [SRU] Fix incorrect GTT calculation on the APU systems (LP: #2162038) //", " Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942)", " - drm/amdgpu: cap GTT size to physical RAM on APUs", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74451", " - drm/panthor: validate firmware interface structure sizes", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74452", " - drm/panthor: reject firmware sections with oversized data", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74453", " - drm/vc4: Zero the tile state data array before each BIN job", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74454", " - drm/vc4: Supply the overflow slot size in BPOS, not the whole bin BO", " size", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74455", " - can: peak_usb: validate uCAN receive record lengths", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74456", " - can: peak_usb: peak_usb_start(): fix double free of transfer buffer on", " URB submit error", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74457", " - can: peak_usb: add bounds check for USB channel index", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74458", " - can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received", " command extents", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74459", " - can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB", " resubmit failure", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74460", " - can: ems_usb: validate CPC message lengths", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74461", " - i2c: imx: Cancel hrtimer before clearing slave pointer", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74462", " - i2c: imx: mark I2C adapter when hardware is powered down", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74463", " - i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock", " deadlock", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74464", " - net: openvswitch: fix skb leak on flow key update failure during ct", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74465", " - net: openvswitch: fix potential UAF on meter attach failure", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-68451", " - s390/zcrypt: Validate length for CCA ECC private key requests", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-68452", " - s390/zcrypt: Validate length for CCA AES cipher key requests", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-68453", " - s390/zcrypt: Fix buffer over-read in cca_cipher2protkey", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74467", " - s390/qeth: Check CAP_NET_ADMIN for private ioctls", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74468", " - gpio: pch: use raw_spinlock_t for the register lock", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74469", " - sctp: prevent peer transport count overflow", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74470", " - scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74471", " - tracing: Check return value of __register_event() in", " trace_module_add_events()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74472", " - ublk: reset kernel-owned dev_info fields in ublk_ctrl_add_dev()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74473", " - vxlan: use pskb_network_may_pull() in route_shortcircuit()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74474", " - vxlan: use pskb_network_may_pull() for transmit path header pulls", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74475", " - vxlan: use neigh_ha_snapshot() in route_shortcircuit()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74476", " - veth: convert frag_list skbs before running XDP", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74477", " - uprobes: Fix NULL pointer dereference in hprobe_expire()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74478", " - um: vector: fix use-after-free in vector_mmsg_rx()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74479", " - net: pktgen: fix proc entry use-after-free", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74480", " - net: bridge: stop fast-leave after deleting a port group", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74481", " - mm/page_reporting: use system_freezable_wq to fix UAF during suspend", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74484", " - binfmt_misc: don't let an 'F' entry pin its own instance", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74485", " - binfmt_misc: reject a flag character as the field delimiter", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74486", " - binfmt_misc: use exe_file_deny_write_access() for the interpreter clone", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74487", " - binfmt_misc: restore write access when removing an entry", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74488", " - wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74490", " - tipc: avoid use-after-free in poll trace queue dumps", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74491", " - of/address: Fix NULL bus dereference in of_pci_range_parser_one()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74492", " - netfilter: ipset: do not update comments from kernel-side hash adds", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74493", " - net/smc: fix socket use-after-free during link group termination", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74494", " - ksmbd: reject repeated SMB2 NEGOTIATE requests", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74495", " - igbvf: Fix leak in TX DMA error cleanup", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74497", " - ALSA: usb-audio: Clamp frame size in implicit-feedback mode", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74498", " - ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74499", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74500", " - ALSA: usb-audio: fix stack info leak in RME Digiface status", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74501", " - ALSA: usb-audio: fix use-after-free in ump_to_endpoint()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74502", " - ALSA: ump: fix double free of out_cvts on rawmidi error", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74503", " - ALSA: timer: Clear SNDRV_TIMER_IFLG_DEAD once the close completes", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74504", " - ALSA: seq: Fix division by zero in initialize_timer()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74505", " - ALSA: 6fire: Fix UAF at error handling during probe", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74506", " - afs: Fix UAF when sending a message", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74507", " - Bluetooth: HIDP: validate numbered report payloads", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74508", " - Bluetooth: HIDP: reject frames without a transaction header", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74509", " - Bluetooth: hci_sync: Fix advertising data UAFs", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74510", " - Bluetooth: mgmt: fix UAF in pair command cancellation", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74511", " - Bluetooth: mgmt: fix pending command UAF in EIR updates", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74512", " - audit: fix potential use-after-free in audit_del_rule()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74513", " - dibs: fix use-after-free of dmb_node in loopback", " attach/detach/unregister", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74514", " - KVM: s390: pci: Fix memory accounting for pinned/unpinned pages", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74515", " - KVM: s390: pci: Reject adapter interrupt forwarding if already enabled", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74516", " - KVM: SVM: Update x2APIC MSR intercepts if AVIC is inhibited while L2 is", " active", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74518", " - mm/hugetlb: fix list corruption in allocate_file_region_entries()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74519", " - pinctrl: devicetree: don't free uninitialized dev_name on error path", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74520", " - iommu/iommufd: Fix IOPF group ownership UAF", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74522", " - ksmbd: fix use-after-free in __close_file_table_ids()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74523", " - qede: sync udp_tunnel ports outside qede_lock in the recovery path", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74524", " - riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74525", " - net: sxgbe: free TX rings on RX allocation failure", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74531", " - Bluetooth: hci_conn: hold conn reference in abort_conn_sync()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74532", " - Bluetooth: btintel: Validate length before parsing diagnostics TLV", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74534", " - Bluetooth: ISO: fix refcounting of iso_conn", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74535", " - Bluetooth: ISO: avoid deadlocks in iso_sock_timeout", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74536", " - Bluetooth: ISO: fix leaking sk after socket release", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74537", " - Bluetooth: ISO: hold sk properly in iso_conn_ready", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74538", " - Bluetooth: ISO: lock sk in iso_connect_ind", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74539", " - Bluetooth: ISO: lock sk in iso_sock_getname", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74540", " - Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74541", " - Bluetooth: ISO: clear iso_data always when detaching conn from hcon", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74543", " - net: udp_tunnel: fix memory leak in udp_tunnel_nic_unregister()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74545", " - rtase: fix double free of multi-frag skb on DMA map failure", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74546", " - hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74547", " - hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74548", " - forcedeth: fix UAF of txrx_stats in nv_remove", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74549", " - hwmon: (nct6775-core) Prevent access to unsupported weight registers", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74550", " - net: do not send ICMP/NDISC Redirects when peer allocation fails", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74551", " - hwmon: (nzxt-smart2) DMA-align output buffer", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74552", " - hwmon: (lm90) Only report alarms if driver is ready", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74553", " - hwmon: (nct6775-core) Fix number of temperature registers for NCT6116", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74555", " - scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74556", " - scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection", " buffer", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74557", " - scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74559", " - xsk: drain continuation descs after overflow in xsk_build_skb()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74560", " - xsk: fix buffer leak in xsk_drop_skb() for AF_XDP multi-buffer Tx", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74563", " - rds: tcp: hold the RCU lock across ipv6_chk_addr() in", " rds_tcp_laddr_check()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74579", " - netfilter: nft_payload: fix mask build for partial field offload", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74564", " - netfilter: xt_hashlimit: validate hashtable supports", " XT_HASHLIMIT_RATE_MATCH", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74565", " - netfilter: nf_tables: make nft_object rhltable per table", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74566", " - keys: make keyring key-chunk byte order agree with", " keyring_diff_objects()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74567", " - keys: fix out-of-bounds read in keyring_get_key_chunk()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74569", " - netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in", " sip_help_tcp()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74572", " - btrfs: zoned: fix deadlock between metadata writeback and transaction", " commit", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74573", " - iommu/arm-smmu-v3-iommufd: Require exactly one Stream ID for a vDEVICE", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74574", " - dmaengine: idxd: fix fdev setup failure cleanup in idxd_cdev_open()", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74575", " - thunderbolt: Prevent XDomain delayed work use-after-free on disconnect", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74576", " - mm/slab: prevent unbounded recursion in free path with new kmalloc type", "", " * Resolute update: upstream stable patchset 2026-08-31 (LP: #2165942) //", " CVE-2026-74577", " - net: mpls: initialize rtm_tos in mpls_getroute()", "" ], "package": "linux", "version": "7.0.0-39.39", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 2168074, 2168012, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167950, 2167609, 2167609, 2167609, 2167609, 2167609, 2167609, 2167609, 2167609, 2167609, 2167609, 2165251, 2162917, 2166944, 2160475, 2166631, 2165732, 2148534, 2158217, 2158540, 2166235, 2166181, 2166517, 2166363, 2166363, 2166363, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2166029, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2166730, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2162038, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942, 2165942 ], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 10:42:15 +0200" } ], "notes": "linux-modules-7.0.0-42-generic version '7.0.0-42.42' (source package linux version '7.0.0-42.42') was added. linux-modules-7.0.0-42-generic version '7.0.0-42.42' has the same source package name, linux, as removed package linux-modules-7.0.0-38-generic. As such we can use the source package version of the removed package, '7.0.0-38.38', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-image-7.0.0-38-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "7.0.0-38.38", "version": "7.0.0-38.38" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-main-modules-zfs-7.0.0-38-generic", "from_version": { "source_package_name": "linux-main-signed", "source_package_version": "7.0.0-38.38", "version": "7.0.0-38.38" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-modules-7.0.0-38-generic", "from_version": { "source_package_name": "linux", "source_package_version": "7.0.0-38.38", "version": "7.0.0-38.38" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "notes": "Changelog diff for Ubuntu 26.04 resolute image from daily image serial 20261027 to 20261105", "from_series": "resolute", "to_series": "resolute", "from_serial": "20261027", "to_serial": "20261105", "from_manifest_filename": "daily_manifest.previous", "to_manifest_filename": "manifest.current" }