{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-5.15.0-1104-kvm", "linux-image-5.15.0-1104-kvm", "linux-kvm-headers-5.15.0-1104", "linux-modules-5.15.0-1104-kvm" ], "removed": [ "linux-headers-5.15.0-1103-kvm", "linux-image-5.15.0-1103-kvm", "linux-kvm-headers-5.15.0-1103", "linux-modules-5.15.0-1103-kvm" ], "diff": [ "linux-headers-kvm", "linux-image-kvm", "linux-kvm", "python3-httplib2", "python3-idna", "tar", "ubuntu-advantage-tools", "ubuntu-pro-client", "ubuntu-pro-client-l10n", "wget", "xxd" ] } }, "diff": { "deb": [ { "name": "linux-headers-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1103.99", "version": "5.15.0.1103.99" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1104.100", "version": "5.15.0.1104.100" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1104", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1104.100", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Hannah Peuckmann ", "date": "Tue, 30 Jun 2026 09:20:51 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1103.99", "version": "5.15.0.1103.99" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1104.100", "version": "5.15.0.1104.100" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1104", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1104.100", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Hannah Peuckmann ", "date": "Tue, 30 Jun 2026 09:20:51 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1103.99", "version": "5.15.0.1103.99" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1104.100", "version": "5.15.0.1104.100" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1104", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1104.100", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Hannah Peuckmann ", "date": "Tue, 30 Jun 2026 09:20:51 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-httplib2", "from_version": { "source_package_name": "python-httplib2", "source_package_version": "0.20.2-2", "version": "0.20.2-2" }, "to_version": { "source_package_name": "python-httplib2", "source_package_version": "0.20.2-2ubuntu0.1", "version": "0.20.2-2ubuntu0.1" }, "cves": [ { "cve": "CVE-2026-59939", "url": "https://ubuntu.com/security/CVE-2026-59939", "cve_description": "httplib2 is a comprehensive HTTP client library for Python. Prior to 0.32.0, httplib2 performs unbounded decompression of HTTP response bodies encoded with Content-Encoding: gzip or deflate in _decompressContent in httplib2/init.py, allowing a malicious or compromised HTTP server to return a small compressed payload that expands to an arbitrarily large size in memory and causes MemoryError or OOM-kill in the client process. This issue is fixed in version 0.32.0.", "cve_priority": "medium", "cve_public_date": "2026-07-08 20:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-59939", "url": "https://ubuntu.com/security/CVE-2026-59939", "cve_description": "httplib2 is a comprehensive HTTP client library for Python. Prior to 0.32.0, httplib2 performs unbounded decompression of HTTP response bodies encoded with Content-Encoding: gzip or deflate in _decompressContent in httplib2/init.py, allowing a malicious or compromised HTTP server to return a small compressed payload that expands to an arbitrarily large size in memory and causes MemoryError or OOM-kill in the client process. This issue is fixed in version 0.32.0.", "cve_priority": "medium", "cve_public_date": "2026-07-08 20:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: unbounded decompression of HTTP response bodies", " - debian/patches/CVE-2026-59939.patch: decompression limited by size and", " ratio; require python 3.8+ in README.md, python3/httplib2/__init__.py,", " python3/httplib2/decode.py, setup.cfg, tests/__init__.py,", " tests/test_encoding.py.", " - CVE-2026-59939", "" ], "package": "python-httplib2", "version": "0.20.2-2ubuntu0.1", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 10 Jul 2026 08:18:56 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-idna", "from_version": { "source_package_name": "python-idna", "source_package_version": "3.3-1ubuntu0.1", "version": "3.3-1ubuntu0.1" }, "to_version": { "source_package_name": "python-idna", "source_package_version": "3.3-1ubuntu0.2", "version": "3.3-1ubuntu0.2" }, "cves": [ { "cve": "CVE-2026-45409", "url": "https://ubuntu.com/security/CVE-2026-45409", "cve_description": "Internationalized Domain Names in Applications (IDNA) for Python provides support for Internationalized Domain Names in Applications (IDNA) and Unicode IDNA Compatibility Processing. In versions prior to 3.15, payloads such as `\"\\u0660\" * N` or `\"\\u30fb\" * N + \"\\u6f22\"` utilize the `valid_contexto` function prior to length rejection, and for high values of `N` will take a long time to process. This is the same issue as CVE-2024-3651, however the original remediation in 2024 was not a complete fix. A specially crafted argument to the `idna.encode()` function could consume significant resources. This may lead to a denial-of-service. Starting in version 3.14, the function rejects long inputs as soon as practicable prior to any further processing to minimize resource consumption. In version 3.15, this approach was extended to lesser used alternate functions (i.e. per-label conversions and codec support). A workaround is available. Domain names cannot exceed 253 characters in length. If this length limit is enforced prior to passing the domain to the `idna.encode()` function, it should no longer consume significant resources. This is triggered by arbitrarily large inputs that would not occur in normal usage, but may be passed to the library assuming there is no preliminary input validation by the higher-level application.", "cve_priority": "medium", "cve_public_date": "2026-06-05 23:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-45409", "url": "https://ubuntu.com/security/CVE-2026-45409", "cve_description": "Internationalized Domain Names in Applications (IDNA) for Python provides support for Internationalized Domain Names in Applications (IDNA) and Unicode IDNA Compatibility Processing. In versions prior to 3.15, payloads such as `\"\\u0660\" * N` or `\"\\u30fb\" * N + \"\\u6f22\"` utilize the `valid_contexto` function prior to length rejection, and for high values of `N` will take a long time to process. This is the same issue as CVE-2024-3651, however the original remediation in 2024 was not a complete fix. A specially crafted argument to the `idna.encode()` function could consume significant resources. This may lead to a denial-of-service. Starting in version 3.14, the function rejects long inputs as soon as practicable prior to any further processing to minimize resource consumption. In version 3.15, this approach was extended to lesser used alternate functions (i.e. per-label conversions and codec support). A workaround is available. Domain names cannot exceed 253 characters in length. If this length limit is enforced prior to passing the domain to the `idna.encode()` function, it should no longer consume significant resources. This is triggered by arbitrarily large inputs that would not occur in normal usage, but may be passed to the library assuming there is no preliminary input validation by the higher-level application.", "cve_priority": "medium", "cve_public_date": "2026-06-05 23:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: DoS via specially crafted inputs to idna.encode()", " - debian/patches/CVE-2026-45409-1.patch: Reject oversized inputs up-front in", " idna/core.py, tests/test_idna.py.", " - debian/patches/CVE-2026-45409-2.patch: Use valid_string_length() for early", " oversized-input check in idna/core.py.", " - debian/patches/CVE-2026-45409-3.patch: Enforce early length limits in", " check_label in idna/core.py, tests/test_idna.py.", " - CVE-2026-45409", "" ], "package": "python-idna", "version": "3.3-1ubuntu0.2", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 14 Jul 2026 13:21:34 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "tar", "from_version": { "source_package_name": "tar", "source_package_version": "1.34+dfsg-1ubuntu0.1.22.04.4", "version": "1.34+dfsg-1ubuntu0.1.22.04.4" }, "to_version": { "source_package_name": "tar", "source_package_version": "1.34+dfsg-1ubuntu0.1.22.04.5", "version": "1.34+dfsg-1ubuntu0.1.22.04.5" }, "cves": [ { "cve": "CVE-2026-5704", "url": "https://ubuntu.com/security/CVE-2026-5704", "cve_description": "A flaw was found in tar. A remote attacker could exploit this vulnerability by crafting a malicious archive, leading to hidden file injection with fully attacker-controlled content. This bypasses pre-extraction inspection mechanisms, potentially allowing an attacker to introduce malicious files onto a system without detection.", "cve_priority": "medium", "cve_public_date": "2026-04-06 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2160650 ], "changes": [ { "cves": [ { "cve": "CVE-2026-5704", "url": "https://ubuntu.com/security/CVE-2026-5704", "cve_description": "A flaw was found in tar. A remote attacker could exploit this vulnerability by crafting a malicious archive, leading to hidden file injection with fully attacker-controlled content. This bypasses pre-extraction inspection mechanisms, potentially allowing an attacker to introduce malicious files onto a system without detection.", "cve_priority": "medium", "cve_public_date": "2026-04-06 16:16:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: Extract files issue", " - debian/patches/CVE-2026-5704-*.patch: address a regression", " that makes valid files not extract in src/list.c,", " tests/Makefile.am, tests/extrac32.at, tests/extrac34.at,", " test/testsuite.at, src/extract.c, tests/extract23,", " tests/extrac30.at (LP: #2160650).", "" ], "package": "tar", "version": "1.34+dfsg-1ubuntu0.1.22.04.5", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [ 2160650 ], "author": "Leonidas Da Silva Barbosa ", "date": "Wed, 15 Jul 2026 11:39:01 -0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "ubuntu-advantage-tools", "from_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "37.2ubuntu~22.04", "version": "37.2ubuntu~22.04" }, "to_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "37.2ubuntu~22.04.1", "version": "37.2ubuntu~22.04.1" }, "cves": [ { "cve": "CVE-2026-9494", "url": "https://ubuntu.com/security/CVE-2026-9494", "cve_description": "An information disclosure vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client validates Ubuntu Pro APT credentials by executing /usr/lib/apt/apt-helper using the download-file command. During this process, the secret bearer token is embedded directly in the cleartext URL component passed via the command-line arguments (argv), resulting in a URL format such as https://bearer:@esm.ubuntu.com/.../. On systems utilizing a default-mounted /proc file system where process-hiding mitigations (such as hidepid) are disabled, an unprivileged local attacker can monitor system processes and read the sensitive bearer token directly from /proc//cmdline while the helper process is actively running. This leaked token can subsequently be used to gain unauthorized access to the victim's Ubuntu Pro or Expanded Security Maintenance (ESM) repositories.", "cve_priority": "medium", "cve_public_date": "2026-07-17 14:00:00 UTC" }, { "cve": "CVE-2026-11386", "url": "https://ubuntu.com/security/CVE-2026-11386", "cve_description": "An input validation and injection vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client constructs APT source files (such as /etc/apt/sources.list.d/ubuntu-.list or their DEB822 equivalents) using data received directly from the contract server response via the directives.suites[] and directives.aptURL fields. Because the client utilizes Python's str.format() to write these files without performing escaping, validation, or newline character filtering, a malicious or tampered contract response containing embedded newline (\\n) characters can successfully inject arbitrary, attacker-controlled deb configuration lines into root-owned APT sources. When combined with the unvalidated additionalPackages[] field—which is passed positionally into a root-executed apt-get install command—an attacker capable of spoofing or manipulating the contract response (e.g., via a compromised internal infrastructure, an intercepted connection utilizing a trusted CA, or local logical bugs) can force the client to fetch and install malicious packages. This ultimately leads to arbitrary code execution with root privileges on the affected system. This component is preinstalled on supported Ubuntu Server releases and auto-attaches by default on cloud provider Ubuntu Pro images.", "cve_priority": "high", "cve_public_date": "2026-07-17 14:00:00 UTC" }, { "cve": "CVE-2026-12391", "url": "https://ubuntu.com/security/CVE-2026-12391", "cve_description": "An insecure symlink following vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools) within the pro collect-logs command framework. The utility creates or utilizes predictable temporary file paths or user-accessible log directories when gathering diagnostic information without verifying the file type or ownership. An unprivileged local attacker can exploit this behavior by creating a symbolic link (symlink) at a predictable destination path pointing to an arbitrary, root-readable file (such as /etc/shadow or private files within /root). When a root administrator or operator subsequently executes the pro collect-logs command, the tool follows the user-controlled symlink, reads the target file, and compresses its contents into the resulting diagnostic support archive. Because the output archive remains readable by the unprivileged user, the attacker can extract and read the sensitive root-owned files, leading to a complete information disclosure of system secrets.", "cve_priority": "medium", "cve_public_date": "2026-07-17 14:00:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-9494", "url": "https://ubuntu.com/security/CVE-2026-9494", "cve_description": "An information disclosure vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client validates Ubuntu Pro APT credentials by executing /usr/lib/apt/apt-helper using the download-file command. During this process, the secret bearer token is embedded directly in the cleartext URL component passed via the command-line arguments (argv), resulting in a URL format such as https://bearer:@esm.ubuntu.com/.../. On systems utilizing a default-mounted /proc file system where process-hiding mitigations (such as hidepid) are disabled, an unprivileged local attacker can monitor system processes and read the sensitive bearer token directly from /proc//cmdline while the helper process is actively running. This leaked token can subsequently be used to gain unauthorized access to the victim's Ubuntu Pro or Expanded Security Maintenance (ESM) repositories.", "cve_priority": "medium", "cve_public_date": "2026-07-17 14:00:00 UTC" }, { "cve": "CVE-2026-11386", "url": "https://ubuntu.com/security/CVE-2026-11386", "cve_description": "An input validation and injection vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client constructs APT source files (such as /etc/apt/sources.list.d/ubuntu-.list or their DEB822 equivalents) using data received directly from the contract server response via the directives.suites[] and directives.aptURL fields. Because the client utilizes Python's str.format() to write these files without performing escaping, validation, or newline character filtering, a malicious or tampered contract response containing embedded newline (\\n) characters can successfully inject arbitrary, attacker-controlled deb configuration lines into root-owned APT sources. When combined with the unvalidated additionalPackages[] field—which is passed positionally into a root-executed apt-get install command—an attacker capable of spoofing or manipulating the contract response (e.g., via a compromised internal infrastructure, an intercepted connection utilizing a trusted CA, or local logical bugs) can force the client to fetch and install malicious packages. This ultimately leads to arbitrary code execution with root privileges on the affected system. This component is preinstalled on supported Ubuntu Server releases and auto-attaches by default on cloud provider Ubuntu Pro images.", "cve_priority": "high", "cve_public_date": "2026-07-17 14:00:00 UTC" }, { "cve": "CVE-2026-12391", "url": "https://ubuntu.com/security/CVE-2026-12391", "cve_description": "An insecure symlink following vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools) within the pro collect-logs command framework. The utility creates or utilizes predictable temporary file paths or user-accessible log directories when gathering diagnostic information without verifying the file type or ownership. An unprivileged local attacker can exploit this behavior by creating a symbolic link (symlink) at a predictable destination path pointing to an arbitrary, root-readable file (such as /etc/shadow or private files within /root). When a root administrator or operator subsequently executes the pro collect-logs command, the tool follows the user-controlled symlink, reads the target file, and compresses its contents into the resulting diagnostic support archive. Because the output archive remains readable by the unprivileged user, the attacker can extract and read the sensitive root-owned files, leading to a complete information disclosure of system secrets.", "cve_priority": "medium", "cve_public_date": "2026-07-17 14:00:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Information disclosure", " - Remove credentials out of argv into apt's own auth.conf.d facility.", " - CVE-2026-9494", " * SECURITY UPDATE: Improper input validation", " - enforce StrictStringDataValue to applicable fields in directives", " - reject newline, carriage return, spaces, and shell meta characters", " in StrictStringDataValue", " - CVE-2026-11386", " * SECURITY UPDATE: Symlink attack", " - reject symlink log files in user-controlled directory trees during", " pro collect-logs", " - restrict pro collect-logs generated support archive permission to", " root only", " - CVE-2026-12391", "" ], "package": "ubuntu-advantage-tools", "version": "37.2ubuntu~22.04.1", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Eduardo Barretto ", "date": "Mon, 06 Jul 2026 15:36:19 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "ubuntu-pro-client", "from_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "37.2ubuntu~22.04", "version": "37.2ubuntu~22.04" }, "to_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "37.2ubuntu~22.04.1", "version": "37.2ubuntu~22.04.1" }, "cves": [ { "cve": "CVE-2026-9494", "url": "https://ubuntu.com/security/CVE-2026-9494", "cve_description": "An information disclosure vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client validates Ubuntu Pro APT credentials by executing /usr/lib/apt/apt-helper using the download-file command. During this process, the secret bearer token is embedded directly in the cleartext URL component passed via the command-line arguments (argv), resulting in a URL format such as https://bearer:@esm.ubuntu.com/.../. On systems utilizing a default-mounted /proc file system where process-hiding mitigations (such as hidepid) are disabled, an unprivileged local attacker can monitor system processes and read the sensitive bearer token directly from /proc//cmdline while the helper process is actively running. This leaked token can subsequently be used to gain unauthorized access to the victim's Ubuntu Pro or Expanded Security Maintenance (ESM) repositories.", "cve_priority": "medium", "cve_public_date": "2026-07-17 14:00:00 UTC" }, { "cve": "CVE-2026-11386", "url": "https://ubuntu.com/security/CVE-2026-11386", "cve_description": "An input validation and injection vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client constructs APT source files (such as /etc/apt/sources.list.d/ubuntu-.list or their DEB822 equivalents) using data received directly from the contract server response via the directives.suites[] and directives.aptURL fields. Because the client utilizes Python's str.format() to write these files without performing escaping, validation, or newline character filtering, a malicious or tampered contract response containing embedded newline (\\n) characters can successfully inject arbitrary, attacker-controlled deb configuration lines into root-owned APT sources. When combined with the unvalidated additionalPackages[] field—which is passed positionally into a root-executed apt-get install command—an attacker capable of spoofing or manipulating the contract response (e.g., via a compromised internal infrastructure, an intercepted connection utilizing a trusted CA, or local logical bugs) can force the client to fetch and install malicious packages. This ultimately leads to arbitrary code execution with root privileges on the affected system. This component is preinstalled on supported Ubuntu Server releases and auto-attaches by default on cloud provider Ubuntu Pro images.", "cve_priority": "high", "cve_public_date": "2026-07-17 14:00:00 UTC" }, { "cve": "CVE-2026-12391", "url": "https://ubuntu.com/security/CVE-2026-12391", "cve_description": "An insecure symlink following vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools) within the pro collect-logs command framework. The utility creates or utilizes predictable temporary file paths or user-accessible log directories when gathering diagnostic information without verifying the file type or ownership. An unprivileged local attacker can exploit this behavior by creating a symbolic link (symlink) at a predictable destination path pointing to an arbitrary, root-readable file (such as /etc/shadow or private files within /root). When a root administrator or operator subsequently executes the pro collect-logs command, the tool follows the user-controlled symlink, reads the target file, and compresses its contents into the resulting diagnostic support archive. Because the output archive remains readable by the unprivileged user, the attacker can extract and read the sensitive root-owned files, leading to a complete information disclosure of system secrets.", "cve_priority": "medium", "cve_public_date": "2026-07-17 14:00:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-9494", "url": "https://ubuntu.com/security/CVE-2026-9494", "cve_description": "An information disclosure vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client validates Ubuntu Pro APT credentials by executing /usr/lib/apt/apt-helper using the download-file command. During this process, the secret bearer token is embedded directly in the cleartext URL component passed via the command-line arguments (argv), resulting in a URL format such as https://bearer:@esm.ubuntu.com/.../. On systems utilizing a default-mounted /proc file system where process-hiding mitigations (such as hidepid) are disabled, an unprivileged local attacker can monitor system processes and read the sensitive bearer token directly from /proc//cmdline while the helper process is actively running. This leaked token can subsequently be used to gain unauthorized access to the victim's Ubuntu Pro or Expanded Security Maintenance (ESM) repositories.", "cve_priority": "medium", "cve_public_date": "2026-07-17 14:00:00 UTC" }, { "cve": "CVE-2026-11386", "url": "https://ubuntu.com/security/CVE-2026-11386", "cve_description": "An input validation and injection vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client constructs APT source files (such as /etc/apt/sources.list.d/ubuntu-.list or their DEB822 equivalents) using data received directly from the contract server response via the directives.suites[] and directives.aptURL fields. Because the client utilizes Python's str.format() to write these files without performing escaping, validation, or newline character filtering, a malicious or tampered contract response containing embedded newline (\\n) characters can successfully inject arbitrary, attacker-controlled deb configuration lines into root-owned APT sources. When combined with the unvalidated additionalPackages[] field—which is passed positionally into a root-executed apt-get install command—an attacker capable of spoofing or manipulating the contract response (e.g., via a compromised internal infrastructure, an intercepted connection utilizing a trusted CA, or local logical bugs) can force the client to fetch and install malicious packages. This ultimately leads to arbitrary code execution with root privileges on the affected system. This component is preinstalled on supported Ubuntu Server releases and auto-attaches by default on cloud provider Ubuntu Pro images.", "cve_priority": "high", "cve_public_date": "2026-07-17 14:00:00 UTC" }, { "cve": "CVE-2026-12391", "url": "https://ubuntu.com/security/CVE-2026-12391", "cve_description": "An insecure symlink following vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools) within the pro collect-logs command framework. The utility creates or utilizes predictable temporary file paths or user-accessible log directories when gathering diagnostic information without verifying the file type or ownership. An unprivileged local attacker can exploit this behavior by creating a symbolic link (symlink) at a predictable destination path pointing to an arbitrary, root-readable file (such as /etc/shadow or private files within /root). When a root administrator or operator subsequently executes the pro collect-logs command, the tool follows the user-controlled symlink, reads the target file, and compresses its contents into the resulting diagnostic support archive. Because the output archive remains readable by the unprivileged user, the attacker can extract and read the sensitive root-owned files, leading to a complete information disclosure of system secrets.", "cve_priority": "medium", "cve_public_date": "2026-07-17 14:00:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Information disclosure", " - Remove credentials out of argv into apt's own auth.conf.d facility.", " - CVE-2026-9494", " * SECURITY UPDATE: Improper input validation", " - enforce StrictStringDataValue to applicable fields in directives", " - reject newline, carriage return, spaces, and shell meta characters", " in StrictStringDataValue", " - CVE-2026-11386", " * SECURITY UPDATE: Symlink attack", " - reject symlink log files in user-controlled directory trees during", " pro collect-logs", " - restrict pro collect-logs generated support archive permission to", " root only", " - CVE-2026-12391", "" ], "package": "ubuntu-advantage-tools", "version": "37.2ubuntu~22.04.1", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Eduardo Barretto ", "date": "Mon, 06 Jul 2026 15:36:19 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "ubuntu-pro-client-l10n", "from_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "37.2ubuntu~22.04", "version": "37.2ubuntu~22.04" }, "to_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "37.2ubuntu~22.04.1", "version": "37.2ubuntu~22.04.1" }, "cves": [ { "cve": "CVE-2026-9494", "url": "https://ubuntu.com/security/CVE-2026-9494", "cve_description": "An information disclosure vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client validates Ubuntu Pro APT credentials by executing /usr/lib/apt/apt-helper using the download-file command. During this process, the secret bearer token is embedded directly in the cleartext URL component passed via the command-line arguments (argv), resulting in a URL format such as https://bearer:@esm.ubuntu.com/.../. On systems utilizing a default-mounted /proc file system where process-hiding mitigations (such as hidepid) are disabled, an unprivileged local attacker can monitor system processes and read the sensitive bearer token directly from /proc//cmdline while the helper process is actively running. This leaked token can subsequently be used to gain unauthorized access to the victim's Ubuntu Pro or Expanded Security Maintenance (ESM) repositories.", "cve_priority": "medium", "cve_public_date": "2026-07-17 14:00:00 UTC" }, { "cve": "CVE-2026-11386", "url": "https://ubuntu.com/security/CVE-2026-11386", "cve_description": "An input validation and injection vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client constructs APT source files (such as /etc/apt/sources.list.d/ubuntu-.list or their DEB822 equivalents) using data received directly from the contract server response via the directives.suites[] and directives.aptURL fields. Because the client utilizes Python's str.format() to write these files without performing escaping, validation, or newline character filtering, a malicious or tampered contract response containing embedded newline (\\n) characters can successfully inject arbitrary, attacker-controlled deb configuration lines into root-owned APT sources. When combined with the unvalidated additionalPackages[] field—which is passed positionally into a root-executed apt-get install command—an attacker capable of spoofing or manipulating the contract response (e.g., via a compromised internal infrastructure, an intercepted connection utilizing a trusted CA, or local logical bugs) can force the client to fetch and install malicious packages. This ultimately leads to arbitrary code execution with root privileges on the affected system. This component is preinstalled on supported Ubuntu Server releases and auto-attaches by default on cloud provider Ubuntu Pro images.", "cve_priority": "high", "cve_public_date": "2026-07-17 14:00:00 UTC" }, { "cve": "CVE-2026-12391", "url": "https://ubuntu.com/security/CVE-2026-12391", "cve_description": "An insecure symlink following vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools) within the pro collect-logs command framework. The utility creates or utilizes predictable temporary file paths or user-accessible log directories when gathering diagnostic information without verifying the file type or ownership. An unprivileged local attacker can exploit this behavior by creating a symbolic link (symlink) at a predictable destination path pointing to an arbitrary, root-readable file (such as /etc/shadow or private files within /root). When a root administrator or operator subsequently executes the pro collect-logs command, the tool follows the user-controlled symlink, reads the target file, and compresses its contents into the resulting diagnostic support archive. Because the output archive remains readable by the unprivileged user, the attacker can extract and read the sensitive root-owned files, leading to a complete information disclosure of system secrets.", "cve_priority": "medium", "cve_public_date": "2026-07-17 14:00:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-9494", "url": "https://ubuntu.com/security/CVE-2026-9494", "cve_description": "An information disclosure vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client validates Ubuntu Pro APT credentials by executing /usr/lib/apt/apt-helper using the download-file command. During this process, the secret bearer token is embedded directly in the cleartext URL component passed via the command-line arguments (argv), resulting in a URL format such as https://bearer:@esm.ubuntu.com/.../. On systems utilizing a default-mounted /proc file system where process-hiding mitigations (such as hidepid) are disabled, an unprivileged local attacker can monitor system processes and read the sensitive bearer token directly from /proc//cmdline while the helper process is actively running. This leaked token can subsequently be used to gain unauthorized access to the victim's Ubuntu Pro or Expanded Security Maintenance (ESM) repositories.", "cve_priority": "medium", "cve_public_date": "2026-07-17 14:00:00 UTC" }, { "cve": "CVE-2026-11386", "url": "https://ubuntu.com/security/CVE-2026-11386", "cve_description": "An input validation and injection vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client constructs APT source files (such as /etc/apt/sources.list.d/ubuntu-.list or their DEB822 equivalents) using data received directly from the contract server response via the directives.suites[] and directives.aptURL fields. Because the client utilizes Python's str.format() to write these files without performing escaping, validation, or newline character filtering, a malicious or tampered contract response containing embedded newline (\\n) characters can successfully inject arbitrary, attacker-controlled deb configuration lines into root-owned APT sources. When combined with the unvalidated additionalPackages[] field—which is passed positionally into a root-executed apt-get install command—an attacker capable of spoofing or manipulating the contract response (e.g., via a compromised internal infrastructure, an intercepted connection utilizing a trusted CA, or local logical bugs) can force the client to fetch and install malicious packages. This ultimately leads to arbitrary code execution with root privileges on the affected system. This component is preinstalled on supported Ubuntu Server releases and auto-attaches by default on cloud provider Ubuntu Pro images.", "cve_priority": "high", "cve_public_date": "2026-07-17 14:00:00 UTC" }, { "cve": "CVE-2026-12391", "url": "https://ubuntu.com/security/CVE-2026-12391", "cve_description": "An insecure symlink following vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools) within the pro collect-logs command framework. The utility creates or utilizes predictable temporary file paths or user-accessible log directories when gathering diagnostic information without verifying the file type or ownership. An unprivileged local attacker can exploit this behavior by creating a symbolic link (symlink) at a predictable destination path pointing to an arbitrary, root-readable file (such as /etc/shadow or private files within /root). When a root administrator or operator subsequently executes the pro collect-logs command, the tool follows the user-controlled symlink, reads the target file, and compresses its contents into the resulting diagnostic support archive. Because the output archive remains readable by the unprivileged user, the attacker can extract and read the sensitive root-owned files, leading to a complete information disclosure of system secrets.", "cve_priority": "medium", "cve_public_date": "2026-07-17 14:00:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Information disclosure", " - Remove credentials out of argv into apt's own auth.conf.d facility.", " - CVE-2026-9494", " * SECURITY UPDATE: Improper input validation", " - enforce StrictStringDataValue to applicable fields in directives", " - reject newline, carriage return, spaces, and shell meta characters", " in StrictStringDataValue", " - CVE-2026-11386", " * SECURITY UPDATE: Symlink attack", " - reject symlink log files in user-controlled directory trees during", " pro collect-logs", " - restrict pro collect-logs generated support archive permission to", " root only", " - CVE-2026-12391", "" ], "package": "ubuntu-advantage-tools", "version": "37.2ubuntu~22.04.1", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Eduardo Barretto ", "date": "Mon, 06 Jul 2026 15:36:19 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "wget", "from_version": { "source_package_name": "wget", "source_package_version": "1.21.2-2ubuntu1.1", "version": "1.21.2-2ubuntu1.1" }, "to_version": { "source_package_name": "wget", "source_package_version": "1.21.2-2ubuntu1.3", "version": "1.21.2-2ubuntu1.3" }, "cves": [ { "cve": "CVE-2026-58469", "url": "https://ubuntu.com/security/CVE-2026-58469", "cve_description": "GNU Wget through 1.25.0, fixed in commit 37a40fc, contains a heap buffer underread vulnerability in the clean_metalink_string() function within src/metalink.c that allows a malicious server to trigger memory corruption by serving a Metalink document containing a whitespace-only URL. Attackers can cause the function to decrement a pointer past the start of the buffer when processing an all-whitespace Metalink URL, potentially leading to abnormal program behavior.", "cve_priority": "medium", "cve_public_date": "2026-07-07 21:17:00 UTC" }, { "cve": "CVE-2026-58470", "url": "https://ubuntu.com/security/CVE-2026-58470", "cve_description": "GNU Wget through 1.25.0, fixed in commit 43d3ba9, contains an integer overflow vulnerability in the parse_content_range() function within src/http.c that allows server-controlled values to cause signed integer arithmetic to overflow. Attackers can supply malicious Content-Range header values to trigger undefined behavior and download desynchronization in the affected client.", "cve_priority": "medium", "cve_public_date": "2026-07-07 21:17:00 UTC" }, { "cve": "CVE-2026-58471", "url": "https://ubuntu.com/security/CVE-2026-58471", "cve_description": "GNU Wget through 1.25.0, fixed in commit c2640fe, contains a heap buffer overflow vulnerability in the convert_fname() function within src/url.c that allows remote attackers to trigger memory corruption through a server-supplied filename requiring character set conversion. When the output buffer is too small during iconv E2BIG reallocation, the reallocation logic miscalculates the remaining space, leading to a heap buffer overflow that can be exploited via a maliciously crafted server response.", "cve_priority": "medium", "cve_public_date": "2026-07-07 21:17:00 UTC" }, { "cve": "CVE-2026-58472", "url": "https://ubuntu.com/security/CVE-2026-58472", "cve_description": "GNU Wget through 1.25.0, fixed in commit dd692d9, contains a heap buffer overflow vulnerability in the html_quote_string() function in src/convert.c that allows a remote attacker to trigger memory corruption by supplying a crafted HTML attribute with a large number of characters requiring entity encoding. A server-supplied HTML attribute causes a signed integer counter to overflow during output size accumulation, resulting in an undersized heap allocation and subsequent heap buffer overflow during the copy phase.", "cve_priority": "medium", "cve_public_date": "2026-07-07 21:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-58469", "url": "https://ubuntu.com/security/CVE-2026-58469", "cve_description": "GNU Wget through 1.25.0, fixed in commit 37a40fc, contains a heap buffer underread vulnerability in the clean_metalink_string() function within src/metalink.c that allows a malicious server to trigger memory corruption by serving a Metalink document containing a whitespace-only URL. Attackers can cause the function to decrement a pointer past the start of the buffer when processing an all-whitespace Metalink URL, potentially leading to abnormal program behavior.", "cve_priority": "medium", "cve_public_date": "2026-07-07 21:17:00 UTC" }, { "cve": "CVE-2026-58470", "url": "https://ubuntu.com/security/CVE-2026-58470", "cve_description": "GNU Wget through 1.25.0, fixed in commit 43d3ba9, contains an integer overflow vulnerability in the parse_content_range() function within src/http.c that allows server-controlled values to cause signed integer arithmetic to overflow. Attackers can supply malicious Content-Range header values to trigger undefined behavior and download desynchronization in the affected client.", "cve_priority": "medium", "cve_public_date": "2026-07-07 21:17:00 UTC" }, { "cve": "CVE-2026-58471", "url": "https://ubuntu.com/security/CVE-2026-58471", "cve_description": "GNU Wget through 1.25.0, fixed in commit c2640fe, contains a heap buffer overflow vulnerability in the convert_fname() function within src/url.c that allows remote attackers to trigger memory corruption through a server-supplied filename requiring character set conversion. When the output buffer is too small during iconv E2BIG reallocation, the reallocation logic miscalculates the remaining space, leading to a heap buffer overflow that can be exploited via a maliciously crafted server response.", "cve_priority": "medium", "cve_public_date": "2026-07-07 21:17:00 UTC" }, { "cve": "CVE-2026-58472", "url": "https://ubuntu.com/security/CVE-2026-58472", "cve_description": "GNU Wget through 1.25.0, fixed in commit dd692d9, contains a heap buffer overflow vulnerability in the html_quote_string() function in src/convert.c that allows a remote attacker to trigger memory corruption by supplying a crafted HTML attribute with a large number of characters requiring entity encoding. A server-supplied HTML attribute causes a signed integer counter to overflow during output size accumulation, resulting in an undersized heap allocation and subsequent heap buffer overflow during the copy phase.", "cve_priority": "medium", "cve_public_date": "2026-07-07 21:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer overflow in metalink.", " - debian/patches/CVE-2026-58469.patch: Fix buffer overflow in", " src/metalink.c", " - CVE-2026-58469", " * SECURITY UPDATE: Integer overflow in http", " - debian/patches/CVE-2026-58470.patch: Fix integer overflow in src/http.c", " - CVE-2026-58470", " * SECURITY UPDATE: Buffer overflow in convert_fname.", " - debian/patches/CVE-2026-58471.patch: Fix buffer overflow in src/url.c", " - CVE-2026-58471", " * SECURITY UPDATE: Integer and buffer overflow in html_quote_string.", " - debian/patches/CVE-2026-58472.patch: Fix integer+buffer overflow in", " src/convert.c", " - CVE-2026-58472", "" ], "package": "wget", "version": "1.21.2-2ubuntu1.3", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Kyle Kernick ", "date": "Fri, 10 Jul 2026 16:04:53 -0600" } ], "notes": null, "is_version_downgrade": false }, { "name": "xxd", "from_version": { "source_package_name": "vim", "source_package_version": "2:8.2.3995-1ubuntu2.33", "version": "2:8.2.3995-1ubuntu2.33" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:8.2.3995-1ubuntu2.34", "version": "2:8.2.3995-1ubuntu2.34" }, "cves": [ { "cve": "CVE-2026-59856", "url": "https://ubuntu.com/security/CVE-2026-59856", "cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0736, the PHP omni-completion script in runtime/autoload/phpcomplete.vim interpolates a class or trait name, taken from the contents of the edited buffer, into a search() pattern that is run via win_execute() without escaping. A name containing a single quote can terminate the search() string argument early, and because the bar is honored as an Ex command separator, the remainder of the name is run as Ex commands; via the :! command this allows arbitrary operating-system command execution when a victim opens a crafted PHP file and invokes omni-completion. This issue is fixed in version 9.2.0736.", "cve_priority": "medium", "cve_public_date": "2026-07-09 23:17:00 UTC" }, { "cve": "CVE-2026-59857", "url": "https://ubuntu.com/security/CVE-2026-59857", "cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0725, the single-byte branch of spell_soundfold_sal() in src/spell.c translates a word through a spell file's SAL sound-folding rules into a caller-owned result buffer, but its result writes are guarded with reslen < MAXWLEN, allowing reslen to reach MAXWLEN before res[reslen] = NUL writes one byte past the end of the MAXWLEN-element stack buffer. A boundary-length word passed to soundfold(), or reached via sound-based spell suggestion while a SAL-based spell language is active under a non-multibyte 8-bit encoding, can corrupt the eval_soundfold() stack frame and crash the editor. This issue is fixed in version 9.2.0725.", "cve_priority": "medium", "cve_public_date": "2026-07-09 23:17:00 UTC" }, { "cve": "CVE-2026-59858", "url": "https://ubuntu.com/security/CVE-2026-59858", "cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0735, the C omni-completion script in runtime/autoload/ccomplete.vim interpolates the typeref: or typename: extension field of a tags entry, without escaping, into a :vimgrep pattern that is run through :execute. Because :vimgrep honors the bar as a command separator, a crafted tag field can close the search pattern and append an arbitrary Ex command; opening a hostile .c file whose project tags file contains such an entry and invoking C omni-completion runs that command as the editing user. This issue is fixed in version 9.2.0735.", "cve_priority": "medium", "cve_public_date": "2026-07-09 23:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-59856", "url": "https://ubuntu.com/security/CVE-2026-59856", "cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0736, the PHP omni-completion script in runtime/autoload/phpcomplete.vim interpolates a class or trait name, taken from the contents of the edited buffer, into a search() pattern that is run via win_execute() without escaping. A name containing a single quote can terminate the search() string argument early, and because the bar is honored as an Ex command separator, the remainder of the name is run as Ex commands; via the :! command this allows arbitrary operating-system command execution when a victim opens a crafted PHP file and invokes omni-completion. This issue is fixed in version 9.2.0736.", "cve_priority": "medium", "cve_public_date": "2026-07-09 23:17:00 UTC" }, { "cve": "CVE-2026-59857", "url": "https://ubuntu.com/security/CVE-2026-59857", "cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0725, the single-byte branch of spell_soundfold_sal() in src/spell.c translates a word through a spell file's SAL sound-folding rules into a caller-owned result buffer, but its result writes are guarded with reslen < MAXWLEN, allowing reslen to reach MAXWLEN before res[reslen] = NUL writes one byte past the end of the MAXWLEN-element stack buffer. A boundary-length word passed to soundfold(), or reached via sound-based spell suggestion while a SAL-based spell language is active under a non-multibyte 8-bit encoding, can corrupt the eval_soundfold() stack frame and crash the editor. This issue is fixed in version 9.2.0725.", "cve_priority": "medium", "cve_public_date": "2026-07-09 23:17:00 UTC" }, { "cve": "CVE-2026-59858", "url": "https://ubuntu.com/security/CVE-2026-59858", "cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0735, the C omni-completion script in runtime/autoload/ccomplete.vim interpolates the typeref: or typename: extension field of a tags entry, without escaping, into a :vimgrep pattern that is run through :execute. Because :vimgrep honors the bar as a command separator, a crafted tag field can close the search pattern and append an arbitrary Ex command; opening a hostile .c file whose project tags file contains such an entry and invoking C omni-completion runs that command as the editing user. This issue is fixed in version 9.2.0735.", "cve_priority": "medium", "cve_public_date": "2026-07-09 23:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Command execution in PHP omni-completion.", " - debian/patches/CVE-2026-59856.patch: Quote the class name before", " inserting it into the search() in runtime/autoload/phpcomplete.vim", " - CVE-2026-59856", " * SECURITY UPDATE: Stack out-of-bounds write in spell_soundfold_sal().", " - debian/patches/CVE-2026-59857.patch: Bound the single-byte SAL result", " writes in src/spell.c", " - CVE-2026-59857", " * SECURITY UPDATE: Arbitrary command execution during C omni-completion.", " - debian/patches/CVE-2026-59858.patch: Escape the type field before", " inserting it into pattern in runtime/autoload/ccomplete.vim", " - CVE-2026-59858", "" ], "package": "vim", "version": "2:8.2.3995-1ubuntu2.34", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Kyle Kernick ", "date": "Mon, 13 Jul 2026 13:08:21 -0600" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-5.15.0-1104-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1103.108", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1104.109", "version": "5.15.0-1104.109" }, "cves": [ { "cve": "CVE-2026-46137", "url": "https://ubuntu.com/security/CVE-2026-46137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: fix potential data-race This mptcp_pm_add_timer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bh_lock_sock(). If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46275", "url": "https://ubuntu.com/security/CVE-2026-46275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart. The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the `hu` struct. When the scheduled work executes later, it blindly dereferences the freed `hu` struct. Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently. Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities.", "cve_priority": "high", "cve_public_date": "2026-06-08 16:16:00 UTC" }, { "cve": "CVE-2025-23141", "url": "https://ubuntu.com/security/CVE-2025-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where \"accepting\" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit can access guest memory. The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triple_fault_event_test selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario. ============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted ----------------------------- include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2026-43052", "url": "https://ubuntu.com/security/CVE-2026-43052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check tdls flag in ieee80211_tdls_oper When NL80211_TDLS_ENABLE_LINK is called, the code only checks if the station exists but not whether it is actually a TDLS station. This allows the operation to proceed for non-TDLS stations, causing unintended side effects like modifying channel context and HT protection before failing. Add a check for sta->sta.tdls early in the ENABLE_LINK case, before any side effects occur, to ensure the operation is only allowed for actual TDLS peers.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2025-22107", "url": "https://ubuntu.com/security/CVE-2025-22107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry() There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-21863", "url": "https://ubuntu.com/security/CVE-2025-21863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: prevent opcode speculation sqe->opcode is used for different tables, make sure we santitise it against speculations.", "cve_priority": "low", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2026-46274", "url": "https://ubuntu.com/security/CVE-2026-46274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io-wq: check that the predecessor is hashed in io_wq_remove_pending() io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0]. Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory. Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot.", "cve_priority": "high", "cve_public_date": "2026-06-08 16:16:00 UTC" }, { "cve": "CVE-2026-45846", "url": "https://ubuntu.com/security/CVE-2026-45846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst() bareudp_fill_metadata_dst() passes bareudp->sock to udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check. The socket is only created in bareudp_open() and NULLed in bareudp_stop(), so calling this function while the device is down triggers a NULL dereference via sock->sk. BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160) Call Trace: bareudp_fill_metadata_dst (drivers/net/bareudp.c:532) do_execute_actions (net/openvswitch/actions.c:901) ovs_execute_actions (net/openvswitch/actions.c:1589) ovs_packet_cmd_execute (net/openvswitch/datapath.c:700) genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1209) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths in the same driver.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45844", "url": "https://ubuntu.com/security/CVE-2026-45844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: arp_tables: fix IEEE1394 ARP payload parsing Weiming Shi says: \"arp_packet_match() unconditionally parses the ARP payload assuming two hardware addresses are present (source and target). However, IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address field, and arp_hdr_len() already accounts for this by returning a shorter length for ARPHRD_IEEE1394 devices. As a result, on IEEE1394 interfaces arp_packet_match() advances past a nonexistent target hardware address and reads the wrong bytes for both the target device address comparison and the target IP address. This causes arptables rules to match against garbage data, leading to incorrect filtering decisions: packets that should be accepted may be dropped and vice versa. The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already handles this correctly by skipping the target hardware address for ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match().\" Mangle the original patch to always return 0 (no match) in case user matches on the target hardware address which is never present in IEEE1394. Note that this returns 0 (no match) for either normal and inverse match because matching in the target hardware address in ARPHRD_IEEE1394 has never been supported by arptables. This is intentional, matching on the target hardware address should never evaluate true for ARPHRD_IEEE1394. Moreover, adjust arpt_mangle to drop the packet too as AI suggests: In arpt_mangle, the logic assumes a standard ARP layout. Because IEEE1394 (FireWire) omits the target hardware address, the linear pointer arithmetic miscalculates the offset for the target IP address. This causes mangling operations to write to the wrong location, leading to packet corruption. To ensure safety, this patch drops packets (NF_DROP) when mangling is requested for these fields on IEEE1394 devices, as the current implementation cannot correctly map the FireWire ARP payload. This omits both mangling target hardware and IP address. Even if IP address mangling should be possible in IEEE1394, this would require to adjust arpt_mangle offset calculation, which has never been supported. Based on patch from Weiming Shi .", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45843", "url": "https://ubuntu.com/security/CVE-2026-45843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: bound decode() reads against the compressed packet length slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code. A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets. Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45842", "url": "https://ubuntu.com/security/CVE-2026-45842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: reject VJ receive packets on instances with no rstate array slhc_init() accepts rslots == 0 as a valid configuration, with the documented meaning of 'no receive compression'. In that case the allocation loop in slhc_init() is skipped, so comp->rstate stays NULL and comp->rslot_limit stays 0 (from the kzalloc of struct slcompress). The receive helpers do not defend against that configuration. slhc_uncompress() dereferences comp->rstate[x] when the VJ header carries an explicit connection ID, and slhc_remember() later assigns cs = &comp->rstate[...] after only comparing the packet's slot number to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the range check, and the code dereferences a NULL rstate. The configuration is reachable in-tree through PPP. PPPIOCSMAXCID stores its argument in a signed int, and (val >> 16) uses arithmetic shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1 is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because /dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path is reachable from an unprivileged user namespace. Once the malformed VJ state is installed, any inbound VJ-compressed or VJ-uncompressed frame that selects slot 0 crashes the kernel in softirq context: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519) Call Trace: ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466) ppp_input (drivers/net/ppp/ppp_generic.c:2359) ppp_async_process (drivers/net/ppp/ppp_async.c:492) tasklet_action_common (kernel/softirq.c:926) handle_softirqs (kernel/softirq.c:623) run_ksoftirqd (kernel/softirq.c:1055) smpboot_thread_fn (kernel/smpboot.c:160) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) Reject the receive side on such instances instead of touching rstate. slhc_uncompress() falls through to its existing 'bad' label, which bumps sls_i_error and enters the toss state. slhc_remember() mirrors that with an explicit sls_i_error increment followed by slhc_toss(); the sls_i_runt counter is not used here because a missing rstate is an internal configuration state, not a runt packet. The transmit path is unaffected: the only in-tree caller that picks rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and slip.c always calls slhc_init(16, 16), so comp->tstate remains valid and slhc_compress() continues to work.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45841", "url": "https://ubuntu.com/security/CVE-2026-45841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO nf_osf_match_one() computes ctx->window % f->wss.val in the OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a subsequent matching TCP SYN divides by zero and panics the kernel. Reject the bogus fingerprint in nfnl_osf_add_callback() above the per-option for-loop. f->wss is per-fingerprint, not per-option, so the check must run regardless of f->opt_num (including 0). Also reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that as \"should not happen\". Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:220) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:348) nf_hook_slow (net/netfilter/core.c:622) ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv (include/linux/skbuff.h:1162) __netif_receive_skb_one_core (net/core/dev.c:6181) process_backlog (net/core/dev.c:6642) __napi_poll (net/core/dev.c:7710) net_rx_action (net/core/dev.c:7945) handle_softirqs (kernel/softirq.c:622)", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45840", "url": "https://ubuntu.com/security/CVE-2026-45840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: cap upcall PID array size and pre-size vport replies The vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENL_UNS_ADMIN_PERM. kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Kernel panic - not syncing: Fatal exception Reject attempts to set more PIDs than nr_cpu_ids in ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply size in ovs_vport_cmd_msg_size() based on that bound, similar to the existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the two sides stay consistent.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46319", "url": "https://ubuntu.com/security/CVE-2026-46319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: Only release RCU read lock after ct_ft When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero() is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft object. This vulnerability can lead to privilege escalation. Analysis from zdi-disclosures@trendmicro.com: When initializing act_ct, tcf_ct_init() is called, which internally triggers tcf_ct_flow_table_get(). static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params) { struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ... } static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params) { void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj; } At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft from zones_ht . The lookup is performed within an RCU read critical section through rcu_read_lock() / rcu_read_unlock(), which prevents the object from being freed. However, at the point of function return, rcu_read_unlock() has already been called, and there is nothing preventing ct_ft from being freed before reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomes the race window, during which ct_ft can be freed. Free Process: tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put(). static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft) { if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); } } At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work static void tcf_ct_flow_table_cleanup_work(struct work_struct *work) { struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE); } tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes between [1] and [2], UAF occurs. This race condition has a very short race window, making it generally difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was inserted after[1]", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-45839", "url": "https://ubuntu.com/security/CVE-2026-45839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec() CO-RE accessor strings are colon-separated indices that describe a path from a root BTF type to a target field, e.g. \"0:1:2\" walks through nested struct members. bpf_core_parse_spec() parses each component with sscanf(\"%d\"), so negative values like -1 are silently accepted. The subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the upper bound and always pass for negative values because C integer promotion converts the __u16 btf_vlen result to int, making the comparison (int)(-1) >= (int)(N) false for any positive N. When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff, producing an out-of-bounds read far past the members array. A crafted BPF program with a negative CO-RE accessor on any struct that exists in vmlinux BTF (e.g. task_struct) crashes the kernel deterministically during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y (default on major distributions). The bug is reachable with CAP_BPF: BUG: unable to handle page fault for address: ffffed11818b6626 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full) RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354) RAX: 00000000ffffffff Call Trace: bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321) bpf_core_apply (kernel/bpf/btf.c:9507) check_core_relo (kernel/bpf/verifier.c:19475) bpf_check (kernel/bpf/verifier.c:26031) bpf_prog_load (kernel/bpf/syscall.c:3089) __sys_bpf (kernel/bpf/syscall.c:6228) CO-RE accessor indices are inherently non-negative (struct member index, array element index, or enumerator index), so reject them immediately after parsing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45838", "url": "https://ubuntu.com/security/CVE-2026-45838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix end-of-list detection in cgroup_storage_get_next_key() list_next_entry() never returns NULL -- when the current element is the last entry it wraps to the list head via container_of(). The subsequent NULL check is therefore dead code and get_next_key() never returns -ENOENT for the last element, instead reading storage->key from a bogus pointer that aliases internal map fields and copying the result to userspace. Replace it with list_entry_is_head() so the function correctly returns -ENOENT when there are no more entries.", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46214", "url": "https://ubuntu.com/security/CVE-2026-46214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix accept queue count leak on transport mismatch virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listener to reject all new connections. Fix by moving sk_acceptq_added() to after the transport validation, matching the pattern used by vmci_transport and hyperv_transport.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46234", "url": "https://ubuntu.com/security/CVE-2026-46234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: fix buffer size clamping order In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint. This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size. Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45836", "url": "https://ubuntu.com/security/CVE-2026-45836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46231", "url": "https://ubuntu.com/security/CVE-2026-46231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: put backbone reference on failed claim hash insert When batadv_bla_add_claim() fails to insert a new claim into the hash, it leaked a reference to the backbone_gw for which the claim was intended. Call batadv_backbone_gw_put() on the error path to release the reference and avoid leaking the backbone_gw object.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46233", "url": "https://ubuntu.com/security/CVE-2026-46233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: only purge non-released claims When batadv_bla_purge_claims() goes through the list of claims, it is only traversing the hash list with an rcu_read_lock(). Due to a potential parallel batadv_claim_put(), it can happen that it encounters a claim which was actually in the process of being released+freed by batadv_claim_release(). In this case, backbone_gw is set to NULL before the delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is then no longer allowed because it would cause a NULL-ptr derefence. To avoid this, only claims with a valid reference counter must be purged. All others are already taken care of.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46212", "url": "https://ubuntu.com/security/CVE-2026-46212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: prevent use-after-free when deleting claims When batadv_bla_del_backbone_claims() removes all claims for a backbone, it does this by dropping the link entry in the hash list. This list entry itself was one of the references which need to be dropped at the same time via batadv_claim_put(). But the batadv_claim_put() must not be done before the last access to the claim object in this function. Otherwise the claim might be freed already by the batadv_claim_release() function before the list entry was dropped.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46238", "url": "https://ubuntu.com/security/CVE-2026-46238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop caching unowned originator pointers in BAT IV BAT IV keeps the last-hop neighbor address in each neigh_node, but some paths also cache an originator pointer derived from a temporary lookup. That pointer is not owned by the neigh_node and may no longer refer to a live originator entry after purge handling runs. Stop storing the auxiliary originator pointer in the BAT IV neighbor state. When BAT IV needs the neighbor originator data, resolve it from the stored neighbor address and drop the reference again after use. [sven: avoid bonding logic for outgoing OGM]", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46206", "url": "https://ubuntu.com/security/CVE-2026-46206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject new tp_meter sessions during teardown Prevent tp_meter from starting new sender or receiver sessions after mesh_state has left BATADV_MESH_ACTIVE.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46198", "url": "https://ubuntu.com/security/CVE-2026-46198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix integer overflow on buff_pos Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size check is done using the int type in batadv_iv_ogm_aggr_packet whereas the buff_pos variable uses the s16 type. This could lead to an out-of-bound read.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46227", "url": "https://ubuntu.com/security/CVE-2026-46227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the \"sk != asoc->base.sk\" and \"asoc->base.dead\" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 (\"sctp: walk the list of asoc safely\") was added for.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46220", "url": "https://ubuntu.com/security/CVE-2026-46220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission sdma_v4_0_ring_emit_fence() contains two BUG_ON(addr & 0x3) assertions that verify fence writeback addresses are dword-aligned. These assertions can be reached from unprivileged userspace via crafted DRM_IOCTL_AMDGPU_CS submissions, causing a fatal kernel panic in a scheduler worker thread. Replace both BUG_ON() calls with WARN_ON() to log the condition without crashing the kernel. A misaligned fence address at this point indicates a driver bug, but crashing the kernel is never the correct response when the assertion is reachable from userspace. The CS IOCTL path is the correct place to filter invalid submissions; the ring emission callback is too late to do anything about it. (cherry picked from commit b90250bd933afd1ba94d86d6b13821997b22b18e)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46197", "url": "https://ubuntu.com/security/CVE-2026-46197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: validate SVM ioctl nattr against buffer size Validate nattr field against the buffer size, preventing out-of-bounds buffer access via user-controlled attribute count. (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46209", "url": "https://ubuntu.com/security/CVE-2026-46209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1); However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value. A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46230", "url": "https://ubuntu.com/security/CVE-2026-46230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg Check bounds against the end of the BO whenever we access the msg.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46219", "url": "https://ubuntu.com/security/CVE-2026-46219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix use-after-free on unbind The state machine work is scheduled by the interrupt handler and therefore needs to be cancelled after disabling interrupts to avoid a potential use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46236", "url": "https://ubuntu.com/security/CVE-2026-46236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: xbox_remote: heed DMA restrictions The buffer for IO must not be part of the device structure because that violates the DMA coherency rules.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46205", "url": "https://ubuntu.com/security/CVE-2026-46205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: media: atomisp: Disallow all private IOCTLs Disallow all private IOCTLs. These aren't quite as safe as one could assume of IOCTL handlers; disable them for now. Instead of removing the code, return in the beginning of the function if cmd is non-zero in order to keep static checkers happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46168", "url": "https://ubuntu.com/security/CVE-2026-46168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix scheduling with atomic in timestamp sockopt Using lock_sock_fast() (atomic context) around sock_set_timestamp() and sock_set_timestamping() is unsafe, as both helpers can sleep. Replace lock_sock_fast() with sleepable lock_sock()/release_sock() to avoid scheduling while atomic panic.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46189", "url": "https://ubuntu.com/security/CVE-2026-46189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path Sashiko points out that pvrdma_uar_free() is already called within pvrdma_dealloc_ucontext(), so calling it before triggers a double free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46133", "url": "https://ubuntu.com/security/CVE-2026-46133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject unknown opcodes before ICRC processing Even after applying commit 7244491dab34 (\"RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv\"), a single unauthenticated UDP packet can still trigger panic. That patch handled payload_size() underflow only for valid opcodes with short packets, not for packets carrying an unknown opcode. The unknown-opcode OOB read described below predates that commit and reaches back to the initial Soft RoCE driver. The check added there reads pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The rxe_opcode[] array has 256 entries but is only populated for defined IB opcodes; any other entry (for example opcode 0xff) is zero-initialized, so length == 0 and the check degenerates to pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES which underflows when length == 0 and passes a huge value to rxe_crc32(), causing an out-of-bounds read of the skb payload. Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma link add rxe0 type rxe netdev eth0 A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and QPN=IB_MULTICAST_QPN triggers: BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170 Read of size 1 at addr ... The buggy address is located 0 bytes to the right of allocated 704-byte region Call Trace: crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 Subsequent packets with the same shape fault on unmapped memory and panic the kernel. The trigger requires only module load and \"rdma link add\"; no QP, no connection, and no authentication. Fix this by rejecting packets whose opcode has no rxe_opcode[] entry, detected via the zero mask or zero length, before any length arithmetic runs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46127", "url": "https://ubuntu.com/security/CVE-2026-46127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp() Sashiko points out that pd->uctx isn't initialized until late in the function so all these error flow references are NULL and will crash. Use the uctx that isn't NULL.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46178", "url": "https://ubuntu.com/security/CVE-2026-46178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq() Sashiko points out that mlx4_srq_alloc() was not undone during error unwind, add the missing call to mlx4_srq_free().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46112", "url": "https://ubuntu.com/security/CVE-2026-46112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix unlocked call to hns_roce_qp_remove() Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory. Grab the same locks the other two callers use.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46304", "url": "https://ubuntu.com/security/CVE-2026-46304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the final controller reference through nvmet_cq_put(). If that triggers nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on the same nvmet-wq. Call chain: nvmet_tcp_schedule_release_queue() kref_put(&queue->kref, nvmet_tcp_release_queue) nvmet_tcp_release_queue() queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq process_one_work() nvmet_tcp_release_queue_work() nvmet_cq_put(&queue->nvme_cq) nvmet_cq_destroy() nvmet_ctrl_put(cq->ctrl) nvmet_ctrl_free() flush_work(&ctrl->async_event_work) <--- nvmet_wq Previously Scheduled by :- \t\t nvmet_add_async_event \t\t queue_work(nvmet_wq, &ctrl->async_event_work); This trips lockdep with a possible recursive locking warning. [ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55 [ 5223.061801] loop0: detected capacity change from 0 to 2097152 [ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 [ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420) [ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349. [ 5223.128453] nvme nvme1: new ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349 [ 5233.199447] nvme nvme1: Removing ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\" [ 5233.227718] ============================================ [ 5233.231283] WARNING: possible recursive locking detected [ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N [ 5233.238434] -------------------------------------------- [ 5233.241852] kworker/u192:6/2413 is trying to acquire lock: [ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 [ 5233.251438] but task is already holding lock: [ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.261125] other info that might help us debug this: [ 5233.265333] Possible unsafe locking scenario: [ 5233.269217] CPU0 [ 5233.270795] ---- [ 5233.272436] lock((wq_completion)nvmet-wq); [ 5233.275241] lock((wq_completion)nvmet-wq); [ 5233.278020] *** DEADLOCK *** [ 5233.281793] May be due to missing lock nesting notation [ 5233.286195] 3 locks held by kworker/u192:6/2413: [ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0 [ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 [ 5233.304290] stack backtrace: [ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full) [ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST [ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp] [ 5233.306532] Call Trace: [ 5233.306534] [ 5233.306536] dump_stack_lvl+0x73/0xb0 [ 5233.306552] print_deadlock_bug+0x225/0x2f0 [ 5233.306556] __lock_acquire+0x13f0/0x2290 [ 5233.306563] lock_acquire+0xd0/0x300 [ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306571] ? __flush_work+0x20b/0x530 [ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306577] touch_wq_lockdep_map+0x3b/0x90 [ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90 [ 52 ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46161", "url": "https://ubuntu.com/security/CVE-2026-46161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix divide-by-zero in setup_geo() with zero far_copies setup_geo() extracts near_copies (nc) and far_copies (fc) from the user-provided layout parameter without checking for zero. When fc=0 with the \"improved\" far set layout selected, 'geo->far_set_size = disks / fc' triggers a divide-by-zero. Validate nc and fc immediately after extraction, returning -1 if either is zero.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46124", "url": "https://ubuntu.com/security/CVE-2026-46124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate block number from NFS file handle in isofs_export_iget isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker- controlled block number (ifid->block or ifid->parent_block) from the NFS file handle to isofs_export_iget(), which only rejects block == 0 before calling isofs_iget() and ultimately sb_bread(). A crafted file handle with fh_len sufficient to pass the check added by commit 0405d4b63d08 (\"isofs: Prevent the use of too small fid\") can still drive the server to read any in-range block on the backing device as if it were an iso_directory_record. That earlier fix was assigned CVE-2025-37780. sb_bread() on an out-of-range block returns NULL cleanly via the EIO path, so there is no memory-safety violation. For in-range reads of adjacent-partition data on the same block device, the unrelated bytes end up in iso_inode_info fields that reach the NFS client as dentry metadata. The deployment surface (isofs exported over NFS from loop-mounted images) is narrow and requires an authenticated NFS peer, but the malformed-file-handle class is reportable as hardening next to the existing CVE-2025-37780 fix. Reject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent() call sites with a single line.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46303", "url": "https://ubuntu.com/security/CVE-2026-46303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b (\"[PATCH] rock.c: handle corrupted directories\") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 (\"isofs: Fix infinite looping over CE entries\") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.", "cve_priority": "medium", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46294", "url": "https://ubuntu.com/security/CVE-2026-46294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a buffer overflow in ioctl processing Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the \"outptr\" variable to the next 8-byte boundary: \toutptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The \"for\" loop is iterated again, it executes: \tremaining = len - (outptr - outbuf); 5. If \"outptr\" points past \"outbuf + len\", the arithmetics wraps around and the variable \"remaining\" contains unusually high number 6. With \"remaining\" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, \"outptr = align_ptr(outptr)\" can't overshoot the input buffer and the bug can't happen accidentally", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46107", "url": "https://ubuntu.com/security/CVE-2026-46107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-thin: fix metadata refcount underflow There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count. If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in \"device mapper: space map common: unable to decrement block\" errors. Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46301", "url": "https://ubuntu.com/security/CVE-2026-46301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: topcliff-pch: fix use-after-free on unbind Give the driver a chance to flush its queue before releasing the DMA buffers on driver unbind", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46273", "url": "https://ubuntu.com/security/CVE-2026-46273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmveth: Disable GSO for packets with small MSS Some physical adapters on Power systems do not support segmentation offload when the MSS is less than 224 bytes. Attempting to send such packets causes the adapter to freeze, stopping all traffic until manually reset. Implement ndo_features_check to disable GSO for packets with small MSS values. The network stack will perform software segmentation instead. The 224-byte minimum matches ibmvnic commit (\"ibmvnic: Enforce stronger sanity checks on GSO packets\") which uses the same physical adapters in SEA configurations. The issue occurs specifically when the hardware attempts to perform segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets (gso_segs == 1) do not trigger the problematic LSO code path and are transmitted normally without segmentation. Add an ndo_features_check callback to disable GSO when MSS < 224 bytes. Also call vlan_features_check() to ensure proper handling of VLAN packets, particularly QinQ (802.1ad) configurations where the hardware parser may not support certain offload features. Validated using iptables to force small MSS values. Without the fix, the adapter freezes. With the fix, packets are segmented in software and transmission succeeds. Comprehensive regression testing completedd (MSS tests, performance, stability).", "cve_priority": "high", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-43502", "url": "https://ubuntu.com/security/CVE-2026-43502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: handle zerocopy send cleanup before the message is queued A zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket. The purge path currently infers zerocopy state from rm->m_rs, so an unqueued message can be cleaned up as if it owned normal payload pages. However, zerocopy ownership is really determined by the presence of op_mmp_znotifier, regardless of whether the message has reached the socket queue. Capture op_mmp_znotifier up front in rds_message_purge() and use it as the cleanup discriminator. If the message is already associated with a socket, keep the existing completion path. Otherwise, drop the pinned page accounting directly and release the notifier before putting the payload pages. This keeps early send failure cleanup consistent with the zerocopy lifetime rules without changing the normal queued completion path.", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46120", "url": "https://ubuntu.com/security/CVE-2026-46120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: Use cached t->net in ip6erspan_changelink(). After commit 5e72ce3e3980 (\"net: ipv6: Use link netns in newlink() of rtnl_link_ops\"), ip6erspan_newlink() correctly resolves the per-netns ip6gre hash via link_net. ip6erspan_changelink() was not converted in that series and still uses dev_net(dev), which diverges from the device's creation netns after IFLA_NET_NS_FD migration. This re-inserts the tunnel into the wrong per-netns hash. The original netns keeps a stale entry. When that netns is later destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a slab-use-after-free reported by KASAN, followed by a kernel BUG at net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify(). Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). ip6gre_changelink() earlier in the same file already uses the cached t->net; only ip6erspan_changelink() has the wrong shape.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46184", "url": "https://ubuntu.com/security/CVE-2026-46184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sound: ua101: fix division by zero at probe Add a missing sanity check for bNrChannels in detect_usb_format() to prevent a division by zero in playback_urb_complete() and capture_urb_complete(). USB core does not validate class-specific descriptor fields such as bNrChannels, so drivers must verify them before use. If a device provides bNrChannels = 0, frame_bytes becomes zero and is later used as a divisor in the URB completion handlers, leading to a kernel crash.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46132", "url": "https://ubuntu.com/security/CVE-2026-46132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack without initialisation: \tstruct ifla_vf_broadcast vf_broadcast; The struct contains a single fixed 32-byte field: \t/* include/uapi/linux/if_link.h */ \tstruct ifla_vf_broadcast { \t\t__u8 broadcast[32]; \t}; The function then copies dev->broadcast into it using dev->addr_len as the length: \tmemcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len); On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via: \tnla_put(skb, IFLA_VF_BROADCAST, \t\tsizeof(vf_broadcast), &vf_broadcast) leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK request, repeatable. The other vf_* structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vf_vlan_info, node_guid and port_guid a few lines above. vf_broadcast was simply missed when it was added. Reachability: any unprivileged local process can open AF_NETLINK / NETLINK_ROUTE without capabilities and send RTM_GETLINK with an IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nla_put() when reproduced. Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf_* structs in the same function.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46150", "url": "https://ubuntu.com/security/CVE-2026-46150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fanotify: fix false positive on permission events fsnotify_get_mark_safe() may return false for a mark on an unrelated group, which results in bypassing the permission check. Fix by skipping over detached marks that are not in the current group.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45834", "url": "https://ubuntu.com/security/CVE-2026-45834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-45835", "url": "https://ubuntu.com/security/CVE-2026-45835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46186", "url": "https://ubuntu.com/security/CVE-2026-46186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: validate rx pkt_type header length virtbt_rx_handle() reads the leading pkt_type byte from the RX skb and forwards the remainder to hci_recv_frame() for every event/ACL/SCO/ISO type, without checking that the remaining payload is at least the fixed HCI header for that type. After the preceding patch bounds the backend-supplied used.len to [1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches hci_recv_frame() with skb->len already pulled to 0. If the byte happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification fast-path in hci_dev_classify_pkt_type() dereferences hci_acl_hdr(skb)->handle whenever the HCI device has an active CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of uninitialized RX-buffer data. The same hazard exists for every packet type the driver accepts because none of the switch cases in virtbt_rx_handle() check skb->len against the per-type minimum HCI header size before handing the frame to the core. After stripping pkt_type, require skb->len to cover the fixed header size for the selected type (event 2, ACL 4, SCO 3, ISO 4) before calling hci_recv_frame(); drop ratelimited otherwise. Unknown pkt_type values still take the original kfree_skb() default path. Use bt_dev_err_ratelimited() because both the length and pkt_type values come from an untrusted backend that can otherwise flood the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46123", "url": "https://ubuntu.com/security/CVE-2026-46123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: clamp rx length before skb_put virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one(). Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device. The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory. Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle(). Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log. Same class of bug as commit c04db81cd028 (\"net/9p: Fix buffer overflow in USB transport layer\"), which hardened the USB 9p transport against unchecked device-reported length.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46172", "url": "https://ubuntu.com/security/CVE-2026-46172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: xfrm6: release dst on error in xfrm6_rcv_encap() xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6_route_input_lookup() returns a referenced dst entry even when the lookup resolves to an error route. If dst->error is set, xfrm6_rcv_encap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries. Release the dst before jumping to the drop path.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46146", "url": "https://ubuntu.com/security/CVE-2026-46146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3() The convert_chmap_v3() has a loop with its increment size of cs_desc->wLength, but we forgot to validate cs_desc->wLength itself, which may lead to potential endless loop by a malformed descriptor. Add a proper size check to abort the loop for plugging the hole.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46167", "url": "https://ubuntu.com/security/CVE-2026-46167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. Ideally that short command should be detected and error out, but many printers are known to send \"incorrect\" responses back so we can't just do that. statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl. usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller. Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no \"leak\" of information happening.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46151", "url": "https://ubuntu.com/security/CVE-2026-46151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix heap leak in IEEE 1284 device ID via short response usblp_ctrl_msg() collapses the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GET_DEVICE_ID control transfer short and the driver has no way to know. usblp_cache_device_id_string() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves device_id_string[2..1022] holding stale kmalloc heap. That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf(\"%s\", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device. Fix this up by just zapping the buffer with zeros before each request sent to the device.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46122", "url": "https://ubuntu.com/security/CVE-2026-46122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43: enforce bounds check on firmware key index in b43_rx() The firmware-controlled key index in b43_rx() can exceed the dev->key[] array size (58 entries). The existing B43_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read. Make the B43_WARN_ON check enforcing by dropping the frame when the firmware returns an invalid key index.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46307", "url": "https://ubuntu.com/security/CVE-2026-46307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath5k: do not access array OOB Vincent reports: > The ath5k driver seems to do an array-index-out-of-bounds access as > shown by the UBSAN kernel message: > UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20 > index 4 is out of range for type 'ieee80211_tx_rate [4]' > ... > Call Trace: > > dump_stack_lvl+0x5d/0x80 > ubsan_epilogue+0x5/0x2b > __ubsan_handle_out_of_bounds.cold+0x46/0x4b > ath5k_tasklet_tx+0x4e0/0x560 [ath5k] > tasklet_action_common+0xb5/0x1c0 It is real. 'ts->ts_final_idx' can be 3 on 5212, so: info->status.rates[ts->ts_final_idx + 1].idx = -1; with the array defined as: struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES]; while the size is: #define IEEE80211_TX_MAX_RATES 4 is indeed bogus. Set this 'idx = -1' sentinel only if the array index is less than the array size. As mac80211 will not look at rates beyond the size (IEEE80211_TX_MAX_RATES). Note: The effect of the OOB write is negligible. It just overwrites the next member of info->status, i.e. ack_signal.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46187", "url": "https://ubuntu.com/security/CVE-2026-46187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: fix kthread lifetime race between self-exit and external-stop RSI driver use both self-exit(kthread_complete_and_exit) and external-stop (kthread_stop) when killing a kthread. Generally, kthread_stop() is called first, and in this case, no particular issues occur. However, in rare instances where kthread_complete_and_exit() is called first and then kthread_stop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again. Therefore, to prevent this with minimal modification, you must remove kthread_stop() and change the code to wait until the self-exit operation is completed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46163", "url": "https://ubuntu.com/security/CVE-2026-46163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43legacy: enforce bounds check on firmware key index in RX path Same fix as b43: the firmware-controlled key index in b43legacy_rx() can exceed dev->max_nr_keys. The existing B43legacy_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read of dev->key[]. Make the check enforcing by dropping the frame for invalid indices.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46044", "url": "https://ubuntu.com/security/CVE-2026-46044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:ssif: Clean up kthread on errors If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43496", "url": "https://ubuntu.com/security/CVE-2026-43496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peeked When red qdisc has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] [ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq] [ 78.672148][ T363] ? __pfx__printk+0x10/0x10 [ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0 [ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0 [ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red] [ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf] [ 78.673566][ T363] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead.", "cve_priority": "medium", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2024-56727", "url": "https://ubuntu.com/security/CVE-2024-56727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c Adding error pointer check after calling otx2_mbox_get_rsp().", "cve_priority": "medium", "cve_public_date": "2024-12-29 12:15:00 UTC" }, { "cve": "CVE-2026-31489", "url": "https://ubuntu.com/security/CVE-2026-31489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: meson-spicc: Fix double-put in remove path meson_spicc_probe() registers the controller with devm_spi_register_controller(), so teardown already drops the controller reference via devm cleanup. Calling spi_controller_put() again in meson_spicc_remove() causes a double-put.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31476", "url": "https://ubuntu.com/security/CVE-2026-31476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: do not expire session on binding failure When a multichannel session binding request fails (e.g. wrong password), the error path unconditionally sets sess->state = SMB2_SESSION_EXPIRED. However, during binding, sess points to the target session looked up via ksmbd_session_lookup_slowpath() -- which belongs to another connection's user. This allows a remote attacker to invalidate any active session by simply sending a binding request with a wrong password (DoS). Fix this by skipping session expiration when the failed request was a binding attempt, since the session does not belong to the current connection. The reference taken by ksmbd_session_lookup_slowpath() is still correctly released via ksmbd_user_session_put().", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43497", "url": "https://ubuntu.com/security/CVE-2026-43497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages to userspace but sets no vm_ops on the VMA. This means the kernel cannot track active mmaps. When dlfb_realloc_framebuffer() replaces the backing buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated. On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages while userspace PTEs still reference them, resulting in a use-after-free: the process retains read/write access to freed kernel pages. Add vm_operations_struct with open/close callbacks that maintain an atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(), check mmap_count and return -EBUSY if the buffer is currently mapped, preventing buffer replacement while userspace holds stale PTEs. Tested with PoC using dummy_hcd + raw_gadget USB device emulation.", "cve_priority": "low", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46108", "url": "https://ubuntu.com/security/CVE-2026-46108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:si: Return state to normal if message allocation fails There were places where nothing would get started if a message allocation failed, so the driver needs to return to normal state.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46128", "url": "https://ubuntu.com/security/CVE-2026-46128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Check event message buffer response for bad data The event message buffer response data size got checked later when processing, but check it right after the response comes back. It appears some BMCs may return an empty message instead of an error when fetching events. There are apparently some new BMCs that make this error, so we need to compensate.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46177", "url": "https://ubuntu.com/security/CVE-2026-46177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Add limits to event and receive message requests The driver would just fetch events and receive messages until the BMC said it was done. To avoid issues with BMCs that never say they are done, add a limit of 10 fetches at a time. In addition, an si interface has an attn state it can return from the hardware which is supposed to cause a flag fetch to see if the driver needs to fetch events or message or a few other things. If the attn bit gets stuck, it's a similar problem. So allow messages in between flag fetches so the driver itself doesn't get stuck. This is a more general fix than the previous fix for the specific bad BMC, but should fix the more general issue of a BMC that won't stop saying it has data. This has been there from the beginning of the driver. It's not a bug per-se, but it is accounting for bugs in BMCs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46149", "url": "https://ubuntu.com/security/CVE-2026-46149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show() target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered. Commit 27e06650a5ea (\"scsi: target: target_core_configfs: Add length check to avoid buffer overflow\") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46101", "url": "https://ubuntu.com/security/CVE-2026-46101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: reject zero shift in nft_bitwise Reject zero shift operands for nft_bitwise left and right shift expressions during initialization. The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour. Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46099", "url": "https://ubuntu.com/security/CVE-2026-46099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels seg6_input_core() and rpl_input() call ip6_route_input() which sets a NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking dst_hold() unconditionally. On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpu_rt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence: ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1] rt_genid_bump_ipv6() -> bumps fib6_sernum [fib6_sernum from W to Z] ip6_route_output() -> ip6_pol_route() -> FIB lookup resolves fib6_nh [nhid=N] -> rt6_get_pcpu_route() pcpu_rt->sernum != fib6_sernum [W <> Z, stale] -> prev = xchg(rt6i_pcpu, NULL) -> dst_release(prev) [prev is pcpu_rt, refcount 1->0, dead] dst = skb_dst(skb) [dst is the dead pcpu_rt] dst_cache_set_ip6(dst) -> dst_hold() on dead dst -> WARN / use-after-free For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release the pcpu_rt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6_nh and its rt6i_pcpu entry. Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after ip6_route_input() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6_route_output() already returns a refcounted dst.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46033", "url": "https://ubuntu.com/security/CVE-2026-46033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject short ahash digests during instance creation authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46062", "url": "https://ubuntu.com/security/CVE-2026-46062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix integer overflow in run_unpack() volume boundary check The volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses raw addition which can wrap around for large lcn and len values, bypassing the validation. Use check_add_overflow() as is already done for the adjacent prev_lcn + dlcn and vcn64 + len checks added by commit 3ac37e100385 (\"ntfs3: Fix integer overflow in run_unpack()\"). Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46072", "url": "https://ubuntu.com/security/CVE-2026-46072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: add buffer boundary checks to run_unpack() run_unpack() checks `run_buf < run_last` at the top of the while loop but then reads size_size and offset_size bytes via run_unpack_s64() without verifying they fit within the remaining buffer. A crafted NTFS image with truncated run data in an MFT attribute triggers an OOB heap read of up to 15 bytes when the filesystem is mounted. Add boundary checks before each run_unpack_s64() call to ensure the declared field size does not exceed the remaining buffer. Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46023", "url": "https://ubuntu.com/security/CVE-2026-46023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm mirror: fix integer overflow in create_dirty_log() The argument count calculation in create_dirty_log() performs `*args_used = 2 + param_count` before validating against argc. When a user provides a param_count close to UINT_MAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent `argc < *args_used` check to be bypassed. The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array. Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46077", "url": "https://ubuntu.com/security/CVE-2026-46077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-tdes - fix DMA sync direction Before DMA output is consumed by the CPU, ->dma_addr_out must be synced with dma_sync_single_for_cpu() instead of dma_sync_single_for_device(). Using the wrong direction can return stale cache data on non-coherent platforms.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45986", "url": "https://ubuntu.com/security/CVE-2026-45986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccree - fix a memory leak in cc_mac_digest() Add cc_unmap_result() if cc_map_hash_request_final() fails to prevent potential memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46019", "url": "https://ubuntu.com/security/CVE-2026-46019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the first page using free_page(), leaking the remaining 3 pages. Use free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46015", "url": "https://ubuntu.com/security/CVE-2026-46015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: call sk_data_ready() after listener migration When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46040", "url": "https://ubuntu.com/security/CVE-2026-46040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails When fsnotify_add_inode_mark_locked() fails in inotify_new_watch(), the error path calls inotify_remove_from_idr() but does not call dec_inotify_watches() to undo the preceding inc_inotify_watches(). This leaks a watch count, and repeated failures can exhaust the max_user_watches limit with -ENOSPC even when no watches are active. Prior to commit 1cce1eea0aff (\"inotify: Convert to using per-namespace limits\"), the watch count was incremented after fsnotify_add_mark_locked() succeeded, so this path was not affected. The conversion moved inc_inotify_watches() before the mark insertion without adding the corresponding rollback. Add the missing dec_inotify_watches() call in the error path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46070", "url": "https://ubuntu.com/security/CVE-2026-46070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: validate payload size before accessing journal metadata r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block. A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets. Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46051", "url": "https://ubuntu.com/security/CVE-2026-46051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix soft lockup in retry_aligned_read() When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46046", "url": "https://ubuntu.com/security/CVE-2026-46046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all() The commit c8e008b60492 (\"ext4: ignore xattrs past end\") introduced a refcount leak in when block_csum is false. ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to get iloc.bh, but never releases it with brelse().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46285", "url": "https://ubuntu.com/security/CVE-2026-46285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: docg3: fix use-after-free in docg3_release() In docg3_release(), the docg3 pointer is obtained from cascade->floors[0]->priv before the loop that calls doc_release_device() on each floor. doc_release_device() frees the docg3 struct via kfree(docg3) at line 1881. After the loop, docg3->cascade->bch dereferences the already-freed pointer. Fix this by accessing cascade->bch directly, which is equivalent since docg3->cascade points back to the same cascade struct, and is already available as a local variable. This also removes the now-unused docg3 local variable.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46082", "url": "https://ubuntu.com/security/CVE-2026-46082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. [sean: tag for stable@]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45987", "url": "https://ubuntu.com/security/CVE-2026-45987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2 After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46024", "url": "https://ubuntu.com/security/CVE-2026-46024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply() If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for both protocol and result, this is currently not treated as an error. In case of ac->negotiating == true and ac->protocol > 0, this leads to setting ac->protocol = 0 and ac->ops = NULL. Thereafter, the check for ac->protocol != protocol returns false, and init_protocol() is not called. Subsequently, ac->ops->handle_reply() is called, which leads to a null pointer dereference, because ac->ops is still NULL. This patch changes the check for ac->protocol != protocol to !ac->protocol, as this also includes the case when the protocol was set to zero in the message. This causes the message to be treated as containing a bad auth protocol.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46037", "url": "https://ubuntu.com/security/CVE-2026-46037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: validate reply type before using icmp_pointers Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type. That value is outside the range covered by icmp_pointers[], which only describes the traditional ICMP types up to NR_ICMP_TYPES. Avoid consulting icmp_pointers[] for reply types outside that range, and use array_index_nospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46027", "url": "https://ubuntu.com/security/CVE-2026-46027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid early lgr access in smc_clc_wait_msg A CLC decline can be received while the handshake is still in an early stage, before the connection has been associated with a link group. The decline handling in smc_clc_wait_msg() updates link-group level sync state for first-contact declines, but that state only exists after link group setup has completed. Guard the link-group update accordingly and keep the per-socket peer diagnosis handling unchanged. This preserves the existing sync_err handling for established link-group contexts and avoids touching link-group state before it is available.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46053", "url": "https://ubuntu.com/security/CVE-2026-46053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: fix MR cleanup on copy error __rds_rdma_map() hands sg/pages ownership to the transport after get_mr() succeeds. If copying the generated cookie back to user space fails after that point, the error path must not free those resources again before dropping the MR reference. Remove the duplicate unpin/free from the put_user() failure branch so that MR teardown is handled only through the existing final cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46004", "url": "https://ubuntu.com/security/CVE-2026-46004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Handle probe errors properly The probe procedure of setup_card() in caiaq driver doesn't treat the error cases gracefully, e.g. the error from snd_card_register() calls snd_card_free() but continues. This would lead to a UAF for the further calls like snd_usb_caiaq_control_init(), as Berk suggested in another patch in the link below. However, the problem is not only that; in general, this function drops the all error handlings (as it's a void function) although its caller can propagate an error to snd_probe(), which eventually calls snd_card_free() as a proper error path. That said, we should treat each error case in setup_card(), and just return the error code promptly, which is then handled later as a fatal error in snd_probe(). This patch achieves it by changing the setup_card() to return an error code. Also, the superfluous snd_card_free() call is removed, too. Note that card->private_free can be set still safely at returning an error. All called functions in card_free() have checks of the unassigned resources or NULL checks.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46050", "url": "https://ubuntu.com/security/CVE-2026-46050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix deadlock with check operation and nowait requests When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b (\"raid10: cleanup memleak at raid10_make_request\") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case. This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0. Output of r10conf state of the array when we hit this condition: crash> struct r10conf \tbarrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0, Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier(): md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46049", "url": "https://ubuntu.com/security/CVE-2026-46049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Add fallback to default RSR for S/PDIF spdif_passthru_playback_get_resources() uses atc->pll_rate as the RSR for the MSR calculation loop. However, pll_rate is only updated in atc_pll_init() and not in hw_pll_init(), so it remains 0 after the card init. When spdif_passthru_playback_setup() skips atc_pll_init() for 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin indefinitely. Add fallback to use atc->rsr when atc->pll_rate is 0. This reflects the hardware state, since hw_card_init() already configures the PLL to the default RSR.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46002", "url": "https://ubuntu.com/security/CVE-2026-46002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext2: reject inodes with zero i_nlink and valid mode in ext2_iget() ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is zero or i_dtime is set, treating them as deleted. However, the case of i_nlink == 0 with a non-zero mode and zero dtime slips through. Since ext2 has no orphan list, such a combination can only result from filesystem corruption - a legitimate inode deletion always sets either i_dtime or clears i_mode before freeing the inode. A crafted image can exploit this gap to present such an inode to the VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via ext2_unlink(), ext2_rename() and ext2_rmdir(): WARNING: CPU: 3 PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295 vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477 do_unlinkat+0x53e/0x730 fs/namei.c:4541 __x64_sys_unlink+0xc6/0x110 fs/namei.c:4587 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 646 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rename+0x35e/0x850 fs/ext2/namei.c:374 vfs_rename+0xf2f/0x2060 fs/namei.c:5021 do_renameat2+0xbe2/0xd50 fs/namei.c:5178 __x64_sys_rename+0x7e/0xa0 fs/namei.c:5223 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 634 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311 vfs_rmdir+0x204/0x690 fs/namei.c:4348 do_rmdir+0x372/0x3e0 fs/namei.c:4407 __x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Extend the existing i_nlink == 0 check to also catch this case, reporting the corruption via ext2_error() and returning -EFSCORRUPTED. This rejects the inode at load time and prevents it from reaching any of the namei.c paths. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46047", "url": "https://ubuntu.com/security/CVE-2026-46047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Fix use-after-free in driver remove() In the remove callback, if a packet arrives after destroy_workqueue() is called, but before sock_release(), the qrtr_ns_data_ready() callback will try to queue the work, causing use-after-free issue. Fix this issue by saving the default 'sk_data_ready' callback during qrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback at the start of remove(). This ensures that even if a packet arrives after destroy_workqueue(), the work struct will not be dereferenced. Note that it is also required to ensure that the RX threads are completed before destroying the workqueue, because the threads could be using the qrtr_ns_data_ready() callback.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46009", "url": "https://ubuntu.com/security/CVE-2026-46009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to do later. This leads to an oops when .allow_link fails or when .drop_link is performed. Remove the helper. Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46102", "url": "https://ubuntu.com/security/CVE-2026-46102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: strparser: fix skb_head leak in strp_abort_strp() When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46098", "url": "https://ubuntu.com/security/CVE-2026-46098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: caif: clear client service pointer on teardown `caif_connect()` can tear down an existing client after remote shutdown by calling `caif_disconnect_client()` followed by `caif_free_client()`. `caif_free_client()` releases the service layer referenced by `adap_layer->dn`, but leaves that pointer stale. When the socket is later destroyed, `caif_sock_destructor()` calls `caif_free_client()` again and dereferences the freed service pointer. Clear the client/service links before releasing the service object so repeated teardown becomes harmless.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46088", "url": "https://ubuntu.com/security/CVE-2026-46088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names() snd_ctl_elem_init_enum_names() advances pointer p through the names buffer while decrementing buf_len. If buf_len reaches zero but items remain, the next iteration calls strnlen(p, 0). While strnlen(p, 0) returns 0 and would hit the existing name_len == 0 error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks maxlen against __builtin_dynamic_object_size(). When Clang loses track of p's object size inside the loop, this triggers a BRK exception panic before the return value is examined. Add a buf_len == 0 guard at the loop entry to prevent calling fortified strnlen() on an exhausted buffer. Found by kernel fuzz testing through Xiaomi Smartphone.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46080", "url": "https://ubuntu.com/security/CVE-2026-46080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: split transactions in dio completion to avoid credit exhaustion During ocfs2 dio operations, JBD2 may report warnings via following call trace: ocfs2_dio_end_io_write ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_split_extent ocfs2_try_to_merge_extent ocfs2_extend_rotate_transaction ocfs2_extend_trans jbd2__journal_restart start_this_handle output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449 To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to handle extents in a batch of transaction. Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode should only be removed from the orphan list after the extent tree update is complete. This ensures that if a crash occurs in the middle of extent tree updates, we won't leave stale blocks beyond EOF. This patch also changes the logic for updating the inode size and removing orphan, making it similar to ext4_dio_write_end_io(). Both operations are performed only when everything looks good. Finally, thanks to Jans and Joseph for providing the bug fix prototype and suggestions.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-21739", "url": "https://ubuntu.com/security/CVE-2025-21739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix use-after free in init error and remove paths devm_blk_crypto_profile_init() registers a cleanup handler to run when the associated (platform-) device is being released. For UFS, the crypto private data and pointers are stored as part of the ufs_hba's data structure 'struct ufs_hba::crypto_profile'. This structure is allocated as part of the underlying ufshcd and therefore Scsi_host allocation. During driver release or during error handling in ufshcd_pltfrm_init(), this structure is released as part of ufshcd_dealloc_host() before the (platform-) device associated with the crypto call above is released. Once this device is released, the crypto cleanup code will run, using the just-released 'struct ufs_hba::crypto_profile'. This causes a use-after-free situation: Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0 In other words, the initialisation code flow is: platform-device probe ufshcd_pltfrm_init() ufshcd_alloc_host() scsi_host_alloc() allocation of struct ufs_hba creation of scsi-host devices devm_blk_crypto_profile_init() devm registration of cleanup handler using platform-device and during error handling of ufshcd_pltfrm_init() or during driver removal: ufshcd_dealloc_host() scsi_host_put() put_device(scsi-host) release of struct ufs_hba put_device(platform-device) crypto cleanup handler To fix this use-after free, change ufshcd_alloc_host() to register a devres action to automatically cleanup the underlying SCSI device on ufshcd destruction, without requiring explicit calls to ufshcd_dealloc_host(). This way: * the crypto profile and all other ufs_hba-owned resources are destroyed before SCSI (as they've been registered after) * a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as it's not needed anymore * no future drivers using ufshcd_alloc_host() could ever forget adding the cleanup", "cve_priority": "low", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2026-46064", "url": "https://ubuntu.com/security/CVE-2026-46064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix heap over-read in ibmasm_send_i2o_message() The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO. Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure. Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controller's free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it. Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45994", "url": "https://ubuntu.com/security/CVE-2026-45994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix OOB reads in command_file_write due to missing size checks The command_file_write() handler allocates a kernel buffer of exactly count bytes and copies user data into it, but does not validate the buffer against the dot command protocol before passing it to get_dot_command_size() and get_dot_command_timeout(). Since both the allocation size (count) and the header fields (command_size, data_size) are independently user-controlled, an attacker can cause get_dot_command_size() to return a value exceeding the allocation, triggering OOB reads in get_dot_command_timeout() and an out-of-bounds memcpy_toio() that leaks kernel heap memory to the service processor. Fix with two guards: reject writes smaller than sizeof(struct dot_command_header) before allocation, then after copying user data reject commands where the buffer is smaller than the total size declared by the header (sizeof(header) + command_size + data_size). This ensures all subsequent header and payload field accesses stay within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46022", "url": "https://ubuntu.com/security/CVE-2026-46022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt() ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60). A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started. The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes: queue_begin + reader * sizeof(struct remote_input) with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception. Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46006", "url": "https://ubuntu.com/security/CVE-2026-46006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix u32 overflow in pushbuf reloc bounds check nouveau_gem_pushbuf_reloc_apply() validates each relocation with if (r->reloc_bo_offset + 4 > nvbo->bo.base.size) but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size. Cast to u64 so the addition happens in 64-bit arithmetic. [ Add Fixes: tag. - Danilo ]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46018", "url": "https://ubuntu.com/security/CVE-2026-46018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES parse_uac2_sample_rate_range() caps the number of enumerated rates at MAX_NR_RATES, but it only breaks out of the current rate loop. A malformed UAC2 RANGE response with additional triplets continues parsing the remaining triplets and repeatedly prints \"invalid uac2 rates\" while probe still holds register_mutex. Stop the whole parse once the cap is reached and return the number of rates collected so far.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-31696", "url": "https://ubuntu.com/security/CVE-2026-31696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing validation of ticket length in non-XDR key preparsing In rxrpc_preparse(), there are two paths for parsing key payloads: the XDR path (for large payloads) and the non-XDR path (for payloads <= 28 bytes). While the XDR path (rxrpc_preparse_xdr_rxkad()) correctly validates the ticket length against AFSTOKEN_RK_TIX_MAX, the non-XDR path fails to do so. This allows an unprivileged user to provide a very large ticket length. When this key is later read via rxrpc_read(), the total token size (toksize) calculation results in a value that exceeds AFSTOKEN_LENGTH_MAX, triggering a WARN_ON(). [ 2001.302904] WARNING: CPU: 2 PID: 2108 at net/rxrpc/key.c:778 rxrpc_read+0x109/0x5c0 [rxrpc] Fix this by adding a check in the non-XDR parsing path of rxrpc_preparse() to ensure the ticket length does not exceed AFSTOKEN_RK_TIX_MAX, bringing it into parity with the XDR parsing logic.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31697", "url": "https://ubuntu.com/security/CVE-2026-31697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388 CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31698", "url": "https://ubuntu.com/security/CVE-2026-31698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033 CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31699", "url": "https://ubuntu.com/security/CVE-2026-31699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405 CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31701", "url": "https://ubuntu.com/security/CVE-2026-31701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: take a reference on the USB device in create_card() The caiaq driver stores a pointer to the parent USB device in cdev->chip.dev but never takes a reference on it. The card's private_free callback, snd_usb_caiaq_card_free(), can run asynchronously via snd_card_free_when_closed() after the USB device has already been disconnected and freed, so any access to cdev->chip.dev in that path dereferences a freed usb_device. On top of the refcounting issue, the current card_free implementation calls usb_reset_device(cdev->chip.dev). A reset in a free callback is inappropriate: the device is going away, the call takes the device lock in a teardown context, and the reset races with the disconnect path that the callback is already cleaning up after. Take a reference on the USB device in create_card() with usb_get_dev(), drop it with usb_put_dev() in the free callback, and remove the usb_reset_device() call.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31694", "url": "https://ubuntu.com/security/CVE-2026-31694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject oversized dirents in page cache fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31716", "url": "https://ubuntu.com/security/CVE-2026-31716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate rec->used in journal-replay file record check check_file_record() validates rec->total against the record size but never validates rec->used. The do_action() journal-replay handlers read rec->used from disk and use it to compute memmove lengths: DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next)) When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall. This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay Fix this up by bounding rec->used correctly. This is much like commit b2bc7c44ed17 (\"fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\") which checked different values in this same switch statement.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31676", "url": "https://ubuntu.com/security/CVE-2026-31676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31409", "url": "https://ubuntu.com/security/CVE-2026-31409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: unset conn->binding on failed binding request When a multichannel SMB2_SESSION_SETUP request with SMB2_SESSION_REQ_FLAG_BINDING fails ksmbd sets conn->binding = true but never clears it on the error path. This leaves the connection in a binding state where all subsequent ksmbd_session_lookup_all() calls fall back to the global sessions table. This fix it by clearing conn->binding = false in the error path.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2023-53596", "url": "https://ubuntu.com/security/CVE-2023-53596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: base: Free devm resources when unregistering a device In the current code, devres_release_all() only gets called if the device has a bus and has been probed. This leads to issues when using bus-less or driver-less devices where the device might never get freed if a managed resource holds a reference to the device. This is happening in the DRM framework for example. We should thus call devres_release_all() in the device_del() function to make sure that the device-managed actions are properly executed when the device is unregistered, even if it has neither a bus nor a driver. This is effectively the same change than commit 2f8d16a996da (\"devres: release resources on device_del()\") that got reverted by commit a525a3ddeaca (\"driver core: free devres in device_release\") over memory leaks concerns. This patch effectively combines the two commits mentioned above to release the resources both on device_del() and device_release() and get the best of both worlds.", "cve_priority": "low", "cve_public_date": "2025-10-04 16:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2025-38192", "url": "https://ubuntu.com/security/CVE-2025-38192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: clear the dst when changing skb protocol A not-so-careful NAT46 BPF program can crash the kernel if it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10) The output interface has a 4->6 program attached at ingress. We try to loop the multicast skb back to the sending socket. Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr and changes skb->protocol to v6. We enter ip6_rcv_core which tries to use skb_dst(). But the dst is still an IPv4 one left after IPv4 mcast output. Clear the dst in all BPF helpers which change the protocol. Try to preserve metadata dsts, those may carry non-routing metadata.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-21712", "url": "https://ubuntu.com/security/CVE-2025-21712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime After commit ec6bb299c7c3 (\"md/md-bitmap: add 'sync_size' into struct md_bitmap_stats\"), following panic is reported: Oops: general protection fault, probably for non-canonical address RIP: 0010:bitmap_get_stats+0x2b/0xa0 Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Root cause is that bitmap_get_stats() can be called at anytime if mddev is still there, even if bitmap is destroyed, or not fully initialized. Deferenceing bitmap in this case can crash the kernel. Meanwhile, the above commit start to deferencing bitmap->storage, make the problem easier to trigger. Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2026-43328", "url": "https://ubuntu.com/security/CVE-2026-43328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error path When kobject_init_and_add() fails, cpufreq_dbs_governor_init() calls kobject_put(&dbs_data->attr_set.kobj). The kobject release callback cpufreq_dbs_data_release() calls gov->exit(dbs_data) and kfree(dbs_data), but the current error path then calls gov->exit(dbs_data) and kfree(dbs_data) again, causing a double free. Keep the direct kfree(dbs_data) for the gov->init() failure path, but after kobject_init_and_add() has been called, let kobject_put() handle the cleanup through cpufreq_dbs_data_release().", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-23066", "url": "https://ubuntu.com/security/CVE-2026-23066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recvmsg() unconditional requeue If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at the front of the recvmsg queue already has its mutex locked, it requeues the call - whether or not the call is already queued. The call may be on the queue because MSG_PEEK was also passed and so the call was not dequeued or because the I/O thread requeued it. The unconditional requeue may then corrupt the recvmsg queue, leading to things like UAFs or refcount underruns. Fix this by only requeuing the call if it isn't already on the queue - and moving it to the front if it is already queued. If we don't queue it, we have to put the ref we obtained by dequeuing it. Also, MSG_PEEK doesn't dequeue the call so shouldn't call rxrpc_notify_socket() for the call if we didn't use up all the data on the queue, so fix that also.", "cve_priority": "high", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-27407", "url": "https://ubuntu.com/security/CVE-2024-27407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fixed overflow check in mi_enum_attr()", "cve_priority": "high", "cve_public_date": "2024-05-17 12:15:00 UTC" }, { "cve": "CVE-2023-45896", "url": "https://ubuntu.com/security/CVE-2023-45896", "cve_description": "ntfs3 in the Linux kernel through 6.8.0 allows a physically proximate attacker to read kernel memory by mounting a filesystem (e.g., if a Linux distribution is configured to allow unprivileged mounts of removable media) and then leveraging local access to trigger an out-of-bounds read. A length value can be larger than the amount of memory allocated. NOTE: the supplier's perspective is that there is no vulnerability when an attack requires an attacker-modified filesystem image.", "cve_priority": "medium", "cve_public_date": "2024-08-28 05:15:00 UTC" }, { "cve": "CVE-2023-52737", "url": "https://ubuntu.com/security/CVE-2023-52737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: lock the inode in shared mode before starting fiemap Currently fiemap does not take the inode's lock (VFS lock), it only locks a file range in the inode's io tree. This however can lead to a deadlock if we have a concurrent fsync on the file and fiemap code triggers a fault when accessing the user space buffer with fiemap_fill_next_extent(). The deadlock happens on the inode's i_mmap_lock semaphore, which is taken both by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by syzbot and triggers a trace like the following: task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 wait_on_state fs/btrfs/extent-io-tree.c:707 [inline] wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751 lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742 find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488 writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863 __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174 extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091 extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211 do_writepages+0x3c3/0x680 mm/page-writeback.c:2581 filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388 __filemap_fdatawrite_range mm/filemap.c:421 [inline] filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439 btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline] start_ordered_ops fs/btrfs/file.c:1737 [inline] btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839 generic_write_sync include/linux/fs.h:2885 [inline] btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684 call_write_iter include/linux/fs.h:2189 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9 RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006 RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8 INFO: task syz-executor361:5697 blocked for more than 145 seconds. Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095 __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260 btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526 do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947 wp_page_shared+0x15e/0x380 mm/memory.c:3295 handle_pte_fault mm/memory.c:4949 [inline] __handle_mm_fault mm/memory.c:5073 [inline] handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219 do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428 handle_page_fault arch/x86/mm/fault.c:1519 [inline] exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233 Code: 74 0a 89 (...) RSP: 0018:ffffc9000570f330 EFLAGS: 000502 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-05-21 16:15:00 UTC" }, { "cve": "CVE-2025-38626", "url": "https://ubuntu.com/security/CVE-2025-38626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode w/ \"mode=lfs\" mount option, generic/299 will cause system panic as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2835! Call Trace: f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720 The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may trigger foreground gc only if it allocates any physical block, it will be a little bit later when there is multiple threads writing data w/ aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so f2fs_map_blocks() does block allocations aggressively. In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_blocks().", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2024-46770", "url": "https://ubuntu.com/security/CVE-2024-46770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Add netif_device_attach/detach into PF reset flow Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. getting coalesce settings can result in a NULL pointer dereference seen below. Reproduction steps: Once the driver is fully initialized, trigger reset: \t# echo 1 > /sys/class/net//device/reset when reset is in progress try to get coalesce settings using ethtool: \t# ethtool -c BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7 RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice] RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206 RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000 R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40 FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0 Call Trace: ice_get_coalesce+0x17/0x30 [ice] coalesce_prepare_data+0x61/0x80 ethnl_default_doit+0xde/0x340 genl_family_rcv_msg_doit+0xf2/0x150 genl_rcv_msg+0x1b3/0x2c0 netlink_rcv_skb+0x5b/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x19c/0x290 netlink_sendmsg+0x222/0x490 __sys_sendto+0x1df/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7faee60d8e27 Calling netif_device_detach() before reset makes the net core not call the driver when ethtool command is issued, the attempt to execute an ethtool command during reset will result in the following message: netlink error: No such device instead of NULL pointer dereference. Once reset is done and ice_rebuild() is executing, the netif_device_attach() is called to allow for ethtool operations to occur again in a safe manner.", "cve_priority": "medium", "cve_public_date": "2024-09-18 08:15:00 UTC" }, { "cve": "CVE-2025-38105", "url": "https://ubuntu.com/security/CVE-2025-38105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Kill timer properly at removal The USB-audio MIDI code initializes the timer, but in a rare case, the driver might be freed without the disconnect call. This leaves the timer in an active state while the assigned object is released via snd_usbmidi_free(), which ends up with a kernel warning when the debug configuration is enabled, as spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be killed properly. While we're at it, replace the existing timer_delete_sync() at the disconnect callback with timer_shutdown_sync(), too.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2024-27389", "url": "https://ubuntu.com/security/CVE-2024-27389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore: inode: Only d_invalidate() is needed Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning: WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410 Using the combo of d_drop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use d_invalidate() and update the code to not bother checking for error codes that can never happen. ---", "cve_priority": "medium", "cve_public_date": "2024-05-01 13:15:00 UTC" }, { "cve": "CVE-2023-52682", "url": "https://ubuntu.com/security/CVE-2023-52682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait on block writeback for post_read case If inode is compressed, but not encrypted, it missed to call f2fs_wait_on_block_writeback() to wait for GCed page writeback in IPU write path. Thread A\t\t\t\tGC-Thread \t\t\t\t\t- f2fs_gc \t\t\t\t\t - do_garbage_collect \t\t\t\t\t - gc_data_segment \t\t\t\t\t - move_data_block \t\t\t\t\t - f2fs_submit_page_write \t\t\t\t\t migrate normal cluster's block via \t\t\t\t\t meta_inode's page cache - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_submit_page_bio IRQ - f2fs_read_end_io \t\t\t\t\tIRQ \t\t\t\t\told data overrides new data due to \t\t\t\t\tout-of-order GC and common IO. \t\t\t\t\t- f2fs_read_end_io", "cve_priority": "medium", "cve_public_date": "2024-05-17 15:15:00 UTC" }, { "cve": "CVE-2024-56719", "url": "https://ubuntu.com/security/CVE-2024-56719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix TSO DMA API usage causing oops Commit 66600fac7a98 (\"net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data\") moved the assignment of tx_skbuff_dma[]'s members to be later in stmmac_tso_xmit(). The buf (dma cookie) and len stored in this structure are passed to dma_unmap_single() by stmmac_tx_clean(). The DMA API requires that the dma cookie passed to dma_unmap_single() is the same as the value returned from dma_map_single(). However, by moving the assignment later, this is not the case when priv->dma_cap.addr64 > 32 as \"des\" is offset by proto_hdr_len. This causes problems such as: dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed and with DMA_API_DEBUG enabled: DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes] Fix this by maintaining \"des\" as the original DMA cookie, and use tso_des to pass the offset DMA cookie to stmmac_tso_allocator(). Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/", "cve_priority": "medium", "cve_public_date": "2024-12-29 09:15:00 UTC" }, { "cve": "CVE-2024-41079", "url": "https://ubuntu.com/security/CVE-2024-41079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: always initialize cqe.result The spec doesn't mandate that the first two double words (aka results) for the command queue entry need to be set to 0 when they are not used (not specified). Though, the target implemention returns 0 for TCP and FC but not for RDMA. Let's make RDMA behave the same and thus explicitly initializing the result field. This prevents leaking any data from the stack.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2023-53545", "url": "https://ubuntu.com/security/CVE-2023-53545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: unmap and remove csa_va properly Root PD BO should be reserved before unmap and remove a bo_va from VM otherwise lockdep will complain. v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian) [14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu] [14616.937096] Call Trace: [14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu] [14616.937187] drm_file_free+0x1d6/0x300 [drm] [14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm] [14616.937220] drm_release+0x5e/0x100 [drm] [14616.937234] __fput+0x9f/0x280 [14616.937239] ____fput+0xe/0x20 [14616.937241] task_work_run+0x61/0x90 [14616.937246] exit_to_user_mode_prepare+0x215/0x220 [14616.937251] syscall_exit_to_user_mode+0x2a/0x60 [14616.937254] do_syscall_64+0x48/0x90 [14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd", "cve_priority": "medium", "cve_public_date": "2025-10-04 16:15:00 UTC" }, { "cve": "CVE-2025-68239", "url": "https://ubuntu.com/security/CVE-2025-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: restore write access before closing files opened by open_exec() bm_register_write() opens an executable file using open_exec(), which internally calls do_open_execat() and denies write access on the file to avoid modification while it is being executed. However, when an error occurs, bm_register_write() closes the file using filp_close() directly. This does not restore the write permission, which may cause subsequent write operations on the same file to fail. Fix this by calling exe_file_allow_write_access() before filp_close() to restore the write permission properly.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-38659", "url": "https://ubuntu.com/security/CVE-2025-38659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: No more self recovery When a node withdraws and it turns out that it is the only node that has the filesystem mounted, gfs2 currently tries to replay the local journal to bring the filesystem back into a consistent state. Not only is that a very bad idea, it has also never worked because gfs2_recover_func() will refuse to do anything during a withdraw. However, before even getting to this point, gfs2_recover_func() dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free before commit 04133b607a78 (\"gfs2: Prevent double iput for journal on error\") and is a NULL pointer dereference since then. Simply get rid of self recovery to fix that.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2022-49961", "url": "https://ubuntu.com/security/CVE-2022-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg->precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored state. To show a concrete example of the problem: 0000000000000000 : 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 10: r2 = -1 0000000000000058 : 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit 00000000000000b8 : 23: w0 = 0 24: exit For the first case, the single line execution's exploration will prune the search at insn 14 for the branch insn 9's second leg as it will be verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will always be 0 so at runtime we don't get error for being greater than UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just sees reg->precise as false for both r2 registers in both states, hence considers them equal for purposes of states_equal. If we propagated precise markers using the backtracking support, we would use the precise marking to then ensure that old r2 (UINT_MAX) was within the new r2 (1) and this would never be true, so the verification would rightfully fail. The end result is that the out of bounds access at instruction 19 would be permitted without this fix. Note that reg->precise is always set to true when user does not have CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static or global functions)), hence this is only a problem when precision marks need to be explicitly propagated (i.e. privileged users with CAP_BPF). A simplified test case has been included in the next patch to prevent future regressions.", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2024-47809", "url": "https://ubuntu.com/security/CVE-2024-47809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix possible lkb_resource null dereference This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded. The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference. In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.", "cve_priority": "medium", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2025-38250", "url": "https://ubuntu.com/security/CVE-2025-38250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix use-after-free in vhci_flush() syzbot reported use-after-free in vhci_flush() without repro. [0] From the splat, a thread close()d a vhci file descriptor while its device was being used by iotcl() on another thread. Once the last fd refcnt is released, vhci_release() calls hci_unregister_dev(), hci_free_dev(), and kfree() for struct vhci_data, which is set to hci_dev->dev->driver_data. The problem is that there is no synchronisation after unlinking hdev from hci_dev_list in hci_unregister_dev(). There might be another thread still accessing the hdev which was fetched before the unlink operation. We can use SRCU for such synchronisation. Let's run hci_dev_reset() under SRCU and wait for its completion in hci_unregister_dev(). Another option would be to restore hci_dev->destruct(), which was removed in commit 587ae086f6e4 (\"Bluetooth: Remove unused hci-destruct cb\"). However, this would not be a good solution, as we should not run hci_unregister_dev() while there are in-flight ioctl() requests, which could lead to another data-race KCSAN splat. Note that other drivers seem to have the same problem, for exmaple, virtbt_remove(). [0]: BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718 CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name ---truncated---", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2026-43281", "url": "https://ubuntu.com/security/CVE-2026-43281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate() Although it is guided that `#mbox-cells` must be at least 1, there are many instances of `#mbox-cells = <0>;` in the device tree. If that is the case and the corresponding mailbox controller does not provide `fw_xlate` and of_xlate` function pointers, `fw_mbox_index_xlate()` will be used by default and out-of-bounds accesses could occur due to lack of bounds check in that function.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23157", "url": "https://ubuntu.com/security/CVE-2026-23157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not strictly require dirty metadata threshold for metadata writepages [BUG] There is an internal report that over 1000 processes are waiting at the io_schedule_timeout() of balance_dirty_pages(), causing a system hang and trigger a kernel coredump. The kernel is v6.4 kernel based, but the root problem still applies to any upstream kernel before v6.18. [CAUSE] From Jan Kara for his wisdom on the dirty page balance behavior first. This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB. Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there's dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying. When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit. So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in that cgroup. So that means the only way to reduce the dirty pages of that cgroup is to writeback the dirty pages of btrfs btree inode, and only after that those processes can exit balance_dirty_pages(). Now back to the btrfs part, btree_writepages() is responsible for writing back dirty btree inode pages. The problem here is, there is a btrfs internal threshold that if the btree inode's dirty bytes are below the 32M threshold, it will not do any writeback. This behavior is to batch as much metadata as possible so we won't write back those tree blocks and then later re-COW them again for another modification. This internal 32MiB is higher than the existing dirty page size (28MiB), meaning no writeback will happen, causing a deadlock between btrfs and cgroup: - Btrfs doesn't want to write back btree inode until more dirty pages - Cgroup/MM doesn't want more dirty pages for btrfs btree inode Thus any process touching that btree inode is put into sleep until the number of dirty pages is reduced. Thanks Jan Kara a lot for the analysis of the root cause. [ENHANCEMENT] Since kernel commit b55102826d7d (\"btrfs: set AS_KERNEL_FILE on the btree_inode\"), btrfs btree inode pages will only be charged to the root cgroup which should have a much larger limit than btrfs' 32MiB threshold. So it should not affect newer kernels. But for all current LTS kernels, they are all affected by this problem, and backporting the whole AS_KERNEL_FILE may not be a good idea. Even for newer kernels I still think it's a good idea to get rid of the internal threshold at btree_writepages(), since for most cases cgroup/MM has a better view of full system memory usage than btrfs' fixed threshold. For internal callers using btrfs_btree_balance_dirty() since that function is already doing internal threshold check, we don't need to bother them. But for external callers of btree_writepages(), just respect their requests and write back whatever they want, ignoring the internal btrfs threshold to avoid such deadlock on btree inode dirty page balancing.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23141", "url": "https://ubuntu.com/security/CVE-2026-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: check for inline extents in range_is_hole_in_parent() Before accessing the disk_bytenr field of a file extent item we need to check if we are dealing with an inline extent. This is because for inline extents their data starts at the offset of the disk_bytenr field. So accessing the disk_bytenr means we are accessing inline data or in case the inline data is less than 8 bytes we can actually cause an invalid memory access if this inline extent item is the first item in the leaf or access metadata from other items.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-40005", "url": "https://ubuntu.com/security/CVE-2025-40005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: Implement refcount to handle unbind during busy driver support indirect read and indirect write operation with assumption no force device removal(unbind) operation. However force device removal(removal) is still available to root superuser. Unbinding driver during operation causes kernel crash. This changes ensure driver able to handle such operation for indirect read and indirect write by implementing refcount to track attached devices to the controller and gracefully wait and until attached devices remove operation completed before proceed with removal operation.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2023-53629", "url": "https://ubuntu.com/security/CVE-2023-53629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: dlm: fix use after free in midcomms commit While working on processing dlm message in softirq context I experienced the following KASAN use-after-free warning: [ 151.760477] ================================================================== [ 151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347 [ 151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828 [ 151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014 [ 151.768726] Call Trace: [ 151.769277] [ 151.769748] dump_stack_lvl+0x5b/0x86 [ 151.770556] print_report+0x180/0x4c8 [ 151.771378] ? kasan_complete_mode_report_info+0x7c/0x1e0 [ 151.772241] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.773069] kasan_report+0x93/0x1a0 [ 151.773668] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.774514] __asan_load4+0x7e/0xa0 [ 151.775089] dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.775890] ? create_message.isra.29.constprop.64+0x57/0xc0 [ 151.776770] send_common+0x19f/0x1b0 [ 151.777342] ? remove_from_waiters+0x60/0x60 [ 151.778017] ? lock_downgrade+0x410/0x410 [ 151.778648] ? __this_cpu_preempt_check+0x13/0x20 [ 151.779421] ? rcu_lockdep_current_cpu_online+0x88/0xc0 [ 151.780292] _convert_lock+0x46/0x150 [ 151.780893] convert_lock+0x7b/0xc0 [ 151.781459] dlm_lock+0x3ac/0x580 [ 151.781993] ? 0xffffffffc0540000 [ 151.782522] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.783379] ? dlm_scan_rsbs+0xa70/0xa70 [ 151.784003] ? preempt_count_sub+0xd6/0x130 [ 151.784661] ? is_module_address+0x47/0x70 [ 151.785309] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.786166] ? 0xffffffffc0540000 [ 151.786693] ? lockdep_init_map_type+0xc3/0x360 [ 151.787414] ? 0xffffffffc0540000 [ 151.787947] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.789004] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.789858] ? 0xffffffffc0540000 [ 151.790392] ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture] [ 151.791347] ? delay_tsc+0x94/0xc0 [ 151.791898] torture_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.792735] ? torture_start+0x30/0x30 [dlm_locktorture] [ 151.793606] lock_torture+0x177/0x270 [dlm_locktorture] [ 151.794448] ? torture_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture] [ 151.795539] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.796476] ? do_raw_spin_lock+0x11e/0x1e0 [ 151.797152] ? mark_held_locks+0x34/0xb0 [ 151.797784] ? _raw_spin_unlock_irqrestore+0x30/0x70 [ 151.798581] ? __kthread_parkme+0x79/0x110 [ 151.799246] ? trace_preempt_on+0x2a/0xf0 [ 151.799902] ? __kthread_parkme+0x79/0x110 [ 151.800579] ? preempt_count_sub+0xd6/0x130 [ 151.801271] ? __kasan_check_read+0x11/0x20 [ 151.801963] ? __kthread_parkme+0xec/0x110 [ 151.802630] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.803569] kthread+0x192/0x1d0 [ 151.804104] ? kthread_complete_and_exit+0x30/0x30 [ 151.804881] ret_from_fork+0x1f/0x30 [ 151.805480] [ 151.806111] Allocated by task 1347: [ 151.806681] kasan_save_stack+0x26/0x50 [ 151.807308] kasan_set_track+0x25/0x30 [ 151.807920] kasan_save_alloc_info+0x1e/0x30 [ 151.808609] __kasan_slab_alloc+0x63/0x80 [ 151.809263] kmem_cache_alloc+0x1ad/0x830 [ 151.809916] dlm_allocate_mhandle+0x17/0x20 [ 151.810590] dlm_midcomms_get_mhandle+0x96/0x260 [ 151.811344] _create_message+0x95/0x180 [ 151.811994] create_message.isra.29.constprop.64+0x57/0xc0 [ 151.812880] send_common+0x129/0x1b0 [ 151.813467] _convert_lock+0x46/0x150 [ 151.814074] convert_lock+0x7b/0xc0 [ 151.814648] dlm_lock+0x3ac/0x580 [ 151.815199] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.816258] torture_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.817129] lock_t ---truncated---", "cve_priority": "high", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2025-71221", "url": "https://ubuntu.com/security/CVE-2025-71221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue() Add proper locking in mmp_pdma_residue() to prevent use-after-free when accessing descriptor list and descriptor contents. The race occurs when multiple threads call tx_status() while the tasklet on another CPU is freeing completed descriptors: CPU 0 CPU 1 ----- ----- mmp_pdma_tx_status() mmp_pdma_residue() -> NO LOCK held list_for_each_entry(sw, ..) DMA interrupt dma_do_tasklet() -> spin_lock(&desc_lock) list_move(sw->node, ...) spin_unlock(&desc_lock) | dma_pool_free(sw) <- FREED! -> access sw->desc <- UAF! This issue can be reproduced when running dmatest on the same channel with multiple threads (threads_per_chan > 1). Fix by protecting the chain_running list iteration and descriptor access with the chan->desc_lock spinlock.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23204", "url": "https://ubuntu.com/security/CVE-2026-23204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: use skb_header_pointer_careful() skb_header_pointer() does not fully validate negative @offset values. Use skb_header_pointer_careful() instead. GangMin Kim provided a report and a repro fooling u32_classify(): BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0 net/sched/cls_u32.c:221", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-71161", "url": "https://ubuntu.com/security/CVE-2025-71161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: disable recursive forward error correction There are two problems with the recursive correction: 1. It may cause denial-of-service. In fec_read_bufs, there is a loop that has 253 iterations. For each iteration, we may call verity_hash_for_block recursively. There is a limit of 4 nested recursions - that means that there may be at most 253^4 (4 billion) iterations. Red Hat QE team actually created an image that pushes dm-verity to this limit - and this image just makes the udev-worker process get stuck in the 'D' state. 2. It doesn't work. In fec_read_bufs we store data into the variable \"fio->bufs\", but fio bufs is shared between recursive invocations, if \"verity_hash_for_block\" invoked correction recursively, it would overwrite partially filled fio->bufs.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2022-50552", "url": "https://ubuntu.com/security/CVE-2022-50552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: use quiesced elevator switch when reinitializing queues The hctx's run_work may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally. nvme nvme0: resetting controller nvme nvme0: 32/0/0 default/read/poll queues BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:kyber_has_work+0x29/0x70 ... Call Trace: __blk_mq_do_dispatch_sched+0x83/0x2b0 __blk_mq_sched_dispatch_requests+0x12e/0x170 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x2b/0x50 process_one_work+0x1ef/0x380 worker_thread+0x2d/0x3e0", "cve_priority": "low", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2024-36922", "url": "https://ubuntu.com/security/CVE-2024-36922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: read txq->read_ptr under lock If we read txq->read_ptr without lock, we can read the same value twice, then obtain the lock, and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in the WARN_ONCE() a little later. Fix that by reading txq->read_ptr under lock.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2024-53221", "url": "https://ubuntu.com/security/CVE-2024-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix null-ptr-deref in f2fs_submit_page_bio() There's issue as follows when concurrently installing the f2fs.ko module and mounting the f2fs file system: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs] Call Trace: f2fs_submit_page_bio+0x126/0x8b0 [f2fs] __get_meta_page+0x1d4/0x920 [f2fs] get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs] validate_checkpoint+0xac/0x290 [f2fs] f2fs_get_valid_checkpoint+0x207/0x950 [f2fs] f2fs_fill_super+0x1007/0x39b0 [f2fs] mount_bdev+0x183/0x250 legacy_get_tree+0xf4/0x1e0 vfs_get_tree+0x88/0x340 do_new_mount+0x283/0x5e0 path_mount+0x2b2/0x15b0 __x64_sys_mount+0x1fe/0x270 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Above issue happens as the biset of the f2fs file system is not initialized before register \"f2fs_fs_type\". To address above issue just register \"f2fs_fs_type\" at the last in init_f2fs_fs(). Ensure that all f2fs file system resources are initialized.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-56657", "url": "https://ubuntu.com/security/CVE-2024-56657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Avoid WARN() for symlink errors Using WARN() for showing the error of symlink creations don't give more information than telling that something goes wrong, since the usual code path is a lregister callback from each control element creation. More badly, the use of WARN() rather confuses fuzzer as if it were serious issues. This patch downgrades the warning messages to use the normal dev_err() instead of WARN(). For making it clearer, add the function name to the prefix, too.", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2022-49803", "url": "https://ubuntu.com/security/CVE-2022-49803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Fix memory leak of nsim_dev->fa_cookie kmemleak reports this issue: unreferenced object 0xffff8881bac872d0 (size 8): comm \"sh\", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie .. nsim_drv_remove() The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To fix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove().", "cve_priority": "medium", "cve_public_date": "2025-05-01 15:16:00 UTC" }, { "cve": "CVE-2022-50116", "url": "https://ubuntu.com/security/CVE-2022-50116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix deadlock and link starvation in outgoing data path The current implementation queues up new control and user packets as needed and processes this queue down to the ldisc in the same code path. That means that the upper and the lower layer are hard coupled in the code. Due to this deadlocks can happen as seen below while transmitting data, especially during ldisc congestion. Furthermore, the data channels starve the control channel on high transmission load on the ldisc. Introduce an additional control channel data queue to prevent timeouts and link hangups during ldisc congestion. This is being processed before the user channel data queue in gsm_data_kick(), i.e. with the highest priority. Put the queue to ldisc data path into a workqueue and trigger it whenever new data has been put into the transmission queue. Change gsm_dlci_data_sweep() accordingly to fill up the transmission queue until TX_THRESH_HI. This solves the locking issue, keeps latency low and provides good performance on high data load. Note that now all packets from a DLCI are removed from the internal queue if the associated DLCI was closed. This ensures that no data is sent by the introduced write task to an already closed DLCI. BUG: spinlock recursion on CPU#0, test_v24_loop/124 lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0 CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x34/0x44 do_raw_spin_lock+0x76/0xa0 _raw_spin_lock_irqsave+0x72/0x80 uart_write_room+0x3b/0xc0 gsm_data_kick+0x14b/0x240 [n_gsm] gsmld_write_wakeup+0x35/0x70 [n_gsm] tty_wakeup+0x53/0x60 tty_port_default_wakeup+0x1b/0x30 serial8250_tx_chars+0x12f/0x220 serial8250_handle_irq.part.0+0xfe/0x150 serial8250_default_handle_irq+0x48/0x80 serial8250_interrupt+0x56/0xa0 __handle_irq_event_percpu+0x78/0x1f0 handle_irq_event+0x34/0x70 handle_fasteoi_irq+0x90/0x1e0 __common_interrupt+0x69/0x100 common_interrupt+0x48/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:__do_softirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00 RSP: 0018:ffffc90000003f98 EFLAGS: 00000286 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7 RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? __do_softirq+0x73/0x34e irq_exit_rcu+0xb5/0x100 common_interrupt+0xa4/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50 Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 3d 97 33 ff 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44 RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? _raw_spin_unlock_irqrestore+0x23/0x50 gsmtty_write+0x65/0x80 [n_gsm] n_tty_write+0x33f/0x530 ? swake_up_all+0xe0/0xe0 file_tty_write.constprop.0+0x1b1/0x320 ? n_tty_flush_buffer+0xb0/0xb0 new_sync_write+0x10c/0x190 vfs_write+0x282/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f3e5e35c15c Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2026-31586", "url": "https://ubuntu.com/security/CVE-2026-31586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: blk-cgroup: fix use-after-free in cgwb_release_workfn() cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) ** Stack based on commit 66672af7a095 (\"Add linux-next specific files for 20260410\") I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh (The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.) Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31598", "url": "https://ubuntu.com/security/CVE-2026-31598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible deadlock between unlink and dio_end_io_write ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key. Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir \t ocfs2_expand_inline_dir \t down_write(&oi->ip_alloc_sem) <- Lock B Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode) Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31642", "url": "https://ubuntu.com/security/CVE-2026-31642", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call removal to use RCU safe deletion Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop. This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by: Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that. rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31664", "url": "https://ubuntu.com/security/CVE-2026-31664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear trailing padding in build_polexpire() build_expire() clears the trailing padding bytes of struct xfrm_user_expire after setting the hard field via memset_after(), but the analogous function build_polexpire() does not do this for struct xfrm_user_polexpire. The padding bytes after the __u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners, leaking kernel heap memory contents. Add the missing memset_after() call, matching build_expire().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43075", "url": "https://ubuntu.com/security/CVE-2026-43075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix out-of-bounds write in ocfs2_write_end_inline KASAN reports a use-after-free write of 4086 bytes in ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF. The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk id_count field to determine whether a write fits in inline data. On a corrupted filesystem, id_count can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer. Call trace (crash path): vfs_copy_file_range (fs/read_write.c:1634) do_splice_direct splice_direct_to_actor iter_file_splice_write ocfs2_file_write_iter generic_perform_write ocfs2_write_end ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949) ocfs2_write_end_inline (fs/ocfs2/aops.c:1915) memcpy_from_folio <-- KASAN: write OOB So add id_count upper bound check in ocfs2_validate_inode_block() to alongside the existing i_size check to fix it.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43076", "url": "https://ubuntu.com/security/CVE-2026-43076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate inline data i_size during inode read When reading an inode from disk, ocfs2_validate_inode_block() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's i_size can exceed the actual inline data capacity (id_count). This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory. In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry() Fix by adding a validation check in ocfs2_validate_inode_block() to ensure inodes with inline data have i_size <= id_count. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-23444", "url": "https://ubuntu.com/security/CVE-2026-23444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do. Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free. Document the skb ownership guarantee in the function's kdoc.", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2025-38710", "url": "https://ubuntu.com/security/CVE-2025-38710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Validate i_depth for exhash directories A fuzzer test introduced corruption that ends up with a depth of 0 in dir_e_read(), causing an undefined shift by 32 at: index = hash >> (32 - dip->i_depth); As calculated in an open-coded way in dir_make_exhash(), the minimum depth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 is invalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time. So we can avoid the undefined behaviour by checking for depth values lower than the minimum in gfs2_dinode_in(). Values greater than the maximum are already being checked for there. Also switch the calculation in dir_make_exhash() to use ilog2() to clarify how the depth is calculated. Tested with the syzkaller repro.c and xfstests '-g quick'.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2026-23442", "url": "https://ubuntu.com/security/CVE-2026-23442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: add NULL checks for idev in SRv6 paths __in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER). Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31594", "url": "https://ubuntu.com/security/CVE-2026-31594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to perform later. This leads to an oops when .allow_link fails or when .drop_link is performed. The following is an example oops of the former case: Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pci_epc_remove_epf+0x78/0xe0 (P) pci_primary_epc_epf_link+0x88/0xa8 configfs_symlink+0x1f4/0x5a0 vfs_symlink+0x134/0x1d8 do_symlinkat+0x88/0x138 __arm64_sys_symlinkat+0x74/0xe0 [...] Remove the helper, and drop pci_epc_put(). EPC device refcounting is tied to the configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2022-50073", "url": "https://ubuntu.com/security/CVE-2022-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null Fixes a NULL pointer derefence bug triggered from tap driver. When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null (in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb) virtio_net_hdr_to_skb calls dev_parse_header_protocol which needs skb->dev field to be valid. The line that trigers the bug is in dev_parse_header_protocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->header_ops || !dev->header_ops->parse_protocol) 22e1: mov 0x10(%rbx),%rax 22e5:\t mov 0x230(%rax),%rax Setting skb->dev before the call in tap.c fixes the issue. BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tap_get_user+0x3f1/0x540 [tap] tap_sendmsg+0x56/0x362 [tap] ? get_tx_bufs+0xc2/0x1e0 [vhost_net] handle_tx_copy+0x114/0x670 [vhost_net] handle_tx+0xb0/0xe0 [vhost_net] handle_tx_kick+0x15/0x20 [vhost_net] vhost_worker+0x7b/0xc0 [vhost] ? vhost_vring_call_reset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2026-31576", "url": "https://ubuntu.com/security/CVE-2026-31576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: hackrf: fix to not free memory after the device is registered in hackrf_probe() In hackrf driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open hackrf fd \t\t\t\t\t\t.... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... \t\t\t\t\t\tsys_ioctl(fd, ...); \t\t\t\t\t\t v4l2_ioctl(); \t\t\t\t\t\t video_is_registered() // UAF!! \t\t\t\t\t\t.... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t v4l2_release() // UAF!! \t\t\t\t\t\t hackrf_video_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked. However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver's release() is invoked. Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven't been released yet. And since release() free memory too, race to use-after-free and double-free vuln occur. To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43058", "url": "https://ubuntu.com/security/CVE-2026-43058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix pass-by-value structs causing MSAN warnings vidtv_ts_null_write_into() and vidtv_ts_pcr_write_into() take their argument structs by value, causing MSAN to report uninit-value warnings. While only vidtv_ts_null_write_into() has triggered a report so far, both functions share the same issue. Fix by passing both structs by const pointer instead, avoiding the stack copy of the struct along with its MSAN shadow and origin metadata. The functions do not modify the structs, which is enforced by the const qualifier.", "cve_priority": "medium", "cve_public_date": "2026-05-02 07:16:00 UTC" }, { "cve": "CVE-2026-31577", "url": "https://ubuntu.com/security/CVE-2026-31577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map The DAT inode's btree node cache (i_assoc_inode) is initialized lazily during btree operations. However, nilfs_mdt_save_to_shadow_map() assumes i_assoc_inode is already initialized when copying dirty pages to the shadow map during GC. If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before any btree operation has occurred on the DAT inode, i_assoc_inode is NULL leading to a general protection fault. Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always initialized before any GC operation can use it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31578", "url": "https://ubuntu.com/security/CVE-2026-31578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: as102: fix to not free memory after the device is registered in as102_usb_probe() In as102_usb driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open as102 fd \t\t\t\t\t\t.... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t as102_release() // UAF!! \t\t\t\t\t\t as102_usb_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a USB character device registered with usb_register_dev() is later unregistered (via usb_deregister_dev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked. In as102, as102_usb_probe() calls usb_register_dev() and then, on an error path, does usb_deregister_dev() and frees as102_dev_t right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102_release() --> as102_usb_release() and access or free as102_dev_t again, occur a race to use-after-free and double-free vuln. The fix is to never kfree(as102_dev_t) directly once usb_register_dev() has succeeded. After deregistration, defer freeing memory to .release(). In other words, let release() perform the last kfree when the final open FD is closed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31580", "url": "https://ubuntu.com/security/CVE-2026-31580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bcache: fix cached_dev.sb_bio use-after-free and crash In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention: ``` [6888366.280350] Call Trace: [6888366.280452] blk_update_request+0x14e/0x370 [6888366.280561] blk_mq_end_request+0x1a/0x130 [6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd] [6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd] [6888366.280903] __complete_request+0x22/0x70 [libceph] [6888366.281032] osd_dispatch+0x15e/0xb40 [libceph] [6888366.281164] ? inet_recvmsg+0x5b/0xd0 [6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph] [6888366.281405] ceph_con_process_message+0x79/0x140 [libceph] [6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph] [6888366.281661] ceph_con_workfn+0x329/0x680 [libceph] ``` After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped. Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio. This patch hopes to wait for sb_write to complete in cached_dev_free. It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31581", "url": "https://ubuntu.com/security/CVE-2026-31581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: fix use-after-free on disconnect In usb6fire_chip_abort(), the chip struct is allocated as the card's private data (via snd_card_new with sizeof(struct sfire_chip)). When snd_card_free_when_closed() is called and no file handles are open, the card and embedded chip are freed synchronously. The subsequent chip->card = NULL write then hits freed slab memory. Call trace: usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline] usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953 Fix by moving the card lifecycle out of usb6fire_chip_abort() and into usb6fire_chip_disconnect(). The card pointer is saved in a local before any teardown, snd_card_disconnect() is called first to prevent new opens, URBs are aborted while chip is still valid, and snd_card_free_when_closed() is called last so chip is never accessed after the card may be freed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31583", "url": "https://ubuntu.com/security/CVE-2026-31583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free in em28xx_v4l2_open() em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock, creating a race with em28xx_v4l2_init()'s error path and em28xx_v4l2_fini(), both of which free the em28xx_v4l2 struct and set dev->v4l2 to NULL under dev->lock. This race leads to two issues: - use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler, since the video_device is embedded in the freed em28xx_v4l2 struct. - NULL pointer dereference in em28xx_resolution_set() when accessing v4l2->norm, since dev->v4l2 has been set to NULL. Fix this by moving the mutex_lock() before the dev->v4l2 read and adding a NULL check for dev->v4l2 under the lock.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31585", "url": "https://ubuntu.com/security/CVE-2026-31585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix nfeeds state corruption on start_streaming failure syzbot reported a memory leak in vidtv_psi_service_desc_init [1]. When vidtv_start_streaming() fails inside vidtv_start_feed(), the nfeeds counter is left incremented even though no feed was actually started. This corrupts the driver state: subsequent start_feed calls see nfeeds > 1 and skip starting the mux, while stop_feed calls eventually try to stop a non-existent stream. This state corruption can also lead to memory leaks, since the mux and channel resources may be partially allocated during a failed start_streaming but never cleaned up, as the stop path finds dvb->streaming == false and returns early. Fix by decrementing nfeeds back when start_streaming fails, keeping the counter in sync with the actual number of active feeds. [1] BUG: memory leak unreferenced object 0xffff888145b50820 (size 32): comm \"syz.0.17\", pid 6068, jiffies 4294944486 backtrace (crc 90a0c7d4): vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31686", "url": "https://ubuntu.com/security/CVE-2026-31686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/kasan: fix double free for kasan pXds kasan_free_pxd() assumes the page table is always struct page aligned. But that's not always the case for all architectures. E.g. In case of powerpc with 64K pagesize, PUD table (of size 4096) comes from slab cache named pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's just directly pass the start of the pxd table which is passed as the 1st argument. This fixes the below double free kasan issue seen with PMEM: radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages ================================================================== BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20 Free of addr c0000003c38e0000 by task ndctl/2164 CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeries Call Trace: dump_stack_lvl+0x88/0xc4 (unreliable) print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140 kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec ---- interrupt: 3000 at 0x7fff93b3d3f4 NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000 REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392) MSR: 800000000280f033 CR: 48888208 XER: 00000000 <...> NIP [00007fff93b3d3f4] 0x7fff93b3d3f4 LR [00007fff93b3d3f4] 0x7fff93b3d3f4 ---- interrupt: 3000 The buggy address belongs to the object at c0000003c38e0000 which belongs to the cache pgtable-2^9 of size 4096 The buggy address is located 0 bytes inside of 4096-byte region [c0000003c38e0000, c0000003c38e1000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:c0000003bfd63e01 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) page_type: f5(slab) raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected [ 138.953636] [ T2164] Memory state around the buggy address: [ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953669] [ T2164] ^ [ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953692] [ T2164] ================================================================== [ 138.953701] [ T2164] Disabling lock debugging due to kernel taint", "cve_priority": "low", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2026-31588", "url": "https://ubuntu.com/security/CVE-2026-31588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use scratch field in MMIO fragment to hold small write values When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value. This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, *and* both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable. The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by overwrite the data value with garbage. Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *al ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31630", "url": "https://ubuntu.com/security/CVE-2026-31630", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: proc: size address buffers for %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with \"%pISpc\". That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23399", "url": "https://ubuntu.com/security/CVE-2026-23399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nf_tables: nft_dynset: fix possible stateful expression memleak in error path If cloning the second stateful expression in the element via GFP_ATOMIC fails, then the first stateful expression remains in place without being released.   unreferenced object (percpu) 0x607b97e9cab8 (size 16):     comm \"softirq\", pid 0, jiffies 4294931867     hex dump (first 16 bytes on cpu 3):       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     backtrace (crc 0):       pcpu_alloc_noprof+0x453/0xd80       nft_counter_clone+0x9c/0x190 [nf_tables]       nft_expr_clone+0x8f/0x1b0 [nf_tables]       nft_dynset_new+0x2cb/0x5f0 [nf_tables]       nft_rhash_update+0x236/0x11c0 [nf_tables]       nft_dynset_eval+0x11f/0x670 [nf_tables]       nft_do_chain+0x253/0x1700 [nf_tables]       nft_do_chain_ipv4+0x18d/0x270 [nf_tables]       nf_hook_slow+0xaa/0x1e0       ip_local_deliver+0x209/0x330", "cve_priority": "medium", "cve_public_date": "2026-03-28 08:15:00 UTC" }, { "cve": "CVE-2024-35865", "url": "https://ubuntu.com/security/CVE-2024-35865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.", "cve_priority": "medium", "cve_public_date": "2024-05-19 09:15:00 UTC" }, { "cve": "CVE-2026-31590", "url": "https://ubuntu.com/security/CVE-2026-31590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION Drop the WARN in sev_pin_memory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing: struct kvm_enc_region range = { .addr = 0, .size = -1ul, }; __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range); Note, the checks in sev_mem_enc_register_region() that presumably exist to verify the incoming address+size are completely worthless, as both \"addr\" and \"size\" are u64s and SEV is 64-bit only, i.e. they _can't_ be greater than ULONG_MAX. That wart will be cleaned up in the near future. \tif (range->addr > ULONG_MAX || range->size > ULONG_MAX) \t\treturn -EINVAL; Opportunistically add a comment to explain why the code calculates the number of pages the \"hard\" way, e.g. instead of just shifting @ulen.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31596", "url": "https://ubuntu.com/security/CVE-2026-31596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle invalid dinode in ocfs2_group_extend [BUG] kernel BUG at fs/ocfs2/resize.c:308! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308 Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe Call Trace: ... ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... [CAUSE] ocfs2_group_extend() assumes that the global bitmap inode block returned from ocfs2_inode_lock() has already been validated and BUG_ONs when the signature is not a dinode. That assumption is too strong for crafted filesystems because the JBD2-managed buffer path can bypass structural validation and return an invalid dinode to the resize ioctl. [FIX] Validate the dinode explicitly in ocfs2_group_extend(). If the global bitmap buffer does not contain a valid dinode, report filesystem corruption with ocfs2_error() and fail the resize operation instead of crashing the kernel.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31597", "url": "https://ubuntu.com/security/CVE-2026-31597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY, as documented in mm/filemap.c: \"If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap().\" When this happens, a concurrent munmap() can call remove_vma() and free the vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call dereferences it -- a use-after-free. Fix this by saving ip_blkno as a plain integer before calling filemap_fault(), and removing vma from the trace event. Since ip_blkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31599", "url": "https://ubuntu.com/security/CVE-2026-31599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections syzbot reported a general protection fault in vidtv_psi_desc_assign [1]. vidtv_psi_pmt_stream_init() can return NULL on memory allocation failure, but vidtv_channel_pmt_match_sections() does not check for this. When tail is NULL, the subsequent call to vidtv_psi_desc_assign(&tail->descriptor, desc) dereferences a NULL pointer offset, causing a general protection fault. Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean up the already-allocated stream chain and return. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629 Call Trace: vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline] vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479 vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31602", "url": "https://ubuntu.com/security/CVE-2026-31602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Limit PTP to a single page Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic. ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ct_vm_map() tries to access beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count remain unchanged.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31603", "url": "https://ubuntu.com/security/CVE-2026-31603", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: sm750fb: fix division by zero in ps_to_hz() ps_to_hz() is called from hw_sm750_crtc_set_mode() without validating that pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO causes a division by zero. Fix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent with other framebuffer drivers.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31605", "url": "https://ubuntu.com/security/CVE-2026-31605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31615", "url": "https://ubuntu.com/security/CVE-2026-31615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: renesas_usb3: validate endpoint index in standard request handlers The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math. This is just like what was done in commit ee0d382feb44 (\"usb: gadget: aspeed_udc: validate endpoint index for ast udc\") for the aspeed driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31616", "url": "https://ubuntu.com/security/CVE-2026-31616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete() A broken/bored/mean USB host can overflow the skb_shared_info->frags[] array on a Linux gadget exposing a Phonet function by sending an unbounded sequence of full-page OUT transfers. pn_rx_complete() finalizes the skb only when req->actual < req->length, where req->length is set to PAGE_SIZE by the gadget. If the host always sends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never be reset and each completion will add another fragment via skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17), subsequent frag stores overwrite memory adjacent to the shinfo on the heap. Drop the skb and account a length error when the frag limit is reached, matching the fix applied in t7xx by commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\").", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31617", "url": "https://ubuntu.com/security/CVE-2026-31617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb() The block_len read from the host-supplied NTB header is checked against ntb_max but has no lower bound. When block_len is smaller than opts->ndp_size, the bounds check of: \tndp_index > (block_len - opts->ndp_size) will underflow producing a huge unsigned value that ndp_index can never exceed, defeating the check entirely. The same underflow occurs in the datagram index checks against block_len - opts->dpe_size. With those checks neutered, a malicious USB host can choose ndp_index and datagram offsets that point past the actual transfer, and the skb_put_data() copies adjacent kernel memory into the network skb. Fix this by rejecting block lengths that cannot hold at least the NTB header plus one NDP. This will make block_len - opts->ndp_size and block_len - opts->dpe_size both well-defined. Commit 8d2b1a1ec9f5 (\"CDC-NCM: avoid overflow in sanity checking\") fixed a related class of issues on the host side of NCM.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31618", "url": "https://ubuntu.com/security/CVE-2026-31618", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31619", "url": "https://ubuntu.com/security/CVE-2026-31619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: fireworks: bound device-supplied status before string array lookup The status field in an EFW response is a 32-bit value supplied by the firewire device. efr_status_names[] has 17 entries so a status value outside that range goes off into the weeds when looking at the %s value. Even worse, the status could return EFR_STATUS_INCOMPLETE which is 0x80000000, and is obviously not in that array of potential strings. Fix this up by properly bounding the index against the array size and printing \"unknown\" if it's not recognized.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31622", "url": "https://ubuntu.com/security/CVE-2026-31622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: digital: Bounds check NFC-A cascade depth in SDD response handler The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3 or 4 bytes to target->nfcid1 on each round, but the number of cascade rounds is controlled entirely by the peer device. The peer sets the cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the cascade-incomplete bit in the SEL_RES (deciding whether another round follows). ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver actually enforces this. This means a malicious peer can keep the cascade running, writing past the heap-allocated nfc_target with each round. Fix this by rejecting the response when the accumulated UID would exceed the buffer. Commit e329e71013c9 (\"NFC: nci: Bounds check struct nfc_target arrays\") fixed similar missing checks against the same field on the NCI path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31623", "url": "https://ubuntu.com/security/CVE-2026-31623", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete() A malicious USB device claiming to be a CDC Phonet modem can overflow the skb_shared_info->frags[] array by sending an unbounded sequence of full-page bulk transfers. Drop the skb and increment the length error when the frag limit is reached. This matches the same fix that commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\") did for the t7xx driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31624", "url": "https://ubuntu.com/security/CVE-2026-31624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: clamp report_size in s32ton() to avoid undefined shift s32ton() shifts by n-1 where n is the field's report_size, a value that comes directly from a HID device. The HID parser bounds report_size only to <= 256, so a broken HID device can supply a report descriptor with a wide field that triggers shift exponents up to 256 on a 32-bit type when an output report is built via hid_output_field() or hid_set_field(). Commit ec61b41918587 (\"HID: core: fix shift-out-of-bounds in hid_report_raw_event\") added the same n > 32 clamp to the function snto32(), but s32ton() was never given the same fix as I guess syzbot hadn't figured out how to fuzz a device the same way. Fix this up by just clamping the max value of n, just like snto32() does.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31625", "url": "https://ubuntu.com/security/CVE-2026-31625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: alps: fix NULL pointer dereference in alps_raw_event() Commit ecfa6f34492c (\"HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them\") attempted to fix up the HID drivers that had missed the previous fix that was done in 2ff5baa9b527 (\"HID: appleir: Fix potential NULL dereference at raw event handle\"), but the alps driver was missed. Fix this up by properly checking in the hid-alps driver that it had been claimed correctly before attempting to process the raw event.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31626", "url": "https://ubuntu.com/security/CVE-2026-31626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify() Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using uninitialized data. Smatch warns that only 6 bytes are copied to this 8-byte (u64) variable, leaving the last two bytes uninitialized: drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify() warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes) Initializing the variable at the start of the function fixes this warning and ensures predictable behavior.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31627", "url": "https://ubuntu.com/security/CVE-2026-31627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: s3c24xx: check the size of the SMBUS message before using it The first byte of an i2c SMBUS message is the size, and it should be verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX before processing it. This is the same logic that was added in commit a6e04f05ce0b (\"i2c: tegra: check msg length in SMBUS block read\") to the i2c tegra driver.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31532", "url": "https://ubuntu.com/security/CVE-2026-31532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: fix ro->uniq use-after-free in raw_rcv() raw_release() unregisters raw CAN receive filters via can_rx_unregister(), but receiver deletion is deferred with call_rcu(). This leaves a window where raw_rcv() may still be running in an RCU read-side critical section after raw_release() frees ro->uniq, leading to a use-after-free of the percpu uniq storage. Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific socket destructor. can_rx_unregister() takes an extra reference to the socket and only drops it from the RCU callback, so freeing uniq from sk_destruct ensures the percpu area is not released until the relevant callbacks have drained. [mkl: applied manually]", "cve_priority": "high", "cve_public_date": "2026-04-23 12:17:00 UTC" }, { "cve": "CVE-2026-31629", "url": "https://ubuntu.com/security/CVE-2026-31629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: add missing return after LLCP_CLOSED checks In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket state is LLCP_CLOSED, the code correctly calls release_sock() and nfc_llcp_sock_put() but fails to return. Execution falls through to the remainder of the function, which calls release_sock() and nfc_llcp_sock_put() again. This results in a double release_sock() and a refcount underflow via double nfc_llcp_sock_put(), leading to a use-after-free. Add the missing return statements after the LLCP_CLOSED branches in both functions to prevent the fall-through.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31407", "url": "https://ubuntu.com/security/CVE-2026-31407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: add missing netlink policy validations Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink. These attributes are used by the kernel without any validation. Extend the netlink policies accordingly. Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-43079", "url": "https://ubuntu.com/security/CVE-2026-43079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Skip discovery table for offline dies This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0. WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore] Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at \"pmu->boxes[die] = box\" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43080", "url": "https://ubuntu.com/security/CVE-2026-43080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: Drop large packets with UDP encap syzbot reported a WARN on my patch series [1]. The actual issue is an overflow of 16-bit UDP length field, and it exists in the upstream code. My series added a debug WARN with an overflow check that exposed the issue, that's why syzbot tripped on my patches, rather than on upstream code. syzbot's repro: r0 = socket$pppl2tp(0x18, 0x1, 0x1) r1 = socket$inet6_udp(0xa, 0x2, 0x0) connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c) connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\\x00', '\\xff\\xff', @empty}}}}, 0x32) writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)=\"ee\", 0x34000}], 0x1) It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP encapsulation, and l2tp_xmit_core doesn't check for overflows when it assigns the UDP length field. The value gets trimmed to 16 bites. Add an overflow check that drops oversized packets and avoids sending packets with trimmed UDP length to the wire. syzbot's stack trace (with my patch applied): len >= 65536u WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957 Modules linked in: CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline] RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline] RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327 Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f RSP: 0018:ffffc90003d67878 EFLAGS: 00010293 RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000 RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004 R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900 R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000 FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0 Call Trace: pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x503/0x550 net/socket.c:1195 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1 vfs_writev+0x33c/0x990 fs/read_write.c:1059 do_writev+0x154/0x2e0 fs/read_write.c:1105 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f636479c629 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629 RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31673", "url": "https://ubuntu.com/security/CVE-2026-31673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: read UNIX_DIAG_VFS data under unix_state_lock Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unix_release_sock() clears u->path under unix_state_lock() and drops the path reference after unlocking. Read the inode and device numbers for UNIX_DIAG_VFS while holding unix_state_lock(), then emit the netlink attribute after dropping the lock. This keeps the VFS data stable while the reply is being built.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31681", "url": "https://ubuntu.com/security/CVE-2026-31681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_multiport: validate range encoding in checkentry ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end. The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule. Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43085", "url": "https://ubuntu.com/security/CVE-2026-43085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator When batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send() appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSG_DONE message body. Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes the nfgenmsg payload via nfnl_fill_hdr(), consistent with how __build_packet_message() already constructs NFULNL_MSG_PACKET headers.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43089", "url": "https://ubuntu.com/security/CVE-2026-43089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_mapping() struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43093", "url": "https://ubuntu.com/security/CVE-2026-43093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: tighten UMEM headroom validation to account for tailroom and min frame The current headroom validation in xdp_umem_reg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skb_shared_info stored at the end of XSK frame would be corrupted. HW typically works with 128-aligned sizes so let us provide this value as bare minimum. Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43098", "url": "https://ubuntu.com/security/CVE-2026-43098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: s3fwrn5: allocate rx skb before consuming bytes s3fwrn82_uart_read() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already deliver a complete frame before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43099", "url": "https://ubuntu.com/security/CVE-2026-43099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: fix null-ptr-deref in icmp_build_probe() ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing this error pointer to dev_hold() will cause a kernel crash with null-ptr-deref. Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting \"No Such Interface\".", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43103", "url": "https://ubuntu.com/security/CVE-2026-43103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lapbether: handle NETDEV_PRE_TYPE_CHANGE lapbeth_data_transmit() expects the underlying device type to be ARPHRD_ETHER. Returning NOTIFY_BAD from lapbeth_device_event() makes sure bonding driver can not break this expectation.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31684", "url": "https://ubuntu.com/security/CVE-2026-31684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_csum: validate nested VLAN headers tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43074", "url": "https://ubuntu.com/security/CVE-2026-43074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: defer struct eventpoll free to RCU grace period In certain situations, ep_free() in eventpoll.c will kfree the epi->ep eventpoll struct while it still being used by another concurrent thread. Defer the kfree() to an RCU callback to prevent UAF.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43104", "url": "https://ubuntu.com/security/CVE-2026-43104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix a memory leak in hang state error path When vc4_save_hang_state() encounters an early return condition, it returns without freeing the previously allocated `kernel_state`, leaking memory. Add the missing kfree() calls by consolidating the early return paths into a single place.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43105", "url": "https://ubuntu.com/security/CVE-2026-43105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix memory leak of BO array in hang state The hang state's BO array is allocated separately with kzalloc() in vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the missing kfree() for the BO array before freeing the hang state struct.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43110", "url": "https://ubuntu.com/security/CVE-2026-43110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: validate bsscfg indices in IF events brcmf_fweh_handle_if_event() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check. Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array. [add missing wifi prefix]", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43111", "url": "https://ubuntu.com/security/CVE-2026-43111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: fix use-after-free in roccat_report_event roccat_report_event() iterates over the device->readers list without holding the readers_lock. This allows a concurrent roccat_release() to remove and free a reader while it's still being accessed, leading to a use-after-free. Protect the readers list traversal with the readers_lock mutex.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43112", "url": "https://ubuntu.com/security/CVE-2026-43112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath When cifs_sanitize_prepath is called with an empty string or a string containing only delimiters (e.g., \"/\"), the current logic attempts to check *(cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read. This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL. The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.", "cve_priority": "low", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43113", "url": "https://ubuntu.com/security/CVE-2026-43113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wl1251: validate packet IDs before indexing tx_frames wl1251_tx_packet_cb() uses the firmware completion ID directly to index the fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it. Reject completion IDs that fall outside wl->tx_frames[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2025-54518", "url": "https://ubuntu.com/security/CVE-2025-54518", "cve_description": "Improper isolation of shared resources within the CPU operation cache on Zen 2-based products could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation.", "cve_priority": "high", "cve_public_date": "2026-05-15 05:16:00 UTC" }, { "cve": "CVE-2026-46174", "url": "https://ubuntu.com/security/CVE-2026-46174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2025-71150", "url": "https://ubuntu.com/security/CVE-2025-71150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix refcount leak when invalid session is found on session lookup When a session is found but its state is not SMB2_SESSION_VALID, It indicates that no valid session was found, but it is missing to decrement the reference count acquired by the session lookup, which results in a reference count leak. This patch fixes the issue by explicitly calling ksmbd_user_session_put to release the reference to the session.", "cve_priority": "medium", "cve_public_date": "2026-01-23 15:16:00 UTC" }, { "cve": "CVE-2026-23395", "url": "https://ubuntu.com/security/CVE-2026-23395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ Currently the code attempts to accept requests regardless of the command identifier which may cause multiple requests to be marked as pending (FLAG_DEFER_SETUP) which can cause more than L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer causing an overflow. The spec is quite clear that the same identifier shall not be used on subsequent requests: 'Within each signaling channel a different Identifier shall be used for each successive request or indication.' https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d So this attempts to check if there are any channels pending with the same identifier and rejects if any are found.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31549", "url": "https://ubuntu.com/security/CVE-2026-31549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: cp2615: fix serial string NULL-deref at probe The cp2615 driver uses the USB device serial string as the i2c adapter name but does not make sure that the string exists. Verify that the device has a serial number before accessing it to avoid triggering a NULL-pointer dereference (e.g. with malicious devices).", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31433", "url": "https://ubuntu.com/security/CVE-2026-31433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potencial OOB in get_file_all_info() for compound requests When a compound request consists of QUERY_DIRECTORY + QUERY_INFO (FILE_ALL_INFORMATION) and the first command consumes nearly the entire max_trans_size, get_file_all_info() would blindly call smbConvertToUTF16() with PATH_MAX, causing out-of-bounds write beyond the response buffer. In get_file_all_info(), there was a missing validation check for the client-provided OutputBufferLength before copying the filename into FileName field of the smb2_file_all_info structure. If the filename length exceeds the available buffer space, it could lead to potential buffer overflows or memory corruption during smbConvertToUTF16 conversion. This calculating the actual free buffer size using smb2_calc_max_out_buf_len() and returning -EINVAL if the buffer is insufficient and updating smbConvertToUTF16 to use the actual filename length (clamped by PATH_MAX) to ensure a safe copy operation.", "cve_priority": "high", "cve_public_date": "2026-04-22 09:16:00 UTC" }, { "cve": "CVE-2026-31480", "url": "https://ubuntu.com/security/CVE-2026-31480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential deadlock in cpu hotplug with osnoise The following sequence may leads deadlock in cpu hotplug: task1 task2 task3 ----- ----- ----- mutex_lock(&interface_lock) [CPU GOING OFFLINE] cpus_write_lock(); osnoise_cpu_die(); kthread_stop(task3); wait_for_completion(); osnoise_sleep(); mutex_lock(&interface_lock); cpus_read_lock(); [DEAD LOCK] Fix by swap the order of cpus_read_lock() and mutex_lock(&interface_lock).", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31466", "url": "https://ubuntu.com/security/CVE-2026-31466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix folio isn't locked in softleaf_to_folio() On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows: \tCPU0 CPU1 deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags. This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio() because of the race between folio split and zap_nonpresent_ptes() leading to a folio incorrectly undergoing modification without a folio lock being held. This is a BUG_ON() before commit 93976a20345b (\"mm: eliminate further swapops predicates\"), which in merged in v6.19-rc1. To fix it, add missing smp_rmb() if the softleaf entry is migration entry in softleaf_to_folio() and softleaf_to_page(). [tujinjiang@huawei.com: update function name and comments]", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43054", "url": "https://ubuntu.com/security/CVE-2026-43054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Drain commands in target_reset handler tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS without draining any in-flight commands. The SCSI EH documentation (scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver has made lower layers \"forget about timed out scmds\" and is ready for new commands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug, mpi3mr) enforces this by draining or completing outstanding commands before returning SUCCESS. Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight scsi_cmnd structures for recovery commands (e.g. TUR) while the target core still has async completion work queued for the old se_cmd. The memset in queuecommand zeroes se_lun and lun_ref_active, causing transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN reference prevents transport_clear_lun_ref() from completing, hanging configfs LUN unlink forever in D-state: INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transport_clear_lun_ref+0x78/0x90 [target_core_mod] core_tpg_remove_lun+0x28/0xb0 [target_core_mod] target_fabric_port_unlink+0x50/0x60 [target_core_mod] configfs_unlink+0x156/0x1f0 [configfs] vfs_unlink+0x109/0x290 do_unlinkat+0x1d5/0x2d0 Fix this by making tcm_loop_target_reset() actually drain commands: 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that the target core knows about (those not yet CMD_T_COMPLETE). 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and flush_work() on each se_cmd — this drains any deferred completion work for commands that already had CMD_T_COMPLETE set before the TMR (which the TMR skips via __target_check_io_state()). This is the same pattern used by mpi3mr, scsi_debug, and libsas to drain outstanding commands during reset.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-23401", "url": "https://ubuntu.com/security/CVE-2026-23401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE When installing an emulated MMIO SPTE, do so *after* dropping/zapping the existing SPTE (if it's shadow-present). While commit a54aa15c6bda3 was right about it being impossible to convert a shadow-present SPTE to an MMIO SPTE due to a _guest_ write, it failed to account for writes to guest memory that are outside the scope of KVM. E.g. if host userspace modifies a shadowed gPTE to switch from a memslot to emulted MMIO and then the guest hits a relevant page fault, KVM will install the MMIO SPTE without first zapping the shadow-present SPTE. ------------[ cut here ]------------ is_shadow_present_pte(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm] Call Trace: mmu_set_spte+0x237/0x440 [kvm] ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47fa3f ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-04-01 09:16:00 UTC" }, { "cve": "CVE-2026-31454", "url": "https://ubuntu.com/security/CVE-2026-31454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: save ailp before dropping the AIL lock in push callbacks In xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the AIL lock is dropped to perform buffer IO. Once the cluster buffer no longer protects the log item from reclaim, the log item may be freed by background reclaim or the dquot shrinker. The subsequent spin_lock() call dereferences lip->li_ailp, which is a use-after-free. Fix this by saving the ailp pointer in a local variable while the AIL lock is held and the log item is guaranteed to be valid.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31446", "url": "https://ubuntu.com/security/CVE-2026-31446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in update_super_work when racing with umount Commit b98535d09179 (\"ext4: fix bug_on in start_this_handle during umount filesystem\") moved ext4_unregister_sysfs() before flushing s_sb_upd_work to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups reads during unmount. However, this introduced a use-after-free because update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which accesses the kobject's kernfs_node after it has been freed by kobject_del() in ext4_unregister_sysfs(): update_super_work ext4_put_super ----------------- -------------- ext4_unregister_sysfs(sb) kobject_del(&sbi->s_kobj) __kobject_del() sysfs_remove_dir() kobj->sd = NULL sysfs_put(sd) kernfs_put() // RCU free ext4_notify_error_sysfs(sbi) sysfs_notify(&sbi->s_kobj) kn = kobj->sd // stale pointer kernfs_get(kn) // UAF on freed kernfs_node ext4_journal_destroy() flush_work(&sbi->s_sb_upd_work) Instead of reordering the teardown sequence, fix this by making ext4_notify_error_sysfs() detect that sysfs has already been torn down by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call in that case. A dedicated mutex (s_error_notify_mutex) serializes ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs() to prevent TOCTOU races where the kobject could be deleted between the state_in_sysfs check and the sysfs_notify() call.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31450", "url": "https://ubuntu.com/security/CVE-2026-31450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: publish jinode after initialization ext4_inode_attach_jinode() publishes ei->jinode to concurrent users. It used to set ei->jinode before jbd2_journal_init_jbd_inode(), allowing a reader to observe a non-NULL jinode with i_vfs_inode still unset. The fast commit flush path can then pass this jinode to jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and may crash. Below is the crash I observe: ``` BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xas_find_marked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: filemap_get_folios_tag+0x87/0x2a0 __filemap_fdatawait_range+0x5f/0xd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? cap_safe_nice+0x37/0x70 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 filemap_fdatawait_range_keep_errors+0x12/0x40 ext4_fc_commit+0x697/0x8b0 ? ext4_file_write_iter+0x64b/0x950 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? vfs_write+0x356/0x480 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ext4_sync_file+0xf7/0x370 do_fsync+0x3b/0x80 ? syscall_trace_enter+0x108/0x1d0 __x64_sys_fdatasync+0x16/0x20 do_syscall_64+0x62/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... ``` Fix this by initializing the jbd2_inode first. Use smp_wmb() and WRITE_ONCE() to publish ei->jinode after initialization. Readers use READ_ONCE() to fetch the pointer.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31726", "url": "https://ubuntu.com/security/CVE-2026-31726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix NULL pointer dereference during unbind race Commit b81ac4395bbe (\"usb: gadget: uvc: allow for application to cleanly shutdown\") introduced two stages of synchronization waits totaling 1500ms in uvc_function_unbind() to prevent several types of kernel panics. However, this timing-based approach is insufficient during power management (PM) transitions. When the PM subsystem starts freezing user space processes, the wait_event_interruptible_timeout() is aborted early, which allows the unbind thread to proceed and nullify the gadget pointer (cdev->gadget = NULL): [ 814.123447][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind() [ 814.178583][ T3173] PM: suspend entry (deep) [ 814.192487][ T3173] Freezing user space processes [ 814.197668][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind no clean disconnect, wait for release When the PM subsystem resumes or aborts the suspend and tasks are restarted, the V4L2 release path is executed and attempts to access the already nullified gadget pointer, triggering a kernel panic: [ 814.292597][ C0] PM: pm_system_irq_wakeup: 479 triggered dhdpcie_host_wake [ 814.386727][ T3173] Restarting tasks ... [ 814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 814.404021][ T4558] pc : usb_gadget_deactivate+0x14/0xf4 [ 814.404031][ T4558] lr : usb_function_deactivate+0x54/0x94 [ 814.404078][ T4558] Call trace: [ 814.404080][ T4558] usb_gadget_deactivate+0x14/0xf4 [ 814.404083][ T4558] usb_function_deactivate+0x54/0x94 [ 814.404087][ T4558] uvc_function_disconnect+0x1c/0x5c [ 814.404092][ T4558] uvc_v4l2_release+0x44/0xac [ 814.404095][ T4558] v4l2_release+0xcc/0x130 Address the race condition and NULL pointer dereference by: 1. State Synchronization (flag + mutex) Introduce a 'func_unbound' flag in struct uvc_device. This allows uvc_function_disconnect() to safely skip accessing the nullified cdev->gadget pointer. As suggested by Alan Stern, this flag is protected by a new mutex (uvc->lock) to ensure proper memory ordering and prevent instruction reordering or speculative loads. This mutex is also used to protect 'func_connected' for consistent state management. 2. Explicit Synchronization (completion) Use a completion to synchronize uvc_function_unbind() with the uvc_vdev_release() callback. This prevents Use-After-Free (UAF) by ensuring struct uvc_device is freed after all video device resources are released.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31728", "url": "https://ubuntu.com/security/CVE-2026-31728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop A race condition between gether_disconnect() and eth_stop() leads to a NULL pointer dereference. Specifically, if eth_stop() is triggered concurrently while gether_disconnect() is tearing down the endpoints, eth_stop() attempts to access the cleared endpoint descriptor, causing the following NPE: Unable to handle kernel NULL pointer dereference Call trace: __dwc3_gadget_ep_enable+0x60/0x788 dwc3_gadget_ep_enable+0x70/0xe4 usb_ep_enable+0x60/0x15c eth_stop+0xb8/0x108 Because eth_stop() crashes while holding the dev->lock, the thread running gether_disconnect() fails to acquire the same lock and spins forever, resulting in a hardlockup: Core - Debugging Information for Hardlockup core(7) Call trace: queued_spin_lock_slowpath+0x94/0x488 _raw_spin_lock+0x64/0x6c gether_disconnect+0x19c/0x1e8 ncm_set_alt+0x68/0x1a0 composite_setup+0x6a0/0xc50 The root cause is that the clearing of dev->port_usb in gether_disconnect() is delayed until the end of the function. Move the clearing of dev->port_usb to the very beginning of gether_disconnect() while holding dev->lock. This cuts off the link immediately, ensuring eth_stop() will see dev->port_usb as NULL and safely bail out.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31721", "url": "https://ubuntu.com/security/CVE-2026-31721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: move list and spinlock inits from bind to alloc There was an issue when you did the following: - setup and bind an hid gadget - open /dev/hidg0 - use the resulting fd in EPOLL_CTL_ADD - unbind the UDC - bind the UDC - use the fd in EPOLL_CTL_DEL When CONFIG_DEBUG_LIST was enabled, a list_del corruption was reported within remove_wait_queue (via ep_remove_wait_queue). After some debugging I found out that the queues, which f_hid registers via poll_wait were the problem. These were initialized using init_waitqueue_head inside hidg_bind. So effectively, the bind function re-initialized the queues while there were still items in them. The solution is to move the initialization from hidg_bind to hidg_alloc to extend their lifetimes to the lifetime of the function instance. Additionally, I found many other possibly problematic init calls in the bind function, which I moved as well.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31670", "url": "https://ubuntu.com/security/CVE-2026-31670", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rfkill: prevent unlimited numbers of rfkill events from being created Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a \"large\" number (i.e. 1000) to prevent abuses like this.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31634", "url": "https://ubuntu.com/security/CVE-2026-31634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix reference count leak in rxrpc_server_keyring() This patch fixes a reference count leak in rxrpc_server_keyring() by checking if rx->securities is already set.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31651", "url": "https://ubuntu.com/security/CVE-2026-31651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix NULL-deref on disconnect Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31656", "url": "https://ubuntu.com/security/CVE-2026-31656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` <4> [487.221889] Workqueue: i915-unordered engine_retire [i915] <4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] Call Trace: <4> [487.222711] <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ? __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ? __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ? __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] ``` Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it. (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31658", "url": "https://ubuntu.com/security/CVE-2026-31658", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit() When dma_map_single() fails in tse_start_xmit(), the function returns NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure. Add dev_kfree_skb_any() before returning to properly free the skb.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31660", "url": "https://ubuntu.com/security/CVE-2026-31660", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: allocate rx skb before consuming bytes pn532_receive_buf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already hand a complete frame to pn533_recv_frame() before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31661", "url": "https://ubuntu.com/security/CVE-2026-31661", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: Fix dma_free_coherent() size dma_alloc_consistent() may change the size to align it. The new size is saved in alloced. Change the free size to match the allocation size.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31662", "url": "https://ubuntu.com/security/CVE-2026-31662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round. Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31665", "url": "https://ubuntu.com/security/CVE-2026-31665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: fix use-after-free in timeout object destroy nft_ct_timeout_obj_destroy() frees the timeout object with kfree() immediately after nf_ct_untimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcu_dereference() in nf_ct_timeout_data(). Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c. KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2024-56557", "url": "https://ubuntu.com/security/CVE-2024-56557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer The AD7923 was updated to support devices with 8 channels, but the size of tx_buf and ring_xfer was not increased accordingly, leading to a potential buffer overflow in ad7923_update_scan_mode().", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2024-36898", "url": "https://ubuntu.com/security/CVE-2024-36898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: fix uninitialised kfifo If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace. Initialise the kfifo in the case where the software debounce is already active.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2025-40016", "url": "https://ubuntu.com/security/CVE-2025-40016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID. In a previous attempt commit 3dd075fe8ebb (\"media: uvcvideo: Require entities to have a non-zero unique ID\"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2026-31667", "url": "https://ubuntu.com/security/CVE-2026-31667", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: uinput - fix circular locking dependency with ff-core A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller): ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex The cycle is caused by four lock acquisition paths: 1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex. 2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex. 3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex. 4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex. Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes. To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock. Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible. Lock ordering after the fix: ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31671", "url": "https://ubuntu.com/security/CVE-2026-31671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_report() struct xfrm_user_report is a __u8 proto field followed by a struct xfrm_selector which means there is three \"empty\" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31672", "url": "https://ubuntu.com/security/CVE-2026-31672", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00usb: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the USB anchor lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43336", "url": "https://ubuntu.com/security/CVE-2026-43336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: chacha: Zeroize permuted_state before it leaves scope Since the ChaCha permutation is invertible, the local variable 'permuted_state' is sufficient to compute the original 'state', and thus the key, even after the permutation has been done. While the kernel is quite inconsistent about zeroizing secrets on the stack (and some prominent userspace crypto libraries don't bother at all since it's not guaranteed to work anyway), the kernel does try to do it as a best practice, especially in cases involving the RNG. Thus, explicitly zeroize 'permuted_state' before it goes out of scope.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31695", "url": "https://ubuntu.com/security/CVE-2026-31695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free Currently we execute `SET_NETDEV_DEV(dev, &priv->lowerdev->dev)` for the virt_wifi net devices. However, unregistering a virt_wifi device in netdev_run_todo() can happen together with the device referenced by SET_NETDEV_DEV(). It can result in use-after-free during the ethtool operations performed on a virt_wifi device that is currently being unregistered. Such a net device can have the `dev.parent` field pointing to the freed memory, but ethnl_ops_begin() calls `pm_runtime_get_sync(dev->dev.parent)`. Let's remove SET_NETDEV_DEV for virt_wifi to avoid bugs like this: ================================================================== BUG: KASAN: slab-use-after-free in __pm_runtime_resume+0xe2/0xf0 Read of size 2 at addr ffff88810cfc46f8 by task pm/606 Call Trace: dump_stack_lvl+0x4d/0x70 print_report+0x170/0x4f3 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 kasan_report+0xda/0x110 ? __pm_runtime_resume+0xe2/0xf0 ? __pm_runtime_resume+0xe2/0xf0 __pm_runtime_resume+0xe2/0xf0 ethnl_ops_begin+0x49/0x270 ethnl_set_features+0x23c/0xab0 ? __pfx_ethnl_set_features+0x10/0x10 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xf/0xf0 ? local_clock+0x10/0x30 ? kasan_save_track+0x25/0x60 ? __kasan_kmalloc+0x7f/0x90 ? genl_family_rcv_msg_attrs_parse.isra.0+0x150/0x2c0 genl_family_rcv_msg_doit+0x1e7/0x2c0 ? __pfx_genl_family_rcv_msg_doit+0x10/0x10 ? __pfx_cred_has_capability.isra.0+0x10/0x10 ? stack_trace_save+0x8e/0xc0 genl_rcv_msg+0x411/0x660 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_ethnl_set_features+0x10/0x10 netlink_rcv_skb+0x121/0x380 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_down_read+0x10/0x10 genl_rcv+0x23/0x30 netlink_unicast+0x60f/0x830 ? __pfx_netlink_unicast+0x10/0x10 ? __pfx___alloc_skb+0x10/0x10 netlink_sendmsg+0x6ea/0xbc0 ? __pfx_netlink_sendmsg+0x10/0x10 ? __futex_queue+0x10b/0x1f0 ____sys_sendmsg+0x7a2/0x950 ? copy_msghdr_from_user+0x26b/0x430 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ___sys_sendmsg+0xf8/0x180 ? __pfx____sys_sendmsg+0x10/0x10 ? __pfx_futex_wait+0x10/0x10 ? fdget+0x2e4/0x4a0 __sys_sendmsg+0x11f/0x1c0 ? __pfx___sys_sendmsg+0x10/0x10 do_syscall_64+0xe2/0x570 ? exc_page_fault+0x66/0xb0 entry_SYSCALL_64_after_hwframe+0x77/0x7f This fix may be combined with another one in the ethtool subsystem: https://lore.kernel.org/all/20260322075917.254874-1-alex.popov@linux.com/T/#u", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2024-56584", "url": "https://ubuntu.com/security/CVE-2024-56584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/tctx: work around xa_store() allocation error issue syzbot triggered the following WARN_ON: WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51 which is the WARN_ON_ONCE(!xa_empty(&tctx->xa)); sanity check in __io_uring_free() when a io_uring_task is going through its final put. The syzbot test case includes injecting memory allocation failures, and it very much looks like xa_store() can fail one of its memory allocations and end up with ->head being non-NULL even though no entries exist in the xarray. Until this issue gets sorted out, work around it by attempting to iterate entries in our xarray, and WARN_ON_ONCE() if one is found.", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2026-31720", "url": "https://ubuntu.com/security/CVE-2026-31720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: validate control request size f_audio_complete() copies req->length bytes into a 4-byte stack variable: u32 data = 0; memcpy(&data, req->buf, req->length); req->length is derived from the host-controlled USB request path, which can lead to a stack out-of-bounds write. Validate req->actual against the expected payload size for the supported control selectors and decode only the expected amount of data. This avoids copying a host-influenced length into a fixed-size stack object.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43342", "url": "https://ubuntu.com/security/CVE-2026-43342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Protect RNDIS options with mutex The class/subclass/protocol options are suspectible to race conditions as they can be accessed concurrently through configfs. Use existing mutex to protect these options. This issue was identified during code inspection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43343", "url": "https://ubuntu.com/security/CVE-2026-43343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_subset: Fix unbalanced refcnt in geth_free geth_alloc() increments the reference count, but geth_free() fails to decrement it. This prevents the configuration of attributes via configfs after unlinking the function. Decrement the reference count in geth_free() to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-68256", "url": "https://ubuntu.com/security/CVE-2025-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser The Information Element (IE) parser rtw_get_ie() trusted the length byte of each IE without validating that the IE body (len bytes after the 2-byte header) fits inside the remaining frame buffer. A malformed frame can advertise an IE length larger than the available data, causing the parser to increment its pointer beyond the buffer end. This results in out-of-bounds reads or, depending on the pattern, an infinite loop. Fix by validating that (offset + 2 + len) does not exceed the limit before accepting the IE or advancing to the next element. This prevents OOB reads and ensures the parser terminates safely on malformed frames.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40103", "url": "https://ubuntu.com/security/CVE-2025-40103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix refcount leak for cifs_sb_tlink Fix three refcount inconsistency issues related to `cifs_sb_tlink`. Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be called after successful calls to `cifs_sb_tlink()`. Three calls fail to update refcount accordingly, leading to possible resource leaks.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-38006", "url": "https://ubuntu.com/security/CVE-2025-38006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: Don't access ifa_index when missing In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but only when the struct ifaddrmsg is provided. Otherwise it will be comparing to uninitialised memory - reproducible in the syzkaller case from dhcpd, or busybox \"ip addr show\". The kernel MCTP implementation has always filtered by ifa_index, so existing userspace programs expecting to dump MCTP addresses must already be passing a valid ifa_index value (either 0 or a real index). BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40323", "url": "https://ubuntu.com/security/CVE-2025-40323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Set fb_display[i]->mode to NULL when the mode is released Recently, we discovered the following issue through syzkaller: BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0. Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2026-23031", "url": "https://ubuntu.com/security/CVE-2026-23031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak In gs_can_open(), the URBs for USB-in transfers are allocated, added to the parent->rx_submitted anchor and submitted. In the complete callback gs_usb_receive_bulk_callback(), the URB is processed and resubmitted. In gs_can_close() the URBs are freed by calling usb_kill_anchored_urbs(parent->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in gs_can_close(). Fix the memory leak by anchoring the URB in the gs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-43324", "url": "https://ubuntu.com/security/CVE-2026-43324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix interrupt synchronization error This fixes an error in synchronization in the dummy-hcd driver. The error has a somewhat involved history. The synchronization mechanism was introduced by commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), which added an emulated \"interrupts enabled\" flag together with code emulating synchronize_irq() (it waits until all current handler callbacks have returned). But the emulated interrupt-disable occurred too late, after the driver containing the handler callback routines had been told that it was unbound and no more callbacks would occur. Commit 4a5d797a9f9c (\"usb: gadget: dummy_hcd: fix gpf in gadget_setup\") tried to fix this by moving the synchronize_irq() emulation code from dummy_stop() to dummy_pullup(), which runs before the unbind callback. There still were races, though, because the emulated interrupt-disable still occurred too late. It couldn't be moved to dummy_pullup(), because that routine can be called for reasons other than an impending unbind. Therefore commits 7dc0c55e9f30 (\"USB: UDC core: Add udc_async_callbacks gadget op\") and 04145a03db9d (\"USB: UDC: Implement udc_async_callbacks in dummy-hcd\") added an API allowing the UDC core to tell dummy-hcd exactly when emulated interrupts and their callbacks should be disabled. That brings us to the current state of things, which is still wrong because the emulated synchronize_irq() occurs before the emulated interrupt-disable! That's no good, beause it means that more emulated interrupts can occur after the synchronize_irq() emulation has run, leading to the possibility that a callback handler may be running when the gadget driver is unbound. To fix this, we have to move the synchronize_irq() emulation code yet again, to the dummy_udc_async_callbacks() routine, which takes care of enabling and disabling emulated interrupt requests. The synchronization will now run immediately after emulated interrupts are disabled, which is where it belongs.", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43327", "url": "https://ubuntu.com/security/CVE-2026-43327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix locking/synchronization error Syzbot testing was able to provoke an addressing exception and crash in the usb_gadget_udc_reset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second (\"driver\") argument of NULL. The bad caller was set_link_state() in dummy_hcd.c, and the problem arose because of a race between a USB reset and driver unbind. These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first. The error responsible for the syzbot crash occurred because the stop_activity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stop_activity() occurs in set_link_state() when handling an emulated USB reset, after the test of dum->ints_enabled and before the increment of dum->callback_usage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->ints_enabled and dum->driver. Normally this other thread would have to wait for dum->callback_usage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callback_usage had not yet been incremented. The fix is to increment dum->callback_usage _before_ calling stop_activity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usb_gadget_udc_reset() safely returns and dum->callback_usage has been decremented again.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31737", "url": "https://ubuntu.com/security/CVE-2026-31737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ftgmac100: fix ring allocation unwind on open failure ftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, and rx_scratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function. Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31738", "url": "https://ubuntu.com/security/CVE-2026-31738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: validate ND option lengths in vxlan_na_create vxlan_na_create() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31747", "url": "https://ubuntu.com/security/CVE-2026-31747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me4000: Fix potential overrun of firmware buffer `me4000_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`. Note: The firmware loading was totally broken before commit ac584af59945 (\"staging: comedi: me4000: fix firmware downloading\"), but that is the most sensible target for this fix.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31748", "url": "https://ubuntu.com/security/CVE-2026-31748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me_daq: Fix potential overrun of firmware buffer `me2600_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Although it checks that the supplied firmware is at least 16 bytes long, it does not check that it is long enough to contain the data stream. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31749", "url": "https://ubuntu.com/security/CVE-2026-31749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: ni_atmio16d: Fix invalid clean-up after failed attach If the driver's COMEDI \"attach\" handler function (`atmio16d_attach()`) returns an error, the COMEDI core will call the driver's \"detach\" handler function (`atmio16d_detach()`) to clean up. This calls `reset_atmio16d()` unconditionally, but depending on where the error occurred in the attach handler, the device may not have been sufficiently initialized to call `reset_atmio16d()`. It uses `dev->iobase` as the I/O port base address and `dev->private` as the pointer to the COMEDI device's private data structure. `dev->iobase` may still be set to its initial value of 0, which would result in undesired writes to low I/O port addresses. `dev->private` may still be `NULL`, which would result in null pointer dereferences. Fix `atmio16d_detach()` by checking that `dev->private` is valid (non-null) before calling `reset_atmio16d()`. This implies that `dev->iobase` was set correctly since that is set up before `dev->private`.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43340", "url": "https://ubuntu.com/security/CVE-2026-43340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Reinit dev->spinlock between attachments to low-level drivers `struct comedi_device` is the main controlling structure for a COMEDI device created by the COMEDI subsystem. It contains a member `spinlock` containing a spin-lock that is initialized by the COMEDI subsystem, but is reserved for use by a low-level driver attached to the COMEDI device (at least since commit 25436dc9d84f (\"Staging: comedi: remove RT code\")). Some COMEDI devices (those created on initialization of the COMEDI subsystem when the \"comedi.comedi_num_legacy_minors\" parameter is non-zero) can be attached to different low-level drivers over their lifetime using the `COMEDI_DEVCONFIG` ioctl command. This can result in inconsistent lock states being reported when there is a mismatch in the spin-lock locking levels used by each low-level driver to which the COMEDI device has been attached. Fix it by reinitializing `dev->spinlock` before calling the low-level driver's `attach` function pointer if `CONFIG_LOCKDEP` is enabled.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31751", "url": "https://ubuntu.com/security/CVE-2026-31751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: dt2815: add hardware detection to prevent crash The dt2815 driver crashes when attached to I/O ports without actual hardware present. This occurs because syzkaller or users can attach the driver to arbitrary I/O addresses via COMEDI_DEVCONFIG ioctl. When no hardware exists at the specified port, inb() operations return 0xff (floating bus), but outb() operations can trigger page faults due to undefined behavior, especially under race conditions: BUG: unable to handle page fault for address: 000000007fffff90 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:dt2815_attach+0x6e0/0x1110 Add hardware detection by reading the status register before attempting any write operations. If the read returns 0xff, assume no hardware is present and fail the attach with -ENODEV. This prevents crashes from outb() operations on non-existent hardware.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31752", "url": "https://ubuntu.com/security/CVE-2026-31752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: validate ND option lengths br_nd_send() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31754", "url": "https://ubuntu.com/security/CVE-2026-31754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix state inconsistency on gadget init failure When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency. When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error, so cdns_role_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles. This leads to a synchronous external abort in xhci_gen_setup() when setting up the host controller: [ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408 [ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switch Fix by calling cdns_drd_gadget_off() in the error path to properly clean up the DRD gadget state.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31755", "url": "https://ubuntu.com/security/CVE-2026-31755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix NULL pointer dereference in ep_queue When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when __cdns3_gadget_ep_queue() is called, causing a kernel crash. Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints. This prevents potential crashes when ep_queue is called on endpoints that are not ready.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31756", "url": "https://ubuntu.com/security/CVE-2026-31756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop() dwc2_gadget_exit_clock_gating() internally calls call_gadget() macro, which expects hsotg->lock to be held since it does spin_unlock/spin_lock around the gadget driver callback invocation. However, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating() without holding the lock. This leads to: - spin_unlock on a lock that is not held (undefined behavior) - The lock remaining held after dwc2_gadget_exit_clock_gating() returns, causing a deadlock when spin_lock_irqsave() is called later in the same function. Fix this by acquiring hsotg->lock before calling dwc2_gadget_exit_clock_gating() and releasing it afterwards, which satisfies the locking requirement of the call_gadget() macro.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31758", "url": "https://ubuntu.com/security/CVE-2026-31758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbtmc: Flush anchored URBs in usbtmc_release When calling usbtmc_release, pending anchored URBs must be flushed or killed to prevent use-after-free errors (e.g. in the HCD giveback path). Call usbtmc_draw_down() to allow anchored URBs to be completed.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31759", "url": "https://ubuntu.com/security/CVE-2026-31759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: fix double free in ulpi_register_interface() error path When device_register() fails, ulpi_register() calls put_device() on ulpi->dev. The device release callback ulpi_dev_release() drops the OF node reference and frees ulpi, but the current error path in ulpi_register_interface() then calls kfree(ulpi) again, causing a double free. Let put_device() handle the cleanup through ulpi_dev_release() and avoid freeing ulpi again in ulpi_register_interface().", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31761", "url": "https://ubuntu.com/security/CVE-2026-31761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Move iio_device_register() to correct location iio_device_register() should be at the end of the probe function to prevent race conditions. Place iio_device_register() at the end of the probe function and place iio_device_unregister() accordingly.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31762", "url": "https://ubuntu.com/security/CVE-2026-31762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix irq resource leak The interrupt handler is setup but only a few lines down if iio_trigger_register() fails the function returns without properly releasing the handler. Add cleanup goto to resolve resource leak. Detected by Smatch: drivers/iio/gyro/mpu3050-core.c:1128 mpu3050_trigger_probe() warn: 'irq' from request_threaded_irq() not released on lines: 1124.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31763", "url": "https://ubuntu.com/security/CVE-2026-31763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix incorrect free_irq() variable The handler for the IRQ part of this driver is mpu3050->trig but, in the teardown free_irq() is called with handler mpu3050. Use correct IRQ handler when calling free_irq().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31770", "url": "https://ubuntu.com/security/CVE-2026-31770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) Fix division by zero in occ_show_power_1() In occ_show_power_1() case 1, the accumulator is divided by update_tag without checking for zero. If no samples have been collected yet (e.g. during early boot when the sensor block is included but hasn't been updated), update_tag is zero, causing a kernel divide-by-zero crash. The 2019 fix in commit 211186cae14d (\"hwmon: (occ) Fix division by zero issue\") only addressed occ_get_powr_avg() used by occ_show_power_2() and occ_show_power_a0(). This separate code path in occ_show_power_1() was missed. Fix this by reusing the existing occ_get_powr_avg() helper, which already handles the zero-sample case and uses mul_u64_u32_div() to multiply before dividing for better precision. Move the helper above occ_show_power_1() so it is visible at the call site. [groeck: Fix alignment problems reported by checkpatch]", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43334", "url": "https://ubuntu.com/security/CVE-2026-43334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: force responder MITM requirements before building the pairing response smp_cmd_pairing_req() currently builds the pairing response from the initiator auth_req before enforcing the local BT_SECURITY_HIGH requirement. If the initiator omits SMP_AUTH_MITM, the response can also omit it even though the local side still requires MITM. tk_request() then sees an auth value without SMP_AUTH_MITM and may select JUST_CFM, making method selection inconsistent with the pairing policy the responder already enforces. When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMP_AUTH_MITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31773", "url": "https://ubuntu.com/security/CVE-2026-31773", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: derive legacy responder STK authentication from MITM state The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved. For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result. This also keeps the legacy path aligned with the Secure Connections code, which already treats JUST_WORKS/JUST_CFM as unauthenticated.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31776", "url": "https://ubuntu.com/security/CVE-2026-31776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix missing SPDIFI1 index handling SPDIF1 DAIO type isn't properly handled in daio_device_index() for hw20k2, and it returned -EINVAL, which ended up with the out-of-bounds array access. Follow the hw20k1 pattern and return the proper index for this type, too.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31778", "url": "https://ubuntu.com/security/CVE-2026-31778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix stack out-of-bounds read in init_card The loop creates a whitespace-stripped copy of the card shortname where `len < sizeof(card->id)` is used for the bounds check. Since sizeof(card->id) is 16 and the local id buffer is also 16 bytes, writing 16 non-space characters fills the entire buffer, overwriting the terminating nullbyte. When this non-null-terminated string is later passed to snd_card_set_id() -> copy_valid_id_string(), the function scans forward with `while (*nid && ...)` and reads past the end of the stack buffer, reading the contents of the stack. A USB device with a product name containing many non-ASCII, non-space characters (e.g. multibyte UTF-8) will reliably trigger this as follows: BUG: KASAN: stack-out-of-bounds in copy_valid_id_string sound/core/init.c:696 [inline] BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c sound/core/init.c:718 The off-by-one has been present since commit bafeee5b1f8d (\"ALSA: snd_usb_caiaq: give better shortname\") from June 2009 (v2.6.31-rc1), which first introduced this whitespace-stripping loop. The original code never accounted for the null terminator when bounding the copy. Fix this by changing the loop bound to `sizeof(card->id) - 1`, ensuring at least one byte remains as the null terminator.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31780", "url": "https://ubuntu.com/security/CVE-2026-31780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation The variable valuesize is declared as u8 but accumulates the total length of all SSIDs to scan. Each SSID contributes up to 33 bytes (IEEE80211_MAX_SSID_LEN + 1), and with WILC_MAX_NUM_PROBED_SSID (10) SSIDs the total can reach 330, which wraps around to 74 when stored in a u8. This causes kmalloc to allocate only 75 bytes while the subsequent memcpy writes up to 331 bytes into the buffer, resulting in a 256-byte heap buffer overflow. Widen valuesize from u8 to u32 to accommodate the full range.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31781", "url": "https://ubuntu.com/security/CVE-2026-31781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ioc32: stop speculation on the drm_compat_ioctl path The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling array_index_nospec() on the index to the function pointer list.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43333", "url": "https://ubuntu.com/security/CVE-2026-43333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject direct access to nullable PTR_TO_BUF pointers check_mem_access() matches PTR_TO_BUF via base_type() which strips PTR_MAYBE_NULL, allowing direct dereference without a null check. Map iterator ctx->key and ctx->value are PTR_TO_BUF | PTR_MAYBE_NULL. On stop callbacks these are NULL, causing a kernel NULL dereference. Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching the existing PTR_TO_BTF_ID pattern.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31415", "url": "https://ubuntu.com/security/CVE-2026-31415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid overflows in ip6_datagram_send_ctl() Yiming Qian reported : I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via `skb_under_panic()` (local DoS). The core issue is a mismatch between: - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type `__u16`) and - a pointer to the *last* provided destination-options header (`opt->dst1opt`) when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided. - `include/net/ipv6.h`: - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible). (lines 291-307, especially 298) - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`: - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen` without rejecting duplicates. (lines 909-933) - `net/ipv6/ip6_output.c:__ip6_append_data()`: - Uses `opt->opt_flen + opt->opt_nflen` to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - `net/ipv6/ip6_output.c:__ip6_make_skb()`: - Calls `ipv6_push_frag_opts()` if `opt->opt_flen` is non-zero. (lines 1930-1934) - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`: - Push size comes from `ipv6_optlen(opt->dst1opt)` (based on the pointed-to header). (lines 1179-1185 and 1206-1211) 1. `opt_flen` is a 16-bit accumulator: - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`. 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs and increments `opt_flen` each time: - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`: - It computes `len = ((hdr->hdrlen + 1) << 3);` - It checks `CAP_NET_RAW` using `ns_capable(net->user_ns, CAP_NET_RAW)`. (line 922) - Then it does: - `opt->opt_flen += len;` (line 927) - `opt->dst1opt = hdr;` (line 928) There is no duplicate rejection here (unlike the legacy `IPV6_2292DSTOPTS` path which rejects duplicates at `net/ipv6/datagram.c:901-904`). If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps while `dst1opt` still points to a large (2048-byte) destination-options header. In the attached PoC (`poc.c`): - 32 cmsgs with `hdrlen=255` => `len = (255+1)*8 = 2048` - 1 cmsg with `hdrlen=0` => `len = 8` - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8` - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header. 3. The transmit path sizes headers using the wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1463-1465`: - `headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;` With wrapped `opt_flen`, `headersize`/headroom decisions underestimate what will be pushed later. 4. When building the final skb, the actual push length comes from `dst1opt` and is not limited by wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1930-1934`: - `if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);` - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes `dst1opt` via `ipv6_push_exthdr()`. - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does: - `skb_push(skb, ipv6_optlen(opt));` - `memcpy(h, opt, ipv6_optlen(opt));` With insufficient headroom, `skb_push()` underflows and triggers `skb_under_panic()` -> `BUG()`: - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`) - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`) - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target netns user namespace (`ns_capable(net->user_ns, CAP_NET_RAW)`). - Root (or any task with `CAP_NET_RAW`) can trigger this without user namespaces. - An unprivileged `uid=1000` user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced `CAP_NET_RAW` (the attached PoC does this). - Local denial of service: kernel BUG/panic (system crash). - ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31422", "url": "https://ubuntu.com/security/CVE-2026-31422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_flow: fix NULL pointer dereference on shared blocks flow_change() calls tcf_block_q() and dereferences q->handle to derive a default baseclass. Shared blocks leave block->q NULL, causing a NULL deref when a flow filter without a fully qualified baseclass is created on a shared block. Check tcf_block_shared() before accessing block->q and return -EINVAL for shared blocks. This avoids the null-deref shown below: ======================================================================= KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:flow_change (net/sched/cls_flow.c:508) Call Trace: tc_new_tfilter (net/sched/cls_api.c:2432) rtnetlink_rcv_msg (net/core/rtnetlink.c:6980) [...] =======================================================================", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31421", "url": "https://ubuntu.com/security/CVE-2026-31421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL pointer dereference on shared blocks The old-method path in fw_classify() calls tcf_block_q() and dereferences q->handle. Shared blocks leave block->q NULL, causing a NULL deref when an empty cls_fw filter is attached to a shared block and a packet with a nonzero major skb mark is classified. Reject the configuration in fw_change() when the old method (no TCA_OPTIONS) is used on a shared block, since fw_classify()'s old-method path needs block->q which is NULL for shared blocks. The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fw_classify (net/sched/cls_fw.c:81) Call Trace: tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860) tc_run (net/core/dev.c:4401) __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31417", "url": "https://ubuntu.com/security/CVE-2026-31417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix overflow when accumulating packets Add a check to ensure that `x25_sock.fraglen` does not overflow. The `fraglen` also needs to be resetted when purging `fragment_queue` in `x25_clear_queues()`.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43014", "url": "https://ubuntu.com/security/CVE-2026-43014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: properly unregister fixed rate clocks The additional resources allocated with clk_register_fixed_rate() need to be released with clk_unregister_fixed_rate(), otherwise they are lost.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43015", "url": "https://ubuntu.com/security/CVE-2026-43015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix clk handling on PCI glue driver removal platform_device_unregister() may still want to use the registered clks during runtime resume callback. Note that there is a commit d82d5303c4c5 (\"net: macb: fix use after free on rmmod\") that addressed the similar problem of clk vs platform device unregistration but just moved the bug to another place. Save the pointers to clks into local variables for reuse after platform device is unregistered. BUG: KASAN: use-after-free in clk_prepare+0x5a/0x60 Read of size 8 at addr ffff888104f85e00 by task modprobe/597 CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x8d/0xba print_report+0x17f/0x496 kasan_report+0xd9/0x180 clk_prepare+0x5a/0x60 macb_runtime_resume+0x13d/0x410 [macb] pm_generic_runtime_resume+0x97/0xd0 __rpm_callback+0xc8/0x4d0 rpm_callback+0xf6/0x230 rpm_resume+0xeeb/0x1a70 __pm_runtime_resume+0xb4/0x170 bus_remove_device+0x2e3/0x4b0 device_del+0x5b3/0xdc0 platform_device_del+0x4e/0x280 platform_device_unregister+0x11/0x50 pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 519: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x8e/0x90 __clk_register+0x458/0x2890 clk_hw_register+0x1a/0x60 __clk_hw_register_fixed_rate+0x255/0x410 clk_register_fixed_rate+0x3c/0xa0 macb_probe+0x1d8/0x42e [macb_pci] local_pci_probe+0xd7/0x190 pci_device_probe+0x252/0x600 really_probe+0x255/0x7f0 __driver_probe_device+0x1ee/0x330 driver_probe_device+0x4c/0x1f0 __driver_attach+0x1df/0x4e0 bus_for_each_dev+0x15d/0x1f0 bus_add_driver+0x486/0x5e0 driver_register+0x23a/0x3d0 do_one_initcall+0xfd/0x4d0 do_init_module+0x18b/0x5a0 load_module+0x5663/0x7950 __do_sys_finit_module+0x101/0x180 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 597: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x180 __kmem_cache_free+0xbc/0x320 clk_unregister+0x6de/0x8d0 macb_remove+0x73/0xc0 [macb_pci] pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31425", "url": "https://ubuntu.com/security/CVE-2026-31425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: ib: reject FRMR registration before IB connection is established rds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_data and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with i_cm_id = NULL because the connection worker has not yet called rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses the control message before any connection establishment, allowing rds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash the kernel. The existing guard in rds_ib_reg_frmr() only checks for !ic (added in commit 9e630bcb7701), which does not catch this case since ic is allocated early and is always non-NULL once the connection object exists. KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920 Call Trace: rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167) rds_ib_map_frmr (net/rds/ib_frmr.c:252) rds_ib_reg_frmr (net/rds/ib_frmr.c:430) rds_ib_get_mr (net/rds/ib_rdma.c:615) __rds_rdma_map (net/rds/rdma.c:295) rds_cmsg_rdma_map (net/rds/rdma.c:860) rds_sendmsg (net/rds/send.c:1363) ____sys_sendmsg do_syscall_64 Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all non-NULL before proceeding with FRMR registration, mirroring the guard already present in rds_ib_post_inv(). Return -ENODEV when the connection is not ready, which the existing error handling in rds_cmsg_send() converts to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to start the connection worker.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43020", "url": "https://ubuntu.com/security/CVE-2026-43020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate LTK enc_size on load Load Long Term Keys stores the user-provided enc_size and later uses it to size fixed-size stack operations when replying to LE LTK requests. An enc_size larger than the 16-byte key buffer can therefore overflow the reply stack buffer. Reject oversized enc_size values while validating the management LTK record so invalid keys never reach the stored key state.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43024", "url": "https://ubuntu.com/security/CVE-2026-43024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject immediate NF_QUEUE verdict nft_queue is always used from userspace nftables to deliver the NF_QUEUE verdict. Immediately emitting an NF_QUEUE verdict is never used by the userspace nft tools, so reject immediate NF_QUEUE verdicts. The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NF_QUEUE immediate verdicts to address this issue.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31424", "url": "https://ubuntu.com/security/CVE-2026-31424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP Weiming Shi says: xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_* constants. This is only correct for families whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING). ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports: - arpt_CLASSIFY - arpt_mangle - arpt_MARK that provide explicit NFPROTO_ARP match/target declarations.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43026", "url": "https://ubuntu.com/security/CVE-2026-43026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT. The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields. Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled. Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43027", "url": "https://ubuntu.com/security/CVE-2026-43027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_helper: pass helper to expect cleanup nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expect_iter_me() never matches any expectation and all of them survive the cleanup. After unregister returns, nfnl_cthelper_del() frees the helper object immediately. Subsequent expectation dumps or packet-driven init_conntrack() calls then dereference the freed exp->helper, causing a use-after-free. Pass the actual helper pointer so expectations referencing it are properly destroyed before the helper object is freed. BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43028", "url": "https://ubuntu.com/security/CVE-2026-43028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: ensure names are nul-terminated Reject names that lack a \\0 character before feeding them to functions that expect c-strings. Fixes tag is the most recent commit that needs this change.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31416", "url": "https://ubuntu.com/security/CVE-2026-31416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: account for netlink header size This is a followup to an old bug fix: NLMSG_DONE needs to account for the netlink header size, not just the attribute size. This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43329", "url": "https://ubuntu.com/security/CVE-2026-43329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: strictly check for maximum number of actions The maximum number of flowtable hardware offload actions in IPv6 is: * ethernet mangling (4 payload actions, 2 for each ethernet address) * SNAT (4 payload actions) * DNAT (4 payload actions) * Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. * Redirect (1 action) Which makes 17, while the maximum is 16. But act_ct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions. Update flow_action_entry_next() calls to check for the maximum number of supported actions. While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31680", "url": "https://ubuntu.com/security/CVE-2026-31680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: flowlabel: defer exclusive option free until RCU teardown `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file RCU read-side lock and prints `fl->opt->opt_nflen` when an option block is present. Exclusive flowlabels currently free `fl->opt` as soon as `fl->users` drops to zero in `fl_release()`. However, the surrounding `struct ip6_flowlabel` remains visible in the global hash table until later garbage collection removes it and `fl_free_rcu()` finally tears it down. A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that early `kfree()` and dereference freed option state, triggering a crash in `ip6fl_seq_show()`. Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43030", "url": "https://ubuntu.com/security/CVE-2026-43030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix regsafe() for pointers to packet In case rold->reg->range == BEYOND_PKT_END && rcur->reg->range == N regsafe() may return true which may lead to current state with valid packet range not being explored. Fix the bug.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43032", "url": "https://ubuntu.com/security/CVE-2026-43032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: pn533: bound the UART receive buffer pn532_receive_buf() appends every incoming byte to dev->recv_skb and only resets the buffer after pn532_uart_rx_is_frame() recognizes a complete frame. A continuous stream of bytes without a valid PN532 frame header therefore keeps growing the skb until skb_put_u8() hits the tail limit. Drop the accumulated partial frame once the fixed receive buffer is full so malformed UART traffic cannot grow the skb past PN532_UART_SKB_BUFF_LEN.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43035", "url": "https://ubuntu.com/security/CVE-2026-43035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to zero to prevent an info-leak When building netlink messages, tc_chain_fill_node() never initializes the tcm_info field of struct tcmsg. Since the allocation is not zeroed, kernel heap memory is leaked to userspace through this 4-byte field. The fix simply zeroes tcm_info alongside the other fields that are already initialized.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43339", "url": "https://ubuntu.com/security/CVE-2026-43339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible UaF in addrconf_permanent_addr() The mentioned helper try to warn the user about an exceptional condition, but the message is delivered too late, accessing the ipv6 after its possible deletion. Reorder the statement to avoid the possible UaF; while at it, place the warning outside the idev->lock as it needs no protection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31423", "url": "https://ubuntu.com/security/CVE-2026-31423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: fix divide-by-zero in rtsc_min() m2sm() converts a u32 slope to a u64 scaled value. For large inputs (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores the difference of two such u64 values in a u32 variable `dsm` and uses it as a divisor. When the difference is exactly 2^32 the truncation yields zero, causing a divide-by-zero oops in the concave-curve intersection path: Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...] Widen `dsm` to u64 and replace do_div() with div64_u64() so the full difference is preserved.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43040", "url": "https://ubuntu.com/security/CVE-2026-43040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak When processing Router Advertisements with user options the kernel builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data The fix is simple, just zeroes the padding fields.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43041", "url": "https://ubuntu.com/security/CVE-2026-43041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak __radix_tree_create() allocates and links intermediate nodes into the tree one by one. If a subsequent allocation fails, the already-linked nodes remain in the tree with no corresponding leaf entry. These orphaned internal nodes are never reclaimed because radix_tree_for_each_slot() only visits slots containing leaf values. The radix_tree API is deprecated in favor of xarray. As suggested by Matthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray instead of fixing the radix_tree itself [1]. xarray properly handles cleanup of internal nodes — xa_destroy() frees all internal xarray nodes when the qrtr_node is released, preventing the leak. [1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43043", "url": "https://ubuntu.com/security/CVE-2026-43043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af-alg - fix NULL pointer dereference in scatterwalk The AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL) when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL exactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent sendmsg() allocates a new SGL and chains it, but fails to clear the end marker on the previous SGL's last data entry. This causes the crypto scatterwalk to hit a premature end, returning NULL on sg_next() and leading to a kernel panic during dereference. Fix this by explicitly unmarking the end of the previous SGL when performing sg_chain() in af_alg_alloc_tsgl().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43046", "url": "https://ubuntu.com/security/CVE-2026-43046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject root items with drop_progress and zero drop_level [BUG] When recovering relocation at mount time, merge_reloc_root() and btrfs_drop_snapshot() both use BUG_ON(level == 0) to guard against an impossible state: a non-zero drop_progress combined with a zero drop_level in a root_item, which can be triggered: ------------[ cut here ]------------ kernel BUG at fs/btrfs/relocation.c:1545! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2 RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545 Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000 Call Trace: merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861 btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195 btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130 open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640 btrfs_fill_super fs/btrfs/super.c:987 [inline] btrfs_get_tree_super fs/btrfs/super.c:1951 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline] btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ... RIP: 0033:0x7f969c9a8fde Code: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f ---[ end trace 0000000000000000 ]--- The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamic metadata fuzzing tool that corrupts btrfs metadata at runtime. [CAUSE] A non-zero drop_progress.objectid means an interrupted btrfs_drop_snapshot() left a resume point on disk, and in that case drop_level must be greater than 0 because the checkpoint is only saved at internal node levels. Although this invariant is enforced when the kernel writes the root item, it is not validated when the root item is read back from disk. That allows on-disk corruption to provide an invalid state with drop_progress.objectid != 0 and drop_level == 0. When relocation recovery later processes such a root item, merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). The same invalid metadata can also trigger the corresponding BUG_ON() in btrfs_drop_snapshot(). [FIX] Fix this by validating the root_item invariant in tree-checker when reading root items from disk: if drop_progress.objectid is non-zero, drop_level must also be non-zero. Reject such malformed metadata with -EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot() and triggers the BUG_ON. After the fix, the same corruption is correctly rejected by tree-checker and the BUG_ON is no longer triggered.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43047", "url": "https://ubuntu.com/security/CVE-2026-43047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Check to ensure report responses match the request It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes. Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43050", "url": "https://ubuntu.com/security/CVE-2026-43050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix use-after-free in sock_def_readable() A race condition exists between lec_atm_close() setting priv->lecd to NULL and concurrent access to priv->lecd in send_to_lecd(), lec_handle_bridge(), and lec_atm_send(). When the socket is freed via RCU while another thread is still using it, a use-after-free occurs in sock_def_readable() when accessing the socket's wait queue. The root cause is that lec_atm_close() clears priv->lecd without any synchronization, while callers dereference priv->lecd without any protection against concurrent teardown. Fix this by converting priv->lecd to an RCU-protected pointer: - Mark priv->lecd as __rcu in lec.h - Use rcu_assign_pointer() in lec_atm_close() and lecd_attach() for safe pointer assignment - Use rcu_access_pointer() for NULL checks that do not dereference the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and lecd_attach() - Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(), lec_handle_bridge() and lec_atm_send() to safely access lecd - Use rcu_assign_pointer() followed by synchronize_rcu() in lec_atm_close() to ensure all readers have completed before proceeding. This is safe since lec_atm_close() is called from vcc_release() which holds lock_sock(), a sleeping lock. - Remove the manual sk_receive_queue drain from lec_atm_close() since vcc_destroy_socket() already drains it after lec_atm_close() returns. v2: Switch from spinlock + sock_hold/put approach to RCU to properly fix the race. The v1 spinlock approach had two issues pointed out by Eric Dumazet: 1. priv->lecd was still accessed directly after releasing the lock instead of using a local copy. 2. The spinlock did not prevent packets being queued after lec_atm_close() drains sk_receive_queue since timer and workqueue paths bypass netif_stop_queue(). Note: Syzbot patch testing was attempted but the test VM terminated unexpectedly with \"Connection to localhost closed by remote host\", likely due to a QEMU AHCI emulation issue unrelated to this fix. Compile testing with \"make W=1 net/atm/lec.o\" passes cleanly.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43051", "url": "https://ubuntu.com/security/CVE-2026-43051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq The wacom_intuos_bt_irq() function processes Bluetooth HID reports without sufficient bounds checking. A maliciously crafted short report can trigger an out-of-bounds read when copying data into the wacom structure. Specifically, report 0x03 requires at least 22 bytes to safely read the processed data and battery status, while report 0x04 (which falls through to 0x03) requires 32 bytes. Add explicit length checks for these report IDs and log a warning if a short report is received.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31555", "url": "https://ubuntu.com/security/CVE-2026-31555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Clear stale exiting pointer in futex_lock_pi() retry path Fuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524 When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'. After wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0\t\t\t CPU1\t\t CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; \t\t\t futex_lock_pi(uaddr) \t\t\t futex_lock_pi_atomic() \t\t\t\t attach_to_pi_owner() \t\t\t\t // observes EXITING \t\t\t\t *exiting = owner; // takes ref \t\t\t\t return -EBUSY \t\t\t wait_for_owner_exiting(-EBUSY, owner) \t\t\t\t put_task_struct(); // drops ref \t\t\t // exiting still points to owner \t\t\t goto retry; \t\t\t futex_lock_pi_atomic() \t\t\t\t lock_pi_update_atomic() \t\t\t\t cmpxchg(uaddr) \t\t\t\t\t*uaddr ^= WAITERS // whatever \t\t\t\t // value changed \t\t\t\t return -EAGAIN; \t\t\t wait_for_owner_exiting(-EAGAIN, exiting) // stale \t\t\t\t WARN_ON_ONCE(exiting) Fix this by resetting upon retry, essentially aligning it with requeue_pi.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43065", "url": "https://ubuntu.com/security/CVE-2026-43065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: always drain queued discard work in ext4_mb_release() While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]: > If the filesystem is initially mounted with the discard option, > deleting files will populate sbi->s_discard_list and queue > s_discard_work. If it is then remounted with nodiscard, the > EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is > neither cancelled nor flushed. [1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing. In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own. Fix it because it's a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-43066", "url": "https://ubuntu.com/security/CVE-2026-43066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths During code review, Joseph found that ext4_fc_replay_inode() calls ext4_get_fc_inode_loc() to get the inode location, which holds a reference to iloc.bh that must be released via brelse(). However, several error paths jump to the 'out' label without releasing iloc.bh: - ext4_handle_dirty_metadata() failure - sync_dirty_buffer() failure - ext4_mark_inode_used() failure - ext4_iget() failure Fix this by introducing an 'out_brelse' label placed just before the existing 'out' label to ensure iloc.bh is always released. Additionally, make ext4_fc_replay_inode() propagate errors properly instead of always returning 0.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31447", "url": "https://ubuntu.com/security/CVE-2026-31447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: reject mount if bigalloc with s_first_data_block != 0 bigalloc with s_first_data_block != 0 is not supported, reject mounting it.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43068", "url": "https://ubuntu.com/security/CVE-2026-43068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal() There's issue as follows: ... EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): error count since last fsck: 1 EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760 EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760 ... According to the log analysis, blocks are always requested from the corrupted block group. This may happen as follows: ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return error ext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out; After commit 9008a58e5dce (\"ext4: make the bitmap read routines return real error codes\") merged, Commit 163a203ddb36 (\"ext4: mark block group as corrupt on block bitmap error\") is no real solution for allocating blocks from corrupted block groups. This is because if 'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then 'ext4_mb_load_buddy()' may return an error. This means that the block allocation will fail. Therefore, check block group if corrupted when ext4_mb_load_buddy() returns error.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31452", "url": "https://ubuntu.com/security/CVE-2026-31452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: convert inline data to extents when truncate exceeds inline size Add a check in ext4_setattr() to convert files from inline data storage to extent-based storage when truncate() grows the file size beyond the inline capacity. This prevents the filesystem from entering an inconsistent state where the inline data flag is set but the file size exceeds what can be stored inline. Without this fix, the following sequence causes a kernel BUG_ON(): 1. Mount filesystem with inode that has inline flag set and small size 2. truncate(file, 50MB) - grows size but inline flag remains set 3. sendfile() attempts to write data 4. ext4_write_inline_data() hits BUG_ON(write_size > inline_capacity) The crash occurs because ext4_write_inline_data() expects inline storage to accommodate the write, but the actual inline capacity (~60 bytes for i_block + ~96 bytes for xattrs) is far smaller than the file size and write request. The fix checks if the new size from setattr exceeds the inode's actual inline capacity (EXT4_I(inode)->i_inline_size) and converts the file to extent-based storage before proceeding with the size change. This addresses the root cause by ensuring the inline data flag and file size remain consistent during truncate operations.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31455", "url": "https://ubuntu.com/security/CVE-2026-31455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: stop reclaim before pushing AIL during unmount The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while background reclaim and inodegc are still running. This is broken independently of any use-after-free issues - background reclaim and inodegc should not be running while the AIL is being pushed during unmount, as inodegc can dirty and insert inodes into the AIL during the flush, and background reclaim can race to abort and free dirty inodes. Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel background reclaim before pushing the AIL. Stop inodegc before cancelling m_reclaim_work because the inodegc worker can re-queue m_reclaim_work via xfs_inodegc_set_reclaimable.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31464", "url": "https://ubuntu.com/security/CVE-2026-31464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done() A malicious or compromised VIO server can return a num_written value in the discover targets MAD response that exceeds max_targets. This value is stored directly in vhost->num_targets without validation, and is then used as the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], which is only allocated for max_targets entries. Indices at or beyond max_targets access kernel memory outside the DMA-coherent allocation. The out-of-bounds data is subsequently embedded in Implicit Logout and PLOGI MADs that are sent back to the VIO server, leaking kernel memory. Fix by clamping num_written to max_targets before storing it.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31467", "url": "https://ubuntu.com/security/CVE-2026-31467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: add GFP_NOIO in the bio completion if needed The bio completion path in the process context (e.g. dm-verity) will directly call into decompression rather than trigger another workqueue context for minimal scheduling latencies, which can then call vm_map_ram() with GFP_KERNEL. Due to insufficient memory, vm_map_ram() may generate memory swapping I/O, which can cause submit_bio_wait to deadlock in some scenarios. Trimmed down the call stack, as follows: f2fs_submit_read_io submit_bio //bio_list is initialized. mmc_blk_mq_recovery z_erofs_endio vm_map_ram __pte_alloc_kernel __alloc_pages_direct_reclaim shrink_folio_list __swap_writepage submit_bio_wait //bio_list is non-NULL, hang!!! Use memalloc_noio_{save,restore}() to wrap up this path.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31469", "url": "https://ubuntu.com/security/CVE-2026-31469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false A UAF issue occurs when the virtio_net driver is configured with napi_tx=N and the device's IFF_XMIT_DST_RELEASE flag is cleared (e.g., during the configuration of tc route filter rules). When IFF_XMIT_DST_RELEASE is removed from the net_device, the network stack expects the driver to hold the reference to skb->dst until the packet is fully transmitted and freed. In virtio_net with napi_tx=N, skbs may remain in the virtio transmit ring for an extended period. If the network namespace is destroyed while these skbs are still pending, the corresponding dst_ops structure has freed. When a subsequent packet is transmitted, free_old_xmit() is triggered to clean up old skbs. It then calls dst_release() on the skb associated with the stale dst_entry. Since the dst_ops (referenced by the dst_entry) has already been freed, a UAF kernel paging request occurs. fix it by adds skb_dst_drop(skb) in start_xmit to explicitly release the dst reference before the skb is queued in virtio_net. Call Trace: Unable to handle kernel paging request at virtual address ffff80007e150000 CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT ... percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P) dst_release+0xe0/0x110 net/core/dst.c:177 skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177 sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255 dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469 napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527 __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net] free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net] start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net] ... Reproduction Steps: NETDEV=\"enp3s0\" config_qdisc_route_filter() { tc qdisc del dev $NETDEV root tc qdisc add dev $NETDEV root handle 1: prio tc filter add dev $NETDEV parent 1:0 \\ \tprotocol ip prio 100 route to 100 flowid 1:1 ip route add 192.168.1.100/32 dev $NETDEV realm 100 } test_ns() { ip netns add testns ip link set $NETDEV netns testns ip netns exec testns ifconfig $NETDEV 10.0.32.46/24 ip netns exec testns ping -c 1 10.0.32.1 ip netns del testns } config_qdisc_route_filter test_ns sleep 2 test_ns", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31473", "url": "https://ubuntu.com/security/CVE-2026-31473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex MEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0) queue teardown paths. This can race request object cleanup against vb2 queue cancellation and lead to use-after-free reports. We already serialize request queueing against STREAMON/OFF with req_queue_mutex. Extend that serialization to REQBUFS, and also take the same mutex in media_request_ioctl_reinit() so REINIT is in the same exclusion domain. This keeps request cleanup and queue cancellation from running in parallel for request-capable devices.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31570", "url": "https://ubuntu.com/security/CVE-2026-31570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gw: fix OOB heap access in cgw_csum_crc8_rel() cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx(): int from = calc_idx(crc8->from_idx, cf->len); int to = calc_idx(crc8->to_idx, cf->len); int res = calc_idx(crc8->result_idx, cf->len); if (from < 0 || to < 0 || res < 0) return; However, the loop and the result write then use the raw s8 fields directly instead of the computed variables: for (i = crc8->from_idx; ...) /* BUG: raw negative index */ cf->data[crc8->result_idx] = ...; /* BUG: raw negative index */ With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame, calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf->data[-64], and the write goes to cf->data[-64]. This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before the start of the canfd_frame on the heap. The companion function cgw_csum_xor_rel() uses `from`/`to`/`res` correctly throughout; fix cgw_csum_crc8_rel() to match. Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62 To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31483", "url": "https://ubuntu.com/security/CVE-2026-31483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/syscalls: Add spectre boundary for syscall dispatch table The s390 syscall number is directly controlled by userspace, but does not have an array_index_nospec() boundary to prevent access past the syscall function pointer tables.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31485", "url": "https://ubuntu.com/security/CVE-2026-31485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-lpspi: fix teardown order issue (UAF) There is a teardown order issue in the driver. The SPI controller is registered using devm_spi_register_controller(), which delays unregistration of the SPI controller until after the fsl_lpspi_remove() function returns. As the fsl_lpspi_remove() function synchronously tears down the DMA channels, a running SPI transfer triggers the following NULL pointer dereference due to use after free: | fsl_lpspi 42550000.spi: I/O Error in DMA RX | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] | Call trace: | fsl_lpspi_dma_transfer+0x260/0x340 [spi_fsl_lpspi] | fsl_lpspi_transfer_one+0x198/0x448 [spi_fsl_lpspi] | spi_transfer_one_message+0x49c/0x7c8 | __spi_pump_transfer_message+0x120/0x420 | __spi_sync+0x2c4/0x520 | spi_sync+0x34/0x60 | spidev_message+0x20c/0x378 [spidev] | spidev_ioctl+0x398/0x750 [spidev] [...] Switch from devm_spi_register_controller() to spi_register_controller() in fsl_lpspi_probe() and add the corresponding spi_unregister_controller() in fsl_lpspi_remove().", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31565", "url": "https://ubuntu.com/security/CVE-2026-31565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix deadlock during netdev reset with active connections Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering device_delete and subsequent client removal. During client removal, uverbs_client waits for QP reference count to reach zero while cma_client holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31494", "url": "https://ubuntu.com/security/CVE-2026-31494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: use the current queue number for stats There's a potential mismatch between the memory reserved for statistics and the amount of memory written. gem_get_sset_count() correctly computes the number of stats based on the active queues, whereas gem_get_ethtool_stats() indiscriminately copies data using the maximum number of queues, and in the case the number of active queues is less than MACB_MAX_QUEUES, this results in a OOB write as observed in the KASAN splat. ================================================================== BUG: KASAN: vmalloc-out-of-bounds in gem_get_ethtool_stats+0x54/0x78 [macb] Write of size 760 at addr ffff80008080b000 by task ethtool/1027 CPU: [...] Tainted: [E]=UNSIGNED_MODULE Hardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 print_report+0x384/0x5e0 kasan_report+0xa0/0xf0 kasan_check_range+0xe8/0x190 __asan_memcpy+0x54/0x98 gem_get_ethtool_stats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] dev_ethtool+0x1220/0x38c0 dev_ioctl+0x4ac/0xca8 sock_do_ioctl+0x170/0x1d8 sock_ioctl+0x484/0x5d8 __arm64_sys_ioctl+0x12c/0x1b8 invoke_syscall+0xd4/0x258 el0_svc_common.constprop.0+0xb4/0x240 do_el0_svc+0x48/0x68 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 The buggy address belongs to a 1-page vmalloc region starting at 0xffff80008080b000 allocated at dev_ethtool+0x11f0/0x38c0 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff00000a333000 pfn:0xa333 flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff) raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== Fix it by making sure the copied size only considers the active number of queues.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31495", "url": "https://ubuntu.com/security/CVE-2026-31495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: use netlink policy range checks Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors. - CTA_PROTOINFO_TCP_STATE: reject values > TCP_CONNTRACK_SYN_SENT2 at policy level, removing the manual >= TCP_CONNTRACK_MAX check. - CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values > TCP_MAX_WSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count. - CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with CTA_FILTER_F_ALL, removing the manual mask checks. - CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding a new mask define grouping all valid expect flags. Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31427", "url": "https://ubuntu.com/security/CVE-2026-31427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp process_sdp() declares union nf_inet_addr rtp_addr on the stack and passes it to the nf_nat_sip sdp_session hook after walking the SDP media descriptions. However rtp_addr is only initialized inside the media loop when a recognized media type with a non-zero port is found. If the SDP body contains no m= lines, only inactive media sections (m=audio 0 ...) or only unrecognized media types, rtp_addr is never assigned. Despite that, the function still calls hooks->sdp_session() with &rtp_addr, causing nf_nat_sdp_session() to format the stale stack value as an IP address and rewrite the SDP session owner and connection lines with it. With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this results in the session-level o= and c= addresses being rewritten to 0.0.0.0 for inactive SDP sessions. Without stack auto-init the rewritten address is whatever happened to be on the stack. Fix this by pre-initializing rtp_addr from the session-level connection address (caddr) when available, and tracking via a have_rtp_addr flag whether any valid address was established. Skip the sdp_session hook entirely when no valid address exists.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31674", "url": "https://ubuntu.com/security/CVE-2026-31674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check() Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS. rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[]. Validate addrnr during rule installation so malformed rules are rejected before the match logic can use an out-of-range value.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31428", "url": "https://ubuntu.com/security/CVE-2026-31428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD __build_packet_message() manually constructs the NFULA_PAYLOAD netlink attribute using skb_put() and skb_copy_bits(), bypassing the standard nla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes are allocated (including NLA alignment padding), only data_len bytes of actual packet data are copied. The trailing nla_padlen(data_len) bytes (1-3 when data_len is not 4-byte aligned) are never initialized, leaking stale heap contents to userspace via the NFLOG netlink socket. Replace the manual attribute construction with nla_reserve(), which handles the tailroom check, header setup, and padding zeroing via __nla_reserve(). The subsequent skb_copy_bits() fills in the payload data on top of the properly initialized attribute.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31497", "url": "https://ubuntu.com/security/CVE-2026-31497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: clamp SCO altsetting table indices btusb_work() maps the number of active SCO links to USB alternate settings through a three-entry lookup table when CVSD traffic uses transparent voice settings. The lookup currently indexes alts[] with data->sco_num - 1 without first constraining sco_num to the number of available table entries. While the table only defines alternate settings for up to three SCO links, data->sco_num comes from hci_conn_num() and is used directly. Cap the lookup to the last table entry before indexing it so the driver keeps selecting the highest supported alternate setting without reading past alts[].", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31498", "url": "https://ubuntu.com/security/CVE-2026-31498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop l2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTED state to support L2CAP reconfiguration (e.g. MTU changes). However, since both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set from the initial configuration, the reconfiguration path falls through to l2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, and retrans_list without freeing the previous allocations and sets chan->sdu to NULL without freeing the existing skb. This leaks all previously allocated ERTM resources. Additionally, l2cap_parse_conf_req() does not validate the minimum value of remote_mps derived from the RFC max_pdu_size option. A zero value propagates to l2cap_segment_sdu() where pdu_len becomes zero, causing the while loop to never terminate since len is never decremented, exhausting all available memory. Fix the double-init by skipping l2cap_ertm_init() and l2cap_chan_ready() when the channel is already in BT_CONNECTED state, while still allowing the reconfiguration parameters to be updated through l2cap_parse_conf_req(). Also add a pdu_len zero check in l2cap_segment_sdu() as a safeguard.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31507", "url": "https://ubuntu.com/security/CVE-2026-31507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffer smc_rx_splice() allocates one smc_spd_priv per pipe_buffer and stores the pointer in pipe_buffer.private. The pipe_buf_operations for these buffers used .get = generic_pipe_buf_get, which only increments the page reference count when tee(2) duplicates a pipe buffer. The smc_spd_priv pointer itself was not handled, so after tee() both the original and the cloned pipe_buffer share the same smc_spd_priv *. When both pipes are subsequently released, smc_rx_pipe_buf_release() is called twice against the same object: 1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct] 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF] KASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), which then escalates to a NULL-pointer dereference and kernel panic via smc_rx_update_consumer() when it chases the freed priv->smc pointer: BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x650 kasan_report+0xc6/0x100 smc_rx_pipe_buf_release+0x78/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smc_rx_update_consumer+0x8d/0x350 Call Trace: smc_rx_pipe_buf_release+0x121/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception Beyond the memory-safety problem, duplicating an SMC splice buffer is semantically questionable: smc_rx_update_cons() would advance the consumer cursor twice for the same data, corrupting receive-window accounting. A refcount on smc_spd_priv could fix the double-free, but the cursor-accounting issue would still need to be addressed separately. The .get callback is invoked by both tee(2) and splice_pipe_to_pipe() for partial transfers; both will now return -EFAULT. Users who need to duplicate SMC socket data must use a copy-based read path.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31679", "url": "https://ubuntu.com/security/CVE-2026-31679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: validate MPLS set/set_masked payload length validate_set() accepted OVS_KEY_ATTR_MPLS as variable-sized payload for SET/SET_MASKED actions. In action handling, OVS expects fixed-size MPLS key data (struct ovs_key_mpls). Use the already normalized key_len (masked case included) and reject non-matching MPLS action key sizes. Reject invalid MPLS action payload lengths early.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31508", "url": "https://ubuntu.com/security/CVE-2026-31508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Avoid releasing netdev before teardown completes The patch cited in the Fixes tag below changed the teardown code for OVS ports to no longer unconditionally take the RTNL. After this change, the netdev_destroy() callback can proceed immediately to the call_rcu() invocation if the IFF_OVS_DATAPATH flag is already cleared on the netdev. The ovs_netdev_detach_dev() function clears the flag before completing the unregistration, and if it gets preempted after clearing the flag (as can happen on an -rt kernel), netdev_destroy() can complete and the device can be freed before the unregistration completes. This leads to a splat like: [ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025 [ 998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0 [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90 [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246 [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000 [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0 [ 998.393944] PKRU: 55555554 [ 998.393946] Call Trace: [ 998.393949] [ 998.393952] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393961] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393975] ? dp_device_event+0x41/0x80 [openvswitch] [ 998.394009] ? __die_body.cold+0x8/0x12 [ 998.394016] ? die_addr+0x3c/0x60 [ 998.394027] ? exc_general_protection+0x16d/0x390 [ 998.394042] ? asm_exc_general_protection+0x26/0x30 [ 998.394058] ? dev_set_promiscuity+0x8d/0xa0 [ 998.394066] ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch] [ 998.394092] dp_device_event+0x41/0x80 [openvswitch] [ 998.394102] notifier_call_chain+0x5a/0xd0 [ 998.394106] unregister_netdevice_many_notify+0x51b/0xa60 [ 998.394110] rtnl_dellink+0x169/0x3e0 [ 998.394121] ? rt_mutex_slowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlink_rcv_msg+0x142/0x3f0 [ 998.394128] ? avc_has_perm_noaudit+0x69/0xf0 [ 998.394130] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 998.394132] netlink_rcv_skb+0x50/0x100 [ 998.394138] netlink_unicast+0x292/0x3f0 [ 998.394141] netlink_sendmsg+0x21b/0x470 [ 998.394145] ____sys_sendmsg+0x39d/0x3d0 [ 998.394149] ___sys_sendmsg+0x9a/0xe0 [ 998.394156] __sys_sendmsg+0x7a/0xd0 [ 998.394160] do_syscall_64+0x7f/0x170 [ 998.394162] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 998.394165] RIP: 0033:0x7fad61bf4724 [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724 [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003 [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2 ---truncated---", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31509", "url": "https://ubuntu.com/security/CVE-2026-31509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix circular locking dependency in nci_close_device nci_close_device() flushes rx_wq and tx_wq while holding req_lock. This causes a circular locking dependency because nci_rx_work() running on rx_wq can end up taking req_lock too: nci_rx_work -> nci_rx_data_packet -> nci_data_exchange_complete -> __sk_destruct -> rawsock_destruct -> nfc_deactivate_target -> nci_deactivate_target -> nci_request -> mutex_lock(&ndev->req_lock) Move the flush of rx_wq after req_lock has been released. This should safe (I think) because NCI_UP has already been cleared and the transport is closed, so the work will see it and return -ENETDOWN. NIPA has been hitting this running the nci selftest with a debug kernel on roughly 4% of the runs.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31510", "url": "https://ubuntu.com/security/CVE-2026-31510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb Before using sk pointer, check if it is null. Fix the following: KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267] CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025 Workqueue: events l2cap_info_timeout RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce veth0_macvtap: entered promiscuous mode RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: __kasan_check_byte+0x12/0x40 lock_acquire+0x79/0x2e0 lock_sock_nested+0x48/0x100 ? l2cap_sock_ready_cb+0x46/0x160 l2cap_sock_ready_cb+0x46/0x160 l2cap_conn_start+0x779/0xff0 ? __pfx_l2cap_conn_start+0x10/0x10 ? l2cap_info_timeout+0x60/0xa0 ? __pfx___mutex_lock+0x10/0x10 l2cap_info_timeout+0x68/0xa0 ? process_scheduled_works+0xa8d/0x18c0 process_scheduled_works+0xb6e/0x18c0 ? __pfx_process_scheduled_works+0x10/0x10 ? assign_work+0x3d5/0x5e0 worker_thread+0xa53/0xfc0 kthread+0x388/0x470 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x51e/0xb90 ? __pfx_ret_from_fork+0x10/0x10 veth1_macvtap: entered promiscuous mode ? __switch_to+0xc7d/0x1450 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- batman_adv: batadv0: Interface activated: batadv_slave_0 batman_adv: batadv0: Interface activated: batadv_slave_1 netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce ieee80211 phy39: Selected rate control algorithm 'minstrel_ht' RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43069", "url": "https://ubuntu.com/security/CVE-2026-43069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_ll: Fix firmware leak on error path Smatch reports: drivers/bluetooth/hci_ll.c:587 download_firmware() warn: 'fw' from request_firmware() not released on lines: 544. In download_firmware(), if request_firmware() succeeds but the returned firmware content is invalid (no data or zero size), the function returns without releasing the firmware, resulting in a resource leak. Fix this by calling release_firmware() before returning when request_firmware() succeeded but the firmware content is invalid.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31408", "url": "https://ubuntu.com/security/CVE-2026-31408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold sco_recv_frame() reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold a reference under the lock. Fix by using sco_sock_hold() to take a reference before releasing the lock, and adding sock_put() on all exit paths.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-31512", "url": "https://ubuntu.com/security/CVE-2026-31512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv() l2cap_ecred_data_rcv() reads the SDU length field from skb->data using get_unaligned_le16() without first verifying that skb contains at least L2CAP_SDULEN_SIZE (2) bytes. When skb->len is less than 2, this reads past the valid data in the skb. The ERTM reassembly path correctly calls pskb_may_pull() before reading the SDU length (l2cap_reassemble_sdu, L2CAP_SAR_START case). Apply the same validation to the Enhanced Credit Based Flow Control data path.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31515", "url": "https://ubuntu.com/security/CVE-2026-31515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_key: validate families in pfkey_send_migrate() syzbot was able to trigger a crash in skb_put() [1] Issue is that pfkey_send_migrate() does not check old/new families, and that set_ipsecrequest() @family argument was truncated, thus possibly overfilling the skb. Validate families early, do not wait set_ipsecrequest(). [1] skbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev: kernel BUG at net/core/skbuff.c:214 ! Call Trace: skb_over_panic net/core/skbuff.c:219 [inline] skb_put+0x159/0x210 net/core/skbuff.c:2655 skb_put_zero include/linux/skbuff.h:2788 [inline] set_ipsecrequest net/key/af_key.c:3532 [inline] pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636 km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848 xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705 xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31518", "url": "https://ubuntu.com/security/CVE-2026-31518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: esp: fix skb leak with espintcp and async crypto When the TX queue for espintcp is full, esp_output_tail_tcp will return an error and not free the skb, because with synchronous crypto, the common xfrm output code will drop the packet for us. With async crypto (esp_output_done), we need to drop the skb when esp_output_tail_tcp returns an error.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31521", "url": "https://ubuntu.com/security/CVE-2026-31521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: module: Fix kernel panic when a symbol st_shndx is out of bounds The module loader doesn't check for bounds of the ELF section index in simplify_symbols(): for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) { \t\tconst char *name = info->strtab + sym[i].st_name; \t\tswitch (sym[i].st_shndx) { \t\tcase SHN_COMMON: \t\t[...] \t\tdefault: \t\t\t/* Divert to percpu allocation if a percpu var. */ \t\t\tif (sym[i].st_shndx == info->index.pcpu) \t\t\t\tsecbase = (unsigned long)mod_percpu(mod); \t\t\telse /** HERE --> **/\t\tsecbase = info->sechdrs[sym[i].st_shndx].sh_addr; \t\t\tsym[i].st_value += secbase; \t\t\tbreak; \t\t} \t} A symbol with an out-of-bounds st_shndx value, for example 0xffff (known as SHN_XINDEX or SHN_HIRESERVE), may cause a kernel panic: BUG: unable to handle page fault for address: ... RIP: 0010:simplify_symbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exception This can happen when module ELF is legitimately using SHN_XINDEX or when it is corrupted. Add a bounds check in simplify_symbols() to validate that st_shndx is within the valid range before using it. This issue was discovered due to a bug in llvm-objcopy, see relevant discussion for details [1]. [1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31522", "url": "https://ubuntu.com/security/CVE-2026-31522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: avoid memory leak in magicmouse_report_fixup() The magicmouse_report_fixup() function was returning a newly kmemdup()-allocated buffer, but never freeing it. The caller of report_fixup() does not take ownership of the returned pointer, but it *is* permitted to return a sub-portion of the input rdesc, whose lifetime is managed by the caller.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31523", "url": "https://ubuntu.com/security/CVE-2026-31523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-pci: ensure we're polling a polled queue A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31524", "url": "https://ubuntu.com/security/CVE-2026-31524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: asus: avoid memory leak in asus_report_fixup() The asus_report_fixup() function was returning a newly allocated kmemdup()-allocated buffer, but never freeing it. Switch to devm_kzalloc() to ensure the memory is managed and freed automatically when the device is removed. The caller of report_fixup() does not take ownership of the returned pointer, but it is permitted to return a pointer whose lifetime is at least that of the input buffer. Also fix a harmless out-of-bounds read by copying only the original descriptor size.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31788", "url": "https://ubuntu.com/security/CVE-2026-31788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: restrict usage in unprivileged domU The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains. In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature. The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest. Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today. The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot. This is XSA-482 --- V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich)", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31540", "url": "https://ubuntu.com/security/CVE-2026-31540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Check set_default_submission() before deferencing When the i915 driver firmware binaries are not present, the set_default_submission pointer is not set. This pointer is dereferenced during suspend anyways. Add a check to make sure it is set before dereferencing. [ 23.289926] PM: suspend entry (deep) [ 23.293558] Filesystems sync: 0.000 seconds [ 23.298010] Freezing user space processes [ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds) [ 23.309766] OOM killer disabled. [ 23.313027] Freezing remaining freezable tasks [ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 23.342038] serial 00:05: disabled [ 23.345719] serial 00:02: disabled [ 23.349342] serial 00:01: disabled [ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 23.361635] ata1.00: Entering standby power mode [ 23.368863] ata2.00: Entering standby power mode [ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 23.452194] #PF: supervisor instruction fetch in kernel mode [ 23.457896] #PF: error_code(0x0010) - not-present page [ 23.463065] PGD 0 P4D 0 [ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI [ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary) [ 23.482512] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 23.496511] Workqueue: async async_run_entry_fn [ 23.501087] RIP: 0010:0x0 [ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246 [ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f [ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000 [ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff [ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8 [ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68 [ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000 [ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0 [ 23.572539] PKRU: 55555554 [ 23.575281] Call Trace: [ 23.577770] [ 23.579905] intel_engines_reset_default_submission+0x42/0x60 [ 23.585695] __intel_gt_unset_wedged+0x191/0x200 [ 23.590360] intel_gt_unset_wedged+0x20/0x40 [ 23.594675] gt_sanitize+0x15e/0x170 [ 23.598290] i915_gem_suspend_late+0x6b/0x180 [ 23.602692] i915_drm_suspend_late+0x35/0xf0 [ 23.607008] ? __pfx_pci_pm_suspend_late+0x10/0x10 [ 23.611843] dpm_run_callback+0x78/0x1c0 [ 23.615817] device_suspend_late+0xde/0x2e0 [ 23.620037] async_suspend_late+0x18/0x30 [ 23.624082] async_run_entry_fn+0x25/0xa0 [ 23.628129] process_one_work+0x15b/0x380 [ 23.632182] worker_thread+0x2a5/0x3c0 [ 23.635973] ? __pfx_worker_thread+0x10/0x10 [ 23.640279] kthread+0xf6/0x1f0 [ 23.643464] ? __pfx_kthread+0x10/0x10 [ 23.647263] ? __pfx_kthread+0x10/0x10 [ 23.651045] ret_from_fork+0x131/0x190 [ 23.654837] ? __pfx_kthread+0x10/0x10 [ 23.658634] ret_from_fork_asm+0x1a/0x30 [ 23.662597] [ 23.664826] Modules linked in: [ 23.667914] CR2: 0000000000000000 [ 23.671271] ------------[ cut here ]------------ (cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad)", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23434", "url": "https://ubuntu.com/security/CVE-2026-23434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: serialize lock/unlock against other NAND operations nand_lock() and nand_unlock() call into chip->ops.lock_area/unlock_area without holding the NAND device lock. On controllers that implement SET_FEATURES via multiple low-level PIO commands, these can race with concurrent UBI/UBIFS background erase/write operations that hold the device lock, resulting in cmd_pending conflicts on the NAND controller. Add nand_get_device()/nand_release_device() around the lock/unlock operations to serialize them against all other NAND controller access.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23398", "url": "https://ubuntu.com/security/CVE-2026-23398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: fix NULL pointer dereference in icmp_tag_validation() icmp_tag_validation() unconditionally dereferences the result of rcu_dereference(inet_protos[proto]) without checking for NULL. The inet_protos[] array is sparse -- only about 15 of 256 protocol numbers have registered handlers. When ip_no_pmtu_disc is set to 3 (hardened PMTU mode) and the kernel receives an ICMP Fragmentation Needed error with a quoted inner IP header containing an unregistered protocol number, the NULL dereference causes a kernel panic in softirq context. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) Add a NULL check before accessing icmp_strict_tag_validation. If the protocol has no registered handler, return false since it cannot perform strict tag validation.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-23438", "url": "https://ubuntu.com/security/CVE-2026-23438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: guard flow control update with global_tx_fc in buffer switching mvpp2_bm_switch_buffers() unconditionally calls mvpp2_bm_pool_update_priv_fc() when switching between per-cpu and shared buffer pool modes. This function programs CM3 flow control registers via mvpp2_cm3_read()/mvpp2_cm3_write(), which dereference priv->cm3_base without any NULL check. When the CM3 SRAM resource is not present in the device tree (the third reg entry added by commit 60523583b07c (\"dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree\")), priv->cm3_base remains NULL and priv->global_tx_fc is false. Any operation that triggers mvpp2_bm_switch_buffers(), for example an MTU change that crosses the jumbo frame threshold, will crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2_cm3_read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2_bm_pool_update_fc+0x40/0x12c mvpp2_bm_pool_update_priv_fc+0x94/0xd8 mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0 mvpp2_change_mtu+0x140/0x380 __dev_set_mtu+0x1c/0x38 dev_set_mtu_ext+0x78/0x118 dev_set_mtu+0x48/0xa8 dev_ifsioc+0x21c/0x43c dev_ioctl+0x2d8/0x42c sock_ioctl+0x314/0x378 Every other flow control call site in the driver already guards hardware access with either priv->global_tx_fc or port->tx_fc. mvpp2_bm_switch_buffers() is the only place that omits this check. Add the missing priv->global_tx_fc guard to both the disable and re-enable calls in mvpp2_bm_switch_buffers(), consistent with the rest of the driver.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23397", "url": "https://ubuntu.com/security/CVE-2026-23397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfnetlink_osf: validate individual option lengths in fingerprints nfnl_osf_add_callback() validates opt_num bounds and string NUL-termination but does not check individual option length fields. A zero-length option causes nf_osf_match_one() to enter the option matching loop even when foptsize sums to zero, which matches packets with no TCP options where ctx->optp is NULL: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:227) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:293) nf_hook_slow (net/netfilter/core.c:623) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) Additionally, an MSS option (kind=2) with length < 4 causes out-of-bounds reads when nf_osf_match_one() unconditionally accesses optp[2] and optp[3] for MSS value extraction. While RFC 9293 section 3.2 specifies that the MSS option is always exactly 4 bytes (Kind=2, Length=4), the check uses \"< 4\" rather than \"!= 4\" because lengths greater than 4 do not cause memory safety issues -- the buffer is guaranteed to be at least foptsize bytes by the ctx->optsize == foptsize check. Reject fingerprints where any option has zero length, or where an MSS option has length less than 4, at add time rather than trusting these values in the packet matching hot path.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-31546", "url": "https://ubuntu.com/security/CVE-2026-31546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL deref in bond_debug_rlb_hash_show rlb_clear_slave intentionally keeps RLB hash-table entries on the rx_hashtbl_used_head list with slave set to NULL when no replacement slave is available. However, bond_debug_rlb_hash_show visites client_info->slave without checking if it's NULL. Other used-list iterators in bond_alb.c already handle this NULL-slave state safely: - rlb_update_client returns early on !client_info->slave - rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalance compare slave values before visiting - lb_req_update_subnet_clients continues if slave is NULL The following NULL deref crash can be trigger in bond_debug_rlb_hash_show: [ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seq_read_iter (fs/seq_file.c:231) [ 1.296341] seq_read (fs/seq_file.c:164) [ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfs_read (fs/read_write.c:572) [ 1.296981] ksys_read (fs/read_write.c:717) [ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) [ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add a NULL check and print \"(none)\" for entries with no assigned slave.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23439", "url": "https://ubuntu.com/security/CVE-2026-23439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n When CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0 (success) without actually creating a socket. Callers such as fou_create() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference. The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764) [...] Call Trace: genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130) This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23396", "url": "https://ubuntu.com/security/CVE-2026-23396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix NULL deref in mesh_matches_local() mesh_matches_local() unconditionally dereferences ie->mesh_config to compare mesh configuration parameters. When called from mesh_rx_csa_frame(), the parsed action-frame elements may not contain a Mesh Configuration IE, leaving ie->mesh_config NULL and triggering a kernel NULL pointer dereference. The other two callers are already safe: - ieee80211_mesh_rx_bcn_presp() checks !elems->mesh_config before calling mesh_matches_local() - mesh_plink_get_event() is only reached through mesh_process_plink_frame(), which checks !elems->mesh_config, too mesh_rx_csa_frame() is the only caller that passes raw parsed elements to mesh_matches_local() without guarding mesh_config. An adjacent attacker can exploit this by sending a crafted CSA action frame that includes a valid Mesh ID IE but omits the Mesh Configuration IE, crashing the kernel. The captured crash log: Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events_unbound cfg80211_wiphy_work [...] Call Trace: ? __pfx_mesh_matches_local (net/mac80211/mesh.c:65) ieee80211_mesh_rx_queued_mgmt (net/mac80211/mesh.c:1686) [...] ieee80211_iface_work (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802) [...] cfg80211_wiphy_work (net/wireless/core.c:426) process_one_work (net/kernel/workqueue.c:3280) ? assign_work (net/kernel/workqueue.c:1219) worker_thread (net/kernel/workqueue.c:3352) ? __pfx_worker_thread (net/kernel/workqueue.c:3385) kthread (net/kernel/kthread.c:436) [...] ret_from_fork_asm (net/arch/x86/entry/entry_64.S:255) This patch adds a NULL check for ie->mesh_config at the top of mesh_matches_local() to return false early when the Mesh Configuration IE is absent.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-23446", "url": "https://ubuntu.com/security/CVE-2026-23446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: Do not perform PM inside suspend callback syzbot reports \"task hung in rpm_resume\" This is caused by aqc111_suspend calling the PM variant of its write_cmd routine. The simplified call trace looks like this: rpm_suspend() usb_suspend_both() - here udev->dev.power.runtime_status == RPM_SUSPENDING aqc111_suspend() - called for the usb device interface aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() - here we call rpm_resume() on our parent rpm_resume() - Here we wait for a status change that will never happen. At this point we block another task which holds rtnl_lock and locks up the whole networking stack. Fix this by replacing the write_cmd calls with their _nopm variants", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23452", "url": "https://ubuntu.com/security/CVE-2026-23452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM: runtime: Fix a race condition related to device removal The following code in pm_runtime_work() may dereference the dev->parent pointer after the parent device has been freed: \t/* Maybe the parent is now able to suspend. */ \tif (parent && !parent->power.ignore_children) { \t\tspin_unlock(&dev->power.lock); \t\tspin_lock(&parent->power.lock); \t\trpm_idle(parent, RPM_ASYNC); \t\tspin_unlock(&parent->power.lock); \t\tspin_lock(&dev->power.lock); \t} Fix this by inserting a flush_work() call in pm_runtime_remove(). Without this patch blktest block/001 triggers the following complaint sporadically: BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160 Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081 Workqueue: pm pm_runtime_work Call Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0 __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160 _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 Allocated by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50 __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23454", "url": "https://ubuntu.com/security/CVE-2026-23454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: fix use-after-free in mana_hwc_destroy_channel() by reordering teardown A potential race condition exists in mana_hwc_destroy_channel() where hwc->caller_ctx is freed before the HWC's Completion Queue (CQ) and Event Queue (EQ) are destroyed. This allows an in-flight CQ interrupt handler to dereference freed memory, leading to a use-after-free or NULL pointer dereference in mana_hwc_handle_resp(). mana_smc_teardown_hwc() signals the hardware to stop but does not synchronize against IRQ handlers already executing on other CPUs. The IRQ synchronization only happens in mana_hwc_destroy_cq() via mana_gd_destroy_eq() -> mana_gd_deregister_irq(). Since this runs after kfree(hwc->caller_ctx), a concurrent mana_hwc_rx_event_handler() can dereference freed caller_ctx (and rxq->msg_buf) in mana_hwc_handle_resp(). Fix this by reordering teardown to reverse-of-creation order: destroy the TX/RX work queues and CQ/EQ before freeing hwc->caller_ctx. This ensures all in-flight interrupt handlers complete before the memory they access is freed.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23391", "url": "https://ubuntu.com/security/CVE-2026-23391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_CT: drop pending enqueued packets on template removal Templates refer to objects that can go away while packets are sitting in nfqueue refer to: - helper, this can be an issue on module removal. - timeout policy, nfnetlink_cttimeout might remove it. The use of templates with zone and event cache filter are safe, since this just copies values. Flush these enqueued packets in case the template rule gets removed.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43060", "url": "https://ubuntu.com/security/CVE-2026-43060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: drop pending enqueued packets on removal Packets sitting in nfqueue might hold a reference to: - templates that specify the conntrack zone, because a percpu area is used and module removal is possible. - conntrack timeout policies and helper, where object removal leave a stale reference. Since these objects can just go away, drop enqueued packets to avoid stale reference to them. If there is a need for finer grain removal, this logic can be revisited to make selective packet drop upon dependencies.", "cve_priority": "high", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2025-68206", "url": "https://ubuntu.com/security/CVE-2025-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: add seqadj extension for natted connections Sequence adjustment may be required for FTP traffic with PASV/EPSV modes. due to need to re-write packet payload (IP, port) on the ftp control connection. This can require changes to the TCP length and expected seq / ack_seq. The easiest way to reproduce this issue is with PASV mode. Example ruleset: table inet ftp_nat { ct helper ftp_helper { type \"ftp\" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set \"ftp_helper\" } } table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { \t\t\t192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { \t\t\t192.168.13.2 : 192.168.100.1/32 } } } Note that the ftp helper gets assigned *after* the dnat setup. The inverse (nat after helper assign) is handled by an existing check in nf_nat_setup_info() and will not show the problem. Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ ftp nat changes do not work as expected in this case: Connected to 192.168.100.1. [..] ftp> epsv EPSV/EPRT on IPv4 off. ftp> ls 227 Entering passive mode (192,168,100,1,209,129). 421 Service not available, remote server has closed connection. Kernel logs: Missing nfct_seqadj_ext_add() setup call WARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41 [..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 .. Fix this by adding the required extension when a conntrack helper is assigned to a connection that has a nat binding.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-23456", "url": "https://ubuntu.com/security/CVE-2026-23456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case In decode_int(), the CONS case calls get_bits(bs, 2) to read a length value, then calls get_uint(bs, len) without checking that len bytes remain in the buffer. The existing boundary check only validates the 2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint() reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte slab-out-of-bounds read. Add a boundary check for len bytes after get_bits() and before get_uint().", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23457", "url": "https://ubuntu.com/security/CVE-2026-23457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp() sip_help_tcp() parses the SIP Content-Length header with simple_strtoul(), which returns unsigned long, but stores the result in unsigned int clen. On 64-bit systems, values exceeding UINT_MAX are silently truncated before computing the SIP message boundary. For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32, causing the parser to miscalculate where the current message ends. The loop then treats trailing data in the TCP segment as a second SIP message and processes it through the SDP parser. Fix this by changing clen to unsigned long to match the return type of simple_strtoul(), and reject Content-Length values that exceed the remaining TCP payload length.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23458", "url": "https://ubuntu.com/security/CVE-2026-23458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct() ctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for the netlink dump callback ctnetlink_exp_ct_dump_table(), but drops the conntrack reference immediately after netlink_dump_start(). When the dump spans multiple rounds, the second recvmsg() triggers the dump callback which dereferences the now-freed conntrack via nfct_help(ct), leading to a use-after-free on ct->ext. The bug is that the netlink_dump_control has no .start or .done callbacks to manage the conntrack reference across dump rounds. Other dump functions in the same file (e.g. ctnetlink_get_conntrack) properly use .start/.done callbacks for this purpose. Fix this by adding .start and .done callbacks that hold and release the conntrack reference for the duration of the dump, and move the nfct_help() call after the cb->args[0] early-return check in the dump callback to avoid dereferencing ct->ext unnecessarily. BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133 CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 ? aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0 Allocated by task 133: kmem_cache_alloc_noprof+0x134/0x440 __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180 Freed by task 0: slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2025-39764", "url": "https://ubuntu.com/security/CVE-2025-39764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: remove refcounting in expectation dumpers Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption. AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcount_inc_not_zero(&exp->use)) to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2026-23460", "url": "https://ubuntu.com/security/CVE-2026-23460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect syzkaller reported a bug [1], and the reproducer is available at [2]. ROSE sockets use four sk->sk_state values: TCP_CLOSE, TCP_LISTEN, TCP_SYN_SENT, and TCP_ESTABLISHED. rose_connect() already rejects calls for TCP_ESTABLISHED (-EISCONN) and TCP_CLOSE with SS_CONNECTING (-ECONNREFUSED), but lacks a check for TCP_SYN_SENT. When rose_connect() is called a second time while the first connection attempt is still in progress (TCP_SYN_SENT), it overwrites rose->neighbour via rose_get_neigh(). If that returns NULL, the socket is left with rose->state == ROSE_STATE_1 but rose->neighbour == NULL. When the socket is subsequently closed, rose_release() sees ROSE_STATE_1 and calls rose_write_internal() -> rose_transmit_link(skb, NULL), causing a NULL pointer dereference. Per connect(2), a second connect() while a connection is already in progress should return -EALREADY. Add this missing check for TCP_SYN_SENT to complete the state validation in rose_connect(). [1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271 [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23462", "url": "https://ubuntu.com/security/CVE-2026-23462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: Fix possible UAF This fixes the following trace caused by not dropping l2cap_conn reference when user->remove callback is called: [ 97.809249] l2cap_conn_free: freeing conn ffff88810a171c00 [ 97.809907] CPU: 1 UID: 0 PID: 1419 Comm: repro_standalon Not tainted 7.0.0-rc1-dirty #14 PREEMPT(lazy) [ 97.809935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 97.809947] Call Trace: [ 97.809954] [ 97.809961] dump_stack_lvl (lib/dump_stack.c:122) [ 97.809990] l2cap_conn_free (net/bluetooth/l2cap_core.c:1808) [ 97.810017] l2cap_conn_del (./include/linux/kref.h:66 net/bluetooth/l2cap_core.c:1821 net/bluetooth/l2cap_core.c:1798) [ 97.810055] l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7347 (discriminator 1) net/bluetooth/l2cap_core.c:7340 (discriminator 1)) [ 97.810086] ? __pfx_l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7341) [ 97.810117] hci_conn_hash_flush (./include/net/bluetooth/hci_core.h:2152 (discriminator 2) net/bluetooth/hci_conn.c:2644 (discriminator 2)) [ 97.810148] hci_dev_close_sync (net/bluetooth/hci_sync.c:5360) [ 97.810180] ? __pfx_hci_dev_close_sync (net/bluetooth/hci_sync.c:5285) [ 97.810212] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810242] ? up_write (./arch/x86/include/asm/atomic64_64.h:87 (discriminator 5) ./include/linux/atomic/atomic-arch-fallback.h:2852 (discriminator 5) ./include/linux/atomic/atomic-long.h:268 (discriminator 5) ./include/linux/atomic/atomic-instrumented.h:3391 (discriminator 5) kernel/locking/rwsem.c:1385 (discriminator 5) kernel/locking/rwsem.c:1643 (discriminator 5)) [ 97.810267] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810290] ? rcu_is_watching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/context_tracking.h:128 kernel/rcu/tree.c:752) [ 97.810320] hci_unregister_dev (net/bluetooth/hci_core.c:504 net/bluetooth/hci_core.c:2716) [ 97.810346] vhci_release (drivers/bluetooth/hci_vhci.c:691) [ 97.810375] ? __pfx_vhci_release (drivers/bluetooth/hci_vhci.c:678) [ 97.810404] __fput (fs/file_table.c:470) [ 97.810430] task_work_run (kernel/task_work.c:235) [ 97.810451] ? __pfx_task_work_run (kernel/task_work.c:201) [ 97.810472] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810495] ? do_raw_spin_unlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlock_debug.c:142 (discriminator 5)) [ 97.810527] do_exit (kernel/exit.c:972) [ 97.810547] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810574] ? __pfx_do_exit (kernel/exit.c:897) [ 97.810594] ? lock_acquire (kernel/locking/lockdep.c:470 (discriminator 6) kernel/locking/lockdep.c:5870 (discriminator 6) kernel/locking/lockdep.c:5825 (discriminator 6)) [ 97.810616] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810639] ? do_raw_spin_lock (kernel/locking/spinlock_debug.c:95 (discriminator 4) kernel/locking/spinlock_debug.c:118 (discriminator 4)) [ 97.810664] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810688] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1)) [ 97.810721] do_group_exit (kernel/exit.c:1093) [ 97.810745] get_signal (kernel/signal.c:3007 (discriminator 1)) [ 97.810772] ? security_file_permission (./arch/x86/include/asm/jump_label.h:37 security/security.c:2366) [ 97.810803] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810826] ? vfs_read (fs/read_write.c:555) [ 97.810854] ? __pfx_get_signal (kernel/signal.c:2800) [ 97.810880] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810905] ? __pfx_vfs_read (fs/read_write.c:555) [ 97.810932] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810960] arch_do_signal_or_restart (arch/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31551", "url": "https://ubuntu.com/security/CVE-2026-31551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Fix static_branch_dec() underflow for aql_disable. syzbot reported static_branch_dec() underflow in aql_enable_write(). [0] The problem is that aql_enable_write() does not serialise concurrent write()s to the debugfs. aql_enable_write() checks static_key_false(&aql_disable.key) and later calls static_branch_inc() or static_branch_dec(), but the state may change between the two calls. aql_disable does not need to track inc/dec. Let's use static_branch_enable() and static_branch_disable(). [0]: val == 0 WARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288 Modules linked in: CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full) Tainted: [U]=USER, [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311 Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 <0f> 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00 RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4 RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a R13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98 FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0 Call Trace: __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline] __static_key_slow_dec kernel/jump_label.c:321 [inline] static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336 aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343 short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383 vfs_write+0x2aa/0x1070 fs/read_write.c:684 ksys_pwrite64 fs/read_write.c:793 [inline] __do_sys_pwrite64 fs/read_write.c:801 [inline] __se_sys_pwrite64 fs/read_write.c:798 [inline] __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f530cf9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012 RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010 RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000 R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978 ", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23463", "url": "https://ubuntu.com/security/CVE-2026-23463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: fix race condition in qman_destroy_fq When QMAN_FQ_FLAG_DYNAMIC_FQID is set, there's a race condition between fq_table[fq->idx] state and freeing/allocating from the pool and WARN_ON(fq_table[fq->idx]) in qman_create_fq() gets triggered. Indeed, we can have: Thread A Thread B qman_destroy_fq() qman_create_fq() qman_release_fqid() qman_shutdown_fq() gen_pool_free() -- At this point, the fqid is available again -- qman_alloc_fqid() -- so, we can get the just-freed fqid in thread B -- fq->fqid = fqid; fq->idx = fqid * 2; WARN_ON(fq_table[fq->idx]); fq_table[fq->idx] = fq; fq_table[fq->idx] = NULL; And adding some logs between qman_release_fqid() and fq_table[fq->idx] = NULL makes the WARN_ON() trigger a lot more. To prevent that, ensure that fq_table[fq->idx] is set to NULL before gen_pool_free() is called by using smp_wmb().", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31683", "url": "https://ubuntu.com/security/CVE-2026-31683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: avoid OGM aggregation when skb tailroom is insufficient When OGM aggregation state is toggled at runtime, an existing forwarded packet may have been allocated with only packet_len bytes, while a later packet can still be selected for aggregation. Appending in this case can hit skb_put overflow conditions. Reject aggregation when the target skb tailroom cannot accommodate the new packet. The caller then falls back to creating a new forward packet instead of appending.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31550", "url": "https://ubuntu.com/security/CVE-2026-31550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: bcm: bcm2835-power: Increase ASB control timeout The bcm2835_asb_control() function uses a tight polling loop to wait for the ASB bridge to acknowledge a request. During intensive workloads, this handshake intermittently fails for V3D's master ASB on BCM2711, resulting in \"Failed to disable ASB master for v3d\" errors during runtime PM suspend. As a consequence, the failed power-off leaves V3D in a broken state, leading to bus faults or system hangs on later accesses. As the timeout is insufficient in some scenarios, increase the polling timeout from 1us to 5us, which is still negligible in the context of a power domain transition. Also, replace the open-coded ktime_get_ns()/ cpu_relax() polling loop with readl_poll_timeout_atomic().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23368", "url": "https://ubuntu.com/security/CVE-2026-23368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: register phy led_triggers during probe to avoid AB-BA deadlock There is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and LED_TRIGGER_PHY are enabled: [ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc <-- Trying to get lock \"triggers_list_lock\" via down_write(&triggers_list_lock); [ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234 [ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c [ 1362.065489] [<80651fc4>] phylink_fwnode_phy_connect+0x15c/0x23c [ 1362.071480] [<8066ee18>] mtk_open+0x7c/0xba0 [ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0 [ 1362.080384] [<806d7668>] __dev_change_flags+0x244/0x24c [ 1362.085598] [<806d7698>] dev_change_flags+0x28/0x78 [ 1362.090528] [<807150e4>] dev_ioctl+0x4c0/0x654 <-- Hold lock \"rtnl_mutex\" by calling rtnl_lock(); [ 1362.094985] [<80694360>] sock_ioctl+0x2f4/0x4e0 [ 1362.099567] [<802e9c4c>] sys_ioctl+0x32c/0xd8c [ 1362.104022] [<80014504>] syscall_common+0x34/0x58 Here LED_TRIGGER_PHY is registering LED triggers during phy_attach while holding RTNL and then taking triggers_list_lock. [ 1362.191101] [<806c2640>] register_netdevice_notifier+0x60/0x168 <-- Trying to get lock \"rtnl_mutex\" via rtnl_lock(); [ 1362.197073] [<805504ac>] netdev_trig_activate+0x194/0x1e4 [ 1362.202490] [<8054e28c>] led_trigger_set+0x1d4/0x360 <-- Hold lock \"triggers_list_lock\" by down_read(&triggers_list_lock); [ 1362.207511] [<8054eb38>] led_trigger_write+0xd8/0x14c [ 1362.212566] [<80381d98>] sysfs_kf_bin_write+0x80/0xbc [ 1362.217688] [<8037fcd8>] kernfs_fop_write_iter+0x17c/0x28c [ 1362.223174] [<802cbd70>] vfs_write+0x21c/0x3c4 [ 1362.227712] [<802cc0c4>] ksys_write+0x78/0x12c [ 1362.232164] [<80014504>] syscall_common+0x34/0x58 Here LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takes triggers_list_lock and then RTNL. A classical AB-BA deadlock. phy_led_triggers_registers() does not require the RTNL, it does not make any calls into the network stack which require protection. There is also no requirement the PHY has been attached to a MAC, the triggers only make use of phydev state. This allows the call to phy_led_triggers_registers() to be placed elsewhere. PHY probe() and release() don't hold RTNL, so solving the AB-BA deadlock.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23303", "url": "https://ubuntu.com/security/CVE-2026-23303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Don't log plaintext credentials in cifs_set_cifscreds When debug logging is enabled, cifs_set_cifscreds() logs the key payload and exposes the plaintext username and password. Remove the debug log to avoid exposing credentials.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23335", "url": "https://ubuntu.com/security/CVE-2026-23335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah() struct irdma_create_ah_resp { // 8 bytes, no padding __u32 ah_id; // offset 0 - SET (uresp.ah_id = ah->sc_ah.ah_info.ah_idx) __u8 rsvd[4]; // offset 4 - NEVER SET <- LEAK }; rsvd[4]: 4 bytes of stack memory leaked unconditionally. Only ah_id is assigned before ib_respond_udata(). The reserved members of the structure were not zeroed.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23336", "url": "https://ubuntu.com/security/CVE-2026-23336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel rfkill_block work in wiphy_unregister() There is a use-after-free error in cfg80211_shutdown_all_interfaces found by syzkaller: BUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220 Read of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326 CPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events cfg80211_rfkill_block_work Call Trace: dump_stack_lvl+0x116/0x1f0 print_report+0xcd/0x630 kasan_report+0xe0/0x110 cfg80211_shutdown_all_interfaces+0x213/0x220 cfg80211_rfkill_block_work+0x1e/0x30 process_one_work+0x9cf/0x1b70 worker_thread+0x6c8/0xf10 kthread+0x3c5/0x780 ret_from_fork+0x56d/0x700 ret_from_fork_asm+0x1a/0x30 The problem arises due to the rfkill_block work is not cancelled when wiphy is being unregistered. In order to fix the issue cancel the corresponding work in wiphy_unregister(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23281", "url": "https://ubuntu.com/security/CVE-2026-23281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix use-after-free in lbs_free_adapter() The lbs_free_adapter() function uses timer_delete() (non-synchronous) for both command_timer and tx_lockup_timer before the structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If a timer callback is executing when lbs_free_adapter() is called, the callback will access freed memory since lbs_cfg_free() frees the containing structure immediately after lbs_free_adapter() returns. Both timer callbacks (lbs_cmd_timeout_handler and lbs_tx_lockup_handler) access priv->driver_lock, priv->cur_cmd, priv->dev, and other fields, which would all be use-after-free violations. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning. This bug was introduced in commit 8f641d93c38a (\"libertas: detect TX lockups and reset hardware\") where del_timer() was used instead of del_timer_sync() in the cleanup path. The command_timer has had the same issue since the driver was first written.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-38562", "url": "https://ubuntu.com/security/CVE-2025-38562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference error in generate_encryptionkey If client send two session setups with krb5 authenticate to ksmbd, null pointer dereference error in generate_encryptionkey could happen. sess->Preauth_HashValue is set to NULL if session is valid. So this patch skip generate encryption key if session is valid.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2026-45920", "url": "https://ubuntu.com/security/CVE-2026-45920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix dirtyclusters double decrement on fs shutdown fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count: WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4] Tracing the failure shows that the warning fires due to an s_dirtyclusters_counter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4_mb_mark_diskspace_used() and the caller ext4_mb_new_blocks(). First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4_handle_dirty_metadata() call(s) made from ext4_mb_mark_context(). The changed value is non-zero at this point, so ext4_mb_mark_diskspace_used() does not exit after the error bubbles up from ext4_mb_mark_context(). Instead, the former decrements both cluster counters and returns the error up to ext4_mb_new_blocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency. To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4_mb_new_blocks() is responsible for acquiring cluster reservation (via ext4_claim_free_clusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45899", "url": "https://ubuntu.com/security/CVE-2026-45899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop extent cache when splitting extent fails When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45985", "url": "https://ubuntu.com/security/CVE-2026-45985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues. Assume we have an unwritten extent, and then DIO writes the second half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set. Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree. [0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone. Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45924", "url": "https://ubuntu.com/security/CVE-2026-45924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths There are two places where ksmbd_vfs_kern_path_end_removing() needs to be called in order to balance what the corresponding successful call to ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and put the taken references. Otherwise there might be potential deadlocks and unbalanced locks which are caught like: BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work 2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660 CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30 Found by Linux Verification Center (linuxtesting.org).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23227", "url": "https://ubuntu.com/security/CVE-2026-23227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/free Exynos Virtual Display driver performs memory alloc/free operations without lock protection, which easily causes concurrency problem. For example, use-after-free can occur in race scenario like this: ``` \tCPU0\t\t\t\tCPU1\t\t\t\tCPU2 \t----\t\t\t\t----\t\t\t\t---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... \t\t\t\t\t\t\t\tdrm_mode_getconnector() \t\t\t\t\t\t\t\t drm_helper_probe_single_connector_modes() \t\t\t\t\t\t\t\t vidi_get_modes() \t\t\t\t\t\t\t\t if (ctx->raw_edid) // true \t\t\t\t\t\t\t\t drm_edid_dup(ctx->raw_edid); \t\t\t\t\t\t\t\t if (!drm_edid) // false \t\t\t\t\t\t\t\t ... \t\t\t\tvidi_connection_ioctl() \t\t\t\t if (vidi->connection) // false \t\t\t\t drm_edid_free(ctx->raw_edid); // free drm_edid \t\t\t\t ... \t\t\t\t\t\t\t\t drm_edid_alloc(drm_edid->edid) \t\t\t\t\t\t\t\t kmemdup(edid); // UAF!! \t\t\t\t\t\t\t\t ... ``` To prevent these vulns, at least in vidi_context, member variables related to memory alloc/free should be protected with ctx->lock.", "cve_priority": "high", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-45958", "url": "https://ubuntu.com/security/CVE-2026-45958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: fix to avoid directly dereferencing user pointer In vidi_connection_ioctl(), vidi->edid(user pointer) is directly dereferenced in the kernel. This allows arbitrary kernel memory access from the user space, so instead of directly accessing the user pointer in the kernel, we should modify it to copy edid to kernel memory using copy_from_user() and use it.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45956", "url": "https://ubuntu.com/security/CVE-2026-45956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl() vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to obtain a struct vidi_context pointer. However, drm_dev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device. This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more. To resolve this issue, we need to store/delete the vidi device pointer in exynos_drm_private->vidi_dev during bind/unbind, and then read this exynos_drm_private->vidi_dev within ioctl() to obtain the correct struct vidi_context pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23100", "url": "https://ubuntu.com/security/CVE-2026-23100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb_pmd_shared() Patch series \"mm/hugetlb: fixes for PMD table sharing (incl. using mmu_gather)\", v3. One functional fix, one performance regression fix, and two related comment fixes. I cleaned up my prototype I recently shared [1] for the performance fix, deferring most of the cleanups I had in the prototype to a later point. While doing that I identified the other things. The goal of this patch set is to be backported to stable trees \"fairly\" easily. At least patch #1 and #4. Patch #1 fixes hugetlb_pmd_shared() not detecting any sharing Patch #2 + #3 are simple comment fixes that patch #4 interacts with. Patch #4 is a fix for the reported performance regression due to excessive IPI broadcasts during fork()+exit(). The last patch is all about TLB flushes, IPIs and mmu_gather. Read: complicated There are plenty of cleanups in the future to be had + one reasonable optimization on x86. But that's all out of scope for this series. Runtime tested, with a focus on fixing the performance regression using the original reproducer [2] on x86. This patch (of 4): We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->pt_share_count to identify sharing. We didn't convert hugetlb_pmd_shared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table. Page migration, like mbind() or migrate_pages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as \"private\" although they are \"shared\", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the pagemap interface. Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-43061", "url": "https://ubuntu.com/security/CVE-2026-43061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Fix TX deadlock when using DMA `dmaengine_terminate_async` does not guarantee that the `__dma_tx_complete` callback will run. The callback is currently the only place where `dma->tx_running` gets cleared. If the transaction is canceled and the callback never runs, then `dma->tx_running` will never get cleared and we will never schedule new TX DMA transactions again. This change makes it so we clear `dma->tx_running` after we terminate the DMA transaction. This is \"safe\" because `serial8250_tx_dma_flush` is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to `dma->tx_running` is serialized.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-23474", "url": "https://ubuntu.com/security/CVE-2026-23474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: Avoid boot crash in RedBoot partition table parser Given CONFIG_FORTIFY_SOURCE=y and a recent compiler, commit 439a1bcac648 (\"fortify: Use __builtin_dynamic_object_size() when available\") produces the warning below and an oops. Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000 ------------[ cut here ]------------ WARNING: lib/string_helpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1 memcmp: detected buffer overflow: 15 byte read of buffer size 14 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONE As Kees said, \"'names' is pointing to the final 'namelen' many bytes of the allocation ... 'namelen' could be basically any length at all. This fortify warning looks legit to me -- this code used to be reading beyond the end of the allocation.\" Since the size of the dynamic allocation is calculated with strlen() we can use strcmp() instead of memcmp() and remain within bounds.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31393", "url": "https://ubuntu.com/security/CVE-2026-31393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present: - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8). - L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5). A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data. Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43062", "url": "https://ubuntu.com/security/CVE-2026-43062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp() l2cap_ecred_reconf_rsp() casts the incoming data to struct l2cap_ecred_conn_rsp (the ECRED *connection* response, 8 bytes with result at offset 6) instead of struct l2cap_ecred_reconf_rsp (2 bytes with result at offset 0). This causes two problems: - The sizeof(*rsp) length check requires 8 bytes instead of the correct 2, so valid L2CAP_ECRED_RECONF_RSP packets are rejected with -EPROTO. - rsp->result reads from offset 6 instead of offset 0, returning wrong data when the packet is large enough to pass the check. Fix by using the correct type. Also pass the already byte-swapped result variable to BT_DBG instead of the raw __le16 field.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31396", "url": "https://ubuntu.com/security/CVE-2026-31396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix use-after-free access to PTP clock PTP clock is registered on every opening of the interface and destroyed on every closing. However it may be accessed via get_ts_info ethtool call which is possible while the interface is just present in the kernel. BUG: KASAN: use-after-free in ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 Read of size 4 at addr ffff8880194345cc by task syz.0.6/948 CPU: 1 PID: 948 Comm: syz.0.6 Not tainted 6.1.164+ #109 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x17f/0x496 mm/kasan/report.c:420 kasan_report+0xd9/0x180 mm/kasan/report.c:524 ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 gem_get_ts_info+0x138/0x1e0 drivers/net/ethernet/cadence/macb_main.c:3349 macb_get_ts_info+0x68/0xb0 drivers/net/ethernet/cadence/macb_main.c:3371 __ethtool_get_ts_info+0x17c/0x260 net/ethtool/common.c:558 ethtool_get_ts_info net/ethtool/ioctl.c:2367 [inline] __dev_ethtool net/ethtool/ioctl.c:3017 [inline] dev_ethtool+0x2b05/0x6290 net/ethtool/ioctl.c:3095 dev_ioctl+0x637/0x1070 net/core/dev_ioctl.c:510 sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215 sock_ioctl+0x577/0x6d0 net/socket.c:1320 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 457: kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:699 [inline] ptp_clock_register+0x144/0x10e0 drivers/ptp/ptp_clock.c:235 gem_ptp_init+0x46f/0x930 drivers/net/ethernet/cadence/macb_ptp.c:375 macb_open+0x901/0xd10 drivers/net/ethernet/cadence/macb_main.c:2920 __dev_open+0x2ce/0x500 net/core/dev.c:1501 __dev_change_flags+0x56a/0x740 net/core/dev.c:8651 dev_change_flags+0x92/0x170 net/core/dev.c:8722 do_setlink+0xaf8/0x3a80 net/core/rtnetlink.c:2833 __rtnl_newlink+0xbf4/0x1940 net/core/rtnetlink.c:3608 rtnl_newlink+0x63/0xa0 net/core/rtnetlink.c:3655 rtnetlink_rcv_msg+0x3c6/0xed0 net/core/rtnetlink.c:6150 netlink_rcv_skb+0x15d/0x430 net/netlink/af_netlink.c:2511 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x6d7/0xa30 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x97e/0xeb0 net/netlink/af_netlink.c:1872 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x14b/0x180 net/socket.c:730 __sys_sendto+0x320/0x3b0 net/socket.c:2152 __do_sys_sendto net/socket.c:2164 [inline] __se_sys_sendto net/socket.c:2160 [inline] __x64_sys_sendto+0xdc/0x1b0 net/socket.c:2160 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 938: kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1729 [inline] slab_free_freelist_hook mm/slub.c:1755 [inline] slab_free mm/slub.c:3687 [inline] __kmem_cache_free+0xbc/0x320 mm/slub.c:3700 device_release+0xa0/0x240 drivers/base/core.c:2507 kobject_cleanup lib/kobject.c:681 [inline] kobject_release lib/kobject.c:712 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1cd/0x350 lib/kobject.c:729 put_device+0x1b/0x30 drivers/base/core.c:3805 ptp_clock_unregister+0x171/0x270 drivers/ptp/ptp_clock.c:391 gem_ptp_remove+0x4e/0x1f0 drivers/net/ethernet/cadence/macb_ptp.c:404 macb_close+0x1c8/0x270 drivers/net/ethernet/cadence/macb_main.c:2966 __dev_close_many+0x1b9/0x310 net/core/dev.c:1585 __dev_close net/core/dev.c:1597 [inline] __dev_change_flags+0x2bb/0x740 net/core/dev.c:8649 dev_change_fl ---truncated---", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31545", "url": "https://ubuntu.com/security/CVE-2026-31545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: nxp-nci: allow GPIOs to sleep Allow the firmware and enable GPIOs to sleep. This fixes a `WARN_ON' and allows the driver to operate GPIOs which are connected to I2C GPIO expanders. -- >8 -- kernel: WARNING: CPU: 3 PID: 2636 at drivers/gpio/gpiolib.c:3880 gpiod_set_value+0x88/0x98 -- >8 --", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31399", "url": "https://ubuntu.com/security/CVE-2026-31399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/bus: Fix potential use after free in asynchronous initialization Dingisoul with KASAN reports a use after free if device_add() fails in nd_async_device_register(). Commit b6eae0f61db2 (\"libnvdimm: Hold reference on parent while scheduling async init\") correctly added a reference on the parent device to be held until asynchronous initialization was complete. However, if device_add() results in an allocation failure the ref count of the device drops to 0 prior to the parent pointer being accessed. Thus resulting in use after free. The bug bot AI correctly identified the fix. Save a reference to the parent pointer to be used to drop the parent reference regardless of the outcome of device_add().", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31400", "url": "https://ubuntu.com/security/CVE-2026-31400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix cache_request leak in cache_release When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request. In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup. The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up. Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, dequeue and free the cache_request.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2024-46715", "url": "https://ubuntu.com/security/CVE-2024-46715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver: iio: add missing checks on iio_info's callback access Some callbacks from iio_info structure are accessed without any check, so if a driver doesn't implement them trying to access the corresponding sysfs entries produce a kernel oops such as: [ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute [...] [ 2203.783416] Call trace: [ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48 [ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120 [ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4 [ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0 [ 2203.802236] vfs_read from ksys_read+0xa4/0xd4 [ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54 [ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0) [ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000 [ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000 [ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0 [ 2203.830363] Code: bad PC value [ 2203.832695] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-09-18 07:15:00 UTC" }, { "cve": "CVE-2026-23113", "url": "https://ubuntu.com/security/CVE-2026-23113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't support ->read_iter(), loop_rw_iter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path: INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000 Call Trace: context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98 There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2025-39748", "url": "https://ubuntu.com/security/CVE-2025-39748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Forget ranges when refining tnum after JSET Syzbot reported a kernel warning due to a range invariant violation on the following BPF program. 0: call bpf_get_netns_cookie 1: if r0 == 0 goto 2: if r0 & Oxffffffff goto The issue is on the path where we fall through both jumps. That path is unreachable at runtime: after insn 1, we know r0 != 0, but with the sign extension on the jset, we would only fallthrough insn 2 if r0 == 0. Unfortunately, is_branch_taken() isn't currently able to figure this out, so the verifier walks all branches. The verifier then refines the register bounds using the second condition and we end up with inconsistent bounds on this unreachable path: 1: if r0 == 0 goto r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2: if r0 & 0xffffffff goto r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0) r0 after reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0) Improving the range refinement for JSET to cover all cases is tricky. We also don't expect many users to rely on JSET given LLVM doesn't generate those instructions. So instead of improving the range refinement for JSETs, Eduard suggested we forget the ranges whenever we're narrowing tnums after a JSET. This patch implements that approach.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2026-43357", "url": "https://ubuntu.com/security/CVE-2026-43357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050-core: fix pm_runtime error handling The return value of pm_runtime_get_sync() is not checked, allowing the driver to access hardware that may fail to resume. The device usage count is also unconditionally incremented. Use pm_runtime_resume_and_get() which propagates errors and avoids incrementing the usage count on failure. In preenable, add pm_runtime_put_autosuspend() on set_8khz_samplerate() failure since postdisable does not run when preenable fails.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43476", "url": "https://ubuntu.com/security/CVE-2026-43476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas() sizeof(num) evaluates to sizeof(size_t) (8 bytes on 64-bit) instead of the intended __be32 element size (4 bytes). Use sizeof(*meas) to correctly match the buffer element type.", "cve_priority": "medium", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43363", "url": "https://ubuntu.com/security/CVE-2026-43363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/apic: Disable x2apic on resume if the kernel expects so When resuming from s2ram, firmware may re-enable x2apic mode, which may have been disabled by the kernel during boot either because it doesn't support IRQ remapping or for other reasons. This causes the kernel to continue using the xapic interface, while the hardware is in x2apic mode, which causes hangs. This happens on defconfig + bare metal + s2ram. Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be disabled, i.e. when x2apic_mode = 0. The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the pre-sleep configuration or initial boot configuration for each CPU, including MSR state: When executing from the power-on reset vector as a result of waking from an S2 or S3 sleep state, the platform firmware performs only the hardware initialization required to restore the system to either the state the platform was in prior to the initial operating system boot, or to the pre-sleep configuration state. In multiprocessor systems, non-boot processors should be placed in the same state as prior to the initial operating system boot. (further ahead) If this is an S2 or S3 wake, then the platform runtime firmware restores minimum context of the system before jumping to the waking vector. This includes: \tCPU configuration. Platform runtime firmware restores the pre-sleep \tconfiguration or initial boot configuration of each CPU (MSR, MTRR, \tfirmware update, SMBase, and so on). Interrupts must be disabled (for \tIA-32 processors, disabled by CLI instruction). \t(and other things) So at least as per the spec, re-enablement of x2apic by the firmware is allowed if \"x2apic on\" is a part of the initial boot configuration. [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization [ bp: Massage. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43365", "url": "https://ubuntu.com/security/CVE-2026-43365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix undersized l_iclog_roundoff values If the superblock doesn't list a log stripe unit, we set the incore log roundoff value to 512. This leads to corrupt logs and unmountable filesystems in generic/617 on a disk with 4k physical sectors... XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197. XFS (sda1): failed to locate log tail XFS (sda1): log mount/recovery failed: error -74 XFS (sda1): log mount failed XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Ending clean mount ...on the current xfsprogs for-next which has a broken mkfs. xfs_info shows this... meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1 data = bsize=4096 blocks=2579968, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=4096 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=268435456 extents = zoned=0 start=0 reserved=0 ...observe that the log section has sectsz=4096 sunit=0, which means that the roundoff factor is 512, not 4096 as you'd expect. We should fix mkfs not to generate broken filesystems, but anyone can fuzz the ondisk superblock so we should be more cautious. I think the inadequate logic predates commit a6a65fef5ef8d0, but that's clearly going to require a different backport.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43370", "url": "https://ubuntu.com/security/CVE-2026-43370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix use-after-free race in VM acquire Replace non-atomic vm->process_info assignment with cmpxchg() to prevent race when parent/child processes sharing a drm_file both try to acquire the same VM after fork(). (cherry picked from commit c7c573275ec20db05be769288a3e3bb2250ec618)", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43373", "url": "https://ubuntu.com/security/CVE-2026-43373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ncsi: fix skb leak in error paths Early return paths in NCSI RX and AEN handlers fail to release the received skb, resulting in a memory leak. Specifically, ncsi_aen_handler() returns on invalid AEN packets without consuming the skb. Similarly, ncsi_rcv_rsp() exits early when failing to resolve the NCSI device, response handler, or request, leaving the skb unfreed.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43380", "url": "https://ubuntu.com/security/CVE-2026-43380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read The q54sj108a2_debugfs_read function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes 'data' as the destination and 'data_char' as the source. Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since 'data' is only 34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the end of the buffer onto the stack. Additionally, the arguments were swapped: it was reading from the zero-initialized 'data_char' and writing to 'data', resulting in all-zero output regardless of the actual I2C read. Fix this by: 1. Expanding 'data_char' to 66 bytes to safely hold the hex output. 2. Correcting the bin2hex() argument order and using the actual read count. 3. Using a pointer to select the correct output buffer for the final simple_read_from_buffer call.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43381", "url": "https://ubuntu.com/security/CVE-2026-43381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dpcd: return EBUSY for aux xfer if the device is asleep If we have runtime suspended, and userspace wants to use /dev/drm_dp_* then just tell it the device is busy instead of crashing in the GSP code. WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy) Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024 RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them awake while fw updates are happening.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43382", "url": "https://ubuntu.com/security/CVE-2026-43382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid double-rtnl_lock ELP metric worker batadv_v_elp_get_throughput() might be called when the RTNL lock is already held. This could be problematic when the work queue item is cancelled via cancel_delayed_work_sync() in batadv_v_elp_iface_disable(). In this case, an rtnl_lock() would cause a deadlock. To avoid this, rtnl_trylock() was used in this function to skip the retrieval of the ethtool information in case the RTNL lock was already held. But for cfg80211 interfaces, batadv_get_real_netdev() was called - which also uses rtnl_lock(). The approach for __ethtool_get_link_ksettings() must also be used instead and the lockless version __batadv_get_real_netdev() has to be called.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-31405", "url": "https://ubuntu.com/security/CVE-2026-31405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-net: fix OOB access in ULE extension header tables The ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables in handle_one_ule_extension() are declared with 255 elements (valid indices 0-254), but the index htype is derived from network-controlled data as (ule_sndu_type & 0x00FF), giving a range of 0-255. When htype equals 255, an out-of-bounds read occurs on the function pointer table, and the OOB value may be called as a function pointer. Add a bounds check on htype against the array size before either table is accessed. Out-of-range values now cause the SNDU to be discarded.", "cve_priority": "high", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-43387", "url": "https://ubuntu.com/security/CVE-2026-43387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: properly validate the data in rtw_get_ie_ex() Just like in commit 154828bf9559 (\"staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser\"), we don't trust the data in the frame so we should check the length better before acting on it", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43386", "url": "https://ubuntu.com/security/CVE-2026-43386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie The current code checks 'i + 5 < in_len' at the end of the if statement. However, it accesses 'in_ie[i + 5]' before that check, which can lead to an out-of-bounds read. Move the length check to the beginning of the conditional to ensure the index is within bounds before accessing the array.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43420", "url": "https://ubuntu.com/security/CVE-2026-43420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix i_nlink underrun during async unlink During async unlink, we drop the `i_nlink` counter before we receive the completion (that will eventually update the `i_nlink`) because \"we assume that the unlink will succeed\". That is not a bad idea, but it races against deletions by other clients (or against the completion of our own unlink) and can lead to an underrun which emits a WARNING like this one: WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68 Modules linked in: CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drop_nlink+0x50/0x68 lr : ceph_unlink+0x6c4/0x720 sp : ffff80012173bc90 x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680 x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647 x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203 x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365 x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74 x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94 x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002 x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8 Call trace: drop_nlink+0x50/0x68 (P) vfs_unlink+0xb0/0x2e8 do_unlinkat+0x204/0x288 __arm64_sys_unlinkat+0x3c/0x80 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0xa4/0xc8 el0_svc+0x18/0x58 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x154/0x158 In ceph_unlink(), a call to ceph_mdsc_submit_request() submits the CEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion. Meanwhile, between this call and the following drop_nlink() call, a worker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT or just a CEPH_MSG_CLIENT_REPLY (the latter of which could be our own completion). These will lead to a set_nlink() call, updating the `i_nlink` counter to the value received from the MDS. If that new `i_nlink` value happens to be zero, it is illegal to decrement it further. But that is exactly what ceph_unlink() will do then. The WARNING can be reproduced this way: 1. Force async unlink; only the async code path is affected. Having no real clue about Ceph internals, I was unable to find out why the MDS wouldn't give me the \"Fxr\" capabilities, so I patched get_caps_for_async_unlink() to always succeed. (Note that the WARNING dump above was found on an unpatched kernel, without this kludge - this is not a theoretical bug.) 2. Add a sleep call after ceph_mdsc_submit_request() so the unlink completion gets handled by a worker thread before drop_nlink() is called. This guarantees that the `i_nlink` is already zero before drop_nlink() runs. The solution is to skip the counter decrement when it is already zero, but doing so without a lock is still racy (TOCTOU). Since ceph_fill_inode() and handle_cap_grant() both hold the `ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, this seems like the proper lock to protect the `i_nlink` updates. I found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using `afs_vnode.cb_lock`). All three have the zero check as well.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43405", "url": "https://ubuntu.com/security/CVE-2026-43405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Use u32 for non-negative values in ceph_monmap_decode() This patch fixes unnecessary implicit conversions that change signedness of blob_len and num_mon in ceph_monmap_decode(). Currently blob_len and num_mon are (signed) int variables. They are used to hold values that are always non-negative and get assigned in ceph_decode_32_safe(), which is meant to assign u32 values. Both variables are subsequently used as unsigned values, and the value of num_mon is further assigned to monmap->num_mon, which is of type u32. Therefore, both variables should be of type u32. This is especially relevant for num_mon. If the value read from the incoming message is very large, it is interpreted as a negative value, and the check for num_mon > CEPH_MAX_MON does not catch it. This leads to the attempt to allocate a very large chunk of memory for monmap, which will most likely fail. In this case, an unnecessary attempt to allocate memory is performed, and -ENOMEM is returned instead of -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43411", "url": "https://ubuntu.com/security/CVE-2026-43411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix divide-by-zero in tipc_sk_filter_connect() A user can set conn_timeout to any value via setsockopt(TIPC_CONN_TIMEOUT), including values less than 4. When a SYN is rejected with TIPC_ERR_OVERLOAD and the retry path in tipc_sk_filter_connect() executes: delay %= (tsk->conn_timeout / 4); If conn_timeout is in the range [0, 3], the integer division yields 0, and the modulo operation triggers a divide-by-zero exception, causing a kernel oops/panic. Fix this by clamping conn_timeout to a minimum of 4 at the point of use in tipc_sk_filter_connect(). Oops: divide error: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+ RIP: 0010:tipc_sk_filter_rcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362) Call Trace: tipc_sk_backlog_rcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406) __release_sock (include/net/sock.h:1185 net/core/sock.c:3213) release_sock (net/core/sock.c:3797) tipc_connect (net/tipc/socket.c:2570) __sys_connect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098)", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43484", "url": "https://ubuntu.com/security/CVE-2026-43484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: core: Avoid bitfield RMW for claim/retune flags Move claimed and retune control flags out of the bitfield word to avoid unrelated RMW side effects in asynchronous contexts. The host->claimed bit shared a word with retune flags. Writes to claimed in __mmc_claim_host() or retune_now in mmc_mq_queue_rq() can overwrite other bits when concurrent updates happen in other contexts, triggering spurious WARN_ON(!host->claimed). Convert claimed, can_retune, retune_now and retune_paused to bool to remove shared-word coupling.", "cve_priority": "low", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43425", "url": "https://ubuntu.com/security/CVE-2026-43425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: kill download URB on timeout mdc800_device_read() submits download_urb and waits for completion. If the timeout fires and the device has not responded, the function returns without killing the URB, leaving it active. A subsequent read() resubmits the same URB while it is still in-flight, triggering the WARN in usb_submit_urb(): \"URB submitted while active\" Check the return value of wait_event_timeout() and kill the URB if it indicates timeout, ensuring the URB is complete before its status is inspected or the URB is resubmitted. Similar to - commit 372c93131998 (\"USB: yurex: fix control-URB timeout handling\") - commit b98d5000c505 (\"media: rc: iguanair: handle timeouts\")", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43426", "url": "https://ubuntu.com/security/CVE-2026-43426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: fix use-after-free in ISR during device removal In usbhs_remove(), the driver frees resources (including the pipe array) while the interrupt handler (usbhs_interrupt) is still registered. If an interrupt fires after usbhs_pipe_remove() but before the driver is fully unbound, the ISR may access freed memory, causing a use-after-free. Fix this by calling devm_free_irq() before freeing resources. This ensures the interrupt handler is both disabled and synchronized (waits for any running ISR to complete) before usbhs_pipe_remove() is called.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43427", "url": "https://ubuntu.com/security/CVE-2026-43427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: class: cdc-wdm: fix reordering issue in read code path Quoting the bug report: Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdm_read() can see the new length and call copy_to_user() on uninitialized memory. This also violates LKMM data race rules [1]. Fix it by using WRITE_ONCE and memory barriers.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43428", "url": "https://ubuntu.com/security/CVE-2026-43428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: core: Limit the length of unkillable synchronous timeouts The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device. To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector. In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43429", "url": "https://ubuntu.com/security/CVE-2026-43429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: Use usb_bulk_msg_killable() with user-specified timeouts The usbtmc driver accepts timeout values specified by the user in an ioctl command, and uses these timeouts for some usb_bulk_msg() calls. Since the user can specify arbitrarily long timeouts and usb_bulk_msg() uses unkillable waits, call usb_bulk_msg_killable() instead to avoid the possibility of the user hanging a kernel thread indefinitely.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43430", "url": "https://ubuntu.com/security/CVE-2026-43430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: yurex: fix race in probe The bbu member of the descriptor must be set to the value standing for uninitialized values before the URB whose completion handler sets bbu is submitted. Otherwise there is a window during which probing can overwrite already retrieved data.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43432", "url": "https://ubuntu.com/security/CVE-2026-43432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix memory leak in xhci_disable_slot() xhci_alloc_command() allocates a command structure and, when the second argument is true, also allocates a completion structure. Currently, the error handling path in xhci_disable_slot() only frees the command structure using kfree(), causing the completion structure to leak. Use xhci_free_command() instead of kfree(). xhci_free_command() correctly frees both the command structure and the associated completion structure. Since the command structure is allocated with zero-initialization, command->in_ctx is NULL and will not be erroneously freed by xhci_free_command(). This bug was found using an experimental static analysis tool we are developing. The tool is based on the LLVM framework and is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available, but we plan to open-source it after our research is published. The bug was originally detected on v6.13-rc1 using our static analysis tool, and we have verified that the issue persists in the latest mainline kernel. We performed build testing on x86_64 with allyesconfig using GCC=11.4.0. Since triggering these error paths in xhci_disable_slot() requires specific hardware conditions or abnormal state, we were unable to construct a test case to reliably trigger these specific error paths at runtime.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43439", "url": "https://ubuntu.com/security/CVE-2026-43439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup: fix race between task migration and iteration When a task is migrated out of a css_set, cgroup_migrate_add_task() first moves it from cset->tasks to cset->mg_tasks via: list_move_tail(&task->cg_list, &cset->mg_tasks); If a css_task_iter currently has it->task_pos pointing to this task, css_set_move_task() calls css_task_iter_skip() to keep the iterator valid. However, since the task has already been moved to ->mg_tasks, the iterator is advanced relative to the mg_tasks list instead of the original tasks list. As a result, remaining tasks on cset->tasks, as well as tasks queued on cset->mg_tasks, can be skipped by iteration. Fix this by calling css_set_skip_task_iters() before unlinking task->cg_list from cset->tasks. This advances all active iterators to the next task on cset->tasks, so iteration continues correctly even when a task is concurrently being migrated. This race is hard to hit in practice without instrumentation, but it can be reproduced by artificially slowing down cgroup_procs_show(). For example, on an Android device a temporary /sys/kernel/cgroup/cgroup_test knob can be added to inject a delay into cgroup_procs_show(), and then: 1) Spawn three long-running tasks (PIDs 101, 102, 103). 2) Create a test cgroup and move the tasks into it. 3) Enable a large delay via /sys/kernel/cgroup/cgroup_test. 4) In one shell, read cgroup.procs from the test cgroup. 5) Within the delay window, in another shell migrate PID 102 by writing it to a different cgroup.procs file. Under this setup, cgroup.procs can intermittently show only PID 101 while skipping PID 103. Once the migration completes, reading the file again shows all tasks as expected. Note that this change does not allow removing the existing css_set_skip_task_iters() call in css_set_move_task(). The new call in cgroup_migrate_add_task() only handles iterators that are racing with migration while the task is still on cset->tasks. Iterators may also start after the task has been moved to cset->mg_tasks. If we dropped css_set_skip_task_iters() from css_set_move_task(), such iterators could keep task_pos pointing to a migrating task, causing css_task_iter_advance() to malfunction on the destination css_set, up to and including crashes or infinite loops. The race window between migration and iteration is very small, and css_task_iter is not on a hot path. In the worst case, when an iterator is positioned on the first thread of the migrating process, cgroup_migrate_add_task() may have to skip multiple tasks via css_set_skip_task_iters(). However, this only happens when migration and iteration actually race, so the performance impact is negligible compared to the correctness fix provided here.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43480", "url": "https://ubuntu.com/security/CVE-2026-43480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisition The acp3x_5682_init() function did not check the return value of clk_get(), which could lead to dereferencing error pointers in rt5682_clk_enable(). Fix this by: 1. Changing clk_get() to the device-managed devm_clk_get(). 2. Adding proper IS_ERR() checks for both clock acquisitions.", "cve_priority": "low", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43445", "url": "https://ubuntu.com/security/CVE-2026-43445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: e1000/e1000e: Fix leak in 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 after a successful 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 would leak. In these commits, a faulty while condition caused an infinite loop in dma_error: Commit 03b1320dfcee (\"e1000e: remove use of skb_dma_map from e1000e driver\") Commit 602c0554d7b0 (\"e1000: remove use of skb_dma_map from e1000 driver\") Commit c1fa347f20f1 (\"e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()\") fixed the infinite loop, but introduced the off-by-one error. This issue may still exist in the igbvf driver, but I did not address it in this patch.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43449", "url": "https://ubuntu.com/security/CVE-2026-43449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_set dev->online_queues is a count incremented in nvme_init_queue. Thus, valid indices are 0 through dev->online_queues − 1. This patch fixes the loop condition to ensure the index stays within the valid range. Index 0 is excluded because it is the admin queue. KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74 CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: nvme-reset-wq nvme_reset_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xea/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xce/0x5d0 mm/kasan/report.c:482 kasan_report+0xdc/0x110 mm/kasan/report.c:595 __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c:379 nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c:3252 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 34 on cpu 1 at 4.241550s: kasan_save_stack+0x2c/0x60 mm/kasan/common.c:57 kasan_save_track+0x1c/0x70 mm/kasan/common.c:78 kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c:570 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5657 [inline] __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c:5663 kmalloc_array_node_noprof include/linux/slab.h:1075 [inline] nvme_pci_alloc_dev drivers/nvme/host/pci.c:3479 [inline] nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534 local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c:324 pci_call_probe drivers/pci/pci-driver.c:392 [inline] __pci_device_probe drivers/pci/pci-driver.c:417 [inline] pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c:451 call_driver_probe drivers/base/dd.c:583 [inline] really_probe+0x29b/0xb70 drivers/base/dd.c:661 __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c:803 driver_probe_device+0x56/0x1f0 drivers/base/dd.c:833 __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c:1159 async_run_entry_fn+0xa6/0x4b0 kernel/async.c:129 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 The buggy address belongs to the object at ffff88800592a000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 244 bytes to the right of allocated 1152-byte region [ffff88800592a000, ffff88800592a480) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff) page_type: f5(slab) raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000 head: 000fffffc0000040 ffff888001042000 00000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43450", "url": "https://ubuntu.com/security/CVE-2026-43450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table() nfnl_cthelper_dump_table() has a 'goto restart' that jumps to a label inside the for loop body. When the \"last\" helper saved in cb->args[1] is deleted between dump rounds, every entry fails the (cur != last) check, so cb->args[1] is never cleared. The for loop finishes with cb->args[0] == nf_ct_helper_hsize, and the 'goto restart' jumps back into the loop body bypassing the bounds check, causing an 8-byte out-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize]. The 'goto restart' block was meant to re-traverse the current bucket when \"last\" is no longer found, but it was placed after the for loop instead of inside it. Move the block into the for loop body so that the restart only occurs while cb->args[0] is still within bounds. BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131 Call Trace: nfnl_cthelper_dump_table+0x9f/0x1b0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 sock_recvmsg+0xde/0xf0 __sys_recvfrom+0x150/0x200 __x64_sys_recvfrom+0x76/0x90 do_syscall_64+0xc3/0x6e0 Allocated by task 1: __kvmalloc_node_noprof+0x21b/0x700 nf_ct_alloc_hashtable+0x65/0xd0 nf_conntrack_helper_init+0x21/0x60 nf_conntrack_init_start+0x18d/0x300 nf_conntrack_standalone_init+0x12/0xc0", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43451", "url": "https://ubuntu.com/security/CVE-2026-43451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: fix entry leak in bridge verdict error path nfqnl_recv_verdict() calls find_dequeue_entry() to remove the queue entry from the queue data structures, taking ownership of the entry. For PF_BRIDGE packets, it then calls nfqa_parse_bridge() to parse VLAN attributes. If nfqa_parse_bridge() returns an error (e.g. NFQA_VLAN present but NFQA_VLAN_TCI missing), the function returns immediately without freeing the dequeued entry or its sk_buff. This leaks the nf_queue_entry, its associated sk_buff, and all held references (net_device refcounts, struct net refcount). Repeated triggering exhausts kernel memory. Fix this by dropping the entry via nfqnl_reinject() with NF_DROP verdict on the error path, consistent with other error handling in this file.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43452", "url": "https://ubuntu.com/security/CVE-2026-43452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: guard option walkers against 1-byte tail reads When the last byte of options is a non-single-byte option kind, walkers that advance with i += op[i + 1] ? : 1 can read op[i + 1] past the end of the option area. Add an explicit i == optlen - 1 check before dereferencing op[i + 1] in xt_tcpudp and xt_dccp option walkers.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43453", "url": "https://ubuntu.com/security/CVE-2026-43453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop() pipapo_drop() passes rulemap[i + 1].n to pipapo_unmap() as the to_offset argument on every iteration, including the last one where i == m->field_count - 1. This reads one element past the end of the stack-allocated rulemap array (declared as rulemap[NFT_PIPAPO_MAX_FIELDS] with NFT_PIPAPO_MAX_FIELDS == 16). Although pipapo_unmap() returns early when is_last is true without using the to_offset value, the argument is evaluated at the call site before the function body executes, making this a genuine out-of-bounds stack read confirmed by KASAN: BUG: KASAN: stack-out-of-bounds in pipapo_drop+0x50c/0x57c [nf_tables] Read of size 4 at addr ffff8000810e71a4 This frame has 1 object: [32, 160) 'rulemap' The buggy address is at offset 164 -- exactly 4 bytes past the end of the rulemap array. Pass 0 instead of rulemap[i + 1].n on the last iteration to avoid the out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43458", "url": "https://ubuntu.com/security/CVE-2026-43458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: caif: hold tty->link reference in ldisc_open and ser_release A reproducer triggers a KASAN slab-use-after-free in pty_write_room() when caif_serial's TX path calls tty_write_room(). The faulting access is on tty->link->port. Hold an extra kref on tty->link for the lifetime of the caif_serial line discipline: get it in ldisc_open() and drop it in ser_release(), and also drop it on the ldisc_open() error path. With this change applied, the reproducer no longer triggers the UAF in my testing.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43459", "url": "https://ubuntu.com/security/CVE-2026-43459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-core: flush delayed work before removing DAIs and widgets When a sound card is unbound while a PCM stream is open, a use-after-free can occur in snd_soc_dapm_stream_event(), called from the close_delayed_work workqueue handler. During unbind, snd_soc_unbind_card() flushes delayed work and then calls soc_cleanup_card_resources(). Inside cleanup, snd_card_disconnect_sync() releases all PCM file descriptors, and the resulting PCM close path can call snd_soc_dapm_stream_stop() which schedules new delayed work with a pmdown_time timer delay. Since this happens after the flush in snd_soc_unbind_card(), the new work is not caught. soc_remove_link_components() then frees DAPM widgets before this work fires, leading to the use-after-free. The existing flush in soc_free_pcm_runtime() also cannot help as it runs after soc_remove_link_components() has already freed the widgets. Add a flush in soc_cleanup_card_resources() after snd_card_disconnect_sync() (after which no new PCM closes can schedule further delayed work) and before soc_remove_link_dais() and soc_remove_link_components() (which tear down the structures the delayed work accesses).", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-23277", "url": "https://ubuntu.com/security/CVE-2026-23277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit teql_master_xmit() calls netdev_start_xmit(skb, slave) to transmit through slave devices, but does not update skb->dev to the slave device beforehand. When a gretap tunnel is a TEQL slave, the transmit path reaches iptunnel_xmit() which saves dev = skb->dev (still pointing to teql0 master) and later calls iptunnel_xmit_stats(dev, pkt_len). This function does: get_cpu_ptr(dev->tstats) Since teql_master_setup() does not set dev->pcpu_stat_type to NETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstats for teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computes NULL + __per_cpu_offset[cpu], resulting in a page fault. BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206) Fix this by setting skb->dev = slave before calling netdev_start_xmit(), so that tunnel xmit functions see the correct slave device with properly allocated tstats.", "cve_priority": "medium", "cve_public_date": "2026-03-20 09:16:00 UTC" }, { "cve": "CVE-2026-43466", "url": "https://ubuntu.com/security/CVE-2026-43466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery In case of a TX error CQE, a recovery flow is triggered, mlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc, desyncing the DMA FIFO producer and consumer. After recovery, the producer pushes new DMA entries at the old dma_fifo_pc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery. The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dma_fifo_cc is already equal to dma_fifo_pc. There is no need to reset either counter, similar to how skb_fifo pc/cc are untouched. Remove the 'dma_fifo_cc = 0' reset. This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90 Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: ? __warn+0x7d/0x110 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0x16d/0x180 ? handle_bug+0x4f/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 ? iommu_dma_unmap_page+0x2e/0x90 dma_unmap_page_attrs+0x10d/0x1b0 mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core] mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core] mlx5e_napi_poll+0x8b/0xac0 [mlx5_core] __napi_poll+0x24/0x190 net_rx_action+0x32a/0x3b0 ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core] ? notifier_call_chain+0x35/0xa0 handle_softirqs+0xc9/0x270 irq_exit_rcu+0x71/0xd0 common_interrupt+0x7f/0xa0 asm_common_interrupt+0x22/0x40", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43469", "url": "https://ubuntu.com/security/CVE-2026-43469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decrement re_receiving on the early exit paths In the event that rpcrdma_post_recvs() fails to create a work request (due to memory allocation failure, say) or otherwise exits early, we should decrement ep->re_receiving before returning. Otherwise we will hang in rpcrdma_xprt_drain() as re_receiving will never reach zero and the completion will never be triggered. On a system with high memory pressure, this can appear as the following hung task: INFO: task kworker/u385:17:8393 blocked for more than 122 seconds. Tainted: G S E 6.19.0 #3 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u385:17 state:D stack:0 pid:8393 tgid:8393 ppid:2 task_flags:0x4248060 flags:0x00080000 Workqueue: xprtiod xprt_autoclose [sunrpc] Call Trace: __schedule+0x48b/0x18b0 ? ib_post_send_mad+0x247/0xae0 [ib_core] schedule+0x27/0xf0 schedule_timeout+0x104/0x110 __wait_for_common+0x98/0x180 ? __pfx_schedule_timeout+0x10/0x10 wait_for_completion+0x24/0x40 rpcrdma_xprt_disconnect+0x444/0x460 [rpcrdma] xprt_rdma_close+0x12/0x40 [rpcrdma] xprt_autoclose+0x5f/0x120 [sunrpc] process_one_work+0x191/0x3e0 worker_thread+0x2e3/0x420 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x273/0x2b0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2025-54505", "url": "https://ubuntu.com/security/CVE-2025-54505", "cve_description": "A transient execution vulnerability within AMD CPUs may allow a local user-privileged attacker to leak data via the floating point divisor unit, potentially resulting in loss of confidentiality.", "cve_priority": "medium", "cve_public_date": "2026-04-27 16:16:00 UTC" }, { "cve": "CVE-2026-31628", "url": "https://ubuntu.com/security/CVE-2026-31628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU: Fix FPDSS on Zen1 Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43472", "url": "https://ubuntu.com/security/CVE-2026-43472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: unshare: fix unshare_fs() handling There's an unpleasant corner case in unshare(2), when we have a CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that case copy_mnt_ns() gets passed current->fs instead of a private copy, which causes interesting warts in proof of correctness] > I guess if private means fs->users == 1, the condition could still be true. Unfortunately, it's worse than just a convoluted proof of correctness. Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS (and current->fs->users == 1). We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and flips current->fs->{pwd,root} to corresponding locations in the new namespace. Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM). We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's destroyed and its mount tree is dissolved, but... current->fs->root and current->fs->pwd are both left pointing to now detached mounts. They are pinning those, so it's not a UAF, but it leaves the calling process with unshare(2) failing with -ENOMEM _and_ leaving it with pwd and root on detached isolated mounts. The last part is clearly a bug. There is other fun related to that mess (races with pivot_root(), including the one between pivot_root() and fork(), of all things), but this one is easy to isolate and fix - treat CLONE_NEWNS as \"allocate a new fs_struct even if it hadn't been shared in the first place\". Sure, we could go for something like \"if both CLONE_NEWNS *and* one of the things that might end up failing after copy_mnt_ns() call in create_new_namespaces() are set, force allocation of new fs_struct\", but let's keep it simple - the cost of copy_fs_struct() is trivial. Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets a freshly allocated fs_struct, yet to be attached to anything. That seriously simplifies the analysis... FWIW, that bug had been there since the introduction of unshare(2) ;-/", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-43473", "url": "https://ubuntu.com/security/CVE-2026-43473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Add NULL checks when resetting request and reply queues The driver encountered a crash during resource cleanup when the reply and request queues were NULL due to freed memory. This issue occurred when the creation of reply or request queues failed, and the driver freed the memory first, but attempted to mem set the content of the freed memory, leading to a system crash. Add NULL pointer checks for reply and request queues before accessing the reply/request memory during cleanup", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-43475", "url": "https://ubuntu.com/security/CVE-2026-43475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT This resolves the follow splat and lock-up when running with PREEMPT_RT enabled on Hyper-V: [ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002 [ 415.140822] INFO: lockdep is turned off. [ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common [ 415.140846] Preemption disabled at: [ 415.140847] [] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)} [ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024 [ 415.140857] Call Trace: [ 415.140861] [ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140863] dump_stack_lvl+0x91/0xb0 [ 415.140870] __schedule_bug+0x9c/0xc0 [ 415.140875] __schedule+0xdf6/0x1300 [ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980 [ 415.140879] ? rcu_is_watching+0x12/0x60 [ 415.140883] schedule_rtlock+0x21/0x40 [ 415.140885] rtlock_slowlock_locked+0x502/0x1980 [ 415.140891] rt_spin_lock+0x89/0x1e0 [ 415.140893] hv_ringbuffer_write+0x87/0x2a0 [ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0 [ 415.140900] ? rcu_is_watching+0x12/0x60 [ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc] [ 415.140904] ? HARDIRQ_verbose+0x10/0x10 [ 415.140908] ? __rq_qos_issue+0x28/0x40 [ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod] [ 415.140926] __blk_mq_issue_directly+0x4a/0xc0 [ 415.140928] blk_mq_issue_direct+0x87/0x2b0 [ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440 [ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0 [ 415.140935] __blk_flush_plug+0xf4/0x150 [ 415.140940] __submit_bio+0x2b2/0x5c0 [ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360 [ 415.140946] submit_bio_noacct_nocheck+0x272/0x360 [ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4] [ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4] [ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4] [ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4] [ 415.141060] generic_perform_write+0x14e/0x2c0 [ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4] [ 415.141083] vfs_write+0x2ca/0x570 [ 415.141087] ksys_write+0x76/0xf0 [ 415.141089] do_syscall_64+0x99/0x1490 [ 415.141093] ? rcu_is_watching+0x12/0x60 [ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0 [ 415.141097] ? rcu_is_watching+0x12/0x60 [ 415.141098] ? lock_release+0x1f0/0x2a0 [ 415.141100] ? rcu_is_watching+0x12/0x60 [ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0 [ 415.141103] ? rcu_is_watching+0x12/0x60 [ 415.141104] ? __schedule+0xb34/0x1300 [ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170 [ 415.141109] ? do_nanosleep+0x8b/0x160 [ 415.141111] ? hrtimer_nanosleep+0x89/0x100 [ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10 [ 415.141116] ? xfd_validate_state+0x26/0x90 [ 415.141118] ? rcu_is_watching+0x12/0x60 [ 415.141120] ? do_syscall_64+0x1e0/0x1490 [ 415.141121] ? do_syscall_64+0x1e0/0x1490 [ 415.141123] ? rcu_is_watching+0x12/0x60 [ 415.141124] ? do_syscall_64+0x1e0/0x1490 [ 415.141125] ? do_syscall_64+0x1e0/0x1490 [ 415.141127] ? irqentry_exit+0x140/0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-23270", "url": "https://ubuntu.com/security/CVE-2026-23270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocks As Paolo said earlier [1]: \"Since the blamed commit below, classify can return TC_ACT_CONSUMED while the current skb being held by the defragmentation engine. As reported by GangMin Kim, if such packet is that may cause a UaF when the defrag engine later on tries to tuch again such packet.\" act_ct was never meant to be used in the egress path, however some users are attaching it to egress today [2]. Attempting to reach a middle ground, we noticed that, while most qdiscs are not handling TC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, we address the issue by only allowing act_ct to bind to clsact/ingress qdiscs and shared blocks. That way it's still possible to attach act_ct to egress (albeit only with clsact). [1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/ [2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23300", "url": "https://ubuntu.com/security/CVE-2026-23300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop When a standalone IPv6 nexthop object is created with a loopback device (e.g., \"ip -6 nexthop add id 100 dev lo\"), fib6_nh_init() misclassifies it as a reject route. This is because nexthop objects have no destination prefix (fc_dst=::), causing fib6_is_reject() to match any loopback nexthop. The reject path skips fib_nh_common_init(), leaving nhc_pcpu_rth_output unallocated. If an IPv4 route later references this nexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and panics. Simplify the check in fib6_nh_init() to only match explicit reject routes (RTF_REJECT) instead of using fib6_is_reject(). The loopback promotion heuristic in fib6_is_reject() is handled separately by ip6_route_info_create_nh(). After this change, the three cases behave as follows: 1. Explicit reject route (\"ip -6 route add unreachable 2001:db8::/64\"): RTF_REJECT is set, enters reject path, skips fib_nh_common_init(). No behavior change. 2. Implicit loopback reject route (\"ip -6 route add 2001:db8::/32 dev lo\"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. ip6_route_info_create_nh() still promotes it to reject afterward. nhc_pcpu_rth_output is allocated but unused, which is harmless. 3. Standalone nexthop object (\"ip -6 nexthop add id 100 dev lo\"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. nhc_pcpu_rth_output is properly allocated, fixing the crash when IPv4 routes reference this nexthop.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23293", "url": "https://ubuntu.com/security/CVE-2026-23293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. If an IPv6 packet is injected into the interface, route_shortcircuit() is called and a NULL pointer dereference happens on neigh_lookup(). BUG: kernel NULL pointer dereference, address: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neigh_lookup+0x20/0x270 [...] Call Trace: vxlan_xmit+0x638/0x1ef0 [vxlan] dev_hard_start_xmit+0x9e/0x2e0 __dev_queue_xmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x12f/0x1590 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix this by adding an early check on route_shortcircuit() when protocol is ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here because VXLAN can be built-in even when IPv6 is built as a module.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23381", "url": "https://ubuntu.com/security/CVE-2026-23381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. Then, if neigh_suppress is enabled and an ICMPv6 Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() will dereference ipv6_stub->nd_tbl which is NULL, passing it to neigh_lookup(). This causes a kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neigh_lookup+0x16/0xe0 [...] Call Trace: ? neigh_lookup+0x16/0xe0 br_do_suppress_nd+0x160/0x290 [bridge] br_handle_frame_finish+0x500/0x620 [bridge] br_handle_frame+0x353/0x440 [bridge] __netif_receive_skb_core.constprop.0+0x298/0x1110 __netif_receive_skb_one_core+0x3d/0xa0 process_backlog+0xa0/0x140 __napi_poll+0x2c/0x170 net_rx_action+0x2c4/0x3a0 handle_softirqs+0xd0/0x270 do_softirq+0x3f/0x60 Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() in the callers. This is in essence disabling NS/NA suppression when IPv6 is disabled.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23372", "url": "https://ubuntu.com/security/CVE-2026-23372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: rawsock: cancel tx_work before socket teardown In rawsock_release(), cancel any pending tx_work and purge the write queue before orphaning the socket. rawsock_tx_work runs on the system workqueue and calls nfc_data_exchange which dereferences the NCI device. Without synchronization, tx_work can race with socket and device teardown when a process is killed (e.g. by SIGKILL), leading to use-after-free or leaked references. Set SEND_SHUTDOWN first so that if tx_work is already running it will see the flag and skip transmitting, then use cancel_work_sync to wait for any in-progress execution to finish, and finally purge any remaining queued skbs.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23339", "url": "https://ubuntu.com/security/CVE-2026-23339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: free skb on nci_transceive early error paths nci_transceive() takes ownership of the skb passed by the caller, but the -EPROTO, -EINVAL, and -EBUSY error paths return without freeing it. Due to issues clearing NCI_DATA_EXCHANGE fixed by subsequent changes the nci/nci_dev selftest hits the error path occasionally in NIPA, and kmemleak detects leaks: unreferenced object 0xff11000015ce6a40 (size 640): comm \"nci_dev\", pid 3954, jiffies 4295441246 hex dump (first 32 bytes): 6b 6b 6b 6b 00 a4 00 0c 02 e1 03 6b 6b 6b 6b 6b kkkk.......kkkkk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk backtrace (crc 7c40cc2a): kmem_cache_alloc_node_noprof+0x492/0x630 __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xc6/0x8f0 sock_alloc_send_pskb+0x326/0x3f0 nfc_alloc_send_skb+0x94/0x1d0 rawsock_sendmsg+0x162/0x4c0 do_syscall_64+0x117/0xfc0", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23340", "url": "https://ubuntu.com/security/CVE-2026-23340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs When shrinking the number of real tx queues, netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush qdiscs for queues which will no longer be used. qdisc_reset_all_tx_gt() currently serializes qdisc_reset() with qdisc_lock(). However, for lockless qdiscs, the dequeue path is serialized by qdisc_run_begin/end() using qdisc->seqlock instead, so qdisc_reset() can run concurrently with __qdisc_run() and free skbs while they are still being dequeued, leading to UAF. This can easily be reproduced on e.g. virtio-net by imposing heavy traffic while frequently changing the number of queue pairs: iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 done With KASAN enabled, this leads to reports like: BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: ... __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 udp_sendmsg+0x13c9/0x1fc0 ... Allocated by task 1270 on cpu 5 at 44.558414s: ... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg+0x13a6/0x1fc0 ... Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a/0x890 ... Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path by taking qdisc->seqlock for TCQ_F_NOLOCK qdiscs, matching the serialization model already used by dev_reset_queue(). Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state reflects an empty queue, avoiding needless re-scheduling.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23304", "url": "https://ubuntu.com/security/CVE-2026-23304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu() l3mdev_master_dev_rcu() can return NULL when the slave device is being un-slaved from a VRF. All other callers deal with this, but we lost the fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu() with commit 4832c30d5458 (\"net: ipv6: put host and anycast routes on device with address\"). KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418) Call Trace: ip6_pol_route (net/ipv6/route.c:2318) fib6_rule_lookup (net/ipv6/fib6_rules.c:115) ip6_route_output_flags (net/ipv6/route.c:2607) vrf_process_v6_outbound (drivers/net/vrf.c:437) I was tempted to rework the un-slaving code to clear the flag first and insert synchronize_rcu() before we remove the upper. But looks like the explicit fallback to loopback_dev is an established pattern. And I guess avoiding the synchronize_rcu() is nice, too.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23420", "url": "https://ubuntu.com/security/CVE-2026-23420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: Fix a locking bug Make sure that wl->mutex is locked before it is unlocked. This has been detected by the Clang thread-safety analyzer.", "cve_priority": "medium", "cve_public_date": "2026-04-03 14:16:00 UTC" }, { "cve": "CVE-2026-23357", "url": "https://ubuntu.com/security/CVE-2026-23357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix deadlock in error path of mcp251x_open The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish. This issue is similar to the one fixed in commit 7dd9c26bd6cf (\"can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\") but for the error path. To solve this issue move the call to free_irq() after the lock is released. Setting `priv->force_quit = 1` beforehand ensure that the IRQ handler will exit right away once it acquired the lock.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23362", "url": "https://ubuntu.com/security/CVE-2026-23362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix locking for bcm_op runtime updates Commit c2aba69d0c36 (\"can: bcm: add locking for bcm_op runtime updates\") added a locking for some variables that can be modified at runtime when updating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup(). Usually the RX_SETUP only handles and filters incoming traffic with one exception: When the RX_RTR_FRAME flag is set a predefined CAN frame is sent when a specific RTR frame is received. Therefore the rx bcm_op uses bcm_can_tx() which uses the bcm_tx_lock that was only initialized in bcm_tx_setup(). Add the missing spin_lock_init() when allocating the bcm_op in bcm_rx_setup() to handle the RTR case properly.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23286", "url": "https://ubuntu.com/security/CVE-2026-23286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix null-ptr-deref in lec_arp_clear_vccs syzkaller reported a null-ptr-deref in lec_arp_clear_vccs(). This issue can be easily reproduced using the syzkaller reproducer. In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared by multiple lec_arp_table entries (e.g., via entry->vcc or entry->recv_vcc). When the underlying VCC is closed, lec_vcc_close() iterates over all ARP entries and calls lec_arp_clear_vccs() for each matched entry. For example, when lec_vcc_close() iterates through the hlists in priv->lec_arp_empty_ones or other ARP tables: 1. In the first iteration, for the first matched ARP entry sharing the VCC, lec_arp_clear_vccs() frees the associated vpriv (which is vcc->user_back) and sets vcc->user_back to NULL. 2. In the second iteration, for the next matched ARP entry sharing the same VCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv from vcc->user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference it via `vcc->pop = vpriv->old_pop`, leading to a null-ptr-deref crash. Fix this by adding a null check for vpriv before dereferencing it. If vpriv is already NULL, it means the VCC has been cleared by a previous call, so we can safely skip the cleanup and just clear the entry's vcc/recv_vcc pointers. The entire cleanup block (including vcc_release_async()) is placed inside the vpriv guard because a NULL vpriv indicates the VCC has already been fully released by a prior iteration — repeating the teardown would redundantly set flags and trigger callbacks on an already-closing socket. The Fixes tag points to the initial commit because the entry->vcc path has been vulnerable since the original code. The entry->recv_vcc path was later added by commit 8d9f73c0ad2f (\"atm: fix a memory leak of vcc->user_back\") with the same pattern, and both paths are fixed here.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23296", "url": "https://ubuntu.com/security/CVE-2026-23296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix refcount leak for tagset_refcnt This leak will cause a hang when tearing down the SCSI host. For example, iscsid hangs with the following call trace: [130120.652718] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured PID: 2528 TASK: ffff9d0408974e00 CPU: 3 COMMAND: \"iscsid\" #0 [ffffb5b9c134b9e0] __schedule at ffffffff860657d4 #1 [ffffb5b9c134ba28] schedule at ffffffff86065c6f #2 [ffffb5b9c134ba40] schedule_timeout at ffffffff86069fb0 #3 [ffffb5b9c134bab0] __wait_for_common at ffffffff8606674f #4 [ffffb5b9c134bb10] scsi_remove_host at ffffffff85bfe84b #5 [ffffb5b9c134bb30] iscsi_sw_tcp_session_destroy at ffffffffc03031c4 [iscsi_tcp] #6 [ffffb5b9c134bb48] iscsi_if_recv_msg at ffffffffc0292692 [scsi_transport_iscsi] #7 [ffffb5b9c134bb98] iscsi_if_rx at ffffffffc02929c2 [scsi_transport_iscsi] #8 [ffffb5b9c134bbf0] netlink_unicast at ffffffff85e551d6 #9 [ffffb5b9c134bc38] netlink_sendmsg at ffffffff85e554ef", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23356", "url": "https://ubuntu.com/security/CVE-2026-23356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: fix \"LOGIC BUG\" in drbd_al_begin_io_nonblock() Even though we check that we \"should\" be able to do lc_get_cumulative() while holding the device->al_lock spinlock, it may still fail, if some other code path decided to do lc_try_lock() with bad timing. If that happened, we logged \"LOGIC BUG for enr=...\", but still did not return an error. The rest of the code now assumed that this request has references for the relevant activity log extents. The implcations are that during an active resync, mutual exclusivity of resync versus application IO is not guaranteed. And a potential crash at this point may not realizs that these extents could have been target of in-flight IO and would need to be resynced just in case. Also, once the request completes, it will give up activity log references it does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put(). Fix: Do not crash the kernel for a condition that is harmless during normal operation: also catch \"e->refcnt == 0\", not only \"e == NULL\" when being noisy about \"al_complete_io() called on inactive extent %u\\n\". And do not try to be smart and \"guess\" whether something will work, then be surprised when it does not. Deal with the fact that it may or may not work. If it does not, remember a possible \"partially in activity log\" state (only possible for requests that cross extent boundaries), and return an error code from drbd_al_begin_io_nonblock(). A latter call for the same request will then resume from where we left off.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23388", "url": "https://ubuntu.com/security/CVE-2026-23388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check metadata block offset is within range Syzkaller reports a \"general protection fault in squashfs_copy_data\" This is ultimately caused by a corrupted index look-up table, which produces a negative metadata block offset. This is subsequently passed to squashfs_copy_data (via squashfs_read_metadata) where the negative offset causes an out of bounds access. The fix is to check that the offset is within range in squashfs_read_metadata. This will trap this and other cases.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23379", "url": "https://ubuntu.com/security/CVE-2026-23379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: fix divide by zero in the offload path Offloading ETS requires computing each class' WRR weight: this is done by averaging over the sums of quanta as 'q_sum' and 'q_psum'. Using unsigned int, the same integer size as the individual DRR quanta, can overflow and even cause division by zero, like it happened in the following splat: Oops: divide error: 0000 [#1] SMP PTI CPU: 13 UID: 0 PID: 487 Comm: tc Tainted: G E 6.19.0-virtme #45 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Call Trace: ets_qdisc_change+0x870/0xf40 [sch_ets] qdisc_create+0x12b/0x540 tc_modify_qdisc+0x6d7/0xbd0 rtnetlink_rcv_msg+0x168/0x6b0 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x1d6/0x2b0 netlink_sendmsg+0x22e/0x470 ____sys_sendmsg+0x38a/0x3c0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x111/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f440b81c77e Code: 4d 89 d8 e8 d4 bc 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff951e4c10 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000481820 RCX: 00007f440b81c77e RDX: 0000000000000000 RSI: 00007fff951e4cd0 RDI: 0000000000000003 RBP: 00007fff951e4c20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff951f4fa8 R13: 00000000699ddede R14: 00007f440bb01000 R15: 0000000000486980 Modules linked in: sch_ets(E) netdevsim(E) ---[ end trace 0000000000000000 ]--- RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]--- Fix this using 64-bit integers for 'q_sum' and 'q_psum'.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23289", "url": "https://ubuntu.com/security/CVE-2026-23289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq() Fix a user triggerable leak on the system call failure path.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23279", "url": "https://ubuntu.com/security/CVE-2026-23279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix NULL pointer dereference in mesh_rx_csa_frame() In mesh_rx_csa_frame(), elems->mesh_chansw_params_ie is dereferenced at lines 1638 and 1642 without a prior NULL check: ifmsh->chsw_ttl = elems->mesh_chansw_params_ie->mesh_ttl; ... pre_value = le16_to_cpu(elems->mesh_chansw_params_ie->mesh_pre_value); The mesh_matches_local() check above only validates the Mesh ID, Mesh Configuration, and Supported Rates IEs. It does not verify the presence of the Mesh Channel Switch Parameters IE (element ID 118). When a received CSA action frame omits that IE, ieee802_11_parse_elems() leaves elems->mesh_chansw_params_ie as NULL, and the unconditional dereference causes a kernel NULL pointer dereference. A remote mesh peer with an established peer link (PLINK_ESTAB) can trigger this by sending a crafted SPECTRUM_MGMT/CHL_SWITCH action frame that includes a matching Mesh ID and Mesh Configuration IE but omits the Mesh Channel Switch Parameters IE. No authentication beyond the default open mesh peering is required. Crash confirmed on kernel 6.17.0-5-generic via mac80211_hwsim: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:ieee80211_mesh_rx_queued_mgmt+0x143/0x2a0 [mac80211] CR2: 0000000000000000 Fix by adding a NULL check for mesh_chansw_params_ie after mesh_matches_local() returns, consistent with how other optional IEs are guarded throughout the mesh code. The bug has been present since v3.13 (released 2014-01-19).", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23367", "url": "https://ubuntu.com/security/CVE-2026-23367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: radiotap: reject radiotap with unknown bits The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator->_next_ns_data isn't initialized (it's only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value. Fix this by moving the rejection of unknown radiotap fields down to after the in-namespace lookup, so it will really use iterator->_next_ns_data only for vendor namespaces, even in case undefined fields are present.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23318", "url": "https://ubuntu.com/security/CVE-2026-23318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Use correct version for UAC3 header validation The entry of the validators table for UAC3 AC header descriptor is defined with the wrong protocol version UAC_VERSION_2, while it should have been UAC_VERSION_3. This results in the validator never matching for actual UAC3 devices (protocol == UAC_VERSION_3), causing their header descriptors to bypass validation entirely. A malicious USB device presenting a truncated UAC3 header could exploit this to cause out-of-bounds reads when the driver later accesses unvalidated descriptor fields. The bug was introduced in the same commit as the recently fixed UAC3 feature unit sub-type typo, and appears to be from the same copy-paste error when the UAC3 section was created from the UAC2 section.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23370", "url": "https://ubuntu.com/security/CVE-2026-23370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data set_new_password() hex dumps the entire buffer, which contains plaintext password data, including current and new passwords. Remove the hex dump to avoid leaking credentials.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23352", "url": "https://ubuntu.com/security/CVE-2026-23352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/efi: defer freeing of boot services memory efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late(). There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area(). More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete. Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM. If the freed memory resides in the areas that memory map for them is still uninitialized, they won't be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages. Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map. Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that's undesirable late in boot when there is concurrency. More robust approach is to only defer freeing of the EFI boot services memory. Split efi_free_boot_services() in two. First efi_unmap_boot_services() collects ranges that should be freed into an array then efi_free_boot_services() later frees them after deferred init is complete.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23382", "url": "https://ubuntu.com/security/CVE-2026-23382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them In commit 2ff5baa9b527 (\"HID: appleir: Fix potential NULL dereference at raw event handle\"), we handle the fact that raw event callbacks can happen even for a HID device that has not been \"claimed\" causing a crash if a broken device were attempted to be connected to the system. Fix up the remaining in-tree HID drivers that forgot to add this same check to resolve the same issue.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23324", "url": "https://ubuntu.com/security/CVE-2026-23324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: usb: etas_es58x: correctly anchor the urb in the read bulk callback When submitting an urb, that is using the anchor pattern, it needs to be anchored before submitting it otherwise it could be leaked if usb_kill_anchored_urbs() is called. This logic is correctly done elsewhere in the driver, except in the read bulk callback so do that here also.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23298", "url": "https://ubuntu.com/security/CVE-2026-23298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ucan: Fix infinite loop from zero-length messages If a broken ucan device gets a message with the message length field set to 0, then the driver will loop for forever in ucan_read_bulk_callback(), hanging the system. If the length is 0, just skip the message and go on to the next one. This has been fixed in the kvaser_usb driver in the past in commit 0c73772cd2b8 (\"can: kvaser_usb: leaf: Fix potential infinite loop in command parsers\"), so there must be some broken devices out there like this somewhere.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23307", "url": "https://ubuntu.com/security/CVE-2026-23307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a message When looking at the data in a USB urb, the actual_length is the size of the buffer passed to the driver, not the transfer_buffer_length which is set by the driver as the max size of the buffer. When parsing the messages in ems_usb_read_bulk_callback() properly check the size both at the beginning of parsing the message to make sure it is big enough for the expected structure, and at the end of the message to make sure we don't overflow past the end of the buffer for the next message.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23290", "url": "https://ubuntu.com/security/CVE-2026-23290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: validate USB endpoints The pegasus driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23365", "url": "https://ubuntu.com/security/CVE-2026-23365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kalmia: validate USB endpoints The kalmia driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23312", "url": "https://ubuntu.com/security/CVE-2026-23312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: validate USB endpoints The kaweth driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23291", "url": "https://ubuntu.com/security/CVE-2026-23291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: properly drop the usb interface reference on disconnect When the device is disconnected from the driver, there is a \"dangling\" reference count on the usb interface that was grabbed in the probe callback. Fix this up by properly dropping the reference after we are done with it.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23253", "url": "https://ubuntu.com/security/CVE-2026-23253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: fix wrong reinitialization of ringbuffer on reopen dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock.", "cve_priority": "high", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-43123", "url": "https://ubuntu.com/security/CVE-2026-43123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: check return value of con2fb_acquire_newinfo() If fbcon_open() fails when called from con2fb_acquire_newinfo() then info->fbcon_par pointer remains NULL which is later dereferenced. Add check for return value of the function con2fb_acquire_newinfo() to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23220", "url": "https://ubuntu.com/security/CVE-2026-23220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error paths The problem occurs when a signed request fails smb2 signature verification check. In __process_request(), if check_sign_req() returns an error, set_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called. set_smb2_rsp_status() set work->next_smb2_rcv_hdr_off as zero. By resetting next_smb2_rcv_hdr_off to zero, the pointer to the next command in the chain is lost. Consequently, is_chained_smb2_message() continues to point to the same request header instead of advancing. If the header's NextCommand field is non-zero, the function returns true, causing __handle_ksmbd_work() to repeatedly process the same failed request in an infinite loop. This results in the kernel log being flooded with \"bad smb2 signature\" messages and high CPU usage. This patch fixes the issue by changing the return value from SERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures that the processing loop terminates immediately rather than attempting to continue from an invalidated offset.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-45911", "url": "https://ubuntu.com/security/CVE-2026-45911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix role switching during resume If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference. The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped. So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usb_hcd_is_primary_hcd+0x0/0x1c lr : cdns_host_resume+0x24/0x5c ... Call trace: usb_hcd_is_primary_hcd+0x0/0x1c (P) cdns_resume+0x6c/0xbc cdns3_controller_resume.isra.0+0xe8/0x17c cdns3_plat_resume+0x18/0x24 platform_pm_resume+0x2c/0x68 dpm_run_callback+0x90/0x248 device_resume+0x100/0x24c dpm_resume+0x190/0x2ec dpm_resume_end+0x18/0x34 suspend_devices_and_enter+0x2b0/0xa44 pm_suspend+0x16c/0x5fc state_store+0x80/0xec kobj_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x130/0x1dc vfs_write+0x240/0x370 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0x108 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-71287", "url": "https://ubuntu.com/security/CVE-2025-71287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memory: mtk-smi: fix device leak on larb probe Make sure to drop the reference taken when looking up the SMI device during larb probe on late probe failure (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23359", "url": "https://ubuntu.com/security/CVE-2026-23359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stack-out-of-bounds write in devmap get_upper_ifindexes() iterates over all upper devices and writes their indices into an array without checking bounds. Also the callers assume that the max number of upper devices is MAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack, but that assumption is not correct and the number of upper devices could be larger than MAX_NEST_DEV (e.g., many macvlans), causing a stack-out-of-bounds write. Add a max parameter to get_upper_ifindexes() to avoid the issue. When there are too many upper devices, return -EOVERFLOW and abort the redirect. To reproduce, create more than MAX_NEST_DEV(8) macvlans on a device with an XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS. Then send a packet to the device to trigger the XDP redirect path.", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43291", "url": "https://ubuntu.com/security/CVE-2026-43291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: nfc: nci: Fix parameter validation for packet data Since commit 9c328f54741b (\"net: nfc: nci: Add parameter validation for packet data\") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct).", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43283", "url": "https://ubuntu.com/security/CVE-2026-43283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle dma_free_coherent() in error path takes priv->rx_buf.alloc_len as the dma handle. This would lead to improper unmapping of the buffer. Change the dma handle to priv->rx_buf.alloc_phys.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43264", "url": "https://ubuntu.com/security/CVE-2026-43264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: of: display_timing: fix refcount leak in of_get_display_timings() of_parse_phandle() returns a device_node with refcount incremented, which is stored in 'entry' and then copied to 'native_mode'. When the error paths at lines 184 or 192 jump to 'entryfail', native_mode's refcount is not decremented, causing a refcount leak. Fix this by changing the goto target from 'entryfail' to 'timingfail', which properly calls of_node_put(native_mode) before cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43202", "url": "https://ubuntu.com/security/CVE-2026-43202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: vt8500lcdfb: fix missing dma_free_coherent() fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not freed if the error path is reached.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43203", "url": "https://ubuntu.com/security/CVE-2026-43203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: fore200e: fix use-after-free in tasklets during device removal When the PCA-200E or SBA-200E adapter is being detached, the fore200e is deallocated. However, the tx_tasklet or rx_tasklet may still be running or pending, leading to use-after-free bug when the already freed fore200e is accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet(). One of the race conditions can occur as follows: CPU 0 (cleanup) | CPU 1 (tasklet) fore200e_pca_remove_one() | fore200e_interrupt() fore200e_shutdown() | tasklet_schedule() kfree(fore200e) | fore200e_tx_tasklet() | fore200e-> // UAF Fix this by ensuring tx_tasklet or rx_tasklet is properly canceled before the fore200e is released. Add tasklet_kill() in fore200e_shutdown() to synchronize with any pending or running tasklets. Moreover, since fore200e_reset() could prevent further interrupts or data transfers, the tasklet_kill() should be placed after fore200e_reset() to prevent the tasklet from being rescheduled in fore200e_interrupt(). Finally, it only needs to do tasklet_kill() when the fore200e state is greater than or equal to FORE200E_STATE_IRQ, since tasklets are uninitialized in earlier states. In a word, the tasklet_kill() should be placed in the FORE200E_STATE_IRQ branch within the switch...case structure. This bug was identified through static analysis.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43149", "url": "https://ubuntu.com/security/CVE-2026-43149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean() The priv->rx_buffer and priv->tx_buffer are alloc'd together as contiguous buffers in uhdlc_init() but freed as two buffers in uhdlc_memclean(). Change the cleanup to only call dma_free_coherent() once on the whole buffer.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43273", "url": "https://ubuntu.com/security/CVE-2026-43273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: supply snapshot context in ceph_zero_partial_object() The ceph_zero_partial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.conf dd if=/dev/urandom of=/mnt/mycephfs/foo bs=64K count=1 mkdir /mnt/mycephfs/.snap/snap1 md5sum /mnt/mycephfs/.snap/snap1/foo fallocate -p -o 0 -l 4096 /mnt/mycephfs/foo echo 3 > /proc/sys/vm/drop/caches md5sum /mnt/mycephfs/.snap/snap1/foo # get different md5sum!!", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43159", "url": "https://ubuntu.com/security/CVE-2026-43159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix null dereference in find_network The variable pwlan has the possibility of being NULL when passed into rtw_free_network_nolock() which would later dereference the variable.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43211", "url": "https://ubuntu.com/security/CVE-2026-43211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: Fix pci_slot_trylock() error handling Commit a4e772898f8b (\"PCI: Add missing bridge lock to pci_bus_lock()\") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails. Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } } After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug. This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread. Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path. [Same patch later posted by Keith at https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com]", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43206", "url": "https://ubuntu.com/security/CVE-2026-43206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8 bytes via memset without checking the buffer size parameter. This allows unprivileged userspace to trigger an out-of bounds kernel memory write by passing a small buffer, leading to potential privilege escalation.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43275", "url": "https://ubuntu.com/security/CVE-2026-43275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Flush exception handling work when RPM level is zero Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0. When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race condition where the driver could attempt to access the host controller to handle an exception after the system had already entered a deep power-down state, resulting in a system crash. Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete and prevents illegal hardware access during the power-down sequence.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43145", "url": "https://ubuntu.com/security/CVE-2026-43145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_rproc: Fix invalid loaded resource table detection imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded resource table even when the current firmware does not provide one. When the device tree contains a \"rsc-table\" entry, priv->rsc_table is non-NULL and denotes where a resource table would be located if one is present in memory. However, when the current firmware has no resource table, rproc->table_ptr is NULL. The function still returns priv->rsc_table, and the remoteproc core interprets this as a valid loaded resource table. Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when there is no resource table for the current firmware (i.e. when rproc->table_ptr is NULL). This aligns the function's semantics with the remoteproc core: a loaded resource table is only reported when a valid table_ptr exists. With this change, starting firmware without a resource table no longer triggers a crash.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43147", "url": "https://ubuntu.com/security/CVE-2026-43147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV\" This reverts commit 05703271c3cd (\"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV\"), which causes a deadlock by recursively taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of pci_stop_and_remove_bus_device(). For example with the following sequence of commands: $ echo > /sys/bus/pci/devices//sriov_numvfs $ echo 1 > /sys/bus/pci/devices//remove A trimmed trace of the deadlock on a mlx5 device is as below: zsh/5715 is trying to acquire lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140 but task is already holding lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110 [<00000259779c844e>] print_deadlock_bug+0x31e/0x330 [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0 [<00000259779bffac>] lock_acquire+0x14c/0x350 [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520 [<000002597896413c>] mutex_lock_nested+0x3c/0x50 [<00000259784a07e4>] sriov_disable+0x34/0x140 [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core] [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core] [<00000259784857fc>] pci_device_remove+0x3c/0xa0 [<000002597851012e>] device_release_driver_internal+0x18e/0x280 [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0 [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80 [<00000259784972c2>] remove_store+0x72/0x90 [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200 [<0000025977d7241c>] vfs_write+0x24c/0x300 [<0000025977d72696>] ksys_write+0x86/0x110 [<000002597895b61c>] __do_syscall+0x14c/0x400 [<000002597896e0ee>] system_call+0x6e/0x90 This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43289", "url": "https://ubuntu.com/security/CVE-2026-43289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kexec: derive purgatory entry from symbol kexec_load_purgatory() derives image->start by locating e_entry inside an SHF_EXECINSTR section. If the purgatory object contains multiple executable sections with overlapping sh_addr, the entrypoint check can match more than once and trigger a WARN. Derive the entry section from the purgatory_start symbol when present and compute image->start from its final placement. Keep the existing e_entry fallback for purgatories that do not expose the symbol. WARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784 Call Trace: bzImage64_load+0x133/0xa00 __do_sys_kexec_file_load+0x2b3/0x5c0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e [me@linux.beauty: move helper to avoid forward declaration, per Baoquan]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43168", "url": "https://ubuntu.com/security/CVE-2026-43168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix reflink preserve cleanup issue commit c06c303832ec (\"ocfs2: fix xattr array entry __counted_by error\") doesn't handle all cases and the cleanup job for preserved xattr entries still has bug: - the 'last' pointer should be shifted by one unit after cleanup an array entry. - current code logic doesn't cleanup the first entry when xh_count is 1. Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43295", "url": "https://ubuntu.com/security/CVE-2026-43295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net() When idtab allocation fails, net is not registered with rio_add_net() yet, so kfree(net) is sufficient to release the memory. Set mport->net to NULL to avoid dangling pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43148", "url": "https://ubuntu.com/security/CVE-2026-43148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/smp: Add check for kcalloc() failure in parse_thread_groups() As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing it to of_property_read_u32_array().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43163", "url": "https://ubuntu.com/security/CVE-2026-43163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/bitmap: fix GPF in write_page caused by resize race A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod] This is a use-after-free race between bitmap_daemon_work() and __bitmap_resize(). The daemon iterates over `bitmap->storage.filemap` without locking, while the resize path frees that storage via md_bitmap_file_unmap(). `quiesce()` does not stop the md thread, allowing concurrent access to freed pages. Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43200", "url": "https://ubuntu.com/security/CVE-2026-43200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functions struct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target); While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specify the parameters in the correct order, pci_primary_epc_epf_unlink() and pci_secondary_epc_epf_unlink() specify the parameters in the wrong order, leading to the below kernel crash when using the unlink command in configfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0 [mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43158", "url": "https://ubuntu.com/security/CVE-2026-43158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix freemap adjustments when adding xattrs to leaf blocks xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) \t\t\t\t\t+ xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where \"rhs\" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 (\"xfs: fix attr leaf header freemap.size underflow\") and the previous patch that resets zero length freemap entries to have base = 0.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43187", "url": "https://ubuntu.com/security/CVE-2026-43187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: delete attr leaf freemap entries when empty Back in commit 2a2b5932db6758 (\"xfs: fix attr leaf header freemap.size underflow\"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the \"pushed-up\" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43130", "url": "https://ubuntu.com/security/CVE-2026-43130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode Commit 4fc82cd907ac (\"iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected\") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system. For example, if a VM fails to connect to the PCIe device, \"virsh destroy\" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd. Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput Although pci_device_is_present() is slower than pci_dev_is_disconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase. Besides, devtlb_invalidation_with_pasid() is called only in the paths below, which are far less frequent than memory map/unmap. 1. mm-struct release 2. {attach,release}_dev 3. set/remove PASID 4. dirty-tracking setup The gain in system stability far outweighs the negligible cost of using pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43133", "url": "https://ubuntu.com/security/CVE-2026-43133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation Commit cc3ed80ae69f (\"KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state\") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01. As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43196", "url": "https://ubuntu.com/security/CVE-2026-43196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: ti: pruss: Fix double free in pruss_clk_mux_setup() In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectly calls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np) on the error path. However, after the devm_add_action_or_reset() returns, the of_node_put(clk_mux_np) is called again, causing a double free. Fix by returning directly, to avoid the duplicate of_node_put().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43242", "url": "https://ubuntu.com/security/CVE-2026-43242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: ti: k3-socinfo: Fix regmap leak on probe failure The mmio regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43278", "url": "https://ubuntu.com/security/CVE-2026-43278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: clear cloned request bio pointer when last clone bio completes Stale rq->bio values have been observed to cause double-initialization of cloned bios in request-based device-mapper targets, leading to use-after-free and double-free scenarios. One such case occurs when using dm-multipath on top of a PCIe NVMe namespace, where cloned request bios are freed during blk_complete_request(), but rq->bio is left intact. Subsequent clone teardown then attempts to free the same bios again via blk_rq_unprep_clone(). The resulting double-free path looks like: nvme_pci_complete_batch() nvme_complete_batch() blk_mq_end_request_batch() blk_complete_request() // called on a DM clone request bio_endio() // first free of all clone bios ... rq->end_io() // end_clone_request() dm_complete_request(tio->orig) dm_softirq_done() dm_done() dm_end_request() blk_rq_unprep_clone() // second free of clone bios Fix this by clearing the clone request's bio pointer when the last cloned bio completes, ensuring that later teardown paths do not attempt to free already-released bios.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43312", "url": "https://ubuntu.com/security/CVE-2026-43312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov5647: Initialize subdev before controls In ov5647_init_controls() we call v4l2_get_subdevdata, but it is initialized by v4l2_i2c_subdev_init() in the probe, which currently happens after init_controls(). This can result in a segfault if the error condition is hit, and we try to access i2c_client, so fix the order.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43182", "url": "https://ubuntu.com/security/CVE-2026-43182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ccs: Avoid possible division by zero Calculating maximum M for scaler configuration involves dividing by MIN_X_OUTPUT_SIZE limit register's value. Albeit the value is presumably non-zero, the driver was missing the check it in fact was. Fix this.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43246", "url": "https://ubuntu.com/security/CVE-2026-43246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c/tw9906: Fix potential memory leak in tw9906_probe() In one of the error paths in tw9906_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43218", "url": "https://ubuntu.com/security/CVE-2026-43218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c/tw9903: Fix potential memory leak in tw9903_probe() In one of the error paths in tw9903_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43135", "url": "https://ubuntu.com/security/CVE-2026-43135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: Add missing unmap in snd_cx23885_hw_params() In error path, add cx23885_alsa_dma_unmap() to release the resource acquired by cx23885_alsa_dma_map().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43257", "url": "https://ubuntu.com/security/CVE-2026-43257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx88: Add missing unmap in snd_cx88_hw_params() In error path, add cx88_alsa_dma_unmap() to release resource acquired by cx88_alsa_dma_map().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43231", "url": "https://ubuntu.com/security/CVE-2026-43231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-keene: fix memory leak in error path Fix a memory leak in usb_keene_probe(). The v4l2 control handler is initialized and controls are added, but if v4l2_device_register() or video_register_device() fails afterward, the handler was never freed, leaking memory. Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensure the control handler is properly freed for all error paths after it is initialized.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43136", "url": "https://ubuntu.com/security/CVE-2026-43136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Check maxfield in hidpp_get_report_length() Do not crash when a report has no fields. Fake USB gadgets can send their own HID report descriptors and can define report structures without valid fields. This can be used to crash the kernel over USB.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43251", "url": "https://ubuntu.com/security/CVE-2026-43251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: prodikeys: Check presence of pm->input_ep82 Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, pm->input_ep82 stays NULL, which leads to a crash later. This does not happen with the real device, but can be provoked by imposing as one.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43140", "url": "https://ubuntu.com/security/CVE-2026-43140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: Do not crash on missing msc->input Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, msc->input stays NULL, leading to a crash at a later time. Detect this condition in the input_configured() hook and reject the device. This is not supposed to happen with actual magic mouse devices, but can be provoked by imposing as a magic mouse USB device.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43152", "url": "https://ubuntu.com/security/CVE-2026-43152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hid-pl: handle probe errors Errors in init must be reported back or we'll follow a NULL pointer the first time FF is used.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43315", "url": "https://ubuntu.com/security/CVE-2026-43315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeeding Drop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failing as it is trivially easy to trigger from userspace by modifying CPUID after loading CR3. E.g. modifying the state restoration selftest like so: --- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main(int argc, char *argv[]) /* Restore state in a new VM. */ vcpu = vm_recreate_with_one_vcpu(vm); - vcpu_load_state(vcpu, state); + + if (stage == 4) { + state->sregs.cr3 = BIT(44); + vcpu_load_state(vcpu, state); + + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36); + __vcpu_nested_state_set(vcpu, &state->nested); + } else { + vcpu_load_state(vcpu, state); + } /* * Restore XSAVE state in a dummy vCPU, first without doing generates: WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd] Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm] CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd] Call Trace: kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm] kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Simply delete the WARN instead of trying to prevent userspace from shoving \"illegal\" state into CR3. For better or worse, KVM's ABI allows userspace to set CPUID after SREGS, and vice versa, and KVM is very permissive when it comes to guest CPUID. I.e. attempting to enforce the virtual CPU model when setting CPUID could break userspace. Given that the WARN doesn't provide any meaningful protection for KVM or benefit for userspace, simply drop it even though the odds of breaking userspace are minuscule. Opportunistically delete a spurious newline.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43270", "url": "https://ubuntu.com/security/CVE-2026-43270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove() In mtk_mdp_probe(), vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43207", "url": "https://ubuntu.com/security/CVE-2026-43207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix error handling in probe function Add mtk_mdp_unregister_m2m_device() on the error handling path to prevent resource leak. Add check for the return value of vpu_get_plat_device() to prevent null pointer dereference. And vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43132", "url": "https://ubuntu.com/security/CVE-2026-43132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: correctly handle dm_bufio_client_create() failure If either of the calls to dm_bufio_client_create() in verity_fec_ctr() fails, then dm_bufio_client_destroy() is later called with an ERR_PTR() argument. That causes a crash. Fix this.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2025-71274", "url": "https://ubuntu.com/security/CVE-2025-71274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: core: fix race in driver_override_show() and use core helper The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string_attr macro with explicit show and store functions. The new driver_override_store uses the standard driver_set_override helper. Since the introduction of driver_set_override, the comments in include/linux/rpmsg.h have stated that this helper must be used to set or clear driver_override, but the implementation was not updated until now. Because driver_set_override modifies and frees the string while holding the device_lock, the new driver_override_show now correctly holds the device_lock during the read operation to prevent the race. Additionally, since rpmsg_string_attr has only ever been used for driver_override, removing the macro simplifies the code.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43233", "url": "https://ubuntu.com/security/CVE-2026-43233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: fix OOB read in decode_choice() In decode_choice(), the boundary check before get_len() uses the variable `len`, which is still 0 from its initialization at the top of the function: unsigned int type, ext, len = 0; ... if (ext || (son->attr & OPEN)) { BYTE_ALIGN(bs); if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */ return H323_ERROR_BOUND; len = get_len(bs); /* OOB read */ When the bitstream is exactly consumed (bs->cur == bs->end), the check nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent get_len() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well. This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nf_conntrack_h323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer. Fix this by checking for 2 bytes (the maximum that get_len() may read) instead of the uninitialized `len`. This matches the pattern used at every other get_len() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43205", "url": "https://ubuntu.com/security/CVE-2026-43205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: validate num_ifs to prevent out-of-bounds write The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes() but never validates it against DPSW_MAX_IF (64). This value controls iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices into the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reports num_ifs >= 64, the loop can write past the array bounds. Add a bound check for num_ifs in dpaa2_switch_init(). dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all ports match the flood filter, the loop fills all 64 slots and the control interface write overflows by one entry. The check uses >= because num_ifs == DPSW_MAX_IF is also functionally broken. build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ...", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43194", "url": "https://ubuntu.com/security/CVE-2026-43194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: consume xmit errors of GSO frames udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min. These tests use veth to simulate GRO. They attach a trivial (\"return XDP_PASS;\") XDP program to the veth to force TSO off and NAPI on. Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]). In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck. The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok | ok ok ok \\\\ \t\t\t snd_nxt \"x\" means packet lost by veth, and \"ok\" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent. So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above). Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely. We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-\"networks\" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix? Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link).", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43156", "url": "https://ubuntu.com/security/CVE-2026-43156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: enable basic endpoint checking pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors: - usb_rcvbulkpipe(dev, 1) for RX data - usb_sndbulkpipe(dev, 2) for TX data - usb_rcvintpipe(dev, 3) for status interrupts A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes. Add a pegasus_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion. Similar fix to - commit 90b7f2961798 (\"net: usb: rtl8150: enable basic endpoint checking\") - commit 9e7021d2aeae (\"net: usb: catc: enable basic endpoint checking\")", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43232", "url": "https://ubuntu.com/security/CVE-2026-43232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets When the FarSync T-series card is being detached, the fst_card_info is deallocated in fst_remove_one(). However, the fst_tx_task or fst_int_task may still be running or pending, leading to use-after-free bugs when the already freed fst_card_info is accessed in fst_process_tx_work_q() or fst_process_int_work_q(). A typical race condition is depicted below: CPU 0 (cleanup) | CPU 1 (tasklet) | fst_start_xmit() fst_remove_one() | tasklet_schedule() unregister_hdlc_device()| | fst_process_tx_work_q() //handler kfree(card) //free | do_bottom_half_tx() | card-> //use The following KASAN trace was captured: ================================================================== BUG: KASAN: slab-use-after-free in do_bottom_half_tx+0xb88/0xd00 Read of size 4 at addr ffff88800aad101c by task ksoftirqd/3/32 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcb/0x5d0 ? do_bottom_half_tx+0xb88/0xd00 kasan_report+0xb8/0xf0 ? do_bottom_half_tx+0xb88/0xd00 do_bottom_half_tx+0xb88/0xd00 ? _raw_spin_lock_irqsave+0x85/0xe0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx___hrtimer_run_queues+0x10/0x10 fst_process_tx_work_q+0x67/0x90 tasklet_action_common+0x1fa/0x720 ? hrtimer_interrupt+0x31f/0x780 handle_softirqs+0x176/0x530 __irq_exit_rcu+0xab/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 41 on cpu 3 at 72.330843s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 __kasan_kmalloc+0x7f/0x90 fst_add_one+0x1a5/0x1cd0 local_pci_probe+0xdd/0x190 pci_device_probe+0x341/0x480 really_probe+0x1c6/0x6a0 __driver_probe_device+0x248/0x310 driver_probe_device+0x48/0x210 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x101/0x190 __device_attach+0x198/0x3a0 device_initial_probe+0x78/0xa0 pci_bus_add_device+0x81/0xc0 pci_bus_add_devices+0x7e/0x190 enable_slot+0x9b9/0x1130 acpiphp_check_bridge.part.0+0x2e1/0x460 acpiphp_hotplug_notify+0x36c/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... Freed by task 41 on cpu 1 at 75.138639s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x135/0x410 fst_remove_one+0x2ca/0x540 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0x364/0x530 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device+0xd/0x20 disable_slot+0x116/0x260 acpiphp_disable_and_eject_slot+0x4b/0x190 acpiphp_hotplug_notify+0x230/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... The buggy address belongs to the object at ffff88800aad1000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 28 bytes inside of freed 1024-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xaad0 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x100000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000003 ffffea00002ab401 00000000ffffffff 00000000ffffffff head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88800aad0f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800aad0f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800aad1000: fa fb ---truncated---", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43134", "url": "https://ubuntu.com/security/CVE-2026-43134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ This adds a check for encryption key size upon receiving L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAP_CR_LE_BAD_KEY_SIZE.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43180", "url": "https://ubuntu.com/security/CVE-2026-43180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls netif_stop_queue() and netif_wake_queue(). These are TX queue flow control functions unrelated to RX multicast configuration. The premature netif_wake_queue() can re-enable TX while tx_urb is still in-flight, leading to a double usb_submit_urb() on the same URB: kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); } kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done } kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active } This triggers the WARN in usb_submit_urb(): \"URB submitted while active\" This is a similar class of bug fixed in rtl8150 by - commit 958baf5eaee3 (\"net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast\"). Also kaweth_set_rx_mode() is already functionally broken, the real set_rx_mode action is performed by kaweth_async_set_rx_mode(), which in turn is not a no-op only at ndo_open() time.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43139", "url": "https://ubuntu.com/security/CVE-2026-43139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix uninitialized saddr in xfrm6_get_saddr() xfrm6_get_saddr() does not check the return value of ipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6_get_saddr() still returns 0 (success). This causes the caller xfrm_tmpl_resolve_one() to use the uninitialized address in xfrm_state_find(), triggering KMSAN warning: ===================================================== BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940 xfrm_state_find+0x2424/0xa940 xfrm_resolve_and_create_bundle+0x906/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 xfrm_lookup_route+0x63/0x2b0 ip_route_output_flow+0x1ce/0x270 udp_sendmsg+0x2ce1/0x3400 inet_sendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64_sys_sendto+0x130/0x200 x64_sys_call+0x332b/0x3e70 do_syscall_64+0xd3/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable tmp.i.i created at: xfrm_resolve_and_create_bundle+0x3e3/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 ===================================================== Fix by checking the return value of ipv6_dev_get_saddr() and propagating the error.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43141", "url": "https://ubuntu.com/security/CVE-2026-43141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut Number of MW LUTs depends on NTB configuration and can be set to zero, in such scenario rounddown_pow_of_two will cause undefined behaviour and should not be performed. This patch ensures that rounddown_pow_of_two is called on valid value.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43241", "url": "https://ubuntu.com/security/CVE-2026-43241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access Number of MW LUTs depends on NTB configuration and can be set to MAX_MWS, This patch protects against invalid index out of bounds access to mw_sizes When invalid access print message to user that configuration is not valid.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43279", "url": "https://ubuntu.com/security/CVE-2026-43279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Add sanity check for OOB writes at silencing At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2025-71267", "url": "https://ubuntu.com/security/CVE-2025-71267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an ATTR_LIST attribute indicates a zero data size while the driver allocates memory for it. When ntfs_load_attr_list() processes a resident ATTR_LIST with data_size set to zero, it still allocates memory because of al_aligned(0). This creates an inconsistent state where ni->attr_list.size is zero, but ni->attr_list.le is non-null. This causes ni_enum_attr_ex to incorrectly assume that no attribute list exists and enumerates only the primary MFT record. When it finds ATTR_LIST, the code reloads it and restarts the enumeration, repeating indefinitely. The mount operation never completes, hanging the kernel thread. This patch adds validation to ensure that data_size is non-zero before memory allocation. When a zero-sized ATTR_LIST is detected, the function returns -EINVAL, preventing a DoS vulnerability.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2025-71265", "url": "https://ubuntu.com/security/CVE-2025-71265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an attribute header indicates an empty run list, while directory entries reference it as containing actual data. In NTFS, setting evcn=-1 with svcn=0 is a valid way to represent an empty run list, and run_unpack() correctly handles this by checking if evcn + 1 equals svcn and returning early without parsing any run data. However, this creates a problem when there is metadata inconsistency, where the attribute header claims to be empty (evcn=-1) but the caller expects to read actual data. When run_unpack() immediately returns success upon seeing this condition, it leaves the runs_tree uninitialized with run->runs as a NULL. The calling function attr_load_runs_range() assumes that a successful return means that the runs were loaded and sets clen to 0, expecting the next run_lookup_entry() call to succeed. Because runs_tree remains uninitialized, run_lookup_entry() continues to fail, and the loop increments vcn by zero (vcn += 0), leading to an infinite loop. This patch adds a retry counter to detect when run_lookup_entry() fails consecutively after attr_load_runs_vcn(). If the run is still not found on the second attempt, it indicates corrupted metadata and returns -EINVAL, preventing the Denial-of-Service (DoS) vulnerability.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2025-71266", "url": "https://ubuntu.com/security/CVE-2025-71266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: check return value of indx_find to avoid infinite loop We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed dentry in the ntfs3 filesystem can cause the kernel to hang during the lookup operations. By setting the HAS_SUB_NODE flag in an INDEX_ENTRY within a directory's INDEX_ALLOCATION block and manipulating the VCN pointer, an attacker can cause the indx_find() function to repeatedly read the same block, allocating 4 KB of memory each time. The kernel lacks VCN loop detection and depth limits, causing memory exhaustion and an OOM crash. This patch adds a return value check for fnd_push() to prevent a memory exhaustion vulnerability caused by infinite loops. When the index exceeds the size of the fnd->nodes array, fnd_push() returns -EINVAL. The indx_find() function checks this return value and stops processing, preventing further memory allocation.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-43225", "url": "https://ubuntu.com/security/CVE-2026-43225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix memory leak on failure path cfg80211_inform_bss_frame() may return NULL on failure. In that case, the allocated buffer 'buf' is not freed and the function returns early, leading to potential memory leak. Fix this by ensuring that 'buf' is freed on both success and failure paths.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43230", "url": "https://ubuntu.com/security/CVE-2026-43230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: Clear reconnect pending bit When canceling the reconnect worker, care must be taken to reset the reconnect-pending bit. If the reconnect worker has not yet been scheduled before it is canceled, the reconnect-pending bit will stay on forever.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43296", "url": "https://ubuntu.com/security/CVE-2026-43296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Workaround SQM/PSE stalls by disabling sticky NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated. work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21) These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43226", "url": "https://ubuntu.com/security/CVE-2026-43226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: No shortcut out of RDS_CONN_ERROR RDS connections carry a state \"rds_conn_path::cp_state\" and transitions from one state to another and are conditional upon an expected state: \"rds_conn_path_transition.\" There is one exception to this conditionality, which is \"RDS_CONN_ERROR\" that can be enforced by \"rds_conn_path_drop\" regardless of what state the condition is currently in. But as soon as a connection enters state \"RDS_CONN_ERROR\", the connection handling code expects it to go through the shutdown-path. The RDS/TCP multipath changes added a shortcut out of \"RDS_CONN_ERROR\" straight back to \"RDS_CONN_CONNECTING\" via \"rds_tcp_accept_one_path\" (e.g. after \"rds_tcp_state_change\"). A subsequent \"rds_tcp_reset_callbacks\" can then transition the state to \"RDS_CONN_RESETTING\" with a shutdown-worker queued. That'll trip up \"rds_conn_init_shutdown\", which was never adjusted to handle \"RDS_CONN_RESETTING\" and subsequently drops the connection with the dreaded \"DR_INV_CONN_STATE\", which leaves \"RDS_SHUTDOWN_WORK_QUEUED\" on forever. So we do two things here: a) Don't shortcut \"RDS_CONN_ERROR\", but take the longer path through the shutdown code. b) Add \"RDS_CONN_RESETTING\" to the expected states in \"rds_conn_init_shutdown\" so that we won't error out and get stuck, if we ever hit weird state transitions like this again.\"", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43190", "url": "https://ubuntu.com/security/CVE-2026-43190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_tcpmss: check remaining length before reading optlen Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload).", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43255", "url": "https://ubuntu.com/security/CVE-2026-43255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix WARNING in usb_tx_block The function usb_tx_block() submits cardp->tx_urb without ensuring that any previous transmission on this URB has completed. If a second call occurs while the URB is still active (e.g. during rapid firmware loading), usb_submit_urb() detects the active state and triggers a warning: 'URB submitted while active'. Fix this by enforcing serialization: call usb_kill_urb() before submitting the new request. This ensures the URB is idle and safe to reuse.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43314", "url": "https://ubuntu.com/security/CVE-2026-43314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: remove fake timeout to avoid leak request Since commit 15f73f5b3e59 (\"blk-mq: move failure injection out of blk_mq_complete_request\"), drivers are responsible for calling blk_should_fake_timeout() at appropriate code paths and opportunities. However, the dm driver does not implement its own timeout handler and relies on the timeout handling of its slave devices. If an io-timeout-fail error is injected to a dm device, the request will be leaked and never completed, causing tasks to hang indefinitely. Reproduce: 1. prepare dm which has iscsi slave device 2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times 3. read/write dm 4. iscsiadm -m node -u Result: hang task like below [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds. [ 862.244133] Tainted: G E 6.19.0-rc1+ #51 [ 862.244337] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000 [ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi] [ 862.245264] Call Trace: [ 862.245587] [ 862.245814] __schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120 [ 862.247688] elevator_change+0x16d/0x460 [ 862.247893] elevator_set_none+0x87/0xf0 [ 862.248798] blk_unregister_queue+0x12e/0x2a0 [ 862.248995] __del_gendisk+0x231/0x7e0 [ 862.250143] del_gendisk+0x12f/0x1d0 [ 862.250339] sd_remove+0x85/0x130 [sd_mod] [ 862.250650] device_release_driver_internal+0x36d/0x530 [ 862.250849] bus_remove_device+0x1dd/0x3f0 [ 862.251042] device_del+0x38a/0x930 [ 862.252095] __scsi_remove_device+0x293/0x360 [ 862.252291] scsi_remove_target+0x486/0x760 [ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi] [ 862.252886] process_one_work+0x633/0xe50 [ 862.253101] worker_thread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] ret_from_fork+0x2a6/0x470 [ 862.255852] ret_from_fork_asm+0x1a/0x30 [ 862.256037] Remove the blk_should_fake_timeout() check from dm, as dm has no native timeout handling and should not attempt to fake timeouts.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-71292", "url": "https://ubuntu.com/security/CVE-2025-71292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: nlink overflow in jfs_rename If nlink is maximal for a directory (-1) and inside that directory you perform a rename for some child directory (not moving from the parent), then the nlink of the first directory is first incremented and later decremented. Normally this is fine, but when nlink = -1 this causes a wrap around to 0, and then drop_nlink issues a warning. After applying the patch syzbot no longer issues any warnings. I also ran some basic fs tests to look for any regressions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43236", "url": "https://ubuntu.com/security/CVE-2026-43236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying the atmel_hlcdc_plane state structure without properly duplicating the drm_plane_state. In particular, state->commit remained set to the old state commit, which can lead to a use-after-free in the next drm_atomic_commit() call. Fix this by calling __drm_atomic_helper_duplicate_plane_state(), which correctly clones the base drm_plane_state (including the ->commit pointer). It has been seen when closing and re-opening the device node while another DRM client (e.g. fbdev) is still attached: ============================================================================= BUG kmalloc-64 (Not tainted): Poison overwritten ----------------------------------------------------------------------------- 0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0 pid=29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28 Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0 pid=169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0 flags=0x200(workingset|zone=0) Object 0xc611b340 @offset=832 fp=0xc611b7c0", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43269", "url": "https://ubuntu.com/security/CVE-2026-43269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback After several commits, the slab memory increases. Some drm_crtc_commit objects are not freed. The atomic_destroy_state callback only put the framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function to put all the objects that are no longer needed. It has been seen after hours of usage of a graphics application or using kmemleak: unreferenced object 0xc63a6580 (size 64): comm \"egt_basic\", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleak_alloc+0x34/0x3c __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43287", "url": "https://ubuntu.com/security/CVE-2026-43287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Account property blob allocations to memcg DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory. Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM. Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43183", "url": "https://ubuntu.com/security/CVE-2026-43183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx25821: Fix a resource leak in cx25821_dev_setup() Add release_mem_region() if ioremap() fails to release the memory region obtained by cx25821_get_resources().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43316", "url": "https://ubuntu.com/security/CVE-2026-43316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: solo6x10: Check for out of bounds chip_id Clang with CONFIG_UBSAN_SHIFT=y noticed a condition where a signed type (literal \"1\" is an \"int\") could end up being shifted beyond 32 bits, so instrumentation was added (and due to the double is_tw286x() call seen via inlining), Clang decides the second one must now be undefined behavior and elides the rest of the function[1]. This is a known problem with Clang (that is still being worked on), but we can avoid the entire problem by actually checking the existing max chip ID, and now there is no runtime instrumentation added at all since everything is known to be within bounds. Additionally use an unsigned value for the shift to remove the instrumentation even without the explicit bounds checking. [hverkuil: fix checkpatch warning for is_tw286x]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43223", "url": "https://ubuntu.com/security/CVE-2026-43223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix URB leak in pvr2_send_request_ex When pvr2_send_request_ex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2_send_request_ex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usb_submit_urb(). Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43302", "url": "https://ubuntu.com/security/CVE-2026-43302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Set DMA segment size to avoid debug warnings When using V3D rendering with CONFIG_DMA_API_DEBUG enabled, the kernel occasionally reports a segment size mismatch. This is because 'max_seg_size' is not set. The kernel defaults to 64K. setting 'max_seg_size' to the maximum will prevent 'debug_dma_map_sg()' from complaining about the over-mapping of the V3D segment length. DMA-API: v3d 1002000000.v3d: mapping sg segment longer than device claims to support [len=8290304] [max=65536] WARNING: CPU: 0 PID: 493 at kernel/dma/debug.c:1179 debug_dma_map_sg+0x330/0x388 CPU: 0 UID: 0 PID: 493 Comm: Xorg Not tainted 6.12.53-yocto-standard #1 Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_dma_map_sg+0x330/0x388 lr : debug_dma_map_sg+0x330/0x388 sp : ffff8000829a3ac0 x29: ffff8000829a3ac0 x28: 0000000000000001 x27: ffff8000813fe000 x26: ffffc1ffc0000000 x25: ffff00010fdeb760 x24: 0000000000000000 x23: ffff8000816a9bf0 x22: 0000000000000001 x21: 0000000000000002 x20: 0000000000000002 x19: ffff00010185e810 x18: ffffffffffffffff x17: 69766564206e6168 x16: 74207265676e6f6c x15: 20746e656d676573 x14: 20677320676e6970 x13: 5d34303334393134 x12: 0000000000000000 x11: 00000000000000c0 x10: 00000000000009c0 x9 : ffff8000800e0b7c x8 : ffff00010a315ca0 x7 : ffff8000816a5110 x6 : 0000000000000001 x5 : 000000000000002b x4 : 0000000000000002 x3 : 0000000000000008 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00010a315280 Call trace: debug_dma_map_sg+0x330/0x388 __dma_map_sg_attrs+0xc0/0x278 dma_map_sgtable+0x30/0x58 drm_gem_shmem_get_pages_sgt+0xb4/0x140 v3d_bo_create_finish+0x28/0x130 [v3d] v3d_create_bo_ioctl+0x54/0x180 [v3d] drm_ioctl_kernel+0xc8/0x140 drm_ioctl+0x2d4/0x4d8", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43124", "url": "https://ubuntu.com/security/CVE-2026-43124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore: ram_core: fix incorrect success return when vmap() fails In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43227", "url": "https://ubuntu.com/security/CVE-2026-43227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/sh_tmu: Always leave device running after probe The TMU device can be used as both a clocksource and a clockevent provider. The driver tries to be smart and power itself on and off, as well as enabling and disabling its clock when it's not in operation. This behavior is slightly altered if the TMU is used as an early platform device in which case the device is left powered on after probe, but the clock is still enabled and disabled at runtime. This has worked for a long time, but recent improvements in PREEMPT_RT and PROVE_LOCKING have highlighted an issue. As the TMU registers itself as a clockevent provider, clockevents_register_device(), it needs to use raw spinlocks internally as this is the context of which the clockevent framework interacts with the TMU driver. However in the context of holding a raw spinlock the TMU driver can't really manage its power state or clock with calls to pm_runtime_*() and clk_*() as these calls end up in other platform drivers using regular spinlocks to control power and clocks. This mix of spinlock contexts trips a lockdep warning. ============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90 For non-PREEMPT_RT builds this is not really an issue, but for PREEMPT_RT builds where normal spinlocks can sleep this might be an issue. Be cautious and always leave the power and clock running after probe.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43313", "url": "https://ubuntu.com/security/CVE-2026-43313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4() In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDE device and then reassigned an ISA device: dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...); dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...); If the first lookup succeeds but the second fails, dev becomes NULL. This leads to a potential null-pointer dereference when dev_dbg() is called: if (errata.piix4.bmisx) dev_dbg(&dev->dev, ...); To prevent this, use two temporary pointers and retrieve each device independently, avoiding overwriting dev with a possible NULL value. [ rjw: Subject adjustment, added an empty code line ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43266", "url": "https://ubuntu.com/security/CVE-2026-43266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EFI/CPER: don't go past the ARM processor CPER record buffer There's a logic inside GHES/CPER to detect if the section_length is too small, but it doesn't detect if it is too big. Currently, if the firmware receives an ARM processor CPER record stating that a section length is big, kernel will blindly trust section_length, producing a very long dump. For instance, a 67 bytes record with ERR_INFO_NUM set 46198 and section length set to 854918320 would dump a lot of data going a way past the firmware memory-mapped area. Fix it by adding a logic to prevent it to go past the buffer if ERR_INFO_NUM is too big, making it report instead: \t[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 \t[Hardware Error]: event severity: recoverable \t[Hardware Error]: Error 0, type: recoverable \t[Hardware Error]: section_type: ARM processor error \t[Hardware Error]: MIDR: 0xff304b2f8476870a \t[Hardware Error]: section length: 854918320, CPER size: 67 \t[Hardware Error]: section length is too big \t[Hardware Error]: firmware-generated error record is incorrect \t[Hardware Error]: ERR_INFO_NUM is 46198 [ rjw: Subject and changelog tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43277", "url": "https://ubuntu.com/security/CVE-2026-43277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: APEI/GHES: ensure that won't go past CPER allocated record The logic at ghes_new() prevents allocating too large records, by checking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB). Yet, the allocation is done with the actual number of pages from the CPER bios table location, which can be smaller. Yet, a bad firmware could send data with a different size, which might be bigger than the allocated memory, causing an OOPS: Unable to handle kernel paging request at virtual address fff00000f9b40000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000 [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 Workqueue: kacpi_notify acpi_os_execute_deferred pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : hex_dump_to_buffer+0x30c/0x4a0 lr : hex_dump_to_buffer+0x328/0x4a0 sp : ffff800080e13880 x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083 x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004 x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083 x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010 x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008 x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020 x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000 x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008 Call trace: hex_dump_to_buffer+0x30c/0x4a0 (P) print_hex_dump+0xac/0x170 cper_estatus_print_section+0x90c/0x968 cper_estatus_print+0xf0/0x158 __ghes_print_estatus+0xa0/0x148 ghes_proc+0x1bc/0x220 ghes_notify_hed+0x5c/0xb8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x80 acpi_hed_notify+0x28/0x40 acpi_ev_notify_dispatch+0x50/0x80 acpi_os_execute_deferred+0x24/0x48 process_one_work+0x15c/0x3b0 worker_thread+0x2d0/0x400 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44) ---[ end trace 0000000000000000 ]--- Prevent that by taking the actual allocated are into account when checking for CPER length. [ rjw: Subject tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43171", "url": "https://ubuntu.com/security/CVE-2026-43171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EFI/CPER: don't dump the entire memory region The current logic at cper_print_fw_err() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory. The end result can be: - the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region. Fix it by checking if the section length is too small before doing a hex dump. [ rjw: Subject tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43184", "url": "https://ubuntu.com/security/CVE-2026-43184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rnbd-srv: Zero the rsp buffer before using it Before using the data buffer to send back the response message, zero it completely. This prevents any stray bytes to be picked up by the client side when there the message is exchanged between different protocol versions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43261", "url": "https://ubuntu.com/security/CVE-2026-43261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Add support for TSV110 Spectre-BHB mitigation The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43262", "url": "https://ubuntu.com/security/CVE-2026-43262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fiemap page fault fix In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault. Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary. Fixes xfstest generic/742.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43209", "url": "https://ubuntu.com/security/CVE-2026-43209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: minix: Add required sanity checking to minix_check_superblock() The fs/minix implementation of the minix filesystem does not currently support any other value for s_log_zone_size than 0. This is also the only value supported in util-linux; see mkfs.minix.c line 511. In addition, this patch adds some sanity checking for the other minix superblock fields, and moves the minix_blocks_needed() checks for the zmap and imap also to minix_check_super_block(). This also closes a related syzbot bug report.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43268", "url": "https://ubuntu.com/security/CVE-2026-43268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: pretend special inodes as regular files Since commit af153bb63a33 (\"vfs: catch invalid modes in may_open()\") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23241", "url": "https://ubuntu.com/security/CVE-2026-23241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: add missing syscalls to read class The \"at\" variant of getxattr() and listxattr() are missing from the audit read class. Calling getxattrat() or listxattrat() on a file to read its extended attributes will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds missing syscalls to the audit read class.", "cve_priority": "medium", "cve_public_date": "2026-03-17 10:16:00 UTC" }, { "cve": "CVE-2025-71239", "url": "https://ubuntu.com/security/CVE-2025-71239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: add fchmodat2() to change attributes class fchmodat2(), introduced in version 6.6 is currently not in the change attribute class of audit. Calling fchmodat2() to change a file attribute in the same fashion than chmod() or fchmodat() will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds fchmodat2() to the change attributes class.", "cve_priority": "medium", "cve_public_date": "2026-03-17 10:15:00 UTC" }, { "cve": "CVE-2026-45964", "url": "https://ubuntu.com/security/CVE-2026-45964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path Commit 5940d1cf9f42 (\"SUNRPC: Rebalance a kref in auth_gss.c\") added a kref_get(&gss_auth->kref) call to balance the gss_put_auth() done in gss_release_msg(), but forgot to add a corresponding kref_put() on the error path when kstrdup_const() fails. If service_name is non-NULL and kstrdup_const() fails, the function jumps to err_put_pipe_version which calls put_pipe_version() and kfree(gss_msg), but never releases the gss_auth reference. This leads to a kref leak where the gss_auth structure is never freed. Add a forward declaration for gss_free_callback() and call kref_put() in the err_put_pipe_version error path to properly release the reference taken earlier.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45870", "url": "https://ubuntu.com/security/CVE-2026-45870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: auth_gss: fix memory leaks in XDR decoding error paths The gssx_dec_ctx(), gssx_dec_status(), and gssx_dec_name() functions allocate memory via gssx_dec_buffer(), which calls kmemdup(). When a subsequent decode operation fails, these functions return immediately without freeing previously allocated buffers, causing memory leaks. The leak in gssx_dec_ctx() is particularly relevant because the caller (gssp_accept_sec_context_upcall) initializes several buffer length fields to non-zero values, resulting in memory allocation: struct gssx_ctx rctxh = { .exported_context_token.len = GSSX_max_output_handle_sz, .mech.len = GSS_OID_MAX_LEN, .src_name.display_name.len = GSSX_max_princ_sz, .targ_name.display_name.len = GSSX_max_princ_sz }; If, for example, gssx_dec_name() succeeds for src_name but fails for targ_name, the memory allocated for exported_context_token, mech, and src_name.display_name remains unreferenced and cannot be reclaimed. Add error handling with goto-based cleanup to free any previously allocated buffers before returning an error.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45948", "url": "https://ubuntu.com/security/CVE-2026-45948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leak in ext4_ext_shift_extents() In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4_find_extent(), leading to a memory leak. Fix this by jumping to the out label to ensure the path is properly released.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45912", "url": "https://ubuntu.com/security/CVE-2026-45912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't cache extent during splitting extent Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful. Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, when ext4_split_extent_at() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4_find_extent() and ext4_cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting. In adition, if the unwritten extent cache is not shrunk during the splitting, ext4_cache_extents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46250", "url": "https://ubuntu.com/security/CVE-2026-46250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: MIPS: Work around LLVM bug when gp is used as global register variable On MIPS, __current_thread_info is defined as global register variable locating in $gp, and is simply assigned with new address during kernel relocation. This however is broken with LLVM, which always restores $gp if it finds $gp is clobbered in any form, including when intentionally through a global register variable. This is against GCC's documentation[1], which requires a callee-saved register used as global register variable not to be restored if it's clobbered. As a result, $gp will continue to point to the unrelocated kernel after the epilog of relocate_kernel(), leading to an early crash in init_idle, [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY [ 0.000000] Tainted: [W]=WARN [ 0.000000] Hardware name: loongson,loongson64v-4core-virtio [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240 [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001 [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002 [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80 [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80 [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90 [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90 [ 0.000000] Hi : 0000000000000000 [ 0.000000] Lo : 0000000000000000 [ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270 [ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270 [ 0.000000] Status: 540000e2\tKX SX UX KERNEL EXL [ 0.000000] Cause : 00000008 (ExcCode 02) [ 0.000000] BadVA : 0000000000000000 [ 0.000000] PrId : 00006305 (ICT Loongson-3) [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000) [ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528 [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000 [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258 [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98 [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [] init_idle+0x130/0x270 [ 0.000000] [] sched_init+0x5c8/0x6c0 [ 0.000000] [] start_kernel+0x27c/0x7a8 This bug has been reported to LLVM[2] and affects version from (at least) 18 to 21. Let's work around this by using inline assembly to assign $gp before a fix is widely available.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45974", "url": "https://ubuntu.com/security/CVE-2026-45974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not found If btrfs_search_slot_for_read() returns 1, it means we did not find any key greater than or equals to the key we asked for, meaning we have reached the end of the tree and therefore the path is not valid. If this happens we need to break out of the loop and stop, instead of continuing and accessing an invalid path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45965", "url": "https://ubuntu.com/security/CVE-2026-45965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix invalid deref of rawdata when export_binary is unset If the export_binary parameter is disabled on runtime, profiles that were loaded before that will still have their rawdata stored in apparmorfs, with a symbolic link to the rawdata on the policy directory. When one of those profiles are replaced, the rawdata is set to NULL, but when trying to resolve the symbolic links to rawdata for that profile, it will try to dereference profile->rawdata->name when profile->rawdata is now NULL causing an oops. Fix it by checking if rawdata is set. [ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088 [ 168.657420] #PF: supervisor read access in kernel mode [ 168.660619] #PF: error_code(0x0000) - not-present page [ 168.663613] PGD 0 P4D 0 [ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI [ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary) [ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330 [ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8 [ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282 [ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158 [ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80 [ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000 [ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80 [ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0 [ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000 [ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0 [ 168.701696] Call Trace: [ 168.702325] [ 168.702995] rawdata_get_link_data+0x1c/0x30 [ 168.704145] vfs_readlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64_sys_readlink+0x1e/0x30 [ 168.708653] x64_sys_call+0x1d77/0x26b0 [ 168.709525] do_syscall_64+0x81/0x500 [ 168.710348] ? do_statx+0x72/0xb0 [ 168.711109] ? putname+0x3e/0x80 [ 168.711845] ? __x64_sys_statx+0xb7/0x100 [ 168.712711] ? x64_sys_call+0x10fc/0x26b0 [ 168.713577] ? do_syscall_64+0xbf/0x500 [ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0 [ 168.715404] ? irqentry_exit+0xb2/0x740 [ 168.716359] ? exc_page_fault+0x90/0x1b0 [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45848", "url": "https://ubuntu.com/security/CVE-2026-45848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix NULL sock in aa_sock_file_perm Deal with the potential that sock and sock-sk can be NULL during socket setup or teardown. This could lead to an oops. The fix for NULL pointer dereference in __unix_needs_revalidation shows this is at least possible for af_unix sockets. While the fix for af_unix sockets applies for newer mediation this is still the fall back path for older af_unix mediation and other sockets, so ensure it is covered.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45970", "url": "https://ubuntu.com/security/CVE-2026-45970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: alb: fix UAF in rlb_arp_recv during bond up/down The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN. However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag. [ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? __pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry. Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45847", "url": "https://ubuntu.com/security/CVE-2026-45847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: remove WARN_ON_ONCE when accessing forward path array Although unlikely, recent support for IPIP tunnels increases chances of reaching this WARN_ON_ONCE if userspace manages to build a sufficiently long forward path. Remove it.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45890", "url": "https://ubuntu.com/security/CVE-2026-45890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen-netback: reject zero-queue configuration from guest A malicious or buggy Xen guest can write \"0\" to the xenbus key \"multi-queue-num-queues\". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range(). On systems with panic_on_warn=1, this allows a guest-to-host denial of service. The Xen network interface specification requires the queue count to be \"greater than zero\". Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45968", "url": "https://ubuntu.com/security/CVE-2026-45968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuidle: Skip governor when only one idle state is available On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash. [ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668 Fix this by adding a bail-out in cpuidle_select() that returns state 0 directly when state_count <= 1, bypassing the governor and keeping the tick running.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45935", "url": "https://ubuntu.com/security/CVE-2026-45935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot In the 'DeleteIndexEntryRoot' case of the 'do_action' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking. Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize); It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to size_t for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow. This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45864", "url": "https://ubuntu.com/security/CVE-2026-45864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent infinite loops caused by the next valid being the same When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1]. Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this. [1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45868", "url": "https://ubuntu.com/security/CVE-2026-45868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix refcount leak in pcs_add_gpio_func() of_parse_phandle_with_args() returns a device_node pointer with refcount incremented in gpiospec.np. The loop iterates through all phandles but never releases the reference, causing a refcount leak on each iteration. Add of_node_put() calls to release the reference after extracting the needed arguments and on the error path when devm_kzalloc() fails. This bug was detected by our static analysis tool and verified by my code review.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45883", "url": "https://ubuntu.com/security/CVE-2026-45883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: sca3000: Fix a resource leak in sca3000_probe() spi->irq from request_threaded_irq() not released when iio_device_register() fails. Add an return value check and jump to a common error handler when iio_device_register() fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45875", "url": "https://ubuntu.com/security/CVE-2026-45875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: arizona: Fix regulator resource leak on wm5102_clear_write_sequencer() failure The wm5102_clear_write_sequencer() helper may return an error and just return, bypassing the cleanup sequence and causing regulators to remain enabled, leading to a resource leak. Change the direct return to jump to the err_reset label to properly free the resources.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45978", "url": "https://ubuntu.com/security/CVE-2026-45978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: greybus: lights: avoid NULL deref gb_lights_light_config() stores channel_count before allocating the channels array. If kcalloc() fails, gb_lights_release() iterates the non-zero count and dereferences light->channels, which is NULL. Allocate channels first and only then publish channels_count so the cleanup path can't walk a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45954", "url": "https://ubuntu.com/security/CVE-2026-45954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe() In au1200fb_drv_probe(), when platform_get_irq fails(), it directly returns from the function with an error code, which causes a memory leak. Replace it with a goto label to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45857", "url": "https://ubuntu.com/security/CVE-2026-45857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: csiostor: Fix dereference of null pointer rn The error exit path when rn is NULL ends up deferencing the null pointer rn via the use of the macro CSIO_INC_STATS. Fix this by adding a new error return path label after the use of the macro to avoid the deference.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45856", "url": "https://ubuntu.com/security/CVE-2026-45856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45852", "url": "https://ubuntu.com/security/CVE-2026-45852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45869", "url": "https://ubuntu.com/security/CVE-2026-45869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: wm97xx: Fix NULL pointer dereference in power_supply_changed() In `probe()`, `request_irq()` is called before allocating/registering a `power_supply` handle. If an interrupt is fired between the call to `request_irq()` and `power_supply_register()`, the `power_supply` handle will be used uninitialized in `power_supply_changed()` in `wm97xx_bat_update()` (triggered from the interrupt handler). This will lead to a `NULL` pointer dereference since Fix this racy `NULL` pointer dereference by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Since the IRQ is the last thing requests in the `probe()` now, remove the error path for freeing it. Instead add one for unregistering the `power_supply` handle when IRQ request fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45916", "url": "https://ubuntu.com/security/CVE-2026-45916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sbs-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Keep the old behavior of just printing a warning in case of any failures during the IRQ request and finishing the probe successfully.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46270", "url": "https://ubuntu.com/security/CVE-2026-46270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: rt9455: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45936", "url": "https://ubuntu.com/security/CVE-2026-45936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: goldfish: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45885", "url": "https://ubuntu.com/security/CVE-2026-45885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cpcap-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45879", "url": "https://ubuntu.com/security/CVE-2026-45879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq25980: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45902", "url": "https://ubuntu.com/security/CVE-2026-45902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45867", "url": "https://ubuntu.com/security/CVE-2026-45867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: act8945a: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45946", "url": "https://ubuntu.com/security/CVE-2026-45946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Commit 1c1f13a006ed (\"power: supply: ab8500: Move to componentized binding\") introduced this issue during a refactorization. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45866", "url": "https://ubuntu.com/security/CVE-2026-45866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: caif: fix use-after-free in caif_serial ldisc_close() There is a use-after-free bug in caif_serial where handle_tx() may access ser->tty after the tty has been freed. The race condition occurs between ldisc_close() and packet transmission: CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldisc_close() tty_kref_put(ser->tty) [tty may be freed here] <-- race window --> caif_xmit() handle_tx() tty = ser->tty // dangling ptr tty->ops->write() // UAF! schedule_work() ser_release() unregister_netdevice() The root cause is that tty_kref_put() is called in ldisc_close() while the network device is still active and can receive packets. Since ser and tty have a 1:1 binding relationship with consistent lifecycles (ser is allocated in ldisc_open and freed in ser_release via unregister_netdevice, and each ser binds exactly one tty), we can safely defer the tty reference release to ser_release() where the network device is unregistered. Fix this by moving tty_kref_put() from ldisc_close() to ser_release(), after unregister_netdevice(). This ensures the tty reference is held as long as the network device exists, preventing the UAF. Note: We save ser->tty before unregister_netdevice() because ser is embedded in netdev's private data and will be freed along with netdev (needs_free_netdev = true). How to reproduce: Add mdelay(500) at the beginning of ldisc_close() to widen the race window, then run the reproducer program [1]. Note: There is a separate deadloop issue in handle_tx() when using PORT_UNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper serial backend). This deadloop exists even without this patch, and is likely caused by inconsistency between uart_write_room() and uart_write() in serial core. It has been addressed in a separate patch [2]. KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in handle_tx+0x5d1/0x620 Read of size 1 at addr ffff8881131e1490 by task caif_uaf_trigge/9929 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xd0/0x630 kasan_report+0xe4/0x120 handle_tx+0x5d1/0x620 dev_hard_start_xmit+0x9d/0x6c0 __dev_queue_xmit+0x6e2/0x4410 packet_xmit+0x243/0x360 packet_sendmsg+0x26cf/0x5500 __sys_sendto+0x4a3/0x520 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0xc9/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f615df2c0d7 Allocated by task 9930: Freed by task 64: Last potentially related work creation: The buggy address belongs to the object at ffff8881131e1000 which belongs to the cache kmalloc-cg-2k of size 2048 The buggy address is located 1168 bytes inside of freed 2048-byte region [ffff8881131e1000, ffff8881131e1800) The buggy address belongs to the physical page: page_owner tracks the page as allocated page last free pid 9778 tgid 9778 stack trace: Memory state around the buggy address: ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-31411", "url": "https://ubuntu.com/security/CVE-2026-31411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: fix crash due to unvalidated vcc pointer in sigd_send() Reproducer available at [1]. The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values. Fix this by introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found. Since struct atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock_hold/sock_put is sufficient to keep the vcc alive while it is being used. Note that there may be a race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety. [1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3", "cve_priority": "medium", "cve_public_date": "2026-04-08 14:16:00 UTC" }, { "cve": "CVE-2026-46259", "url": "https://ubuntu.com/security/CVE-2026-46259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent.", "cve_priority": "high", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45891", "url": "https://ubuntu.com/security/CVE-2026-45891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix double free issue for tx spare buffer In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory. Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory. The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer. Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new `tx_spare` fails. This ensures the error cleanup path only frees genuinely newly allocated buffers.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45873", "url": "https://ubuntu.com/security/CVE-2026-45873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets Userspace provides an optimized representation in case intervals are adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous set checks on start elements for this reason. However, it is possible to add intervals that overlap to this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end \tA B start end A C Restore the check on overlapping start elements to report an overlap.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46267", "url": "https://ubuntu.com/security/CVE-2026-46267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: hci: shdlc: Stop timers and work before freeing context llc_shdlc_deinit() purges SHDLC skb queues and frees the llc_shdlc structure while its timers and state machine work may still be active. Timer callbacks can schedule sm_work, and sm_work accesses SHDLC state and the skb queues. If teardown happens in parallel with a queued/running work item, it can lead to UAF and other shutdown races. Stop all SHDLC timers and cancel sm_work synchronously before purging the queues and freeing the context. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-46249", "url": "https://ubuntu.com/security/CVE-2026-46249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix PF driver crash with kexec kernel booting During a kexec reboot the hardware is not power-cycled, so AF state from the old kernel can persist into the new kernel. When AF and PF drivers are built as modules, the PF driver may probe before AF reinitializes the hardware. The PF driver treats the RVUM block revision as an indication that AF initialization is complete. If this value is left uncleared at shutdown, PF may incorrectly assume AF is ready and access stale hardware state, leading to a crash. Clear the RVUM block revision during AF shutdown to avoid PF mis-detecting AF readiness after kexec.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45915", "url": "https://ubuntu.com/security/CVE-2026-45915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: avoid parent link count underflow in rmdir Corrupted FAT images can leave a directory inode with an incorrect i_nlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls drop_nlink(dir) and can drive i_nlink to 0, triggering the WARN_ON in drop_nlink(). Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45983", "url": "https://ubuntu.com/security/CVE-2026-45983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: never defer requests during idmap lookup During v4 request compound arg decoding, some ops (e.g. SETATTR) can trigger idmap lookup upcalls. When those upcall responses get delayed beyond the allowed time limit, cache_check() will mark the request for deferral and cause it to be dropped. This prevents nfs4svc_encode_compoundres from being executed, and thus the session slot flag NFSD4_SLOT_INUSE never gets cleared. Subsequent client requests will fail with NFSERR_JUKEBOX, given that the slot will be marked as in-use, making the SEQUENCE op fail. Fix this by making sure that the RQ_USEDEFERRAL flag is always clear during nfs4svc_decode_compoundargs(), since no v4 request should ever be deferred.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45862", "url": "https://ubuntu.com/security/CVE-2026-45862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush cache for PASID table before using it When writing the address of a freshly allocated zero-initialized PASID table to a PASID directory entry, do that after the CPU cache flush for this PASID table, not before it, to avoid the time window when this PASID table may be already used by non-coherent IOMMU hardware while its contents in RAM is still some random old data, not zero-initialized.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45860", "url": "https://ubuntu.com/security/CVE-2026-45860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: increase the connection clean up limit to 64 After the optimization to only perform one GC per jiffy, a new problem was introduced. If more than 8 new connections are tracked per jiffy the list won't be cleaned up fast enough possibly reaching the limit wrongly. In order to prevent this issue, only skip the GC if it was already triggered during the same jiffy and the increment is lower than the clean up limit. In addition, increase the clean up limit to 64 connections to avoid triggering GC too often and do more effective GCs. This has been tested using a HTTP server and several performance tools while having nft_connlimit/xt_connlimit or OVS limit configured. Output of slowhttptest + OVS limit at 52000 connections: slow HTTP test status on 340th second: initializing: 0 pending: 432 connected: 51998 error: 0 closed: 0 service available: YES", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45969", "url": "https://ubuntu.com/security/CVE-2026-45969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: playstation: Add missing check for input_ff_create_memless The ps_gamepad_create() function calls input_ff_create_memless() without verifying its return value, which can lead to incorrect behavior or potential crashes when FF effects are triggered. Add a check for the return value of input_ff_create_memless().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-71304", "url": "https://ubuntu.com/security/CVE-2025-71304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: /smack/doi: accept previously used values Writing to /smack/doi a value that has ever been written there in the past disables networking for non-ambient labels. E.g. # cat /smack/doi 3 # netlabelctl -p cipso list Configured CIPSO mappings (1) DOI value : 3 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (3) domain: \"_\" (IPv4) protocol: UNLABELED domain: DEFAULT (IPv4) protocol: CIPSO, DOI = 3 domain: DEFAULT (IPv6) protocol: UNLABELED # cat /smack/ambient _ # cat /proc/$$/attr/smack/current _ # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.964 ms # echo foo >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.956 ms unknown option 86 # echo 4 >/smack/doi # echo 3 >/smack/doi !> [ 214.050395] smk_cipso_doi:691 cipso add rc = -17 # echo 3 >/smack/doi !> [ 249.402261] smk_cipso_doi:678 remove rc = -2 !> [ 249.402261] smk_cipso_doi:691 cipso add rc = -17 # ping -c1 10.1.95.12 !!> ping: 10.1.95.12: Address family for hostname not supported # echo _ >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.617 ms This happens because Smack keeps decommissioned DOIs, fails to re-add them, and consequently refuses to add the “default” domain map: # netlabelctl -p cipso list Configured CIPSO mappings (2) DOI value : 3 mapping type : PASS_THROUGH DOI value : 4 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (2) domain: \"_\" (IPv4) protocol: UNLABELED !> (no ipv4 map for default domain here) domain: DEFAULT (IPv6) protocol: UNLABELED Fix by clearing decommissioned DOI definitions and serializing concurrent DOI updates with a new lock. Also: - allow /smack/doi to live unconfigured, since adding a map (netlbl_cfg_cipsov4_map_add) may fail. CIPSO_V4_DOI_UNKNOWN(0) indicates the unconfigured DOI - add new DOI before removing the old default map, so the old map remains if the add fails (2008-02-04, Casey Schaufler)", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45904", "url": "https://ubuntu.com/security/CVE-2026-45904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling The recent commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug safe\") restructured the EEH driver to improve synchronization with the PCI hotplug layer. However, it inadvertently moved pci_lock_rescan_remove() outside its intended scope in eeh_handle_normal_event(), leading to broken PCI error reporting and improper EEH event triggering. Specifically, eeh_handle_normal_event() acquired pci_lock_rescan_remove() before calling eeh_pe_bus_get(), but eeh_pe_bus_get() itself attempts to acquire the same lock internally, causing nested locking and disrupting normal EEH event handling paths. This patch adds a boolean parameter do_lock to _eeh_pe_bus_get(), with two public wrappers: eeh_pe_bus_get() with locking enabled. eeh_pe_bus_get_nolock() that skips locking. Callers that already hold pci_lock_rescan_remove() now use eeh_pe_bus_get_nolock() to avoid recursive lock acquisition. Additionally, pci_lock_rescan_remove() calls are restored to the correct position—after eeh_pe_bus_get() and immediately before iterating affected PEs and devices. This ensures EEH-triggered PCI removes occur under proper bus rescan locking without recursive lock contention. The eeh_pe_loc_get() function has been split into two functions: eeh_pe_loc_get(struct eeh_pe *pe) which retrieves the loc for given PE. eeh_pe_loc_get_bus(struct pci_bus *bus) which retrieves the location code for given bus. This resolves lockdep warnings such as: [ 84.964298] [ T928] ============================================ [ 84.964304] [ T928] WARNING: possible recursive locking detected [ 84.964311] [ T928] 6.18.0-rc3 #51 Not tainted [ 84.964315] [ T928] -------------------------------------------- [ 84.964320] [ T928] eehd/928 is trying to acquire lock: [ 84.964324] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964342] [ T928] but task is already holding lock: [ 84.964347] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964357] [ T928] other info that might help us debug this: [ 84.964363] [ T928] Possible unsafe locking scenario: [ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928] lock(pci_rescan_remove_lock); [ 84.964378] [ T928] lock(pci_rescan_remove_lock); [ 84.964383] [ T928] *** DEADLOCK *** [ 84.964388] [ T928] May be due to missing lock nesting notation [ 84.964393] [ T928] 1 lock held by eehd/928: [ 84.964397] [ T928] #0: c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964408] [ T928] stack backtrace: [ 84.964414] [ T928] CPU: 2 UID: 0 PID: 928 Comm: eehd Not tainted 6.18.0-rc3 #51 VOLUNTARY [ 84.964417] [ T928] Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_022) hv:phyp pSeries [ 84.964419] [ T928] Call Trace: [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130 (unreliable) [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [ 84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c00000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46253", "url": "https://ubuntu.com/security/CVE-2026-46253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore/ram: fix buffer overflow in persistent_ram_save_old() persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz->old_log when it is NULL, but it unconditionally updates prz->old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1) 9. ramoops_get_next_prz() → persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45919", "url": "https://ubuntu.com/security/CVE-2026-45919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/rt: Skip currently executing CPU in rto_next_cpu() CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts. The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45871", "url": "https://ubuntu.com/security/CVE-2026-45871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Fix missing cleanup on get_burstcount() error get_burstcount() can return -EBUSY on timeout. When this happens, st33zp24_send() returns directly without releasing the locality acquired earlier. Use goto out_err to ensure proper cleanup when get_burstcount() fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45941", "url": "https://ubuntu.com/security/CVE-2026-45941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_infineon: Fix locality leak on get_burstcount() failure get_burstcount() can return -EBUSY on timeout. When this happens, the function returns directly without releasing the locality that was acquired at the beginning of tpm_tis_i2c_send(). Use goto out_err to ensure proper cleanup when get_burstcount() fails.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45984", "url": "https://ubuntu.com/security/CVE-2026-45984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix use-after-free in iomap inline data write path The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45960", "url": "https://ubuntu.com/security/CVE-2026-45960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: return error when node already exists in hfs_bnode_create When hfs_bnode_create() finds that a node is already hashed (which should not happen in normal operation), it currently returns the existing node without incrementing its reference count. This causes a reference count inconsistency that leads to a kernel panic when the node is later freed in hfs_bnode_put(): kernel BUG at fs/hfsplus/bnode.c:676! BUG_ON(!atomic_read(&node->refcnt)) This scenario can occur when hfs_bmap_alloc() attempts to allocate a node that is already in use (e.g., when node 0's bitmap bit is incorrectly unset), or due to filesystem corruption. Returning an existing node from a create path is not normal operation. Fix this by returning ERR_PTR(-EEXIST) instead of the node when it's already hashed. This properly signals the error condition to callers, which already check for IS_ERR() return values.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23243", "url": "https://ubuntu.com/security/CVE-2026-23243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umad: Reject negative data_len in ib_umad_write ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-23242", "url": "https://ubuntu.com/security/CVE-2026-23242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix potential NULL pointer dereference in header processing If siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(), qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data() dereferences qp->rx_fpdu->more_ddp_segs without checking, which may lead to a NULL pointer deref. Only check more_ddp_segs when rx_fpdu is present. KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-23235", "url": "https://ubuntu.com/security/CVE-2026-23235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix out-of-bounds access in sysfs attribute read/write Some f2fs sysfs attributes suffer from out-of-bounds memory access and incorrect handling of integer values whose size is not 4 bytes. For example: vm:~# echo 65537 > /sys/fs/f2fs/vde/carve_out vm:~# cat /sys/fs/f2fs/vde/carve_out 65537 vm:~# echo 4294967297 > /sys/fs/f2fs/vde/atgc_age_threshold vm:~# cat /sys/fs/f2fs/vde/atgc_age_threshold 1 carve_out maps to {struct f2fs_sb_info}->carve_out, which is a 8-bit integer. However, the sysfs interface allows setting it to a value larger than 255, resulting in an out-of-range update. atgc_age_threshold maps to {struct atgc_management}->age_threshold, which is a 64-bit integer, but its sysfs interface cannot correctly set values larger than UINT_MAX. The root causes are: 1. __sbi_store() treats all default values as unsigned int, which prevents updating integers larger than 4 bytes and causes out-of-bounds writes for integers smaller than 4 bytes. 2. f2fs_sbi_show() also assumes all default values are unsigned int, leading to out-of-bounds reads and incorrect access to integers larger than 4 bytes. This patch introduces {struct f2fs_attr}->size to record the actual size of the integer associated with each sysfs attribute. With this information, sysfs read and write operations can correctly access and update values according to their real data size, avoiding memory corruption and truncation.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23234", "url": "https://ubuntu.com/security/CVE-2026-23234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid UAF in f2fs_write_end_io() As syzbot reported an use-after-free issue in f2fs_write_end_io(). It is caused by below race condition: loop device\t\t\t\tumount - worker_thread - loop_process_work - do_req_filebacked - lo_rw_aio - lo_rw_aio_complete - blk_mq_end_request - blk_update_request - f2fs_write_end_io - dec_page_count - folio_end_writeback \t\t\t\t\t- kill_f2fs_super \t\t\t\t\t - kill_block_super \t\t\t\t\t - f2fs_put_super \t\t\t\t\t : free(sbi) : get_pages(, F2FS_WB_CP_DATA) accessed sbi which is freed In kill_f2fs_super(), we will drop all page caches of f2fs inodes before call free(sbi), it guarantee that all folios should end its writeback, so it should be safe to access sbi before last folio_end_writeback(). Let's relocate ckpt thread wakeup flow before folio_end_writeback() to resolve this issue.", "cve_priority": "low", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23236", "url": "https://ubuntu.com/security/CVE-2026-23236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: smscufx: properly copy ioctl memory to kernelspace The UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data from userspace to kernelspace, and instead directly references the memory, which can cause problems if invalid data is passed from userspace. Fix this all up by correctly copying the memory before accessing it within the kernel.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23266", "url": "https://ubuntu.com/security/CVE-2026-23266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: rivafb: fix divide error in nv3_arb() A userspace program can trigger the RIVA NV3 arbitration code by calling the FBIOPUT_VSCREENINFO ioctl on /dev/fb*. When doing so, the driver recomputes FIFO arbitration parameters in nv3_arb(), using state->mclk_khz (derived from the PRAMDAC MCLK PLL) as a divisor without validating it first. In a normal setup, state->mclk_khz is provided by the real hardware and is non-zero. However, an attacker can construct a malicious or misconfigured device (e.g. a crafted/emulated PCI device) that exposes a bogus PLL configuration, causing state->mclk_khz to become zero. Once nv3_get_param() calls nv3_arb(), the division by state->mclk_khz in the gns calculation causes a divide error and crashes the kernel. Fix this by checking whether state->mclk_khz is zero and bailing out before doing the division. The following log reveals it: rivafb: setting virtual Y resolution to 2184 divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 2187 Comm: syz-executor.0 Not tainted 5.18.0-rc1+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:nv3_arb drivers/video/fbdev/riva/riva_hw.c:439 [inline] RIP: 0010:nv3_get_param+0x3ab/0x13b0 drivers/video/fbdev/riva/riva_hw.c:546 Call Trace: nv3CalcArbitration.constprop.0+0x255/0x460 drivers/video/fbdev/riva/riva_hw.c:603 nv3UpdateArbitrationSettings drivers/video/fbdev/riva/riva_hw.c:637 [inline] CalcStateExt+0x447/0x1b90 drivers/video/fbdev/riva/riva_hw.c:1246 riva_load_video_mode+0x8a9/0xea0 drivers/video/fbdev/riva/fbdev.c:779 rivafb_set_par+0xc0/0x5f0 drivers/video/fbdev/riva/fbdev.c:1196 fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1033 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1109 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1188 __x64_sys_ioctl+0x122/0x190 fs/ioctl.c:856", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2025-71233", "url": "https://ubuntu.com/security/CVE-2025-71233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Avoid creating sub-groups asynchronously The asynchronous creation of sub-groups by a delayed work could lead to a NULL pointer dereference when the driver directory is removed before the work completes. The crash can be easily reproduced with the following commands: # cd /sys/kernel/config/pci_ep/functions/pci_epf_test # for i in {1..20}; do mkdir test && rmdir test; done BUG: kernel NULL pointer dereference, address: 0000000000000088 ... Call Trace: configfs_register_group+0x3d/0x190 pci_epf_cfs_work+0x41/0x110 process_one_work+0x18f/0x350 worker_thread+0x25a/0x3a0 Fix this issue by using configfs_add_default_group() API which does not have the deadlock problem as configfs_register_group() and does not require the delayed work handler. [mani: slightly reworded the description and added stable list]", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71232", "url": "https://ubuntu.com/security/CVE-2025-71232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Free sp in error path to fix system crash System crash seen during load/unload test in a loop, [61110.449331] qla2xxx [0000:27:00.0]-0042:0: Disabled MSI-X. [61110.467494] ============================================================================= [61110.467498] BUG qla2xxx_srbs (Tainted: G OE -------- --- ): Objects remaining in qla2xxx_srbs on __kmem_cache_shutdown() [61110.467501] ----------------------------------------------------------------------------- [61110.467502] Slab 0x000000000ffc8162 objects=51 used=1 fp=0x00000000e25d3d85 flags=0x57ffffc0010200(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [61110.467509] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1 [61110.467513] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023 [61110.467515] Call Trace: [61110.467516] [61110.467519] dump_stack_lvl+0x34/0x48 [61110.467526] slab_err.cold+0x53/0x67 [61110.467534] __kmem_cache_shutdown+0x16e/0x320 [61110.467540] kmem_cache_destroy+0x51/0x160 [61110.467544] qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467607] ? __do_sys_delete_module.constprop.0+0x178/0x280 [61110.467613] ? syscall_trace_enter.constprop.0+0x145/0x1d0 [61110.467616] ? do_syscall_64+0x5c/0x90 [61110.467619] ? exc_page_fault+0x62/0x150 [61110.467622] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [61110.467626] [61110.467627] Disabling lock debugging due to kernel taint [61110.467635] Object 0x0000000026f7e6e6 @offset=16000 [61110.467639] ------------[ cut here ]------------ [61110.467639] kmem_cache_destroy qla2xxx_srbs: Slab cache still has objects when called from qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467659] WARNING: CPU: 53 PID: 455206 at mm/slab_common.c:520 kmem_cache_destroy+0x14d/0x160 [61110.467718] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G B OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1 [61110.467720] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023 [61110.467721] RIP: 0010:kmem_cache_destroy+0x14d/0x160 [61110.467724] Code: 99 7d 07 00 48 89 ef e8 e1 6a 07 00 eb b3 48 8b 55 60 48 8b 4c 24 20 48 c7 c6 70 fc 66 90 48 c7 c7 f8 ef a1 90 e8 e1 ed 7c 00 <0f> 0b eb 93 c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 [61110.467725] RSP: 0018:ffffa304e489fe80 EFLAGS: 00010282 [61110.467727] RAX: 0000000000000000 RBX: ffffffffc0d9a860 RCX: 0000000000000027 [61110.467729] RDX: ffff8fd5ff9598a8 RSI: 0000000000000001 RDI: ffff8fd5ff9598a0 [61110.467730] RBP: ffff8fb6aaf78700 R08: 0000000000000000 R09: 0000000100d863b7 [61110.467731] R10: ffffa304e489fd20 R11: ffffffff913bef48 R12: 0000000040002000 [61110.467731] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [61110.467733] FS: 00007f64c89fb740(0000) GS:ffff8fd5ff940000(0000) knlGS:0000000000000000 [61110.467734] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [61110.467735] CR2: 00007f0f02bfe000 CR3: 00000020ad6dc005 CR4: 0000000000770ee0 [61110.467736] PKRU: 55555554 [61110.467737] Call Trace: [61110.467738] [61110.467739] qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467755] ? __do_sys_delete_module.constprop.0+0x178/0x280 Free sp in the error path to fix the crash.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71238", "url": "https://ubuntu.com/security/CVE-2025-71238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix bsg_done() causing double free Kernel panic observed on system, [5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000 [5353358.825194] #PF: supervisor write access in kernel mode [5353358.825195] #PF: error_code(0x0002) - not-present page [5353358.825196] PGD 100006067 P4D 0 [5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI [5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el9_5.x86_64 #1 [5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025 [5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10 [5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246 [5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000 [5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000 [5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000 [5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090 [5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000 [5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000 [5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0 [5353358.825221] PKRU: 55555554 [5353358.825222] Call Trace: [5353358.825223] [5353358.825224] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825229] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825232] ? sg_copy_buffer+0xc8/0x110 [5353358.825236] ? __die_body.cold+0x8/0xd [5353358.825238] ? page_fault_oops+0x134/0x170 [5353358.825242] ? kernelmode_fixup_or_oops+0x84/0x110 [5353358.825244] ? exc_page_fault+0xa8/0x150 [5353358.825247] ? asm_exc_page_fault+0x22/0x30 [5353358.825252] ? memcpy_erms+0x6/0x10 [5353358.825253] sg_copy_buffer+0xc8/0x110 [5353358.825259] qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx] [5353358.825317] qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx] Most routines in qla_bsg.c call bsg_done() only for success cases. However a few invoke it for failure case as well leading to a double free. Validate before calling bsg_done().", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23221", "url": "https://ubuntu.com/security/CVE-2026-23221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: fix use-after-free in driver_override_show() The driver_override_show() function reads the driver_override string without holding the device_lock. However, driver_override_store() uses driver_set_override(), which modifies and frees the string while holding the device_lock. This can result in a concurrent use-after-free if the string is freed by the store function while being read by the show function. Fix this by holding the device_lock around the read operation.", "cve_priority": "low", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23228", "url": "https://ubuntu.com/security/CVE-2026-23228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection() On kthread_run() failure in ksmbd_tcp_new_connection(), the transport is freed via free_transport(), which does not decrement active_num_conn, leaking this counter. Replace free_transport() with ksmbd_tcp_disconnect().", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23169", "url": "https://ubuntu.com/security/CVE-2026-23169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race in mptcp_pm_nl_flush_addrs_doit() syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id() and/or mptcp_pm_nl_is_backup() Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit() which is not RCU ready. list_splice_init_rcu() can not be called here while holding pernet->lock spinlock. Many thanks to Eulgyu Kim for providing a repro and testing our patches.", "cve_priority": "high", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-37786", "url": "https://ubuntu.com/security/CVE-2025-37786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: free routing table on probe failure If complete = true in dsa_tree_setup(), it means that we are the last switch of the tree which is successfully probing, and we should be setting up all switches from our probe path. After \"complete\" becomes true, dsa_tree_setup_cpu_ports() or any subsequent function may fail. If that happens, the entire tree setup is in limbo: the first N-1 switches have successfully finished probing (doing nothing but having allocated persistent memory in the tree's dst->ports, and maybe dst->rtable), and switch N failed to probe, ending the tree setup process before anything is tangible from the user's PoV. If switch N fails to probe, its memory (ports) will be freed and removed from dst->ports. However, the dst->rtable elements pointing to its ports, as created by dsa_link_touch(), will remain there, and will lead to use-after-free if dereferenced. If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirely possible because that is where ds->ops->setup() is, we get a kasan report like this: ================================================================== BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568 Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42 Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 The simplest way to fix the bug is to delete the routing table in its entirety. dsa_tree_setup_routing_table() has no problem in regenerating it even if we deleted links between ports other than those of switch N, because dsa_link_touch() first checks whether the port pair already exists in dst->rtable, allocating if not. The deletion of the routing table in its entirety already exists in dsa_tree_teardown(), so refactor that into a function that can also be called from the tree setup error path. In my analysis of the commit to blame, it is the one which added dsa_link elements to dst->rtable. Prior to that, each switch had its own ds->rtable which is freed when the switch fails to probe. But the tree is potentially persistent memory.", "cve_priority": "low", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2026-23237", "url": "https://ubuntu.com/security/CVE-2026-23237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: classmate-laptop: Add missing NULL pointer checks In a few places in the Classmate laptop driver, code using the accel object may run before that object's address is stored in the driver data of the input device using it. For example, cmpc_accel_sensitivity_store_v4() is the \"show\" method of cmpc_accel_sensitivity_attr_v4 which is added in cmpc_accel_add_v4(), before calling dev_set_drvdata() for inputdev->dev. If the sysfs attribute is accessed prematurely, the dev_get_drvdata(&inputdev->dev) call in in cmpc_accel_sensitivity_store_v4() returns NULL which leads to a NULL pointer dereference going forward. Moreover, sysfs attributes using the input device are added before initializing that device by cmpc_add_acpi_notify_device() and if one of them is accessed before running that function, a NULL pointer dereference will occur. For example, cmpc_accel_sensitivity_attr_v4 is added before calling cmpc_add_acpi_notify_device() and if it is read prematurely, the dev_get_drvdata(&acpi->dev) call in cmpc_accel_sensitivity_show_v4() returns NULL which leads to a NULL pointer dereference going forward. Fix this by adding NULL pointer checks in all of the relevant places.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23238", "url": "https://ubuntu.com/security/CVE-2026-23238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: romfs: check sb_set_blocksize() return value romfs_fill_super() ignores the return value of sb_set_blocksize(), which can fail if the requested block size is incompatible with the block device's configuration. This can be triggered by setting a loop device's block size larger than PAGE_SIZE using ioctl(LOOP_SET_BLOCK_SIZE, 32768), then mounting a romfs filesystem on that device. When sb_set_blocksize(sb, ROMBSIZE) is called with ROMBSIZE=4096 but the device has logical_block_size=32768, bdev_validate_blocksize() fails because the requested size is smaller than the device's logical block size. sb_set_blocksize() returns 0 (failure), but romfs ignores this and continues mounting. The superblock's block size remains at the device's logical block size (32768). Later, when sb_bread() attempts I/O with this oversized block size, it triggers a kernel BUG in folio_set_bh(): kernel BUG at fs/buffer.c:1582! BUG_ON(size > PAGE_SIZE); Fix by checking the return value of sb_set_blocksize() and failing the mount with -EINVAL if it returns 0.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-31687", "url": "https://ubuntu.com/security/CVE-2026-31687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: omap: do not register driver in probe() Commit 11a78b794496 (\"ARM: OMAP: MPUIO wake updates\") registers the omap_mpuio_driver from omap_mpuio_init(), which is called from omap_gpio_probe(). However, it neither makes sense to register drivers from probe() callbacks of other drivers, nor does the driver core allow registering drivers with a device lock already being held. The latter was revealed by commit dc23806a7c47 (\"driver core: enforce device_lock for driver_match_device()\") leading to a potential deadlock condition described in [1]. Additionally, the omap_mpuio_driver is never unregistered from the driver core, even if the module is unloaded. Hence, register the omap_mpuio_driver from the module initcall and unregister it in module_exit().", "cve_priority": "medium", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2025-71235", "url": "https://ubuntu.com/security/CVE-2025-71235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Delay module unload while fabric scan in progress System crash seen during load/unload test in a loop. [105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086 [105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0 [105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000 [105954.384923] FS: 0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000 [105954.384925] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0 [105954.384928] PKRU: 55555554 [105954.384929] Call Trace: [105954.384931] [105954.384934] qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx] [105954.384962] ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx] [105954.384980] ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx] [105954.384999] ? __wake_up_common+0x80/0x190 [105954.385004] ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx] [105954.385023] ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx] [105954.385040] ? __handle_irq_event_percpu+0x3d/0x190 [105954.385044] ? handle_irq_event+0x58/0xb0 [105954.385046] ? handle_edge_irq+0x93/0x240 [105954.385050] ? __common_interrupt+0x41/0xa0 [105954.385055] ? common_interrupt+0x3e/0xa0 [105954.385060] ? asm_common_interrupt+0x22/0x40 The root cause of this was that there was a free (dma_free_attrs) in the interrupt context. There was a device discovery/fabric scan in progress. A module unload was issued which set the UNLOADING flag. As part of the discovery, after receiving an interrupt a work queue was scheduled (which involved a work to be queued). Since the UNLOADING flag is set, the work item was not allocated and the mapped memory had to be freed. The free occurred in interrupt context leading to system crash. Delay the driver unload until the fabric scan is complete to avoid the crash.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71236", "url": "https://ubuntu.com/security/CVE-2025-71236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Validate sp before freeing associated memory System crash with the following signature [154563.214890] nvme nvme2: NVME-FC{1}: controller connect complete [154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Set ZIO exchange threshold to 3. [154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: SET ZIO Activity exchange threshold to 5. [154565.539974] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 0080 0000. [154565.545744] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 00a0 0000. [154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate). [154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate). [154565.553079] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [154565.553080] #PF: supervisor read access in kernel mode [154565.553082] #PF: error_code(0x0000) - not-present page [154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0 [154565.553089] Oops: 0000 1 PREEMPT SMP PTI [154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: loaded Tainted: G OE ------- --- 5.14.0-503.11.1.el9_5.x86_64 #1 [154565.553096] Hardware name: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 09/30/2024 [154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553141] Code: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 <4c> 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b [154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286 [154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002 [154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47 [154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a [154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0 [154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000 [154565.553152] FS: 0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000 [154565.553154] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0 [154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [154565.553159] PKRU: 55555554 [154565.553160] Call Trace: [154565.553162] [154565.553165] ? show_trace_log_lvl+0x1c4/0x2df [154565.553172] ? show_trace_log_lvl+0x1c4/0x2df [154565.553177] ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553215] ? __die_body.cold+0x8/0xd [154565.553218] ? page_fault_oops+0x134/0x170 [154565.553223] ? snprintf+0x49/0x70 [154565.553229] ? exc_page_fault+0x62/0x150 [154565.553238] ? asm_exc_page_fault+0x22/0x30 Check for sp being non NULL before freeing any associated memory", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71237", "url": "https://ubuntu.com/security/CVE-2025-71237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: Fix potential block overflow that cause system hang When a user executes the FITRIM command, an underflow can occur when calculating nblocks if end_block is too small. Since nblocks is of type sector_t, which is u64, a negative nblocks value will become a very large positive integer. This ultimately leads to the block layer function __blkdev_issue_discard() taking an excessively long time to process the bio chain, and the ns_segctor_sem lock remains held for a long period. This prevents other tasks from acquiring the ns_segctor_sem lock, resulting in the hang reported by syzbot in [1]. If the ending block is too small, typically if it is smaller than 4KiB range, depending on the usage of the segment 0, it may be possible to attempt a discard request beyond the device size causing the hang. Exiting successfully and assign the discarded size (0 in this case) to range->len. Although the start and len values in the user input range are too small, a conservative strategy is adopted here to safely ignore them, which is equivalent to a no-op; it will not perform any trimming and will not throw an error. [1] task:segctord state:D stack:28968 pid:6093 tgid:6093 ppid:2 task_flags:0x200040 flags:0x00080000 Call Trace: rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272 nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline] nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684 [ryusuke: corrected part of the commit message about the consequences]", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23229", "url": "https://ubuntu.com/security/CVE-2026-23229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add spinlock protection with virtqueue notification When VM boots with one virtio-crypto PCI device and builtin backend, run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head! It seems that the data virtqueue need protection when it is handled for virtio done notification. If the spinlock protection is added in virtcrypto_done_task(), openssl benchmark with multiple processes works well.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23222", "url": "https://ubuntu.com/security/CVE-2026-23222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly The existing allocation of scatterlists in omap_crypto_copy_sg_lists() was allocating an array of scatterlist pointers, not scatterlist objects, resulting in a 4x too small allocation. Use sizeof(*new_sg) to get the correct object size.", "cve_priority": "high", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23392", "url": "https://ubuntu.com/security/CVE-2026-23392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-45988", "url": "https://ubuntu.com/security/CVE-2026-45988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix re-decryption of RESPONSE packets If a RESPONSE packet gets a temporary failure during processing, it may end up in a partially decrypted state - and then get requeued for a retry. Fix this by just discarding the packet; we will send another CHALLENGE packet and thereby elicit a further response. Similarly, discard an incoming CHALLENGE packet if we get an error whilst generating a RESPONSE; the server will send another CHALLENGE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46195", "url": "https://ubuntu.com/security/CVE-2026-46195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46135", "url": "https://ubuntu.com/security/CVE-2026-46135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.", "cve_priority": "critical", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31402", "url": "https://ubuntu.com/security/CVE-2026-31402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.", "cve_priority": "critical", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43071", "url": "https://ubuntu.com/security/CVE-2026-43071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dcache: Limit the minimal number of bucket to two There is an OOB read problem on dentry_hashtable when user sets 'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260 There will be only one bucket in dentry_hashtable when dhash_entries is set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then, following process will access more than one buckets(which memory region is not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB! Fix it by limiting the minimal number of dentry_hashtable bucket to two, so that 'd_hash_shift' won't exceeds the bit width of type u32.", "cve_priority": "low", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-46119", "url": "https://ubuntu.com/security/CVE-2026-46119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix slab-out-of-bounds access in auth message processing If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY contains a positive value in its result field, it is treated as an error code by ceph_handle_auth_reply() and returned to handle_auth_reply(). Thereafter, an attempt is made to send the preallocated message of type CEPH_MSG_AUTH, where the returned value is interpreted as the size of the front segment to send. If the result value in the message is greater than the size of the memory buffer allocated for the front segment, an out-of-bounds access occurs, and the content of the memory region beyond this buffer is sent out. This patch fixes the issue by treating only negative values in the result field as errors. Positive values are therefore treated as success in the same way as a zero value. Additionally, a BUG_ON is added to __send_prepared_auth_request() comparing the len parameter to front_alloc_len to prevent sending the message if it exceeds the bounds of the allocation and to make it easier to catch any logic flaws leading to this.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-43501", "url": "https://ubuntu.com/security/CVE-2026-43501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: \tskb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards.", "cve_priority": "critical", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46043", "url": "https://ubuntu.com/security/CVE-2026-46043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43493", "url": "https://ubuntu.com/security/CVE-2026-43493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications.", "cve_priority": "high", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-31637", "url": "https://ubuntu.com/security/CVE-2026-31637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: reject undecryptable rxkad response tickets rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether crypto_skcipher_decrypt() succeeded. A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes. Check the decrypt result and abort the connection with RXKADBADTICKET when ticket decryption fails.", "cve_priority": "critical", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31657", "url": "https://ubuntu.com/security/CVE-2026-31657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: hold claim backbone gateways by reference batadv_bla_add_claim() can replace claim->backbone_gw and drop the old gateway's last reference while readers still follow the pointer. The netlink claim dump path dereferences claim->backbone_gw->orig and takes claim->backbone_gw->crc_lock without pinning the underlying backbone gateway. batadv_bla_check_claim() still has the same naked pointer access pattern. Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate on a stable gateway reference until the read-side work is complete. This keeps the dump and claim-check paths aligned with the lifetime rules introduced for the other BLA claim readers.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31685", "url": "https://ubuntu.com/security/CVE-2026-31685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_eui64: reject invalid MAC header for all packets `eui64_mt6()` derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address. The existing guard only rejects an invalid MAC header when `par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()` can still reach `eth_hdr(skb)` even when the MAC header is not valid. Fix this by removing the `par->fragoff != 0` condition so that packets with an invalid MAC header are rejected before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43117", "url": "https://ubuntu.com/security/CVE-2026-43117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() If overlay is used on top of btrfs, dentry->d_sb translates to overlay's super block and fsid assignment will lead to a crash. Use file_inode(file)->i_sb to always get btrfs_sb.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43114", "url": "https://ubuntu.com/security/CVE-2026-43114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry New test case fails unexpectedly when avx2 matching functions are used. The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo. This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f - This is expected to work, because its the same set after all and it was already loaded once. But with avx2, this fails: nft reports a clashing element. The reported clash is of following form: We successfully re-inserted a . b c . d Then we try to insert a . d avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next. Due to incorrect masking, the skip-step finds the next matching element *only considering the first field*, i.e. we return the already reinserted \"a . b\", even though the last field is different and the entry should not have been matched. No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback. Bisection points to 7711f4bb4b36 (\"netfilter: nft_set_pipapo: fix range overlap detection\") but that fix merely uncovers this bug. Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate. The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31478", "url": "https://ubuntu.com/security/CVE-2026-31478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len() After this commit (e2b76ab8b5c9 \"ksmbd: add support for read compound\"), response buffer management was changed to use dynamic iov array. In the new design, smb2_calc_max_out_buf_len() expects the second argument (hdr2_len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31668", "url": "https://ubuntu.com/security/CVE-2026-31668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: separate dst_cache for input and output paths in seg6 lwtunnel The seg6 lwtunnel uses a single dst_cache per encap route, shared between seg6_input_core() and seg6_output_core(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup. Fix this by splitting the cache into cache_input and cache_output, so each path maintains its own cached dst independently.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31659", "url": "https://ubuntu.com/security/CVE-2026-31659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject oversized global TT response buffers batadv_tt_prepare_tvlv_global_data() builds the allocation length for a global TT response in 16-bit temporaries. When a remote originator advertises a large enough global TT, the TT payload length plus the VLAN header offset can exceed 65535 and wrap before kmalloc(). The full-table response path still uses the original TT payload length when it fills tt_change, so the wrapped allocation is too small and batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object before the later packet-size check runs. Fix this by rejecting TT responses whose TVLV value length cannot fit in the 16-bit TVLV payload length field.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31649", "url": "https://ubuntu.com/security/CVE-2026-31649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix integer underflow in chain mode The jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb->len (total length including page fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc); When a packet has a small linear portion (nopaged_len <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax * i pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware. Fix this by introducing a buf_len local variable clamped to min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmac_xmit() handles page fragments afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31669", "url": "https://ubuntu.com/security/CVE-2026-31669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix slab-use-after-free in __inet_lookup_established The ehash table lookups are lockless and rely on SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability during RCU read-side critical sections. Both tcp_prot and tcpv6_prot have their slab caches created with this flag via proto_register(). However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into tcpv6_prot_override during inet_init() (fs_initcall, level 5), before inet6_init() (module_init/device_initcall, level 6) has called proto_register(&tcpv6_prot). At that point, tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab remains NULL permanently. This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so when these sockets are freed without SOCK_RCU_FREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcu_read_lock can then access freed memory, triggering a slab-use-after-free in __inet_lookup_established. Fix this by splitting the IPv6-specific initialization out of mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called from mptcp_proto_v6_init() before protocol registration. This ensures tcpv6_prot_override.slab correctly inherits the SLAB_TYPESAFE_BY_RCU slab cache.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43011", "url": "https://ubuntu.com/security/CVE-2026-43011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix potential double free of skb When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain: x25_queue_rx_frame returns 1 | v x25_state3_machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25_process_rx_frame returns queued=0 | v x25_backlog_rcv at line 452 sees queued=0 and calls kfree_skb(skb) again This would free the same skb twice. Looking at x25_backlog_rcv: net/x25/x25_in.c:x25_backlog_rcv() { ... queued = x25_process_rx_frame(sk, skb); ... if (!queued) kfree_skb(skb); }", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43037", "url": "https://ubuntu.com/security/CVE-2026-43037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip4ip6_err() Oskar Kjos reported the following problem. ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr value. __ip_options_echo() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->__data, a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE). To fix this we clear skb2->cb[], as suggested by Oskar Kjos. Also add minimal IPv4 header validation (version == 4, ihl >= 5).", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43038", "url": "https://ubuntu.com/security/CVE-2026-43038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31682", "url": "https://ubuntu.com/security/CVE-2026-31682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: linearize skb before parsing ND options br_nd_send() parses neighbour discovery options from ns->opt[] and assumes that these options are in the linear part of request. Its callers only guarantee that the ICMPv6 header and target address are available, so the option area can still be non-linear. Parsing ns->opt[] in that case can access data past the linear buffer. Linearize request before option parsing and derive ns from the linear network header.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-23450", "url": "https://ubuntu.com/security/CVE-2026-23450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1]. smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release(). This leads to two issues: 1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed. The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race): CPU A (softirq) CPU B (process ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* No lock on listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash! Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed. Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight. - Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock(). - Use rcu_read_lock() to protect reading sk_user_data. - Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely. Note: smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected. Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied. [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23428", "url": "https://ubuntu.com/security/CVE-2026-23428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of share_conf in compound request smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without validating tcon->t_state. ksmbd_tree_conn_lookup() checks t_state == TREE_CONNECTED on the initial lookup path, but the compound reuse path bypasses this check entirely. If a prior command in the compound (SMB2_TREE_DISCONNECT) sets t_state to TREE_DISCONNECTED and frees share_conf via ksmbd_share_config_put(), subsequent commands dereference the freed share_conf through work->tcon->share_conf. KASAN report: [ 4.144653] ================================================================== [ 4.145059] BUG: KASAN: slab-use-after-free in smb2_write+0xc74/0xe70 [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44 [ 4.145772] [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY [ 4.145871] 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 [ 4.145875] Workqueue: ksmbd-io handle_ksmbd_work [ 4.145888] Call Trace: [ 4.145892] [ 4.145894] dump_stack_lvl+0x64/0x80 [ 4.145910] print_report+0xce/0x660 [ 4.145919] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 4.145928] ? smb2_write+0xc74/0xe70 [ 4.145931] kasan_report+0xce/0x100 [ 4.145934] ? smb2_write+0xc74/0xe70 [ 4.145937] smb2_write+0xc74/0xe70 [ 4.145939] ? __pfx_smb2_write+0x10/0x10 [ 4.145942] ? _raw_spin_unlock+0xe/0x30 [ 4.145945] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 4.145948] ? smb2_tree_disconnect+0x31c/0x480 [ 4.145951] handle_ksmbd_work+0x40f/0x1080 [ 4.145953] process_one_work+0x5fa/0xef0 [ 4.145962] ? assign_work+0x122/0x3e0 [ 4.145964] worker_thread+0x54b/0xf70 [ 4.145967] ? __pfx_worker_thread+0x10/0x10 [ 4.145970] kthread+0x346/0x470 [ 4.145976] ? recalc_sigpending+0x19b/0x230 [ 4.145980] ? __pfx_kthread+0x10/0x10 [ 4.145984] ret_from_fork+0x4fb/0x6c0 [ 4.145992] ? __pfx_ret_from_fork+0x10/0x10 [ 4.145995] ? __switch_to+0x36c/0xbe0 [ 4.145999] ? __pfx_kthread+0x10/0x10 [ 4.146003] ret_from_fork_asm+0x1a/0x30 [ 4.146013] [ 4.146014] [ 4.149858] Allocated by task 44: [ 4.149953] kasan_save_stack+0x33/0x60 [ 4.150061] kasan_save_track+0x14/0x30 [ 4.150169] __kasan_kmalloc+0x8f/0xa0 [ 4.150274] ksmbd_share_config_get+0x1dd/0xdd0 [ 4.150401] ksmbd_tree_conn_connect+0x7e/0x600 [ 4.150529] smb2_tree_connect+0x2e6/0x1000 [ 4.150645] handle_ksmbd_work+0x40f/0x1080 [ 4.150761] process_one_work+0x5fa/0xef0 [ 4.150873] worker_thread+0x54b/0xf70 [ 4.150978] kthread+0x346/0x470 [ 4.151071] ret_from_fork+0x4fb/0x6c0 [ 4.151176] ret_from_fork_asm+0x1a/0x30 [ 4.151286] [ 4.151332] Freed by task 44: [ 4.151418] kasan_save_stack+0x33/0x60 [ 4.151526] kasan_save_track+0x14/0x30 [ 4.151634] kasan_save_free_info+0x3b/0x60 [ 4.151751] __kasan_slab_free+0x43/0x70 [ 4.151861] kfree+0x1ca/0x430 [ 4.151952] __ksmbd_tree_conn_disconnect+0xc8/0x190 [ 4.152088] smb2_tree_disconnect+0x1cd/0x480 [ 4.152211] handle_ksmbd_work+0x40f/0x1080 [ 4.152326] process_one_work+0x5fa/0xef0 [ 4.152438] worker_thread+0x54b/0xf70 [ 4.152545] kthread+0x346/0x470 [ 4.152638] ret_from_fork+0x4fb/0x6c0 [ 4.152743] ret_from_fork_asm+0x1a/0x30 [ 4.152853] [ 4.152900] The buggy address belongs to the object at ffff88810430c180 [ 4.152900] which belongs to the cache kmalloc-96 of size 96 [ 4.153226] The buggy address is located 20 bytes inside of [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0) [ 4.153549] [ 4.153596] The buggy address belongs to the physical page: [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c [ 4.154000] flags: 0x ---truncated---", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23455", "url": "https://ubuntu.com/security/CVE-2026-23455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read. Add a check to ensure len is positive after the decrement.", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43186", "url": "https://ubuntu.com/security/CVE-2026-43186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43185", "url": "https://ubuntu.com/security/CVE-2026-43185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix signededness bug in smb_direct_prepare_negotiation() smb_direct_prepare_negotiation() casts an unsigned __u32 value from sp->max_recv_size and req->preferred_send_size to a signed int before computing min_t(int, ...). A maliciously provided preferred_send_size of 0x80000000 will return as smaller than max_recv_size, and then be used to set the maximum allowed alowed receive size for the next message. By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow. This fix replaces min_t(int, ...) with min_t(u32)", "cve_priority": "critical", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43341", "url": "https://ubuntu.com/security/CVE-2026-43341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31607", "url": "https://ubuntu.com/security/CVE-2026-31607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: validate number_of_packets in usbip_pack_ret_submit() When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the *original* number_of_packets from the CMD_SUBMIT. A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region. KASAN confirmed this with kernel 7.0.0-rc5: BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69 The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40) The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 (\"usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input\") and b78d830f0049 (\"usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input\"). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets. This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size. Kelvin Mbogo's series (\"usb: usbip: fix integer overflow in usbip_recv_iso()\", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit. Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43383", "url": "https://ubuntu.com/security/CVE-2026-43383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-md5: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2025-68263", "url": "https://ubuntu.com/security/CVE-2025-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: ipc: fix use-after-free in ipc_msg_send_request ipc_msg_send_request() waits for a generic netlink reply using an ipc_msg_table_entry on the stack. The generic netlink handler (handle_generic_event()/handle_response()) fills entry->response under ipc_msg_table_lock, but ipc_msg_send_request() used to validate and free entry->response without holding the same lock. Under high concurrency this allows a race where handle_response() is copying data into entry->response while ipc_msg_send_request() has just freed it, leading to a slab-use-after-free reported by KASAN in handle_generic_event(): BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd] Write of size 12 at addr ffff888198ee6e20 by task pool/109349 ... Freed by task: kvfree ipc_msg_send_request [ksmbd] ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd] Fix by: - Taking ipc_msg_table_lock in ipc_msg_send_request() while validating entry->response, freeing it when invalid, and removing the entry from ipc_msg_table. - Returning the final entry->response pointer to the caller only after the hash entry is removed under the lock. - Returning NULL in the error path, preserving the original API semantics. This makes all accesses to entry->response consistent with handle_response(), which already updates and fills the response buffer under ipc_msg_table_lock, and closes the race that allowed the UAF.", "cve_priority": "critical", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2026-46243", "url": "https://ubuntu.com/security/CVE-2026-46243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key.", "cve_priority": "medium", "cve_public_date": "2026-06-01 17:17:00 UTC" }, { "cve": "CVE-2026-43414", "url": "https://ubuntu.com/security/CVE-2026-43414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Completely fix fcport double free In qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free(). When an error happens, this function is called by qla2x00_sp_release(), when kref_put() releases the first and the last reference. qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport(). Doing it one more time after kref_put() is a bad idea.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43407", "url": "https://ubuntu.com/security/CVE-2026-43407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply() This patch fixes an out-of-bounds access in ceph_handle_auth_reply() that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In ceph_handle_auth_reply(), the value of the payload_len field of such a message is stored in a variable of type int. A value greater than INT_MAX leads to an integer overflow and is interpreted as a negative value. This leads to decrementing the pointer address by this value and subsequently accessing it because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. This patch fixes the issue by changing the data type of payload_len to u32. Additionally, the data type of result_msg_len is changed to u32, as it is also a variable holding a non-negative length. Also, an additional layer of sanity checks is introduced, ensuring that directly after reading it from the message, payload_len and result_msg_len are not greater than the overall segment length. BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph] Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262 CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ceph-msgr ceph_con_workfn [libceph] Call Trace: dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x620 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x72/0x210 kasan_report+0xe7/0x130 ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] __asan_report_load_n_noabort+0xf/0x20 ceph_handle_auth_reply+0x642/0x7a0 [libceph] mon_dispatch+0x973/0x23d0 [libceph] ? apparmor_socket_recvmsg+0x6b/0xa0 ? __pfx_mon_dispatch+0x10/0x10 [libceph] ? __kasan_check_write+0x14/0x30i ? mutex_unlock+0x7f/0xd0 ? __pfx_mutex_unlock+0x10/0x10 ? __pfx_do_recvmsg+0x10/0x10 [libceph] ceph_con_process_message+0x1f1/0x650 [libceph] process_message+0x1e/0x450 [libceph] ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] ? save_fpregs_to_fpstate+0xb0/0x230 ? raw_spin_rq_unlock+0x17/0xa0 ? finish_task_switch.isra.0+0x13b/0x760 ? __switch_to+0x385/0xda0 ? __kasan_check_write+0x14/0x30 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 ceph_con_workfn+0x248/0x10c0 [libceph] process_one_work+0x629/0xf80 ? __kasan_check_write+0x14/0x30 worker_thread+0x87f/0x1570 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_try_to_wake_up+0x10/0x10 ? kasan_print_address_stack_frame+0x1f7/0x280 ? __pfx_worker_thread+0x10/0x10 kthread+0x396/0x830 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? __pfx_kthread+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? recalc_sigpending+0x180/0x210 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3f7/0x610 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x385/0xda0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 [ idryomov: replace if statements with ceph_decode_need() for payload_len and result_msg_len ]", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43406", "url": "https://ubuntu.com/security/CVE-2026-43406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in process_message_header() If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in process_message_header(). Perform an explicit bounds check before decoding the message header.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43304", "url": "https://ubuntu.com/security/CVE-2026-43304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.", "cve_priority": "critical", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-37924", "url": "https://ubuntu.com/security/CVE-2025-37924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in kerberos authentication Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbd_free_user but before sess->user is set to NULL.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37778", "url": "https://ubuntu.com/security/CVE-2025-37778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix dangling pointer in krb_authenticate krb_authenticate frees sess->user and does not set the pointer to NULL. It calls ksmbd_krb5_authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2_sess_setup, which calls krb_authenticate, will be accessing free'd memory when it later uses sess->user.", "cve_priority": "high", "cve_public_date": "2025-05-01 14:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2157390, 1786013, 2157405, 2154194, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156629, 2156629, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198 ], "changes": [ { "cves": [ { "cve": "CVE-2026-46137", "url": "https://ubuntu.com/security/CVE-2026-46137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: fix potential data-race This mptcp_pm_add_timer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bh_lock_sock(). If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46275", "url": "https://ubuntu.com/security/CVE-2026-46275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart. The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the `hu` struct. When the scheduled work executes later, it blindly dereferences the freed `hu` struct. Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently. Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities.", "cve_priority": "high", "cve_public_date": "2026-06-08 16:16:00 UTC" }, { "cve": "CVE-2025-23141", "url": "https://ubuntu.com/security/CVE-2025-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where \"accepting\" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit can access guest memory. The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triple_fault_event_test selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario. ============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted ----------------------------- include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2026-43052", "url": "https://ubuntu.com/security/CVE-2026-43052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check tdls flag in ieee80211_tdls_oper When NL80211_TDLS_ENABLE_LINK is called, the code only checks if the station exists but not whether it is actually a TDLS station. This allows the operation to proceed for non-TDLS stations, causing unintended side effects like modifying channel context and HT protection before failing. Add a check for sta->sta.tdls early in the ENABLE_LINK case, before any side effects occur, to ensure the operation is only allowed for actual TDLS peers.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2025-22107", "url": "https://ubuntu.com/security/CVE-2025-22107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry() There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-21863", "url": "https://ubuntu.com/security/CVE-2025-21863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: prevent opcode speculation sqe->opcode is used for different tables, make sure we santitise it against speculations.", "cve_priority": "low", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2026-46274", "url": "https://ubuntu.com/security/CVE-2026-46274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io-wq: check that the predecessor is hashed in io_wq_remove_pending() io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0]. Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory. Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot.", "cve_priority": "high", "cve_public_date": "2026-06-08 16:16:00 UTC" }, { "cve": "CVE-2026-45846", "url": "https://ubuntu.com/security/CVE-2026-45846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst() bareudp_fill_metadata_dst() passes bareudp->sock to udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check. The socket is only created in bareudp_open() and NULLed in bareudp_stop(), so calling this function while the device is down triggers a NULL dereference via sock->sk. BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160) Call Trace: bareudp_fill_metadata_dst (drivers/net/bareudp.c:532) do_execute_actions (net/openvswitch/actions.c:901) ovs_execute_actions (net/openvswitch/actions.c:1589) ovs_packet_cmd_execute (net/openvswitch/datapath.c:700) genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1209) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths in the same driver.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45844", "url": "https://ubuntu.com/security/CVE-2026-45844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: arp_tables: fix IEEE1394 ARP payload parsing Weiming Shi says: \"arp_packet_match() unconditionally parses the ARP payload assuming two hardware addresses are present (source and target). However, IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address field, and arp_hdr_len() already accounts for this by returning a shorter length for ARPHRD_IEEE1394 devices. As a result, on IEEE1394 interfaces arp_packet_match() advances past a nonexistent target hardware address and reads the wrong bytes for both the target device address comparison and the target IP address. This causes arptables rules to match against garbage data, leading to incorrect filtering decisions: packets that should be accepted may be dropped and vice versa. The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already handles this correctly by skipping the target hardware address for ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match().\" Mangle the original patch to always return 0 (no match) in case user matches on the target hardware address which is never present in IEEE1394. Note that this returns 0 (no match) for either normal and inverse match because matching in the target hardware address in ARPHRD_IEEE1394 has never been supported by arptables. This is intentional, matching on the target hardware address should never evaluate true for ARPHRD_IEEE1394. Moreover, adjust arpt_mangle to drop the packet too as AI suggests: In arpt_mangle, the logic assumes a standard ARP layout. Because IEEE1394 (FireWire) omits the target hardware address, the linear pointer arithmetic miscalculates the offset for the target IP address. This causes mangling operations to write to the wrong location, leading to packet corruption. To ensure safety, this patch drops packets (NF_DROP) when mangling is requested for these fields on IEEE1394 devices, as the current implementation cannot correctly map the FireWire ARP payload. This omits both mangling target hardware and IP address. Even if IP address mangling should be possible in IEEE1394, this would require to adjust arpt_mangle offset calculation, which has never been supported. Based on patch from Weiming Shi .", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45843", "url": "https://ubuntu.com/security/CVE-2026-45843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: bound decode() reads against the compressed packet length slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code. A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets. Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45842", "url": "https://ubuntu.com/security/CVE-2026-45842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: reject VJ receive packets on instances with no rstate array slhc_init() accepts rslots == 0 as a valid configuration, with the documented meaning of 'no receive compression'. In that case the allocation loop in slhc_init() is skipped, so comp->rstate stays NULL and comp->rslot_limit stays 0 (from the kzalloc of struct slcompress). The receive helpers do not defend against that configuration. slhc_uncompress() dereferences comp->rstate[x] when the VJ header carries an explicit connection ID, and slhc_remember() later assigns cs = &comp->rstate[...] after only comparing the packet's slot number to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the range check, and the code dereferences a NULL rstate. The configuration is reachable in-tree through PPP. PPPIOCSMAXCID stores its argument in a signed int, and (val >> 16) uses arithmetic shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1 is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because /dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path is reachable from an unprivileged user namespace. Once the malformed VJ state is installed, any inbound VJ-compressed or VJ-uncompressed frame that selects slot 0 crashes the kernel in softirq context: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519) Call Trace: ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466) ppp_input (drivers/net/ppp/ppp_generic.c:2359) ppp_async_process (drivers/net/ppp/ppp_async.c:492) tasklet_action_common (kernel/softirq.c:926) handle_softirqs (kernel/softirq.c:623) run_ksoftirqd (kernel/softirq.c:1055) smpboot_thread_fn (kernel/smpboot.c:160) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) Reject the receive side on such instances instead of touching rstate. slhc_uncompress() falls through to its existing 'bad' label, which bumps sls_i_error and enters the toss state. slhc_remember() mirrors that with an explicit sls_i_error increment followed by slhc_toss(); the sls_i_runt counter is not used here because a missing rstate is an internal configuration state, not a runt packet. The transmit path is unaffected: the only in-tree caller that picks rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and slip.c always calls slhc_init(16, 16), so comp->tstate remains valid and slhc_compress() continues to work.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45841", "url": "https://ubuntu.com/security/CVE-2026-45841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO nf_osf_match_one() computes ctx->window % f->wss.val in the OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a subsequent matching TCP SYN divides by zero and panics the kernel. Reject the bogus fingerprint in nfnl_osf_add_callback() above the per-option for-loop. f->wss is per-fingerprint, not per-option, so the check must run regardless of f->opt_num (including 0). Also reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that as \"should not happen\". Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:220) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:348) nf_hook_slow (net/netfilter/core.c:622) ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv (include/linux/skbuff.h:1162) __netif_receive_skb_one_core (net/core/dev.c:6181) process_backlog (net/core/dev.c:6642) __napi_poll (net/core/dev.c:7710) net_rx_action (net/core/dev.c:7945) handle_softirqs (kernel/softirq.c:622)", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45840", "url": "https://ubuntu.com/security/CVE-2026-45840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: cap upcall PID array size and pre-size vport replies The vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENL_UNS_ADMIN_PERM. kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Kernel panic - not syncing: Fatal exception Reject attempts to set more PIDs than nr_cpu_ids in ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply size in ovs_vport_cmd_msg_size() based on that bound, similar to the existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the two sides stay consistent.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46319", "url": "https://ubuntu.com/security/CVE-2026-46319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: Only release RCU read lock after ct_ft When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero() is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft object. This vulnerability can lead to privilege escalation. Analysis from zdi-disclosures@trendmicro.com: When initializing act_ct, tcf_ct_init() is called, which internally triggers tcf_ct_flow_table_get(). static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params) { struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ... } static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params) { void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj; } At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft from zones_ht . The lookup is performed within an RCU read critical section through rcu_read_lock() / rcu_read_unlock(), which prevents the object from being freed. However, at the point of function return, rcu_read_unlock() has already been called, and there is nothing preventing ct_ft from being freed before reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomes the race window, during which ct_ft can be freed. Free Process: tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put(). static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft) { if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); } } At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work static void tcf_ct_flow_table_cleanup_work(struct work_struct *work) { struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE); } tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes between [1] and [2], UAF occurs. This race condition has a very short race window, making it generally difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was inserted after[1]", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-45839", "url": "https://ubuntu.com/security/CVE-2026-45839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec() CO-RE accessor strings are colon-separated indices that describe a path from a root BTF type to a target field, e.g. \"0:1:2\" walks through nested struct members. bpf_core_parse_spec() parses each component with sscanf(\"%d\"), so negative values like -1 are silently accepted. The subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the upper bound and always pass for negative values because C integer promotion converts the __u16 btf_vlen result to int, making the comparison (int)(-1) >= (int)(N) false for any positive N. When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff, producing an out-of-bounds read far past the members array. A crafted BPF program with a negative CO-RE accessor on any struct that exists in vmlinux BTF (e.g. task_struct) crashes the kernel deterministically during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y (default on major distributions). The bug is reachable with CAP_BPF: BUG: unable to handle page fault for address: ffffed11818b6626 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full) RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354) RAX: 00000000ffffffff Call Trace: bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321) bpf_core_apply (kernel/bpf/btf.c:9507) check_core_relo (kernel/bpf/verifier.c:19475) bpf_check (kernel/bpf/verifier.c:26031) bpf_prog_load (kernel/bpf/syscall.c:3089) __sys_bpf (kernel/bpf/syscall.c:6228) CO-RE accessor indices are inherently non-negative (struct member index, array element index, or enumerator index), so reject them immediately after parsing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45838", "url": "https://ubuntu.com/security/CVE-2026-45838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix end-of-list detection in cgroup_storage_get_next_key() list_next_entry() never returns NULL -- when the current element is the last entry it wraps to the list head via container_of(). The subsequent NULL check is therefore dead code and get_next_key() never returns -ENOENT for the last element, instead reading storage->key from a bogus pointer that aliases internal map fields and copying the result to userspace. Replace it with list_entry_is_head() so the function correctly returns -ENOENT when there are no more entries.", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46214", "url": "https://ubuntu.com/security/CVE-2026-46214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix accept queue count leak on transport mismatch virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listener to reject all new connections. Fix by moving sk_acceptq_added() to after the transport validation, matching the pattern used by vmci_transport and hyperv_transport.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46234", "url": "https://ubuntu.com/security/CVE-2026-46234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: fix buffer size clamping order In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint. This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size. Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45836", "url": "https://ubuntu.com/security/CVE-2026-45836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46231", "url": "https://ubuntu.com/security/CVE-2026-46231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: put backbone reference on failed claim hash insert When batadv_bla_add_claim() fails to insert a new claim into the hash, it leaked a reference to the backbone_gw for which the claim was intended. Call batadv_backbone_gw_put() on the error path to release the reference and avoid leaking the backbone_gw object.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46233", "url": "https://ubuntu.com/security/CVE-2026-46233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: only purge non-released claims When batadv_bla_purge_claims() goes through the list of claims, it is only traversing the hash list with an rcu_read_lock(). Due to a potential parallel batadv_claim_put(), it can happen that it encounters a claim which was actually in the process of being released+freed by batadv_claim_release(). In this case, backbone_gw is set to NULL before the delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is then no longer allowed because it would cause a NULL-ptr derefence. To avoid this, only claims with a valid reference counter must be purged. All others are already taken care of.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46212", "url": "https://ubuntu.com/security/CVE-2026-46212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: prevent use-after-free when deleting claims When batadv_bla_del_backbone_claims() removes all claims for a backbone, it does this by dropping the link entry in the hash list. This list entry itself was one of the references which need to be dropped at the same time via batadv_claim_put(). But the batadv_claim_put() must not be done before the last access to the claim object in this function. Otherwise the claim might be freed already by the batadv_claim_release() function before the list entry was dropped.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46238", "url": "https://ubuntu.com/security/CVE-2026-46238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop caching unowned originator pointers in BAT IV BAT IV keeps the last-hop neighbor address in each neigh_node, but some paths also cache an originator pointer derived from a temporary lookup. That pointer is not owned by the neigh_node and may no longer refer to a live originator entry after purge handling runs. Stop storing the auxiliary originator pointer in the BAT IV neighbor state. When BAT IV needs the neighbor originator data, resolve it from the stored neighbor address and drop the reference again after use. [sven: avoid bonding logic for outgoing OGM]", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46206", "url": "https://ubuntu.com/security/CVE-2026-46206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject new tp_meter sessions during teardown Prevent tp_meter from starting new sender or receiver sessions after mesh_state has left BATADV_MESH_ACTIVE.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46198", "url": "https://ubuntu.com/security/CVE-2026-46198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix integer overflow on buff_pos Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size check is done using the int type in batadv_iv_ogm_aggr_packet whereas the buff_pos variable uses the s16 type. This could lead to an out-of-bound read.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46227", "url": "https://ubuntu.com/security/CVE-2026-46227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the \"sk != asoc->base.sk\" and \"asoc->base.dead\" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 (\"sctp: walk the list of asoc safely\") was added for.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46220", "url": "https://ubuntu.com/security/CVE-2026-46220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission sdma_v4_0_ring_emit_fence() contains two BUG_ON(addr & 0x3) assertions that verify fence writeback addresses are dword-aligned. These assertions can be reached from unprivileged userspace via crafted DRM_IOCTL_AMDGPU_CS submissions, causing a fatal kernel panic in a scheduler worker thread. Replace both BUG_ON() calls with WARN_ON() to log the condition without crashing the kernel. A misaligned fence address at this point indicates a driver bug, but crashing the kernel is never the correct response when the assertion is reachable from userspace. The CS IOCTL path is the correct place to filter invalid submissions; the ring emission callback is too late to do anything about it. (cherry picked from commit b90250bd933afd1ba94d86d6b13821997b22b18e)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46197", "url": "https://ubuntu.com/security/CVE-2026-46197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: validate SVM ioctl nattr against buffer size Validate nattr field against the buffer size, preventing out-of-bounds buffer access via user-controlled attribute count. (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46209", "url": "https://ubuntu.com/security/CVE-2026-46209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1); However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value. A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46230", "url": "https://ubuntu.com/security/CVE-2026-46230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg Check bounds against the end of the BO whenever we access the msg.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46219", "url": "https://ubuntu.com/security/CVE-2026-46219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix use-after-free on unbind The state machine work is scheduled by the interrupt handler and therefore needs to be cancelled after disabling interrupts to avoid a potential use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46236", "url": "https://ubuntu.com/security/CVE-2026-46236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: xbox_remote: heed DMA restrictions The buffer for IO must not be part of the device structure because that violates the DMA coherency rules.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46205", "url": "https://ubuntu.com/security/CVE-2026-46205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: media: atomisp: Disallow all private IOCTLs Disallow all private IOCTLs. These aren't quite as safe as one could assume of IOCTL handlers; disable them for now. Instead of removing the code, return in the beginning of the function if cmd is non-zero in order to keep static checkers happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46168", "url": "https://ubuntu.com/security/CVE-2026-46168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix scheduling with atomic in timestamp sockopt Using lock_sock_fast() (atomic context) around sock_set_timestamp() and sock_set_timestamping() is unsafe, as both helpers can sleep. Replace lock_sock_fast() with sleepable lock_sock()/release_sock() to avoid scheduling while atomic panic.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46189", "url": "https://ubuntu.com/security/CVE-2026-46189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path Sashiko points out that pvrdma_uar_free() is already called within pvrdma_dealloc_ucontext(), so calling it before triggers a double free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46133", "url": "https://ubuntu.com/security/CVE-2026-46133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject unknown opcodes before ICRC processing Even after applying commit 7244491dab34 (\"RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv\"), a single unauthenticated UDP packet can still trigger panic. That patch handled payload_size() underflow only for valid opcodes with short packets, not for packets carrying an unknown opcode. The unknown-opcode OOB read described below predates that commit and reaches back to the initial Soft RoCE driver. The check added there reads pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The rxe_opcode[] array has 256 entries but is only populated for defined IB opcodes; any other entry (for example opcode 0xff) is zero-initialized, so length == 0 and the check degenerates to pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES which underflows when length == 0 and passes a huge value to rxe_crc32(), causing an out-of-bounds read of the skb payload. Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma link add rxe0 type rxe netdev eth0 A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and QPN=IB_MULTICAST_QPN triggers: BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170 Read of size 1 at addr ... The buggy address is located 0 bytes to the right of allocated 704-byte region Call Trace: crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 Subsequent packets with the same shape fault on unmapped memory and panic the kernel. The trigger requires only module load and \"rdma link add\"; no QP, no connection, and no authentication. Fix this by rejecting packets whose opcode has no rxe_opcode[] entry, detected via the zero mask or zero length, before any length arithmetic runs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46127", "url": "https://ubuntu.com/security/CVE-2026-46127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp() Sashiko points out that pd->uctx isn't initialized until late in the function so all these error flow references are NULL and will crash. Use the uctx that isn't NULL.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46178", "url": "https://ubuntu.com/security/CVE-2026-46178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq() Sashiko points out that mlx4_srq_alloc() was not undone during error unwind, add the missing call to mlx4_srq_free().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46112", "url": "https://ubuntu.com/security/CVE-2026-46112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix unlocked call to hns_roce_qp_remove() Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory. Grab the same locks the other two callers use.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46304", "url": "https://ubuntu.com/security/CVE-2026-46304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the final controller reference through nvmet_cq_put(). If that triggers nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on the same nvmet-wq. Call chain: nvmet_tcp_schedule_release_queue() kref_put(&queue->kref, nvmet_tcp_release_queue) nvmet_tcp_release_queue() queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq process_one_work() nvmet_tcp_release_queue_work() nvmet_cq_put(&queue->nvme_cq) nvmet_cq_destroy() nvmet_ctrl_put(cq->ctrl) nvmet_ctrl_free() flush_work(&ctrl->async_event_work) <--- nvmet_wq Previously Scheduled by :- \t\t nvmet_add_async_event \t\t queue_work(nvmet_wq, &ctrl->async_event_work); This trips lockdep with a possible recursive locking warning. [ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55 [ 5223.061801] loop0: detected capacity change from 0 to 2097152 [ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 [ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420) [ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349. [ 5223.128453] nvme nvme1: new ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349 [ 5233.199447] nvme nvme1: Removing ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\" [ 5233.227718] ============================================ [ 5233.231283] WARNING: possible recursive locking detected [ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N [ 5233.238434] -------------------------------------------- [ 5233.241852] kworker/u192:6/2413 is trying to acquire lock: [ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 [ 5233.251438] but task is already holding lock: [ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.261125] other info that might help us debug this: [ 5233.265333] Possible unsafe locking scenario: [ 5233.269217] CPU0 [ 5233.270795] ---- [ 5233.272436] lock((wq_completion)nvmet-wq); [ 5233.275241] lock((wq_completion)nvmet-wq); [ 5233.278020] *** DEADLOCK *** [ 5233.281793] May be due to missing lock nesting notation [ 5233.286195] 3 locks held by kworker/u192:6/2413: [ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0 [ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 [ 5233.304290] stack backtrace: [ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full) [ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST [ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp] [ 5233.306532] Call Trace: [ 5233.306534] [ 5233.306536] dump_stack_lvl+0x73/0xb0 [ 5233.306552] print_deadlock_bug+0x225/0x2f0 [ 5233.306556] __lock_acquire+0x13f0/0x2290 [ 5233.306563] lock_acquire+0xd0/0x300 [ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306571] ? __flush_work+0x20b/0x530 [ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306577] touch_wq_lockdep_map+0x3b/0x90 [ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90 [ 52 ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46161", "url": "https://ubuntu.com/security/CVE-2026-46161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix divide-by-zero in setup_geo() with zero far_copies setup_geo() extracts near_copies (nc) and far_copies (fc) from the user-provided layout parameter without checking for zero. When fc=0 with the \"improved\" far set layout selected, 'geo->far_set_size = disks / fc' triggers a divide-by-zero. Validate nc and fc immediately after extraction, returning -1 if either is zero.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46124", "url": "https://ubuntu.com/security/CVE-2026-46124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate block number from NFS file handle in isofs_export_iget isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker- controlled block number (ifid->block or ifid->parent_block) from the NFS file handle to isofs_export_iget(), which only rejects block == 0 before calling isofs_iget() and ultimately sb_bread(). A crafted file handle with fh_len sufficient to pass the check added by commit 0405d4b63d08 (\"isofs: Prevent the use of too small fid\") can still drive the server to read any in-range block on the backing device as if it were an iso_directory_record. That earlier fix was assigned CVE-2025-37780. sb_bread() on an out-of-range block returns NULL cleanly via the EIO path, so there is no memory-safety violation. For in-range reads of adjacent-partition data on the same block device, the unrelated bytes end up in iso_inode_info fields that reach the NFS client as dentry metadata. The deployment surface (isofs exported over NFS from loop-mounted images) is narrow and requires an authenticated NFS peer, but the malformed-file-handle class is reportable as hardening next to the existing CVE-2025-37780 fix. Reject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent() call sites with a single line.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46303", "url": "https://ubuntu.com/security/CVE-2026-46303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b (\"[PATCH] rock.c: handle corrupted directories\") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 (\"isofs: Fix infinite looping over CE entries\") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.", "cve_priority": "medium", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46294", "url": "https://ubuntu.com/security/CVE-2026-46294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a buffer overflow in ioctl processing Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the \"outptr\" variable to the next 8-byte boundary: \toutptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The \"for\" loop is iterated again, it executes: \tremaining = len - (outptr - outbuf); 5. If \"outptr\" points past \"outbuf + len\", the arithmetics wraps around and the variable \"remaining\" contains unusually high number 6. With \"remaining\" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, \"outptr = align_ptr(outptr)\" can't overshoot the input buffer and the bug can't happen accidentally", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46107", "url": "https://ubuntu.com/security/CVE-2026-46107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-thin: fix metadata refcount underflow There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count. If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in \"device mapper: space map common: unable to decrement block\" errors. Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46301", "url": "https://ubuntu.com/security/CVE-2026-46301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: topcliff-pch: fix use-after-free on unbind Give the driver a chance to flush its queue before releasing the DMA buffers on driver unbind", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46273", "url": "https://ubuntu.com/security/CVE-2026-46273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmveth: Disable GSO for packets with small MSS Some physical adapters on Power systems do not support segmentation offload when the MSS is less than 224 bytes. Attempting to send such packets causes the adapter to freeze, stopping all traffic until manually reset. Implement ndo_features_check to disable GSO for packets with small MSS values. The network stack will perform software segmentation instead. The 224-byte minimum matches ibmvnic commit (\"ibmvnic: Enforce stronger sanity checks on GSO packets\") which uses the same physical adapters in SEA configurations. The issue occurs specifically when the hardware attempts to perform segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets (gso_segs == 1) do not trigger the problematic LSO code path and are transmitted normally without segmentation. Add an ndo_features_check callback to disable GSO when MSS < 224 bytes. Also call vlan_features_check() to ensure proper handling of VLAN packets, particularly QinQ (802.1ad) configurations where the hardware parser may not support certain offload features. Validated using iptables to force small MSS values. Without the fix, the adapter freezes. With the fix, packets are segmented in software and transmission succeeds. Comprehensive regression testing completedd (MSS tests, performance, stability).", "cve_priority": "high", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-43502", "url": "https://ubuntu.com/security/CVE-2026-43502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: handle zerocopy send cleanup before the message is queued A zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket. The purge path currently infers zerocopy state from rm->m_rs, so an unqueued message can be cleaned up as if it owned normal payload pages. However, zerocopy ownership is really determined by the presence of op_mmp_znotifier, regardless of whether the message has reached the socket queue. Capture op_mmp_znotifier up front in rds_message_purge() and use it as the cleanup discriminator. If the message is already associated with a socket, keep the existing completion path. Otherwise, drop the pinned page accounting directly and release the notifier before putting the payload pages. This keeps early send failure cleanup consistent with the zerocopy lifetime rules without changing the normal queued completion path.", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46120", "url": "https://ubuntu.com/security/CVE-2026-46120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: Use cached t->net in ip6erspan_changelink(). After commit 5e72ce3e3980 (\"net: ipv6: Use link netns in newlink() of rtnl_link_ops\"), ip6erspan_newlink() correctly resolves the per-netns ip6gre hash via link_net. ip6erspan_changelink() was not converted in that series and still uses dev_net(dev), which diverges from the device's creation netns after IFLA_NET_NS_FD migration. This re-inserts the tunnel into the wrong per-netns hash. The original netns keeps a stale entry. When that netns is later destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a slab-use-after-free reported by KASAN, followed by a kernel BUG at net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify(). Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). ip6gre_changelink() earlier in the same file already uses the cached t->net; only ip6erspan_changelink() has the wrong shape.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46184", "url": "https://ubuntu.com/security/CVE-2026-46184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sound: ua101: fix division by zero at probe Add a missing sanity check for bNrChannels in detect_usb_format() to prevent a division by zero in playback_urb_complete() and capture_urb_complete(). USB core does not validate class-specific descriptor fields such as bNrChannels, so drivers must verify them before use. If a device provides bNrChannels = 0, frame_bytes becomes zero and is later used as a divisor in the URB completion handlers, leading to a kernel crash.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46132", "url": "https://ubuntu.com/security/CVE-2026-46132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack without initialisation: \tstruct ifla_vf_broadcast vf_broadcast; The struct contains a single fixed 32-byte field: \t/* include/uapi/linux/if_link.h */ \tstruct ifla_vf_broadcast { \t\t__u8 broadcast[32]; \t}; The function then copies dev->broadcast into it using dev->addr_len as the length: \tmemcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len); On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via: \tnla_put(skb, IFLA_VF_BROADCAST, \t\tsizeof(vf_broadcast), &vf_broadcast) leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK request, repeatable. The other vf_* structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vf_vlan_info, node_guid and port_guid a few lines above. vf_broadcast was simply missed when it was added. Reachability: any unprivileged local process can open AF_NETLINK / NETLINK_ROUTE without capabilities and send RTM_GETLINK with an IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nla_put() when reproduced. Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf_* structs in the same function.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46150", "url": "https://ubuntu.com/security/CVE-2026-46150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fanotify: fix false positive on permission events fsnotify_get_mark_safe() may return false for a mark on an unrelated group, which results in bypassing the permission check. Fix by skipping over detached marks that are not in the current group.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45834", "url": "https://ubuntu.com/security/CVE-2026-45834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-45835", "url": "https://ubuntu.com/security/CVE-2026-45835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46186", "url": "https://ubuntu.com/security/CVE-2026-46186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: validate rx pkt_type header length virtbt_rx_handle() reads the leading pkt_type byte from the RX skb and forwards the remainder to hci_recv_frame() for every event/ACL/SCO/ISO type, without checking that the remaining payload is at least the fixed HCI header for that type. After the preceding patch bounds the backend-supplied used.len to [1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches hci_recv_frame() with skb->len already pulled to 0. If the byte happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification fast-path in hci_dev_classify_pkt_type() dereferences hci_acl_hdr(skb)->handle whenever the HCI device has an active CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of uninitialized RX-buffer data. The same hazard exists for every packet type the driver accepts because none of the switch cases in virtbt_rx_handle() check skb->len against the per-type minimum HCI header size before handing the frame to the core. After stripping pkt_type, require skb->len to cover the fixed header size for the selected type (event 2, ACL 4, SCO 3, ISO 4) before calling hci_recv_frame(); drop ratelimited otherwise. Unknown pkt_type values still take the original kfree_skb() default path. Use bt_dev_err_ratelimited() because both the length and pkt_type values come from an untrusted backend that can otherwise flood the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46123", "url": "https://ubuntu.com/security/CVE-2026-46123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: clamp rx length before skb_put virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one(). Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device. The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory. Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle(). Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log. Same class of bug as commit c04db81cd028 (\"net/9p: Fix buffer overflow in USB transport layer\"), which hardened the USB 9p transport against unchecked device-reported length.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46172", "url": "https://ubuntu.com/security/CVE-2026-46172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: xfrm6: release dst on error in xfrm6_rcv_encap() xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6_route_input_lookup() returns a referenced dst entry even when the lookup resolves to an error route. If dst->error is set, xfrm6_rcv_encap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries. Release the dst before jumping to the drop path.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46146", "url": "https://ubuntu.com/security/CVE-2026-46146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3() The convert_chmap_v3() has a loop with its increment size of cs_desc->wLength, but we forgot to validate cs_desc->wLength itself, which may lead to potential endless loop by a malformed descriptor. Add a proper size check to abort the loop for plugging the hole.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46167", "url": "https://ubuntu.com/security/CVE-2026-46167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. Ideally that short command should be detected and error out, but many printers are known to send \"incorrect\" responses back so we can't just do that. statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl. usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller. Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no \"leak\" of information happening.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46151", "url": "https://ubuntu.com/security/CVE-2026-46151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix heap leak in IEEE 1284 device ID via short response usblp_ctrl_msg() collapses the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GET_DEVICE_ID control transfer short and the driver has no way to know. usblp_cache_device_id_string() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves device_id_string[2..1022] holding stale kmalloc heap. That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf(\"%s\", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device. Fix this up by just zapping the buffer with zeros before each request sent to the device.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46122", "url": "https://ubuntu.com/security/CVE-2026-46122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43: enforce bounds check on firmware key index in b43_rx() The firmware-controlled key index in b43_rx() can exceed the dev->key[] array size (58 entries). The existing B43_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read. Make the B43_WARN_ON check enforcing by dropping the frame when the firmware returns an invalid key index.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46307", "url": "https://ubuntu.com/security/CVE-2026-46307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath5k: do not access array OOB Vincent reports: > The ath5k driver seems to do an array-index-out-of-bounds access as > shown by the UBSAN kernel message: > UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20 > index 4 is out of range for type 'ieee80211_tx_rate [4]' > ... > Call Trace: > > dump_stack_lvl+0x5d/0x80 > ubsan_epilogue+0x5/0x2b > __ubsan_handle_out_of_bounds.cold+0x46/0x4b > ath5k_tasklet_tx+0x4e0/0x560 [ath5k] > tasklet_action_common+0xb5/0x1c0 It is real. 'ts->ts_final_idx' can be 3 on 5212, so: info->status.rates[ts->ts_final_idx + 1].idx = -1; with the array defined as: struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES]; while the size is: #define IEEE80211_TX_MAX_RATES 4 is indeed bogus. Set this 'idx = -1' sentinel only if the array index is less than the array size. As mac80211 will not look at rates beyond the size (IEEE80211_TX_MAX_RATES). Note: The effect of the OOB write is negligible. It just overwrites the next member of info->status, i.e. ack_signal.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46187", "url": "https://ubuntu.com/security/CVE-2026-46187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: fix kthread lifetime race between self-exit and external-stop RSI driver use both self-exit(kthread_complete_and_exit) and external-stop (kthread_stop) when killing a kthread. Generally, kthread_stop() is called first, and in this case, no particular issues occur. However, in rare instances where kthread_complete_and_exit() is called first and then kthread_stop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again. Therefore, to prevent this with minimal modification, you must remove kthread_stop() and change the code to wait until the self-exit operation is completed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46163", "url": "https://ubuntu.com/security/CVE-2026-46163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43legacy: enforce bounds check on firmware key index in RX path Same fix as b43: the firmware-controlled key index in b43legacy_rx() can exceed dev->max_nr_keys. The existing B43legacy_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read of dev->key[]. Make the check enforcing by dropping the frame for invalid indices.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46044", "url": "https://ubuntu.com/security/CVE-2026-46044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:ssif: Clean up kthread on errors If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43496", "url": "https://ubuntu.com/security/CVE-2026-43496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peeked When red qdisc has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] [ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq] [ 78.672148][ T363] ? __pfx__printk+0x10/0x10 [ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0 [ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0 [ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red] [ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf] [ 78.673566][ T363] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead.", "cve_priority": "medium", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2024-56727", "url": "https://ubuntu.com/security/CVE-2024-56727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c Adding error pointer check after calling otx2_mbox_get_rsp().", "cve_priority": "medium", "cve_public_date": "2024-12-29 12:15:00 UTC" }, { "cve": "CVE-2026-31489", "url": "https://ubuntu.com/security/CVE-2026-31489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: meson-spicc: Fix double-put in remove path meson_spicc_probe() registers the controller with devm_spi_register_controller(), so teardown already drops the controller reference via devm cleanup. Calling spi_controller_put() again in meson_spicc_remove() causes a double-put.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31476", "url": "https://ubuntu.com/security/CVE-2026-31476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: do not expire session on binding failure When a multichannel session binding request fails (e.g. wrong password), the error path unconditionally sets sess->state = SMB2_SESSION_EXPIRED. However, during binding, sess points to the target session looked up via ksmbd_session_lookup_slowpath() -- which belongs to another connection's user. This allows a remote attacker to invalidate any active session by simply sending a binding request with a wrong password (DoS). Fix this by skipping session expiration when the failed request was a binding attempt, since the session does not belong to the current connection. The reference taken by ksmbd_session_lookup_slowpath() is still correctly released via ksmbd_user_session_put().", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43497", "url": "https://ubuntu.com/security/CVE-2026-43497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages to userspace but sets no vm_ops on the VMA. This means the kernel cannot track active mmaps. When dlfb_realloc_framebuffer() replaces the backing buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated. On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages while userspace PTEs still reference them, resulting in a use-after-free: the process retains read/write access to freed kernel pages. Add vm_operations_struct with open/close callbacks that maintain an atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(), check mmap_count and return -EBUSY if the buffer is currently mapped, preventing buffer replacement while userspace holds stale PTEs. Tested with PoC using dummy_hcd + raw_gadget USB device emulation.", "cve_priority": "low", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46108", "url": "https://ubuntu.com/security/CVE-2026-46108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:si: Return state to normal if message allocation fails There were places where nothing would get started if a message allocation failed, so the driver needs to return to normal state.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46128", "url": "https://ubuntu.com/security/CVE-2026-46128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Check event message buffer response for bad data The event message buffer response data size got checked later when processing, but check it right after the response comes back. It appears some BMCs may return an empty message instead of an error when fetching events. There are apparently some new BMCs that make this error, so we need to compensate.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46177", "url": "https://ubuntu.com/security/CVE-2026-46177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Add limits to event and receive message requests The driver would just fetch events and receive messages until the BMC said it was done. To avoid issues with BMCs that never say they are done, add a limit of 10 fetches at a time. In addition, an si interface has an attn state it can return from the hardware which is supposed to cause a flag fetch to see if the driver needs to fetch events or message or a few other things. If the attn bit gets stuck, it's a similar problem. So allow messages in between flag fetches so the driver itself doesn't get stuck. This is a more general fix than the previous fix for the specific bad BMC, but should fix the more general issue of a BMC that won't stop saying it has data. This has been there from the beginning of the driver. It's not a bug per-se, but it is accounting for bugs in BMCs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46149", "url": "https://ubuntu.com/security/CVE-2026-46149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show() target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered. Commit 27e06650a5ea (\"scsi: target: target_core_configfs: Add length check to avoid buffer overflow\") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46101", "url": "https://ubuntu.com/security/CVE-2026-46101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: reject zero shift in nft_bitwise Reject zero shift operands for nft_bitwise left and right shift expressions during initialization. The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour. Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46099", "url": "https://ubuntu.com/security/CVE-2026-46099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels seg6_input_core() and rpl_input() call ip6_route_input() which sets a NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking dst_hold() unconditionally. On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpu_rt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence: ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1] rt_genid_bump_ipv6() -> bumps fib6_sernum [fib6_sernum from W to Z] ip6_route_output() -> ip6_pol_route() -> FIB lookup resolves fib6_nh [nhid=N] -> rt6_get_pcpu_route() pcpu_rt->sernum != fib6_sernum [W <> Z, stale] -> prev = xchg(rt6i_pcpu, NULL) -> dst_release(prev) [prev is pcpu_rt, refcount 1->0, dead] dst = skb_dst(skb) [dst is the dead pcpu_rt] dst_cache_set_ip6(dst) -> dst_hold() on dead dst -> WARN / use-after-free For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release the pcpu_rt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6_nh and its rt6i_pcpu entry. Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after ip6_route_input() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6_route_output() already returns a refcounted dst.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46033", "url": "https://ubuntu.com/security/CVE-2026-46033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject short ahash digests during instance creation authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46062", "url": "https://ubuntu.com/security/CVE-2026-46062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix integer overflow in run_unpack() volume boundary check The volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses raw addition which can wrap around for large lcn and len values, bypassing the validation. Use check_add_overflow() as is already done for the adjacent prev_lcn + dlcn and vcn64 + len checks added by commit 3ac37e100385 (\"ntfs3: Fix integer overflow in run_unpack()\"). Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46072", "url": "https://ubuntu.com/security/CVE-2026-46072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: add buffer boundary checks to run_unpack() run_unpack() checks `run_buf < run_last` at the top of the while loop but then reads size_size and offset_size bytes via run_unpack_s64() without verifying they fit within the remaining buffer. A crafted NTFS image with truncated run data in an MFT attribute triggers an OOB heap read of up to 15 bytes when the filesystem is mounted. Add boundary checks before each run_unpack_s64() call to ensure the declared field size does not exceed the remaining buffer. Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46023", "url": "https://ubuntu.com/security/CVE-2026-46023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm mirror: fix integer overflow in create_dirty_log() The argument count calculation in create_dirty_log() performs `*args_used = 2 + param_count` before validating against argc. When a user provides a param_count close to UINT_MAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent `argc < *args_used` check to be bypassed. The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array. Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46077", "url": "https://ubuntu.com/security/CVE-2026-46077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-tdes - fix DMA sync direction Before DMA output is consumed by the CPU, ->dma_addr_out must be synced with dma_sync_single_for_cpu() instead of dma_sync_single_for_device(). Using the wrong direction can return stale cache data on non-coherent platforms.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45986", "url": "https://ubuntu.com/security/CVE-2026-45986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccree - fix a memory leak in cc_mac_digest() Add cc_unmap_result() if cc_map_hash_request_final() fails to prevent potential memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46019", "url": "https://ubuntu.com/security/CVE-2026-46019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the first page using free_page(), leaking the remaining 3 pages. Use free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46015", "url": "https://ubuntu.com/security/CVE-2026-46015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: call sk_data_ready() after listener migration When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46040", "url": "https://ubuntu.com/security/CVE-2026-46040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails When fsnotify_add_inode_mark_locked() fails in inotify_new_watch(), the error path calls inotify_remove_from_idr() but does not call dec_inotify_watches() to undo the preceding inc_inotify_watches(). This leaks a watch count, and repeated failures can exhaust the max_user_watches limit with -ENOSPC even when no watches are active. Prior to commit 1cce1eea0aff (\"inotify: Convert to using per-namespace limits\"), the watch count was incremented after fsnotify_add_mark_locked() succeeded, so this path was not affected. The conversion moved inc_inotify_watches() before the mark insertion without adding the corresponding rollback. Add the missing dec_inotify_watches() call in the error path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46070", "url": "https://ubuntu.com/security/CVE-2026-46070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: validate payload size before accessing journal metadata r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block. A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets. Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46051", "url": "https://ubuntu.com/security/CVE-2026-46051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix soft lockup in retry_aligned_read() When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46046", "url": "https://ubuntu.com/security/CVE-2026-46046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all() The commit c8e008b60492 (\"ext4: ignore xattrs past end\") introduced a refcount leak in when block_csum is false. ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to get iloc.bh, but never releases it with brelse().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46285", "url": "https://ubuntu.com/security/CVE-2026-46285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: docg3: fix use-after-free in docg3_release() In docg3_release(), the docg3 pointer is obtained from cascade->floors[0]->priv before the loop that calls doc_release_device() on each floor. doc_release_device() frees the docg3 struct via kfree(docg3) at line 1881. After the loop, docg3->cascade->bch dereferences the already-freed pointer. Fix this by accessing cascade->bch directly, which is equivalent since docg3->cascade points back to the same cascade struct, and is already available as a local variable. This also removes the now-unused docg3 local variable.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46082", "url": "https://ubuntu.com/security/CVE-2026-46082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. [sean: tag for stable@]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45987", "url": "https://ubuntu.com/security/CVE-2026-45987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2 After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46024", "url": "https://ubuntu.com/security/CVE-2026-46024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply() If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for both protocol and result, this is currently not treated as an error. In case of ac->negotiating == true and ac->protocol > 0, this leads to setting ac->protocol = 0 and ac->ops = NULL. Thereafter, the check for ac->protocol != protocol returns false, and init_protocol() is not called. Subsequently, ac->ops->handle_reply() is called, which leads to a null pointer dereference, because ac->ops is still NULL. This patch changes the check for ac->protocol != protocol to !ac->protocol, as this also includes the case when the protocol was set to zero in the message. This causes the message to be treated as containing a bad auth protocol.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46037", "url": "https://ubuntu.com/security/CVE-2026-46037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: validate reply type before using icmp_pointers Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type. That value is outside the range covered by icmp_pointers[], which only describes the traditional ICMP types up to NR_ICMP_TYPES. Avoid consulting icmp_pointers[] for reply types outside that range, and use array_index_nospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46027", "url": "https://ubuntu.com/security/CVE-2026-46027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid early lgr access in smc_clc_wait_msg A CLC decline can be received while the handshake is still in an early stage, before the connection has been associated with a link group. The decline handling in smc_clc_wait_msg() updates link-group level sync state for first-contact declines, but that state only exists after link group setup has completed. Guard the link-group update accordingly and keep the per-socket peer diagnosis handling unchanged. This preserves the existing sync_err handling for established link-group contexts and avoids touching link-group state before it is available.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46053", "url": "https://ubuntu.com/security/CVE-2026-46053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: fix MR cleanup on copy error __rds_rdma_map() hands sg/pages ownership to the transport after get_mr() succeeds. If copying the generated cookie back to user space fails after that point, the error path must not free those resources again before dropping the MR reference. Remove the duplicate unpin/free from the put_user() failure branch so that MR teardown is handled only through the existing final cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46004", "url": "https://ubuntu.com/security/CVE-2026-46004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Handle probe errors properly The probe procedure of setup_card() in caiaq driver doesn't treat the error cases gracefully, e.g. the error from snd_card_register() calls snd_card_free() but continues. This would lead to a UAF for the further calls like snd_usb_caiaq_control_init(), as Berk suggested in another patch in the link below. However, the problem is not only that; in general, this function drops the all error handlings (as it's a void function) although its caller can propagate an error to snd_probe(), which eventually calls snd_card_free() as a proper error path. That said, we should treat each error case in setup_card(), and just return the error code promptly, which is then handled later as a fatal error in snd_probe(). This patch achieves it by changing the setup_card() to return an error code. Also, the superfluous snd_card_free() call is removed, too. Note that card->private_free can be set still safely at returning an error. All called functions in card_free() have checks of the unassigned resources or NULL checks.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46050", "url": "https://ubuntu.com/security/CVE-2026-46050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix deadlock with check operation and nowait requests When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b (\"raid10: cleanup memleak at raid10_make_request\") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case. This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0. Output of r10conf state of the array when we hit this condition: crash> struct r10conf \tbarrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0, Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier(): md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46049", "url": "https://ubuntu.com/security/CVE-2026-46049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Add fallback to default RSR for S/PDIF spdif_passthru_playback_get_resources() uses atc->pll_rate as the RSR for the MSR calculation loop. However, pll_rate is only updated in atc_pll_init() and not in hw_pll_init(), so it remains 0 after the card init. When spdif_passthru_playback_setup() skips atc_pll_init() for 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin indefinitely. Add fallback to use atc->rsr when atc->pll_rate is 0. This reflects the hardware state, since hw_card_init() already configures the PLL to the default RSR.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46002", "url": "https://ubuntu.com/security/CVE-2026-46002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext2: reject inodes with zero i_nlink and valid mode in ext2_iget() ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is zero or i_dtime is set, treating them as deleted. However, the case of i_nlink == 0 with a non-zero mode and zero dtime slips through. Since ext2 has no orphan list, such a combination can only result from filesystem corruption - a legitimate inode deletion always sets either i_dtime or clears i_mode before freeing the inode. A crafted image can exploit this gap to present such an inode to the VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via ext2_unlink(), ext2_rename() and ext2_rmdir(): WARNING: CPU: 3 PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295 vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477 do_unlinkat+0x53e/0x730 fs/namei.c:4541 __x64_sys_unlink+0xc6/0x110 fs/namei.c:4587 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 646 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rename+0x35e/0x850 fs/ext2/namei.c:374 vfs_rename+0xf2f/0x2060 fs/namei.c:5021 do_renameat2+0xbe2/0xd50 fs/namei.c:5178 __x64_sys_rename+0x7e/0xa0 fs/namei.c:5223 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 634 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311 vfs_rmdir+0x204/0x690 fs/namei.c:4348 do_rmdir+0x372/0x3e0 fs/namei.c:4407 __x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Extend the existing i_nlink == 0 check to also catch this case, reporting the corruption via ext2_error() and returning -EFSCORRUPTED. This rejects the inode at load time and prevents it from reaching any of the namei.c paths. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46047", "url": "https://ubuntu.com/security/CVE-2026-46047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Fix use-after-free in driver remove() In the remove callback, if a packet arrives after destroy_workqueue() is called, but before sock_release(), the qrtr_ns_data_ready() callback will try to queue the work, causing use-after-free issue. Fix this issue by saving the default 'sk_data_ready' callback during qrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback at the start of remove(). This ensures that even if a packet arrives after destroy_workqueue(), the work struct will not be dereferenced. Note that it is also required to ensure that the RX threads are completed before destroying the workqueue, because the threads could be using the qrtr_ns_data_ready() callback.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46009", "url": "https://ubuntu.com/security/CVE-2026-46009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to do later. This leads to an oops when .allow_link fails or when .drop_link is performed. Remove the helper. Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46102", "url": "https://ubuntu.com/security/CVE-2026-46102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: strparser: fix skb_head leak in strp_abort_strp() When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46098", "url": "https://ubuntu.com/security/CVE-2026-46098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: caif: clear client service pointer on teardown `caif_connect()` can tear down an existing client after remote shutdown by calling `caif_disconnect_client()` followed by `caif_free_client()`. `caif_free_client()` releases the service layer referenced by `adap_layer->dn`, but leaves that pointer stale. When the socket is later destroyed, `caif_sock_destructor()` calls `caif_free_client()` again and dereferences the freed service pointer. Clear the client/service links before releasing the service object so repeated teardown becomes harmless.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46088", "url": "https://ubuntu.com/security/CVE-2026-46088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names() snd_ctl_elem_init_enum_names() advances pointer p through the names buffer while decrementing buf_len. If buf_len reaches zero but items remain, the next iteration calls strnlen(p, 0). While strnlen(p, 0) returns 0 and would hit the existing name_len == 0 error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks maxlen against __builtin_dynamic_object_size(). When Clang loses track of p's object size inside the loop, this triggers a BRK exception panic before the return value is examined. Add a buf_len == 0 guard at the loop entry to prevent calling fortified strnlen() on an exhausted buffer. Found by kernel fuzz testing through Xiaomi Smartphone.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46080", "url": "https://ubuntu.com/security/CVE-2026-46080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: split transactions in dio completion to avoid credit exhaustion During ocfs2 dio operations, JBD2 may report warnings via following call trace: ocfs2_dio_end_io_write ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_split_extent ocfs2_try_to_merge_extent ocfs2_extend_rotate_transaction ocfs2_extend_trans jbd2__journal_restart start_this_handle output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449 To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to handle extents in a batch of transaction. Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode should only be removed from the orphan list after the extent tree update is complete. This ensures that if a crash occurs in the middle of extent tree updates, we won't leave stale blocks beyond EOF. This patch also changes the logic for updating the inode size and removing orphan, making it similar to ext4_dio_write_end_io(). Both operations are performed only when everything looks good. Finally, thanks to Jans and Joseph for providing the bug fix prototype and suggestions.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-21739", "url": "https://ubuntu.com/security/CVE-2025-21739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix use-after free in init error and remove paths devm_blk_crypto_profile_init() registers a cleanup handler to run when the associated (platform-) device is being released. For UFS, the crypto private data and pointers are stored as part of the ufs_hba's data structure 'struct ufs_hba::crypto_profile'. This structure is allocated as part of the underlying ufshcd and therefore Scsi_host allocation. During driver release or during error handling in ufshcd_pltfrm_init(), this structure is released as part of ufshcd_dealloc_host() before the (platform-) device associated with the crypto call above is released. Once this device is released, the crypto cleanup code will run, using the just-released 'struct ufs_hba::crypto_profile'. This causes a use-after-free situation: Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0 In other words, the initialisation code flow is: platform-device probe ufshcd_pltfrm_init() ufshcd_alloc_host() scsi_host_alloc() allocation of struct ufs_hba creation of scsi-host devices devm_blk_crypto_profile_init() devm registration of cleanup handler using platform-device and during error handling of ufshcd_pltfrm_init() or during driver removal: ufshcd_dealloc_host() scsi_host_put() put_device(scsi-host) release of struct ufs_hba put_device(platform-device) crypto cleanup handler To fix this use-after free, change ufshcd_alloc_host() to register a devres action to automatically cleanup the underlying SCSI device on ufshcd destruction, without requiring explicit calls to ufshcd_dealloc_host(). This way: * the crypto profile and all other ufs_hba-owned resources are destroyed before SCSI (as they've been registered after) * a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as it's not needed anymore * no future drivers using ufshcd_alloc_host() could ever forget adding the cleanup", "cve_priority": "low", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2026-46064", "url": "https://ubuntu.com/security/CVE-2026-46064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix heap over-read in ibmasm_send_i2o_message() The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO. Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure. Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controller's free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it. Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45994", "url": "https://ubuntu.com/security/CVE-2026-45994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix OOB reads in command_file_write due to missing size checks The command_file_write() handler allocates a kernel buffer of exactly count bytes and copies user data into it, but does not validate the buffer against the dot command protocol before passing it to get_dot_command_size() and get_dot_command_timeout(). Since both the allocation size (count) and the header fields (command_size, data_size) are independently user-controlled, an attacker can cause get_dot_command_size() to return a value exceeding the allocation, triggering OOB reads in get_dot_command_timeout() and an out-of-bounds memcpy_toio() that leaks kernel heap memory to the service processor. Fix with two guards: reject writes smaller than sizeof(struct dot_command_header) before allocation, then after copying user data reject commands where the buffer is smaller than the total size declared by the header (sizeof(header) + command_size + data_size). This ensures all subsequent header and payload field accesses stay within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46022", "url": "https://ubuntu.com/security/CVE-2026-46022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt() ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60). A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started. The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes: queue_begin + reader * sizeof(struct remote_input) with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception. Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46006", "url": "https://ubuntu.com/security/CVE-2026-46006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix u32 overflow in pushbuf reloc bounds check nouveau_gem_pushbuf_reloc_apply() validates each relocation with if (r->reloc_bo_offset + 4 > nvbo->bo.base.size) but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size. Cast to u64 so the addition happens in 64-bit arithmetic. [ Add Fixes: tag. - Danilo ]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46018", "url": "https://ubuntu.com/security/CVE-2026-46018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES parse_uac2_sample_rate_range() caps the number of enumerated rates at MAX_NR_RATES, but it only breaks out of the current rate loop. A malformed UAC2 RANGE response with additional triplets continues parsing the remaining triplets and repeatedly prints \"invalid uac2 rates\" while probe still holds register_mutex. Stop the whole parse once the cap is reached and return the number of rates collected so far.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-31696", "url": "https://ubuntu.com/security/CVE-2026-31696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing validation of ticket length in non-XDR key preparsing In rxrpc_preparse(), there are two paths for parsing key payloads: the XDR path (for large payloads) and the non-XDR path (for payloads <= 28 bytes). While the XDR path (rxrpc_preparse_xdr_rxkad()) correctly validates the ticket length against AFSTOKEN_RK_TIX_MAX, the non-XDR path fails to do so. This allows an unprivileged user to provide a very large ticket length. When this key is later read via rxrpc_read(), the total token size (toksize) calculation results in a value that exceeds AFSTOKEN_LENGTH_MAX, triggering a WARN_ON(). [ 2001.302904] WARNING: CPU: 2 PID: 2108 at net/rxrpc/key.c:778 rxrpc_read+0x109/0x5c0 [rxrpc] Fix this by adding a check in the non-XDR parsing path of rxrpc_preparse() to ensure the ticket length does not exceed AFSTOKEN_RK_TIX_MAX, bringing it into parity with the XDR parsing logic.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31697", "url": "https://ubuntu.com/security/CVE-2026-31697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388 CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31698", "url": "https://ubuntu.com/security/CVE-2026-31698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033 CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31699", "url": "https://ubuntu.com/security/CVE-2026-31699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405 CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31701", "url": "https://ubuntu.com/security/CVE-2026-31701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: take a reference on the USB device in create_card() The caiaq driver stores a pointer to the parent USB device in cdev->chip.dev but never takes a reference on it. The card's private_free callback, snd_usb_caiaq_card_free(), can run asynchronously via snd_card_free_when_closed() after the USB device has already been disconnected and freed, so any access to cdev->chip.dev in that path dereferences a freed usb_device. On top of the refcounting issue, the current card_free implementation calls usb_reset_device(cdev->chip.dev). A reset in a free callback is inappropriate: the device is going away, the call takes the device lock in a teardown context, and the reset races with the disconnect path that the callback is already cleaning up after. Take a reference on the USB device in create_card() with usb_get_dev(), drop it with usb_put_dev() in the free callback, and remove the usb_reset_device() call.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31694", "url": "https://ubuntu.com/security/CVE-2026-31694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject oversized dirents in page cache fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31716", "url": "https://ubuntu.com/security/CVE-2026-31716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate rec->used in journal-replay file record check check_file_record() validates rec->total against the record size but never validates rec->used. The do_action() journal-replay handlers read rec->used from disk and use it to compute memmove lengths: DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next)) When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall. This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay Fix this up by bounding rec->used correctly. This is much like commit b2bc7c44ed17 (\"fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\") which checked different values in this same switch statement.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31676", "url": "https://ubuntu.com/security/CVE-2026-31676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31409", "url": "https://ubuntu.com/security/CVE-2026-31409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: unset conn->binding on failed binding request When a multichannel SMB2_SESSION_SETUP request with SMB2_SESSION_REQ_FLAG_BINDING fails ksmbd sets conn->binding = true but never clears it on the error path. This leaves the connection in a binding state where all subsequent ksmbd_session_lookup_all() calls fall back to the global sessions table. This fix it by clearing conn->binding = false in the error path.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2023-53596", "url": "https://ubuntu.com/security/CVE-2023-53596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: base: Free devm resources when unregistering a device In the current code, devres_release_all() only gets called if the device has a bus and has been probed. This leads to issues when using bus-less or driver-less devices where the device might never get freed if a managed resource holds a reference to the device. This is happening in the DRM framework for example. We should thus call devres_release_all() in the device_del() function to make sure that the device-managed actions are properly executed when the device is unregistered, even if it has neither a bus nor a driver. This is effectively the same change than commit 2f8d16a996da (\"devres: release resources on device_del()\") that got reverted by commit a525a3ddeaca (\"driver core: free devres in device_release\") over memory leaks concerns. This patch effectively combines the two commits mentioned above to release the resources both on device_del() and device_release() and get the best of both worlds.", "cve_priority": "low", "cve_public_date": "2025-10-04 16:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2025-38192", "url": "https://ubuntu.com/security/CVE-2025-38192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: clear the dst when changing skb protocol A not-so-careful NAT46 BPF program can crash the kernel if it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10) The output interface has a 4->6 program attached at ingress. We try to loop the multicast skb back to the sending socket. Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr and changes skb->protocol to v6. We enter ip6_rcv_core which tries to use skb_dst(). But the dst is still an IPv4 one left after IPv4 mcast output. Clear the dst in all BPF helpers which change the protocol. Try to preserve metadata dsts, those may carry non-routing metadata.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-21712", "url": "https://ubuntu.com/security/CVE-2025-21712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime After commit ec6bb299c7c3 (\"md/md-bitmap: add 'sync_size' into struct md_bitmap_stats\"), following panic is reported: Oops: general protection fault, probably for non-canonical address RIP: 0010:bitmap_get_stats+0x2b/0xa0 Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Root cause is that bitmap_get_stats() can be called at anytime if mddev is still there, even if bitmap is destroyed, or not fully initialized. Deferenceing bitmap in this case can crash the kernel. Meanwhile, the above commit start to deferencing bitmap->storage, make the problem easier to trigger. Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2026-43328", "url": "https://ubuntu.com/security/CVE-2026-43328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error path When kobject_init_and_add() fails, cpufreq_dbs_governor_init() calls kobject_put(&dbs_data->attr_set.kobj). The kobject release callback cpufreq_dbs_data_release() calls gov->exit(dbs_data) and kfree(dbs_data), but the current error path then calls gov->exit(dbs_data) and kfree(dbs_data) again, causing a double free. Keep the direct kfree(dbs_data) for the gov->init() failure path, but after kobject_init_and_add() has been called, let kobject_put() handle the cleanup through cpufreq_dbs_data_release().", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-23066", "url": "https://ubuntu.com/security/CVE-2026-23066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recvmsg() unconditional requeue If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at the front of the recvmsg queue already has its mutex locked, it requeues the call - whether or not the call is already queued. The call may be on the queue because MSG_PEEK was also passed and so the call was not dequeued or because the I/O thread requeued it. The unconditional requeue may then corrupt the recvmsg queue, leading to things like UAFs or refcount underruns. Fix this by only requeuing the call if it isn't already on the queue - and moving it to the front if it is already queued. If we don't queue it, we have to put the ref we obtained by dequeuing it. Also, MSG_PEEK doesn't dequeue the call so shouldn't call rxrpc_notify_socket() for the call if we didn't use up all the data on the queue, so fix that also.", "cve_priority": "high", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-27407", "url": "https://ubuntu.com/security/CVE-2024-27407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fixed overflow check in mi_enum_attr()", "cve_priority": "high", "cve_public_date": "2024-05-17 12:15:00 UTC" }, { "cve": "CVE-2023-45896", "url": "https://ubuntu.com/security/CVE-2023-45896", "cve_description": "ntfs3 in the Linux kernel through 6.8.0 allows a physically proximate attacker to read kernel memory by mounting a filesystem (e.g., if a Linux distribution is configured to allow unprivileged mounts of removable media) and then leveraging local access to trigger an out-of-bounds read. A length value can be larger than the amount of memory allocated. NOTE: the supplier's perspective is that there is no vulnerability when an attack requires an attacker-modified filesystem image.", "cve_priority": "medium", "cve_public_date": "2024-08-28 05:15:00 UTC" }, { "cve": "CVE-2023-52737", "url": "https://ubuntu.com/security/CVE-2023-52737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: lock the inode in shared mode before starting fiemap Currently fiemap does not take the inode's lock (VFS lock), it only locks a file range in the inode's io tree. This however can lead to a deadlock if we have a concurrent fsync on the file and fiemap code triggers a fault when accessing the user space buffer with fiemap_fill_next_extent(). The deadlock happens on the inode's i_mmap_lock semaphore, which is taken both by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by syzbot and triggers a trace like the following: task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 wait_on_state fs/btrfs/extent-io-tree.c:707 [inline] wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751 lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742 find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488 writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863 __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174 extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091 extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211 do_writepages+0x3c3/0x680 mm/page-writeback.c:2581 filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388 __filemap_fdatawrite_range mm/filemap.c:421 [inline] filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439 btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline] start_ordered_ops fs/btrfs/file.c:1737 [inline] btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839 generic_write_sync include/linux/fs.h:2885 [inline] btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684 call_write_iter include/linux/fs.h:2189 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9 RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006 RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8 INFO: task syz-executor361:5697 blocked for more than 145 seconds. Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095 __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260 btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526 do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947 wp_page_shared+0x15e/0x380 mm/memory.c:3295 handle_pte_fault mm/memory.c:4949 [inline] __handle_mm_fault mm/memory.c:5073 [inline] handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219 do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428 handle_page_fault arch/x86/mm/fault.c:1519 [inline] exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233 Code: 74 0a 89 (...) RSP: 0018:ffffc9000570f330 EFLAGS: 000502 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-05-21 16:15:00 UTC" }, { "cve": "CVE-2025-38626", "url": "https://ubuntu.com/security/CVE-2025-38626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode w/ \"mode=lfs\" mount option, generic/299 will cause system panic as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2835! Call Trace: f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720 The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may trigger foreground gc only if it allocates any physical block, it will be a little bit later when there is multiple threads writing data w/ aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so f2fs_map_blocks() does block allocations aggressively. In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_blocks().", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2024-46770", "url": "https://ubuntu.com/security/CVE-2024-46770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Add netif_device_attach/detach into PF reset flow Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. getting coalesce settings can result in a NULL pointer dereference seen below. Reproduction steps: Once the driver is fully initialized, trigger reset: \t# echo 1 > /sys/class/net//device/reset when reset is in progress try to get coalesce settings using ethtool: \t# ethtool -c BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7 RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice] RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206 RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000 R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40 FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0 Call Trace: ice_get_coalesce+0x17/0x30 [ice] coalesce_prepare_data+0x61/0x80 ethnl_default_doit+0xde/0x340 genl_family_rcv_msg_doit+0xf2/0x150 genl_rcv_msg+0x1b3/0x2c0 netlink_rcv_skb+0x5b/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x19c/0x290 netlink_sendmsg+0x222/0x490 __sys_sendto+0x1df/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7faee60d8e27 Calling netif_device_detach() before reset makes the net core not call the driver when ethtool command is issued, the attempt to execute an ethtool command during reset will result in the following message: netlink error: No such device instead of NULL pointer dereference. Once reset is done and ice_rebuild() is executing, the netif_device_attach() is called to allow for ethtool operations to occur again in a safe manner.", "cve_priority": "medium", "cve_public_date": "2024-09-18 08:15:00 UTC" }, { "cve": "CVE-2025-38105", "url": "https://ubuntu.com/security/CVE-2025-38105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Kill timer properly at removal The USB-audio MIDI code initializes the timer, but in a rare case, the driver might be freed without the disconnect call. This leaves the timer in an active state while the assigned object is released via snd_usbmidi_free(), which ends up with a kernel warning when the debug configuration is enabled, as spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be killed properly. While we're at it, replace the existing timer_delete_sync() at the disconnect callback with timer_shutdown_sync(), too.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2024-27389", "url": "https://ubuntu.com/security/CVE-2024-27389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore: inode: Only d_invalidate() is needed Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning: WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410 Using the combo of d_drop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use d_invalidate() and update the code to not bother checking for error codes that can never happen. ---", "cve_priority": "medium", "cve_public_date": "2024-05-01 13:15:00 UTC" }, { "cve": "CVE-2023-52682", "url": "https://ubuntu.com/security/CVE-2023-52682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait on block writeback for post_read case If inode is compressed, but not encrypted, it missed to call f2fs_wait_on_block_writeback() to wait for GCed page writeback in IPU write path. Thread A\t\t\t\tGC-Thread \t\t\t\t\t- f2fs_gc \t\t\t\t\t - do_garbage_collect \t\t\t\t\t - gc_data_segment \t\t\t\t\t - move_data_block \t\t\t\t\t - f2fs_submit_page_write \t\t\t\t\t migrate normal cluster's block via \t\t\t\t\t meta_inode's page cache - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_submit_page_bio IRQ - f2fs_read_end_io \t\t\t\t\tIRQ \t\t\t\t\told data overrides new data due to \t\t\t\t\tout-of-order GC and common IO. \t\t\t\t\t- f2fs_read_end_io", "cve_priority": "medium", "cve_public_date": "2024-05-17 15:15:00 UTC" }, { "cve": "CVE-2024-56719", "url": "https://ubuntu.com/security/CVE-2024-56719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix TSO DMA API usage causing oops Commit 66600fac7a98 (\"net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data\") moved the assignment of tx_skbuff_dma[]'s members to be later in stmmac_tso_xmit(). The buf (dma cookie) and len stored in this structure are passed to dma_unmap_single() by stmmac_tx_clean(). The DMA API requires that the dma cookie passed to dma_unmap_single() is the same as the value returned from dma_map_single(). However, by moving the assignment later, this is not the case when priv->dma_cap.addr64 > 32 as \"des\" is offset by proto_hdr_len. This causes problems such as: dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed and with DMA_API_DEBUG enabled: DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes] Fix this by maintaining \"des\" as the original DMA cookie, and use tso_des to pass the offset DMA cookie to stmmac_tso_allocator(). Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/", "cve_priority": "medium", "cve_public_date": "2024-12-29 09:15:00 UTC" }, { "cve": "CVE-2024-41079", "url": "https://ubuntu.com/security/CVE-2024-41079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: always initialize cqe.result The spec doesn't mandate that the first two double words (aka results) for the command queue entry need to be set to 0 when they are not used (not specified). Though, the target implemention returns 0 for TCP and FC but not for RDMA. Let's make RDMA behave the same and thus explicitly initializing the result field. This prevents leaking any data from the stack.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2023-53545", "url": "https://ubuntu.com/security/CVE-2023-53545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: unmap and remove csa_va properly Root PD BO should be reserved before unmap and remove a bo_va from VM otherwise lockdep will complain. v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian) [14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu] [14616.937096] Call Trace: [14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu] [14616.937187] drm_file_free+0x1d6/0x300 [drm] [14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm] [14616.937220] drm_release+0x5e/0x100 [drm] [14616.937234] __fput+0x9f/0x280 [14616.937239] ____fput+0xe/0x20 [14616.937241] task_work_run+0x61/0x90 [14616.937246] exit_to_user_mode_prepare+0x215/0x220 [14616.937251] syscall_exit_to_user_mode+0x2a/0x60 [14616.937254] do_syscall_64+0x48/0x90 [14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd", "cve_priority": "medium", "cve_public_date": "2025-10-04 16:15:00 UTC" }, { "cve": "CVE-2025-68239", "url": "https://ubuntu.com/security/CVE-2025-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: restore write access before closing files opened by open_exec() bm_register_write() opens an executable file using open_exec(), which internally calls do_open_execat() and denies write access on the file to avoid modification while it is being executed. However, when an error occurs, bm_register_write() closes the file using filp_close() directly. This does not restore the write permission, which may cause subsequent write operations on the same file to fail. Fix this by calling exe_file_allow_write_access() before filp_close() to restore the write permission properly.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-38659", "url": "https://ubuntu.com/security/CVE-2025-38659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: No more self recovery When a node withdraws and it turns out that it is the only node that has the filesystem mounted, gfs2 currently tries to replay the local journal to bring the filesystem back into a consistent state. Not only is that a very bad idea, it has also never worked because gfs2_recover_func() will refuse to do anything during a withdraw. However, before even getting to this point, gfs2_recover_func() dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free before commit 04133b607a78 (\"gfs2: Prevent double iput for journal on error\") and is a NULL pointer dereference since then. Simply get rid of self recovery to fix that.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2022-49961", "url": "https://ubuntu.com/security/CVE-2022-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg->precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored state. To show a concrete example of the problem: 0000000000000000 : 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 10: r2 = -1 0000000000000058 : 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit 00000000000000b8 : 23: w0 = 0 24: exit For the first case, the single line execution's exploration will prune the search at insn 14 for the branch insn 9's second leg as it will be verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will always be 0 so at runtime we don't get error for being greater than UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just sees reg->precise as false for both r2 registers in both states, hence considers them equal for purposes of states_equal. If we propagated precise markers using the backtracking support, we would use the precise marking to then ensure that old r2 (UINT_MAX) was within the new r2 (1) and this would never be true, so the verification would rightfully fail. The end result is that the out of bounds access at instruction 19 would be permitted without this fix. Note that reg->precise is always set to true when user does not have CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static or global functions)), hence this is only a problem when precision marks need to be explicitly propagated (i.e. privileged users with CAP_BPF). A simplified test case has been included in the next patch to prevent future regressions.", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2024-47809", "url": "https://ubuntu.com/security/CVE-2024-47809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix possible lkb_resource null dereference This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded. The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference. In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.", "cve_priority": "medium", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2025-38250", "url": "https://ubuntu.com/security/CVE-2025-38250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix use-after-free in vhci_flush() syzbot reported use-after-free in vhci_flush() without repro. [0] From the splat, a thread close()d a vhci file descriptor while its device was being used by iotcl() on another thread. Once the last fd refcnt is released, vhci_release() calls hci_unregister_dev(), hci_free_dev(), and kfree() for struct vhci_data, which is set to hci_dev->dev->driver_data. The problem is that there is no synchronisation after unlinking hdev from hci_dev_list in hci_unregister_dev(). There might be another thread still accessing the hdev which was fetched before the unlink operation. We can use SRCU for such synchronisation. Let's run hci_dev_reset() under SRCU and wait for its completion in hci_unregister_dev(). Another option would be to restore hci_dev->destruct(), which was removed in commit 587ae086f6e4 (\"Bluetooth: Remove unused hci-destruct cb\"). However, this would not be a good solution, as we should not run hci_unregister_dev() while there are in-flight ioctl() requests, which could lead to another data-race KCSAN splat. Note that other drivers seem to have the same problem, for exmaple, virtbt_remove(). [0]: BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718 CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name ---truncated---", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2026-43281", "url": "https://ubuntu.com/security/CVE-2026-43281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate() Although it is guided that `#mbox-cells` must be at least 1, there are many instances of `#mbox-cells = <0>;` in the device tree. If that is the case and the corresponding mailbox controller does not provide `fw_xlate` and of_xlate` function pointers, `fw_mbox_index_xlate()` will be used by default and out-of-bounds accesses could occur due to lack of bounds check in that function.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23157", "url": "https://ubuntu.com/security/CVE-2026-23157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not strictly require dirty metadata threshold for metadata writepages [BUG] There is an internal report that over 1000 processes are waiting at the io_schedule_timeout() of balance_dirty_pages(), causing a system hang and trigger a kernel coredump. The kernel is v6.4 kernel based, but the root problem still applies to any upstream kernel before v6.18. [CAUSE] From Jan Kara for his wisdom on the dirty page balance behavior first. This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB. Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there's dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying. When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit. So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in that cgroup. So that means the only way to reduce the dirty pages of that cgroup is to writeback the dirty pages of btrfs btree inode, and only after that those processes can exit balance_dirty_pages(). Now back to the btrfs part, btree_writepages() is responsible for writing back dirty btree inode pages. The problem here is, there is a btrfs internal threshold that if the btree inode's dirty bytes are below the 32M threshold, it will not do any writeback. This behavior is to batch as much metadata as possible so we won't write back those tree blocks and then later re-COW them again for another modification. This internal 32MiB is higher than the existing dirty page size (28MiB), meaning no writeback will happen, causing a deadlock between btrfs and cgroup: - Btrfs doesn't want to write back btree inode until more dirty pages - Cgroup/MM doesn't want more dirty pages for btrfs btree inode Thus any process touching that btree inode is put into sleep until the number of dirty pages is reduced. Thanks Jan Kara a lot for the analysis of the root cause. [ENHANCEMENT] Since kernel commit b55102826d7d (\"btrfs: set AS_KERNEL_FILE on the btree_inode\"), btrfs btree inode pages will only be charged to the root cgroup which should have a much larger limit than btrfs' 32MiB threshold. So it should not affect newer kernels. But for all current LTS kernels, they are all affected by this problem, and backporting the whole AS_KERNEL_FILE may not be a good idea. Even for newer kernels I still think it's a good idea to get rid of the internal threshold at btree_writepages(), since for most cases cgroup/MM has a better view of full system memory usage than btrfs' fixed threshold. For internal callers using btrfs_btree_balance_dirty() since that function is already doing internal threshold check, we don't need to bother them. But for external callers of btree_writepages(), just respect their requests and write back whatever they want, ignoring the internal btrfs threshold to avoid such deadlock on btree inode dirty page balancing.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23141", "url": "https://ubuntu.com/security/CVE-2026-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: check for inline extents in range_is_hole_in_parent() Before accessing the disk_bytenr field of a file extent item we need to check if we are dealing with an inline extent. This is because for inline extents their data starts at the offset of the disk_bytenr field. So accessing the disk_bytenr means we are accessing inline data or in case the inline data is less than 8 bytes we can actually cause an invalid memory access if this inline extent item is the first item in the leaf or access metadata from other items.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-40005", "url": "https://ubuntu.com/security/CVE-2025-40005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: Implement refcount to handle unbind during busy driver support indirect read and indirect write operation with assumption no force device removal(unbind) operation. However force device removal(removal) is still available to root superuser. Unbinding driver during operation causes kernel crash. This changes ensure driver able to handle such operation for indirect read and indirect write by implementing refcount to track attached devices to the controller and gracefully wait and until attached devices remove operation completed before proceed with removal operation.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2023-53629", "url": "https://ubuntu.com/security/CVE-2023-53629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: dlm: fix use after free in midcomms commit While working on processing dlm message in softirq context I experienced the following KASAN use-after-free warning: [ 151.760477] ================================================================== [ 151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347 [ 151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828 [ 151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014 [ 151.768726] Call Trace: [ 151.769277] [ 151.769748] dump_stack_lvl+0x5b/0x86 [ 151.770556] print_report+0x180/0x4c8 [ 151.771378] ? kasan_complete_mode_report_info+0x7c/0x1e0 [ 151.772241] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.773069] kasan_report+0x93/0x1a0 [ 151.773668] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.774514] __asan_load4+0x7e/0xa0 [ 151.775089] dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.775890] ? create_message.isra.29.constprop.64+0x57/0xc0 [ 151.776770] send_common+0x19f/0x1b0 [ 151.777342] ? remove_from_waiters+0x60/0x60 [ 151.778017] ? lock_downgrade+0x410/0x410 [ 151.778648] ? __this_cpu_preempt_check+0x13/0x20 [ 151.779421] ? rcu_lockdep_current_cpu_online+0x88/0xc0 [ 151.780292] _convert_lock+0x46/0x150 [ 151.780893] convert_lock+0x7b/0xc0 [ 151.781459] dlm_lock+0x3ac/0x580 [ 151.781993] ? 0xffffffffc0540000 [ 151.782522] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.783379] ? dlm_scan_rsbs+0xa70/0xa70 [ 151.784003] ? preempt_count_sub+0xd6/0x130 [ 151.784661] ? is_module_address+0x47/0x70 [ 151.785309] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.786166] ? 0xffffffffc0540000 [ 151.786693] ? lockdep_init_map_type+0xc3/0x360 [ 151.787414] ? 0xffffffffc0540000 [ 151.787947] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.789004] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.789858] ? 0xffffffffc0540000 [ 151.790392] ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture] [ 151.791347] ? delay_tsc+0x94/0xc0 [ 151.791898] torture_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.792735] ? torture_start+0x30/0x30 [dlm_locktorture] [ 151.793606] lock_torture+0x177/0x270 [dlm_locktorture] [ 151.794448] ? torture_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture] [ 151.795539] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.796476] ? do_raw_spin_lock+0x11e/0x1e0 [ 151.797152] ? mark_held_locks+0x34/0xb0 [ 151.797784] ? _raw_spin_unlock_irqrestore+0x30/0x70 [ 151.798581] ? __kthread_parkme+0x79/0x110 [ 151.799246] ? trace_preempt_on+0x2a/0xf0 [ 151.799902] ? __kthread_parkme+0x79/0x110 [ 151.800579] ? preempt_count_sub+0xd6/0x130 [ 151.801271] ? __kasan_check_read+0x11/0x20 [ 151.801963] ? __kthread_parkme+0xec/0x110 [ 151.802630] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.803569] kthread+0x192/0x1d0 [ 151.804104] ? kthread_complete_and_exit+0x30/0x30 [ 151.804881] ret_from_fork+0x1f/0x30 [ 151.805480] [ 151.806111] Allocated by task 1347: [ 151.806681] kasan_save_stack+0x26/0x50 [ 151.807308] kasan_set_track+0x25/0x30 [ 151.807920] kasan_save_alloc_info+0x1e/0x30 [ 151.808609] __kasan_slab_alloc+0x63/0x80 [ 151.809263] kmem_cache_alloc+0x1ad/0x830 [ 151.809916] dlm_allocate_mhandle+0x17/0x20 [ 151.810590] dlm_midcomms_get_mhandle+0x96/0x260 [ 151.811344] _create_message+0x95/0x180 [ 151.811994] create_message.isra.29.constprop.64+0x57/0xc0 [ 151.812880] send_common+0x129/0x1b0 [ 151.813467] _convert_lock+0x46/0x150 [ 151.814074] convert_lock+0x7b/0xc0 [ 151.814648] dlm_lock+0x3ac/0x580 [ 151.815199] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.816258] torture_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.817129] lock_t ---truncated---", "cve_priority": "high", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2025-71221", "url": "https://ubuntu.com/security/CVE-2025-71221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue() Add proper locking in mmp_pdma_residue() to prevent use-after-free when accessing descriptor list and descriptor contents. The race occurs when multiple threads call tx_status() while the tasklet on another CPU is freeing completed descriptors: CPU 0 CPU 1 ----- ----- mmp_pdma_tx_status() mmp_pdma_residue() -> NO LOCK held list_for_each_entry(sw, ..) DMA interrupt dma_do_tasklet() -> spin_lock(&desc_lock) list_move(sw->node, ...) spin_unlock(&desc_lock) | dma_pool_free(sw) <- FREED! -> access sw->desc <- UAF! This issue can be reproduced when running dmatest on the same channel with multiple threads (threads_per_chan > 1). Fix by protecting the chain_running list iteration and descriptor access with the chan->desc_lock spinlock.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23204", "url": "https://ubuntu.com/security/CVE-2026-23204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: use skb_header_pointer_careful() skb_header_pointer() does not fully validate negative @offset values. Use skb_header_pointer_careful() instead. GangMin Kim provided a report and a repro fooling u32_classify(): BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0 net/sched/cls_u32.c:221", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-71161", "url": "https://ubuntu.com/security/CVE-2025-71161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: disable recursive forward error correction There are two problems with the recursive correction: 1. It may cause denial-of-service. In fec_read_bufs, there is a loop that has 253 iterations. For each iteration, we may call verity_hash_for_block recursively. There is a limit of 4 nested recursions - that means that there may be at most 253^4 (4 billion) iterations. Red Hat QE team actually created an image that pushes dm-verity to this limit - and this image just makes the udev-worker process get stuck in the 'D' state. 2. It doesn't work. In fec_read_bufs we store data into the variable \"fio->bufs\", but fio bufs is shared between recursive invocations, if \"verity_hash_for_block\" invoked correction recursively, it would overwrite partially filled fio->bufs.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2022-50552", "url": "https://ubuntu.com/security/CVE-2022-50552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: use quiesced elevator switch when reinitializing queues The hctx's run_work may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally. nvme nvme0: resetting controller nvme nvme0: 32/0/0 default/read/poll queues BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:kyber_has_work+0x29/0x70 ... Call Trace: __blk_mq_do_dispatch_sched+0x83/0x2b0 __blk_mq_sched_dispatch_requests+0x12e/0x170 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x2b/0x50 process_one_work+0x1ef/0x380 worker_thread+0x2d/0x3e0", "cve_priority": "low", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2024-36922", "url": "https://ubuntu.com/security/CVE-2024-36922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: read txq->read_ptr under lock If we read txq->read_ptr without lock, we can read the same value twice, then obtain the lock, and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in the WARN_ONCE() a little later. Fix that by reading txq->read_ptr under lock.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2024-53221", "url": "https://ubuntu.com/security/CVE-2024-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix null-ptr-deref in f2fs_submit_page_bio() There's issue as follows when concurrently installing the f2fs.ko module and mounting the f2fs file system: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs] Call Trace: f2fs_submit_page_bio+0x126/0x8b0 [f2fs] __get_meta_page+0x1d4/0x920 [f2fs] get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs] validate_checkpoint+0xac/0x290 [f2fs] f2fs_get_valid_checkpoint+0x207/0x950 [f2fs] f2fs_fill_super+0x1007/0x39b0 [f2fs] mount_bdev+0x183/0x250 legacy_get_tree+0xf4/0x1e0 vfs_get_tree+0x88/0x340 do_new_mount+0x283/0x5e0 path_mount+0x2b2/0x15b0 __x64_sys_mount+0x1fe/0x270 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Above issue happens as the biset of the f2fs file system is not initialized before register \"f2fs_fs_type\". To address above issue just register \"f2fs_fs_type\" at the last in init_f2fs_fs(). Ensure that all f2fs file system resources are initialized.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-56657", "url": "https://ubuntu.com/security/CVE-2024-56657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Avoid WARN() for symlink errors Using WARN() for showing the error of symlink creations don't give more information than telling that something goes wrong, since the usual code path is a lregister callback from each control element creation. More badly, the use of WARN() rather confuses fuzzer as if it were serious issues. This patch downgrades the warning messages to use the normal dev_err() instead of WARN(). For making it clearer, add the function name to the prefix, too.", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2022-49803", "url": "https://ubuntu.com/security/CVE-2022-49803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Fix memory leak of nsim_dev->fa_cookie kmemleak reports this issue: unreferenced object 0xffff8881bac872d0 (size 8): comm \"sh\", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie .. nsim_drv_remove() The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To fix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove().", "cve_priority": "medium", "cve_public_date": "2025-05-01 15:16:00 UTC" }, { "cve": "CVE-2022-50116", "url": "https://ubuntu.com/security/CVE-2022-50116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix deadlock and link starvation in outgoing data path The current implementation queues up new control and user packets as needed and processes this queue down to the ldisc in the same code path. That means that the upper and the lower layer are hard coupled in the code. Due to this deadlocks can happen as seen below while transmitting data, especially during ldisc congestion. Furthermore, the data channels starve the control channel on high transmission load on the ldisc. Introduce an additional control channel data queue to prevent timeouts and link hangups during ldisc congestion. This is being processed before the user channel data queue in gsm_data_kick(), i.e. with the highest priority. Put the queue to ldisc data path into a workqueue and trigger it whenever new data has been put into the transmission queue. Change gsm_dlci_data_sweep() accordingly to fill up the transmission queue until TX_THRESH_HI. This solves the locking issue, keeps latency low and provides good performance on high data load. Note that now all packets from a DLCI are removed from the internal queue if the associated DLCI was closed. This ensures that no data is sent by the introduced write task to an already closed DLCI. BUG: spinlock recursion on CPU#0, test_v24_loop/124 lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0 CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x34/0x44 do_raw_spin_lock+0x76/0xa0 _raw_spin_lock_irqsave+0x72/0x80 uart_write_room+0x3b/0xc0 gsm_data_kick+0x14b/0x240 [n_gsm] gsmld_write_wakeup+0x35/0x70 [n_gsm] tty_wakeup+0x53/0x60 tty_port_default_wakeup+0x1b/0x30 serial8250_tx_chars+0x12f/0x220 serial8250_handle_irq.part.0+0xfe/0x150 serial8250_default_handle_irq+0x48/0x80 serial8250_interrupt+0x56/0xa0 __handle_irq_event_percpu+0x78/0x1f0 handle_irq_event+0x34/0x70 handle_fasteoi_irq+0x90/0x1e0 __common_interrupt+0x69/0x100 common_interrupt+0x48/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:__do_softirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00 RSP: 0018:ffffc90000003f98 EFLAGS: 00000286 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7 RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? __do_softirq+0x73/0x34e irq_exit_rcu+0xb5/0x100 common_interrupt+0xa4/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50 Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 3d 97 33 ff 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44 RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? _raw_spin_unlock_irqrestore+0x23/0x50 gsmtty_write+0x65/0x80 [n_gsm] n_tty_write+0x33f/0x530 ? swake_up_all+0xe0/0xe0 file_tty_write.constprop.0+0x1b1/0x320 ? n_tty_flush_buffer+0xb0/0xb0 new_sync_write+0x10c/0x190 vfs_write+0x282/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f3e5e35c15c Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2026-31586", "url": "https://ubuntu.com/security/CVE-2026-31586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: blk-cgroup: fix use-after-free in cgwb_release_workfn() cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) ** Stack based on commit 66672af7a095 (\"Add linux-next specific files for 20260410\") I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh (The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.) Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31598", "url": "https://ubuntu.com/security/CVE-2026-31598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible deadlock between unlink and dio_end_io_write ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key. Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir \t ocfs2_expand_inline_dir \t down_write(&oi->ip_alloc_sem) <- Lock B Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode) Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31642", "url": "https://ubuntu.com/security/CVE-2026-31642", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call removal to use RCU safe deletion Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop. This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by: Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that. rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31664", "url": "https://ubuntu.com/security/CVE-2026-31664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear trailing padding in build_polexpire() build_expire() clears the trailing padding bytes of struct xfrm_user_expire after setting the hard field via memset_after(), but the analogous function build_polexpire() does not do this for struct xfrm_user_polexpire. The padding bytes after the __u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners, leaking kernel heap memory contents. Add the missing memset_after() call, matching build_expire().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43075", "url": "https://ubuntu.com/security/CVE-2026-43075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix out-of-bounds write in ocfs2_write_end_inline KASAN reports a use-after-free write of 4086 bytes in ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF. The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk id_count field to determine whether a write fits in inline data. On a corrupted filesystem, id_count can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer. Call trace (crash path): vfs_copy_file_range (fs/read_write.c:1634) do_splice_direct splice_direct_to_actor iter_file_splice_write ocfs2_file_write_iter generic_perform_write ocfs2_write_end ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949) ocfs2_write_end_inline (fs/ocfs2/aops.c:1915) memcpy_from_folio <-- KASAN: write OOB So add id_count upper bound check in ocfs2_validate_inode_block() to alongside the existing i_size check to fix it.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43076", "url": "https://ubuntu.com/security/CVE-2026-43076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate inline data i_size during inode read When reading an inode from disk, ocfs2_validate_inode_block() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's i_size can exceed the actual inline data capacity (id_count). This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory. In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry() Fix by adding a validation check in ocfs2_validate_inode_block() to ensure inodes with inline data have i_size <= id_count. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-23444", "url": "https://ubuntu.com/security/CVE-2026-23444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do. Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free. Document the skb ownership guarantee in the function's kdoc.", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2025-38710", "url": "https://ubuntu.com/security/CVE-2025-38710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Validate i_depth for exhash directories A fuzzer test introduced corruption that ends up with a depth of 0 in dir_e_read(), causing an undefined shift by 32 at: index = hash >> (32 - dip->i_depth); As calculated in an open-coded way in dir_make_exhash(), the minimum depth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 is invalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time. So we can avoid the undefined behaviour by checking for depth values lower than the minimum in gfs2_dinode_in(). Values greater than the maximum are already being checked for there. Also switch the calculation in dir_make_exhash() to use ilog2() to clarify how the depth is calculated. Tested with the syzkaller repro.c and xfstests '-g quick'.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2026-23442", "url": "https://ubuntu.com/security/CVE-2026-23442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: add NULL checks for idev in SRv6 paths __in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER). Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31594", "url": "https://ubuntu.com/security/CVE-2026-31594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to perform later. This leads to an oops when .allow_link fails or when .drop_link is performed. The following is an example oops of the former case: Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pci_epc_remove_epf+0x78/0xe0 (P) pci_primary_epc_epf_link+0x88/0xa8 configfs_symlink+0x1f4/0x5a0 vfs_symlink+0x134/0x1d8 do_symlinkat+0x88/0x138 __arm64_sys_symlinkat+0x74/0xe0 [...] Remove the helper, and drop pci_epc_put(). EPC device refcounting is tied to the configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2022-50073", "url": "https://ubuntu.com/security/CVE-2022-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null Fixes a NULL pointer derefence bug triggered from tap driver. When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null (in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb) virtio_net_hdr_to_skb calls dev_parse_header_protocol which needs skb->dev field to be valid. The line that trigers the bug is in dev_parse_header_protocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->header_ops || !dev->header_ops->parse_protocol) 22e1: mov 0x10(%rbx),%rax 22e5:\t mov 0x230(%rax),%rax Setting skb->dev before the call in tap.c fixes the issue. BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tap_get_user+0x3f1/0x540 [tap] tap_sendmsg+0x56/0x362 [tap] ? get_tx_bufs+0xc2/0x1e0 [vhost_net] handle_tx_copy+0x114/0x670 [vhost_net] handle_tx+0xb0/0xe0 [vhost_net] handle_tx_kick+0x15/0x20 [vhost_net] vhost_worker+0x7b/0xc0 [vhost] ? vhost_vring_call_reset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2026-31576", "url": "https://ubuntu.com/security/CVE-2026-31576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: hackrf: fix to not free memory after the device is registered in hackrf_probe() In hackrf driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open hackrf fd \t\t\t\t\t\t.... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... \t\t\t\t\t\tsys_ioctl(fd, ...); \t\t\t\t\t\t v4l2_ioctl(); \t\t\t\t\t\t video_is_registered() // UAF!! \t\t\t\t\t\t.... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t v4l2_release() // UAF!! \t\t\t\t\t\t hackrf_video_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked. However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver's release() is invoked. Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven't been released yet. And since release() free memory too, race to use-after-free and double-free vuln occur. To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43058", "url": "https://ubuntu.com/security/CVE-2026-43058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix pass-by-value structs causing MSAN warnings vidtv_ts_null_write_into() and vidtv_ts_pcr_write_into() take their argument structs by value, causing MSAN to report uninit-value warnings. While only vidtv_ts_null_write_into() has triggered a report so far, both functions share the same issue. Fix by passing both structs by const pointer instead, avoiding the stack copy of the struct along with its MSAN shadow and origin metadata. The functions do not modify the structs, which is enforced by the const qualifier.", "cve_priority": "medium", "cve_public_date": "2026-05-02 07:16:00 UTC" }, { "cve": "CVE-2026-31577", "url": "https://ubuntu.com/security/CVE-2026-31577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map The DAT inode's btree node cache (i_assoc_inode) is initialized lazily during btree operations. However, nilfs_mdt_save_to_shadow_map() assumes i_assoc_inode is already initialized when copying dirty pages to the shadow map during GC. If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before any btree operation has occurred on the DAT inode, i_assoc_inode is NULL leading to a general protection fault. Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always initialized before any GC operation can use it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31578", "url": "https://ubuntu.com/security/CVE-2026-31578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: as102: fix to not free memory after the device is registered in as102_usb_probe() In as102_usb driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open as102 fd \t\t\t\t\t\t.... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t as102_release() // UAF!! \t\t\t\t\t\t as102_usb_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a USB character device registered with usb_register_dev() is later unregistered (via usb_deregister_dev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked. In as102, as102_usb_probe() calls usb_register_dev() and then, on an error path, does usb_deregister_dev() and frees as102_dev_t right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102_release() --> as102_usb_release() and access or free as102_dev_t again, occur a race to use-after-free and double-free vuln. The fix is to never kfree(as102_dev_t) directly once usb_register_dev() has succeeded. After deregistration, defer freeing memory to .release(). In other words, let release() perform the last kfree when the final open FD is closed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31580", "url": "https://ubuntu.com/security/CVE-2026-31580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bcache: fix cached_dev.sb_bio use-after-free and crash In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention: ``` [6888366.280350] Call Trace: [6888366.280452] blk_update_request+0x14e/0x370 [6888366.280561] blk_mq_end_request+0x1a/0x130 [6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd] [6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd] [6888366.280903] __complete_request+0x22/0x70 [libceph] [6888366.281032] osd_dispatch+0x15e/0xb40 [libceph] [6888366.281164] ? inet_recvmsg+0x5b/0xd0 [6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph] [6888366.281405] ceph_con_process_message+0x79/0x140 [libceph] [6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph] [6888366.281661] ceph_con_workfn+0x329/0x680 [libceph] ``` After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped. Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio. This patch hopes to wait for sb_write to complete in cached_dev_free. It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31581", "url": "https://ubuntu.com/security/CVE-2026-31581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: fix use-after-free on disconnect In usb6fire_chip_abort(), the chip struct is allocated as the card's private data (via snd_card_new with sizeof(struct sfire_chip)). When snd_card_free_when_closed() is called and no file handles are open, the card and embedded chip are freed synchronously. The subsequent chip->card = NULL write then hits freed slab memory. Call trace: usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline] usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953 Fix by moving the card lifecycle out of usb6fire_chip_abort() and into usb6fire_chip_disconnect(). The card pointer is saved in a local before any teardown, snd_card_disconnect() is called first to prevent new opens, URBs are aborted while chip is still valid, and snd_card_free_when_closed() is called last so chip is never accessed after the card may be freed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31583", "url": "https://ubuntu.com/security/CVE-2026-31583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free in em28xx_v4l2_open() em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock, creating a race with em28xx_v4l2_init()'s error path and em28xx_v4l2_fini(), both of which free the em28xx_v4l2 struct and set dev->v4l2 to NULL under dev->lock. This race leads to two issues: - use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler, since the video_device is embedded in the freed em28xx_v4l2 struct. - NULL pointer dereference in em28xx_resolution_set() when accessing v4l2->norm, since dev->v4l2 has been set to NULL. Fix this by moving the mutex_lock() before the dev->v4l2 read and adding a NULL check for dev->v4l2 under the lock.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31585", "url": "https://ubuntu.com/security/CVE-2026-31585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix nfeeds state corruption on start_streaming failure syzbot reported a memory leak in vidtv_psi_service_desc_init [1]. When vidtv_start_streaming() fails inside vidtv_start_feed(), the nfeeds counter is left incremented even though no feed was actually started. This corrupts the driver state: subsequent start_feed calls see nfeeds > 1 and skip starting the mux, while stop_feed calls eventually try to stop a non-existent stream. This state corruption can also lead to memory leaks, since the mux and channel resources may be partially allocated during a failed start_streaming but never cleaned up, as the stop path finds dvb->streaming == false and returns early. Fix by decrementing nfeeds back when start_streaming fails, keeping the counter in sync with the actual number of active feeds. [1] BUG: memory leak unreferenced object 0xffff888145b50820 (size 32): comm \"syz.0.17\", pid 6068, jiffies 4294944486 backtrace (crc 90a0c7d4): vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31686", "url": "https://ubuntu.com/security/CVE-2026-31686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/kasan: fix double free for kasan pXds kasan_free_pxd() assumes the page table is always struct page aligned. But that's not always the case for all architectures. E.g. In case of powerpc with 64K pagesize, PUD table (of size 4096) comes from slab cache named pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's just directly pass the start of the pxd table which is passed as the 1st argument. This fixes the below double free kasan issue seen with PMEM: radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages ================================================================== BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20 Free of addr c0000003c38e0000 by task ndctl/2164 CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeries Call Trace: dump_stack_lvl+0x88/0xc4 (unreliable) print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140 kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec ---- interrupt: 3000 at 0x7fff93b3d3f4 NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000 REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392) MSR: 800000000280f033 CR: 48888208 XER: 00000000 <...> NIP [00007fff93b3d3f4] 0x7fff93b3d3f4 LR [00007fff93b3d3f4] 0x7fff93b3d3f4 ---- interrupt: 3000 The buggy address belongs to the object at c0000003c38e0000 which belongs to the cache pgtable-2^9 of size 4096 The buggy address is located 0 bytes inside of 4096-byte region [c0000003c38e0000, c0000003c38e1000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:c0000003bfd63e01 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) page_type: f5(slab) raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected [ 138.953636] [ T2164] Memory state around the buggy address: [ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953669] [ T2164] ^ [ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953692] [ T2164] ================================================================== [ 138.953701] [ T2164] Disabling lock debugging due to kernel taint", "cve_priority": "low", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2026-31588", "url": "https://ubuntu.com/security/CVE-2026-31588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use scratch field in MMIO fragment to hold small write values When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value. This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, *and* both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable. The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by overwrite the data value with garbage. Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *al ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31630", "url": "https://ubuntu.com/security/CVE-2026-31630", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: proc: size address buffers for %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with \"%pISpc\". That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23399", "url": "https://ubuntu.com/security/CVE-2026-23399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nf_tables: nft_dynset: fix possible stateful expression memleak in error path If cloning the second stateful expression in the element via GFP_ATOMIC fails, then the first stateful expression remains in place without being released.   unreferenced object (percpu) 0x607b97e9cab8 (size 16):     comm \"softirq\", pid 0, jiffies 4294931867     hex dump (first 16 bytes on cpu 3):       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     backtrace (crc 0):       pcpu_alloc_noprof+0x453/0xd80       nft_counter_clone+0x9c/0x190 [nf_tables]       nft_expr_clone+0x8f/0x1b0 [nf_tables]       nft_dynset_new+0x2cb/0x5f0 [nf_tables]       nft_rhash_update+0x236/0x11c0 [nf_tables]       nft_dynset_eval+0x11f/0x670 [nf_tables]       nft_do_chain+0x253/0x1700 [nf_tables]       nft_do_chain_ipv4+0x18d/0x270 [nf_tables]       nf_hook_slow+0xaa/0x1e0       ip_local_deliver+0x209/0x330", "cve_priority": "medium", "cve_public_date": "2026-03-28 08:15:00 UTC" }, { "cve": "CVE-2024-35865", "url": "https://ubuntu.com/security/CVE-2024-35865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.", "cve_priority": "medium", "cve_public_date": "2024-05-19 09:15:00 UTC" }, { "cve": "CVE-2026-31590", "url": "https://ubuntu.com/security/CVE-2026-31590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION Drop the WARN in sev_pin_memory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing: struct kvm_enc_region range = { .addr = 0, .size = -1ul, }; __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range); Note, the checks in sev_mem_enc_register_region() that presumably exist to verify the incoming address+size are completely worthless, as both \"addr\" and \"size\" are u64s and SEV is 64-bit only, i.e. they _can't_ be greater than ULONG_MAX. That wart will be cleaned up in the near future. \tif (range->addr > ULONG_MAX || range->size > ULONG_MAX) \t\treturn -EINVAL; Opportunistically add a comment to explain why the code calculates the number of pages the \"hard\" way, e.g. instead of just shifting @ulen.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31596", "url": "https://ubuntu.com/security/CVE-2026-31596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle invalid dinode in ocfs2_group_extend [BUG] kernel BUG at fs/ocfs2/resize.c:308! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308 Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe Call Trace: ... ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... [CAUSE] ocfs2_group_extend() assumes that the global bitmap inode block returned from ocfs2_inode_lock() has already been validated and BUG_ONs when the signature is not a dinode. That assumption is too strong for crafted filesystems because the JBD2-managed buffer path can bypass structural validation and return an invalid dinode to the resize ioctl. [FIX] Validate the dinode explicitly in ocfs2_group_extend(). If the global bitmap buffer does not contain a valid dinode, report filesystem corruption with ocfs2_error() and fail the resize operation instead of crashing the kernel.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31597", "url": "https://ubuntu.com/security/CVE-2026-31597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY, as documented in mm/filemap.c: \"If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap().\" When this happens, a concurrent munmap() can call remove_vma() and free the vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call dereferences it -- a use-after-free. Fix this by saving ip_blkno as a plain integer before calling filemap_fault(), and removing vma from the trace event. Since ip_blkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31599", "url": "https://ubuntu.com/security/CVE-2026-31599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections syzbot reported a general protection fault in vidtv_psi_desc_assign [1]. vidtv_psi_pmt_stream_init() can return NULL on memory allocation failure, but vidtv_channel_pmt_match_sections() does not check for this. When tail is NULL, the subsequent call to vidtv_psi_desc_assign(&tail->descriptor, desc) dereferences a NULL pointer offset, causing a general protection fault. Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean up the already-allocated stream chain and return. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629 Call Trace: vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline] vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479 vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31602", "url": "https://ubuntu.com/security/CVE-2026-31602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Limit PTP to a single page Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic. ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ct_vm_map() tries to access beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count remain unchanged.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31603", "url": "https://ubuntu.com/security/CVE-2026-31603", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: sm750fb: fix division by zero in ps_to_hz() ps_to_hz() is called from hw_sm750_crtc_set_mode() without validating that pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO causes a division by zero. Fix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent with other framebuffer drivers.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31605", "url": "https://ubuntu.com/security/CVE-2026-31605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31615", "url": "https://ubuntu.com/security/CVE-2026-31615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: renesas_usb3: validate endpoint index in standard request handlers The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math. This is just like what was done in commit ee0d382feb44 (\"usb: gadget: aspeed_udc: validate endpoint index for ast udc\") for the aspeed driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31616", "url": "https://ubuntu.com/security/CVE-2026-31616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete() A broken/bored/mean USB host can overflow the skb_shared_info->frags[] array on a Linux gadget exposing a Phonet function by sending an unbounded sequence of full-page OUT transfers. pn_rx_complete() finalizes the skb only when req->actual < req->length, where req->length is set to PAGE_SIZE by the gadget. If the host always sends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never be reset and each completion will add another fragment via skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17), subsequent frag stores overwrite memory adjacent to the shinfo on the heap. Drop the skb and account a length error when the frag limit is reached, matching the fix applied in t7xx by commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\").", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31617", "url": "https://ubuntu.com/security/CVE-2026-31617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb() The block_len read from the host-supplied NTB header is checked against ntb_max but has no lower bound. When block_len is smaller than opts->ndp_size, the bounds check of: \tndp_index > (block_len - opts->ndp_size) will underflow producing a huge unsigned value that ndp_index can never exceed, defeating the check entirely. The same underflow occurs in the datagram index checks against block_len - opts->dpe_size. With those checks neutered, a malicious USB host can choose ndp_index and datagram offsets that point past the actual transfer, and the skb_put_data() copies adjacent kernel memory into the network skb. Fix this by rejecting block lengths that cannot hold at least the NTB header plus one NDP. This will make block_len - opts->ndp_size and block_len - opts->dpe_size both well-defined. Commit 8d2b1a1ec9f5 (\"CDC-NCM: avoid overflow in sanity checking\") fixed a related class of issues on the host side of NCM.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31618", "url": "https://ubuntu.com/security/CVE-2026-31618", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31619", "url": "https://ubuntu.com/security/CVE-2026-31619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: fireworks: bound device-supplied status before string array lookup The status field in an EFW response is a 32-bit value supplied by the firewire device. efr_status_names[] has 17 entries so a status value outside that range goes off into the weeds when looking at the %s value. Even worse, the status could return EFR_STATUS_INCOMPLETE which is 0x80000000, and is obviously not in that array of potential strings. Fix this up by properly bounding the index against the array size and printing \"unknown\" if it's not recognized.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31622", "url": "https://ubuntu.com/security/CVE-2026-31622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: digital: Bounds check NFC-A cascade depth in SDD response handler The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3 or 4 bytes to target->nfcid1 on each round, but the number of cascade rounds is controlled entirely by the peer device. The peer sets the cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the cascade-incomplete bit in the SEL_RES (deciding whether another round follows). ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver actually enforces this. This means a malicious peer can keep the cascade running, writing past the heap-allocated nfc_target with each round. Fix this by rejecting the response when the accumulated UID would exceed the buffer. Commit e329e71013c9 (\"NFC: nci: Bounds check struct nfc_target arrays\") fixed similar missing checks against the same field on the NCI path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31623", "url": "https://ubuntu.com/security/CVE-2026-31623", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete() A malicious USB device claiming to be a CDC Phonet modem can overflow the skb_shared_info->frags[] array by sending an unbounded sequence of full-page bulk transfers. Drop the skb and increment the length error when the frag limit is reached. This matches the same fix that commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\") did for the t7xx driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31624", "url": "https://ubuntu.com/security/CVE-2026-31624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: clamp report_size in s32ton() to avoid undefined shift s32ton() shifts by n-1 where n is the field's report_size, a value that comes directly from a HID device. The HID parser bounds report_size only to <= 256, so a broken HID device can supply a report descriptor with a wide field that triggers shift exponents up to 256 on a 32-bit type when an output report is built via hid_output_field() or hid_set_field(). Commit ec61b41918587 (\"HID: core: fix shift-out-of-bounds in hid_report_raw_event\") added the same n > 32 clamp to the function snto32(), but s32ton() was never given the same fix as I guess syzbot hadn't figured out how to fuzz a device the same way. Fix this up by just clamping the max value of n, just like snto32() does.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31625", "url": "https://ubuntu.com/security/CVE-2026-31625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: alps: fix NULL pointer dereference in alps_raw_event() Commit ecfa6f34492c (\"HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them\") attempted to fix up the HID drivers that had missed the previous fix that was done in 2ff5baa9b527 (\"HID: appleir: Fix potential NULL dereference at raw event handle\"), but the alps driver was missed. Fix this up by properly checking in the hid-alps driver that it had been claimed correctly before attempting to process the raw event.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31626", "url": "https://ubuntu.com/security/CVE-2026-31626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify() Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using uninitialized data. Smatch warns that only 6 bytes are copied to this 8-byte (u64) variable, leaving the last two bytes uninitialized: drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify() warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes) Initializing the variable at the start of the function fixes this warning and ensures predictable behavior.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31627", "url": "https://ubuntu.com/security/CVE-2026-31627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: s3c24xx: check the size of the SMBUS message before using it The first byte of an i2c SMBUS message is the size, and it should be verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX before processing it. This is the same logic that was added in commit a6e04f05ce0b (\"i2c: tegra: check msg length in SMBUS block read\") to the i2c tegra driver.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31532", "url": "https://ubuntu.com/security/CVE-2026-31532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: fix ro->uniq use-after-free in raw_rcv() raw_release() unregisters raw CAN receive filters via can_rx_unregister(), but receiver deletion is deferred with call_rcu(). This leaves a window where raw_rcv() may still be running in an RCU read-side critical section after raw_release() frees ro->uniq, leading to a use-after-free of the percpu uniq storage. Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific socket destructor. can_rx_unregister() takes an extra reference to the socket and only drops it from the RCU callback, so freeing uniq from sk_destruct ensures the percpu area is not released until the relevant callbacks have drained. [mkl: applied manually]", "cve_priority": "high", "cve_public_date": "2026-04-23 12:17:00 UTC" }, { "cve": "CVE-2026-31629", "url": "https://ubuntu.com/security/CVE-2026-31629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: add missing return after LLCP_CLOSED checks In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket state is LLCP_CLOSED, the code correctly calls release_sock() and nfc_llcp_sock_put() but fails to return. Execution falls through to the remainder of the function, which calls release_sock() and nfc_llcp_sock_put() again. This results in a double release_sock() and a refcount underflow via double nfc_llcp_sock_put(), leading to a use-after-free. Add the missing return statements after the LLCP_CLOSED branches in both functions to prevent the fall-through.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31407", "url": "https://ubuntu.com/security/CVE-2026-31407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: add missing netlink policy validations Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink. These attributes are used by the kernel without any validation. Extend the netlink policies accordingly. Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-43079", "url": "https://ubuntu.com/security/CVE-2026-43079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Skip discovery table for offline dies This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0. WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore] Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at \"pmu->boxes[die] = box\" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43080", "url": "https://ubuntu.com/security/CVE-2026-43080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: Drop large packets with UDP encap syzbot reported a WARN on my patch series [1]. The actual issue is an overflow of 16-bit UDP length field, and it exists in the upstream code. My series added a debug WARN with an overflow check that exposed the issue, that's why syzbot tripped on my patches, rather than on upstream code. syzbot's repro: r0 = socket$pppl2tp(0x18, 0x1, 0x1) r1 = socket$inet6_udp(0xa, 0x2, 0x0) connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c) connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\\x00', '\\xff\\xff', @empty}}}}, 0x32) writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)=\"ee\", 0x34000}], 0x1) It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP encapsulation, and l2tp_xmit_core doesn't check for overflows when it assigns the UDP length field. The value gets trimmed to 16 bites. Add an overflow check that drops oversized packets and avoids sending packets with trimmed UDP length to the wire. syzbot's stack trace (with my patch applied): len >= 65536u WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957 Modules linked in: CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline] RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline] RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327 Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f RSP: 0018:ffffc90003d67878 EFLAGS: 00010293 RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000 RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004 R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900 R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000 FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0 Call Trace: pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x503/0x550 net/socket.c:1195 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1 vfs_writev+0x33c/0x990 fs/read_write.c:1059 do_writev+0x154/0x2e0 fs/read_write.c:1105 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f636479c629 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629 RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31673", "url": "https://ubuntu.com/security/CVE-2026-31673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: read UNIX_DIAG_VFS data under unix_state_lock Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unix_release_sock() clears u->path under unix_state_lock() and drops the path reference after unlocking. Read the inode and device numbers for UNIX_DIAG_VFS while holding unix_state_lock(), then emit the netlink attribute after dropping the lock. This keeps the VFS data stable while the reply is being built.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31681", "url": "https://ubuntu.com/security/CVE-2026-31681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_multiport: validate range encoding in checkentry ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end. The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule. Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43085", "url": "https://ubuntu.com/security/CVE-2026-43085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator When batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send() appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSG_DONE message body. Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes the nfgenmsg payload via nfnl_fill_hdr(), consistent with how __build_packet_message() already constructs NFULNL_MSG_PACKET headers.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43089", "url": "https://ubuntu.com/security/CVE-2026-43089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_mapping() struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43093", "url": "https://ubuntu.com/security/CVE-2026-43093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: tighten UMEM headroom validation to account for tailroom and min frame The current headroom validation in xdp_umem_reg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skb_shared_info stored at the end of XSK frame would be corrupted. HW typically works with 128-aligned sizes so let us provide this value as bare minimum. Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43098", "url": "https://ubuntu.com/security/CVE-2026-43098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: s3fwrn5: allocate rx skb before consuming bytes s3fwrn82_uart_read() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already deliver a complete frame before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43099", "url": "https://ubuntu.com/security/CVE-2026-43099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: fix null-ptr-deref in icmp_build_probe() ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing this error pointer to dev_hold() will cause a kernel crash with null-ptr-deref. Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting \"No Such Interface\".", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43103", "url": "https://ubuntu.com/security/CVE-2026-43103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lapbether: handle NETDEV_PRE_TYPE_CHANGE lapbeth_data_transmit() expects the underlying device type to be ARPHRD_ETHER. Returning NOTIFY_BAD from lapbeth_device_event() makes sure bonding driver can not break this expectation.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31684", "url": "https://ubuntu.com/security/CVE-2026-31684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_csum: validate nested VLAN headers tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43074", "url": "https://ubuntu.com/security/CVE-2026-43074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: defer struct eventpoll free to RCU grace period In certain situations, ep_free() in eventpoll.c will kfree the epi->ep eventpoll struct while it still being used by another concurrent thread. Defer the kfree() to an RCU callback to prevent UAF.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43104", "url": "https://ubuntu.com/security/CVE-2026-43104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix a memory leak in hang state error path When vc4_save_hang_state() encounters an early return condition, it returns without freeing the previously allocated `kernel_state`, leaking memory. Add the missing kfree() calls by consolidating the early return paths into a single place.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43105", "url": "https://ubuntu.com/security/CVE-2026-43105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix memory leak of BO array in hang state The hang state's BO array is allocated separately with kzalloc() in vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the missing kfree() for the BO array before freeing the hang state struct.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43110", "url": "https://ubuntu.com/security/CVE-2026-43110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: validate bsscfg indices in IF events brcmf_fweh_handle_if_event() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check. Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array. [add missing wifi prefix]", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43111", "url": "https://ubuntu.com/security/CVE-2026-43111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: fix use-after-free in roccat_report_event roccat_report_event() iterates over the device->readers list without holding the readers_lock. This allows a concurrent roccat_release() to remove and free a reader while it's still being accessed, leading to a use-after-free. Protect the readers list traversal with the readers_lock mutex.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43112", "url": "https://ubuntu.com/security/CVE-2026-43112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath When cifs_sanitize_prepath is called with an empty string or a string containing only delimiters (e.g., \"/\"), the current logic attempts to check *(cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read. This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL. The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.", "cve_priority": "low", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43113", "url": "https://ubuntu.com/security/CVE-2026-43113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wl1251: validate packet IDs before indexing tx_frames wl1251_tx_packet_cb() uses the firmware completion ID directly to index the fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it. Reject completion IDs that fall outside wl->tx_frames[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2025-54518", "url": "https://ubuntu.com/security/CVE-2025-54518", "cve_description": "Improper isolation of shared resources within the CPU operation cache on Zen 2-based products could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation.", "cve_priority": "high", "cve_public_date": "2026-05-15 05:16:00 UTC" }, { "cve": "CVE-2026-46174", "url": "https://ubuntu.com/security/CVE-2026-46174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2025-71150", "url": "https://ubuntu.com/security/CVE-2025-71150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix refcount leak when invalid session is found on session lookup When a session is found but its state is not SMB2_SESSION_VALID, It indicates that no valid session was found, but it is missing to decrement the reference count acquired by the session lookup, which results in a reference count leak. This patch fixes the issue by explicitly calling ksmbd_user_session_put to release the reference to the session.", "cve_priority": "medium", "cve_public_date": "2026-01-23 15:16:00 UTC" }, { "cve": "CVE-2026-23395", "url": "https://ubuntu.com/security/CVE-2026-23395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ Currently the code attempts to accept requests regardless of the command identifier which may cause multiple requests to be marked as pending (FLAG_DEFER_SETUP) which can cause more than L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer causing an overflow. The spec is quite clear that the same identifier shall not be used on subsequent requests: 'Within each signaling channel a different Identifier shall be used for each successive request or indication.' https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d So this attempts to check if there are any channels pending with the same identifier and rejects if any are found.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31549", "url": "https://ubuntu.com/security/CVE-2026-31549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: cp2615: fix serial string NULL-deref at probe The cp2615 driver uses the USB device serial string as the i2c adapter name but does not make sure that the string exists. Verify that the device has a serial number before accessing it to avoid triggering a NULL-pointer dereference (e.g. with malicious devices).", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31433", "url": "https://ubuntu.com/security/CVE-2026-31433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potencial OOB in get_file_all_info() for compound requests When a compound request consists of QUERY_DIRECTORY + QUERY_INFO (FILE_ALL_INFORMATION) and the first command consumes nearly the entire max_trans_size, get_file_all_info() would blindly call smbConvertToUTF16() with PATH_MAX, causing out-of-bounds write beyond the response buffer. In get_file_all_info(), there was a missing validation check for the client-provided OutputBufferLength before copying the filename into FileName field of the smb2_file_all_info structure. If the filename length exceeds the available buffer space, it could lead to potential buffer overflows or memory corruption during smbConvertToUTF16 conversion. This calculating the actual free buffer size using smb2_calc_max_out_buf_len() and returning -EINVAL if the buffer is insufficient and updating smbConvertToUTF16 to use the actual filename length (clamped by PATH_MAX) to ensure a safe copy operation.", "cve_priority": "high", "cve_public_date": "2026-04-22 09:16:00 UTC" }, { "cve": "CVE-2026-31480", "url": "https://ubuntu.com/security/CVE-2026-31480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential deadlock in cpu hotplug with osnoise The following sequence may leads deadlock in cpu hotplug: task1 task2 task3 ----- ----- ----- mutex_lock(&interface_lock) [CPU GOING OFFLINE] cpus_write_lock(); osnoise_cpu_die(); kthread_stop(task3); wait_for_completion(); osnoise_sleep(); mutex_lock(&interface_lock); cpus_read_lock(); [DEAD LOCK] Fix by swap the order of cpus_read_lock() and mutex_lock(&interface_lock).", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31466", "url": "https://ubuntu.com/security/CVE-2026-31466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix folio isn't locked in softleaf_to_folio() On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows: \tCPU0 CPU1 deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags. This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio() because of the race between folio split and zap_nonpresent_ptes() leading to a folio incorrectly undergoing modification without a folio lock being held. This is a BUG_ON() before commit 93976a20345b (\"mm: eliminate further swapops predicates\"), which in merged in v6.19-rc1. To fix it, add missing smp_rmb() if the softleaf entry is migration entry in softleaf_to_folio() and softleaf_to_page(). [tujinjiang@huawei.com: update function name and comments]", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43054", "url": "https://ubuntu.com/security/CVE-2026-43054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Drain commands in target_reset handler tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS without draining any in-flight commands. The SCSI EH documentation (scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver has made lower layers \"forget about timed out scmds\" and is ready for new commands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug, mpi3mr) enforces this by draining or completing outstanding commands before returning SUCCESS. Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight scsi_cmnd structures for recovery commands (e.g. TUR) while the target core still has async completion work queued for the old se_cmd. The memset in queuecommand zeroes se_lun and lun_ref_active, causing transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN reference prevents transport_clear_lun_ref() from completing, hanging configfs LUN unlink forever in D-state: INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transport_clear_lun_ref+0x78/0x90 [target_core_mod] core_tpg_remove_lun+0x28/0xb0 [target_core_mod] target_fabric_port_unlink+0x50/0x60 [target_core_mod] configfs_unlink+0x156/0x1f0 [configfs] vfs_unlink+0x109/0x290 do_unlinkat+0x1d5/0x2d0 Fix this by making tcm_loop_target_reset() actually drain commands: 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that the target core knows about (those not yet CMD_T_COMPLETE). 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and flush_work() on each se_cmd — this drains any deferred completion work for commands that already had CMD_T_COMPLETE set before the TMR (which the TMR skips via __target_check_io_state()). This is the same pattern used by mpi3mr, scsi_debug, and libsas to drain outstanding commands during reset.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-23401", "url": "https://ubuntu.com/security/CVE-2026-23401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE When installing an emulated MMIO SPTE, do so *after* dropping/zapping the existing SPTE (if it's shadow-present). While commit a54aa15c6bda3 was right about it being impossible to convert a shadow-present SPTE to an MMIO SPTE due to a _guest_ write, it failed to account for writes to guest memory that are outside the scope of KVM. E.g. if host userspace modifies a shadowed gPTE to switch from a memslot to emulted MMIO and then the guest hits a relevant page fault, KVM will install the MMIO SPTE without first zapping the shadow-present SPTE. ------------[ cut here ]------------ is_shadow_present_pte(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm] Call Trace: mmu_set_spte+0x237/0x440 [kvm] ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47fa3f ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-04-01 09:16:00 UTC" }, { "cve": "CVE-2026-31454", "url": "https://ubuntu.com/security/CVE-2026-31454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: save ailp before dropping the AIL lock in push callbacks In xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the AIL lock is dropped to perform buffer IO. Once the cluster buffer no longer protects the log item from reclaim, the log item may be freed by background reclaim or the dquot shrinker. The subsequent spin_lock() call dereferences lip->li_ailp, which is a use-after-free. Fix this by saving the ailp pointer in a local variable while the AIL lock is held and the log item is guaranteed to be valid.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31446", "url": "https://ubuntu.com/security/CVE-2026-31446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in update_super_work when racing with umount Commit b98535d09179 (\"ext4: fix bug_on in start_this_handle during umount filesystem\") moved ext4_unregister_sysfs() before flushing s_sb_upd_work to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups reads during unmount. However, this introduced a use-after-free because update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which accesses the kobject's kernfs_node after it has been freed by kobject_del() in ext4_unregister_sysfs(): update_super_work ext4_put_super ----------------- -------------- ext4_unregister_sysfs(sb) kobject_del(&sbi->s_kobj) __kobject_del() sysfs_remove_dir() kobj->sd = NULL sysfs_put(sd) kernfs_put() // RCU free ext4_notify_error_sysfs(sbi) sysfs_notify(&sbi->s_kobj) kn = kobj->sd // stale pointer kernfs_get(kn) // UAF on freed kernfs_node ext4_journal_destroy() flush_work(&sbi->s_sb_upd_work) Instead of reordering the teardown sequence, fix this by making ext4_notify_error_sysfs() detect that sysfs has already been torn down by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call in that case. A dedicated mutex (s_error_notify_mutex) serializes ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs() to prevent TOCTOU races where the kobject could be deleted between the state_in_sysfs check and the sysfs_notify() call.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31450", "url": "https://ubuntu.com/security/CVE-2026-31450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: publish jinode after initialization ext4_inode_attach_jinode() publishes ei->jinode to concurrent users. It used to set ei->jinode before jbd2_journal_init_jbd_inode(), allowing a reader to observe a non-NULL jinode with i_vfs_inode still unset. The fast commit flush path can then pass this jinode to jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and may crash. Below is the crash I observe: ``` BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xas_find_marked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: filemap_get_folios_tag+0x87/0x2a0 __filemap_fdatawait_range+0x5f/0xd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? cap_safe_nice+0x37/0x70 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 filemap_fdatawait_range_keep_errors+0x12/0x40 ext4_fc_commit+0x697/0x8b0 ? ext4_file_write_iter+0x64b/0x950 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? vfs_write+0x356/0x480 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ext4_sync_file+0xf7/0x370 do_fsync+0x3b/0x80 ? syscall_trace_enter+0x108/0x1d0 __x64_sys_fdatasync+0x16/0x20 do_syscall_64+0x62/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... ``` Fix this by initializing the jbd2_inode first. Use smp_wmb() and WRITE_ONCE() to publish ei->jinode after initialization. Readers use READ_ONCE() to fetch the pointer.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31726", "url": "https://ubuntu.com/security/CVE-2026-31726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix NULL pointer dereference during unbind race Commit b81ac4395bbe (\"usb: gadget: uvc: allow for application to cleanly shutdown\") introduced two stages of synchronization waits totaling 1500ms in uvc_function_unbind() to prevent several types of kernel panics. However, this timing-based approach is insufficient during power management (PM) transitions. When the PM subsystem starts freezing user space processes, the wait_event_interruptible_timeout() is aborted early, which allows the unbind thread to proceed and nullify the gadget pointer (cdev->gadget = NULL): [ 814.123447][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind() [ 814.178583][ T3173] PM: suspend entry (deep) [ 814.192487][ T3173] Freezing user space processes [ 814.197668][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind no clean disconnect, wait for release When the PM subsystem resumes or aborts the suspend and tasks are restarted, the V4L2 release path is executed and attempts to access the already nullified gadget pointer, triggering a kernel panic: [ 814.292597][ C0] PM: pm_system_irq_wakeup: 479 triggered dhdpcie_host_wake [ 814.386727][ T3173] Restarting tasks ... [ 814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 814.404021][ T4558] pc : usb_gadget_deactivate+0x14/0xf4 [ 814.404031][ T4558] lr : usb_function_deactivate+0x54/0x94 [ 814.404078][ T4558] Call trace: [ 814.404080][ T4558] usb_gadget_deactivate+0x14/0xf4 [ 814.404083][ T4558] usb_function_deactivate+0x54/0x94 [ 814.404087][ T4558] uvc_function_disconnect+0x1c/0x5c [ 814.404092][ T4558] uvc_v4l2_release+0x44/0xac [ 814.404095][ T4558] v4l2_release+0xcc/0x130 Address the race condition and NULL pointer dereference by: 1. State Synchronization (flag + mutex) Introduce a 'func_unbound' flag in struct uvc_device. This allows uvc_function_disconnect() to safely skip accessing the nullified cdev->gadget pointer. As suggested by Alan Stern, this flag is protected by a new mutex (uvc->lock) to ensure proper memory ordering and prevent instruction reordering or speculative loads. This mutex is also used to protect 'func_connected' for consistent state management. 2. Explicit Synchronization (completion) Use a completion to synchronize uvc_function_unbind() with the uvc_vdev_release() callback. This prevents Use-After-Free (UAF) by ensuring struct uvc_device is freed after all video device resources are released.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31728", "url": "https://ubuntu.com/security/CVE-2026-31728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop A race condition between gether_disconnect() and eth_stop() leads to a NULL pointer dereference. Specifically, if eth_stop() is triggered concurrently while gether_disconnect() is tearing down the endpoints, eth_stop() attempts to access the cleared endpoint descriptor, causing the following NPE: Unable to handle kernel NULL pointer dereference Call trace: __dwc3_gadget_ep_enable+0x60/0x788 dwc3_gadget_ep_enable+0x70/0xe4 usb_ep_enable+0x60/0x15c eth_stop+0xb8/0x108 Because eth_stop() crashes while holding the dev->lock, the thread running gether_disconnect() fails to acquire the same lock and spins forever, resulting in a hardlockup: Core - Debugging Information for Hardlockup core(7) Call trace: queued_spin_lock_slowpath+0x94/0x488 _raw_spin_lock+0x64/0x6c gether_disconnect+0x19c/0x1e8 ncm_set_alt+0x68/0x1a0 composite_setup+0x6a0/0xc50 The root cause is that the clearing of dev->port_usb in gether_disconnect() is delayed until the end of the function. Move the clearing of dev->port_usb to the very beginning of gether_disconnect() while holding dev->lock. This cuts off the link immediately, ensuring eth_stop() will see dev->port_usb as NULL and safely bail out.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31721", "url": "https://ubuntu.com/security/CVE-2026-31721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: move list and spinlock inits from bind to alloc There was an issue when you did the following: - setup and bind an hid gadget - open /dev/hidg0 - use the resulting fd in EPOLL_CTL_ADD - unbind the UDC - bind the UDC - use the fd in EPOLL_CTL_DEL When CONFIG_DEBUG_LIST was enabled, a list_del corruption was reported within remove_wait_queue (via ep_remove_wait_queue). After some debugging I found out that the queues, which f_hid registers via poll_wait were the problem. These were initialized using init_waitqueue_head inside hidg_bind. So effectively, the bind function re-initialized the queues while there were still items in them. The solution is to move the initialization from hidg_bind to hidg_alloc to extend their lifetimes to the lifetime of the function instance. Additionally, I found many other possibly problematic init calls in the bind function, which I moved as well.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31670", "url": "https://ubuntu.com/security/CVE-2026-31670", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rfkill: prevent unlimited numbers of rfkill events from being created Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a \"large\" number (i.e. 1000) to prevent abuses like this.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31634", "url": "https://ubuntu.com/security/CVE-2026-31634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix reference count leak in rxrpc_server_keyring() This patch fixes a reference count leak in rxrpc_server_keyring() by checking if rx->securities is already set.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31651", "url": "https://ubuntu.com/security/CVE-2026-31651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix NULL-deref on disconnect Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31656", "url": "https://ubuntu.com/security/CVE-2026-31656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` <4> [487.221889] Workqueue: i915-unordered engine_retire [i915] <4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] Call Trace: <4> [487.222711] <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ? __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ? __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ? __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] ``` Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it. (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31658", "url": "https://ubuntu.com/security/CVE-2026-31658", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit() When dma_map_single() fails in tse_start_xmit(), the function returns NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure. Add dev_kfree_skb_any() before returning to properly free the skb.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31660", "url": "https://ubuntu.com/security/CVE-2026-31660", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: allocate rx skb before consuming bytes pn532_receive_buf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already hand a complete frame to pn533_recv_frame() before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31661", "url": "https://ubuntu.com/security/CVE-2026-31661", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: Fix dma_free_coherent() size dma_alloc_consistent() may change the size to align it. The new size is saved in alloced. Change the free size to match the allocation size.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31662", "url": "https://ubuntu.com/security/CVE-2026-31662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round. Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31665", "url": "https://ubuntu.com/security/CVE-2026-31665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: fix use-after-free in timeout object destroy nft_ct_timeout_obj_destroy() frees the timeout object with kfree() immediately after nf_ct_untimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcu_dereference() in nf_ct_timeout_data(). Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c. KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2024-56557", "url": "https://ubuntu.com/security/CVE-2024-56557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer The AD7923 was updated to support devices with 8 channels, but the size of tx_buf and ring_xfer was not increased accordingly, leading to a potential buffer overflow in ad7923_update_scan_mode().", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2024-36898", "url": "https://ubuntu.com/security/CVE-2024-36898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: fix uninitialised kfifo If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace. Initialise the kfifo in the case where the software debounce is already active.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2025-40016", "url": "https://ubuntu.com/security/CVE-2025-40016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID. In a previous attempt commit 3dd075fe8ebb (\"media: uvcvideo: Require entities to have a non-zero unique ID\"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2026-31667", "url": "https://ubuntu.com/security/CVE-2026-31667", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: uinput - fix circular locking dependency with ff-core A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller): ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex The cycle is caused by four lock acquisition paths: 1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex. 2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex. 3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex. 4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex. Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes. To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock. Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible. Lock ordering after the fix: ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31671", "url": "https://ubuntu.com/security/CVE-2026-31671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_report() struct xfrm_user_report is a __u8 proto field followed by a struct xfrm_selector which means there is three \"empty\" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31672", "url": "https://ubuntu.com/security/CVE-2026-31672", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00usb: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the USB anchor lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43336", "url": "https://ubuntu.com/security/CVE-2026-43336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: chacha: Zeroize permuted_state before it leaves scope Since the ChaCha permutation is invertible, the local variable 'permuted_state' is sufficient to compute the original 'state', and thus the key, even after the permutation has been done. While the kernel is quite inconsistent about zeroizing secrets on the stack (and some prominent userspace crypto libraries don't bother at all since it's not guaranteed to work anyway), the kernel does try to do it as a best practice, especially in cases involving the RNG. Thus, explicitly zeroize 'permuted_state' before it goes out of scope.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31695", "url": "https://ubuntu.com/security/CVE-2026-31695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free Currently we execute `SET_NETDEV_DEV(dev, &priv->lowerdev->dev)` for the virt_wifi net devices. However, unregistering a virt_wifi device in netdev_run_todo() can happen together with the device referenced by SET_NETDEV_DEV(). It can result in use-after-free during the ethtool operations performed on a virt_wifi device that is currently being unregistered. Such a net device can have the `dev.parent` field pointing to the freed memory, but ethnl_ops_begin() calls `pm_runtime_get_sync(dev->dev.parent)`. Let's remove SET_NETDEV_DEV for virt_wifi to avoid bugs like this: ================================================================== BUG: KASAN: slab-use-after-free in __pm_runtime_resume+0xe2/0xf0 Read of size 2 at addr ffff88810cfc46f8 by task pm/606 Call Trace: dump_stack_lvl+0x4d/0x70 print_report+0x170/0x4f3 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 kasan_report+0xda/0x110 ? __pm_runtime_resume+0xe2/0xf0 ? __pm_runtime_resume+0xe2/0xf0 __pm_runtime_resume+0xe2/0xf0 ethnl_ops_begin+0x49/0x270 ethnl_set_features+0x23c/0xab0 ? __pfx_ethnl_set_features+0x10/0x10 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xf/0xf0 ? local_clock+0x10/0x30 ? kasan_save_track+0x25/0x60 ? __kasan_kmalloc+0x7f/0x90 ? genl_family_rcv_msg_attrs_parse.isra.0+0x150/0x2c0 genl_family_rcv_msg_doit+0x1e7/0x2c0 ? __pfx_genl_family_rcv_msg_doit+0x10/0x10 ? __pfx_cred_has_capability.isra.0+0x10/0x10 ? stack_trace_save+0x8e/0xc0 genl_rcv_msg+0x411/0x660 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_ethnl_set_features+0x10/0x10 netlink_rcv_skb+0x121/0x380 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_down_read+0x10/0x10 genl_rcv+0x23/0x30 netlink_unicast+0x60f/0x830 ? __pfx_netlink_unicast+0x10/0x10 ? __pfx___alloc_skb+0x10/0x10 netlink_sendmsg+0x6ea/0xbc0 ? __pfx_netlink_sendmsg+0x10/0x10 ? __futex_queue+0x10b/0x1f0 ____sys_sendmsg+0x7a2/0x950 ? copy_msghdr_from_user+0x26b/0x430 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ___sys_sendmsg+0xf8/0x180 ? __pfx____sys_sendmsg+0x10/0x10 ? __pfx_futex_wait+0x10/0x10 ? fdget+0x2e4/0x4a0 __sys_sendmsg+0x11f/0x1c0 ? __pfx___sys_sendmsg+0x10/0x10 do_syscall_64+0xe2/0x570 ? exc_page_fault+0x66/0xb0 entry_SYSCALL_64_after_hwframe+0x77/0x7f This fix may be combined with another one in the ethtool subsystem: https://lore.kernel.org/all/20260322075917.254874-1-alex.popov@linux.com/T/#u", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2024-56584", "url": "https://ubuntu.com/security/CVE-2024-56584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/tctx: work around xa_store() allocation error issue syzbot triggered the following WARN_ON: WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51 which is the WARN_ON_ONCE(!xa_empty(&tctx->xa)); sanity check in __io_uring_free() when a io_uring_task is going through its final put. The syzbot test case includes injecting memory allocation failures, and it very much looks like xa_store() can fail one of its memory allocations and end up with ->head being non-NULL even though no entries exist in the xarray. Until this issue gets sorted out, work around it by attempting to iterate entries in our xarray, and WARN_ON_ONCE() if one is found.", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2026-31720", "url": "https://ubuntu.com/security/CVE-2026-31720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: validate control request size f_audio_complete() copies req->length bytes into a 4-byte stack variable: u32 data = 0; memcpy(&data, req->buf, req->length); req->length is derived from the host-controlled USB request path, which can lead to a stack out-of-bounds write. Validate req->actual against the expected payload size for the supported control selectors and decode only the expected amount of data. This avoids copying a host-influenced length into a fixed-size stack object.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43342", "url": "https://ubuntu.com/security/CVE-2026-43342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Protect RNDIS options with mutex The class/subclass/protocol options are suspectible to race conditions as they can be accessed concurrently through configfs. Use existing mutex to protect these options. This issue was identified during code inspection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43343", "url": "https://ubuntu.com/security/CVE-2026-43343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_subset: Fix unbalanced refcnt in geth_free geth_alloc() increments the reference count, but geth_free() fails to decrement it. This prevents the configuration of attributes via configfs after unlinking the function. Decrement the reference count in geth_free() to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-68256", "url": "https://ubuntu.com/security/CVE-2025-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser The Information Element (IE) parser rtw_get_ie() trusted the length byte of each IE without validating that the IE body (len bytes after the 2-byte header) fits inside the remaining frame buffer. A malformed frame can advertise an IE length larger than the available data, causing the parser to increment its pointer beyond the buffer end. This results in out-of-bounds reads or, depending on the pattern, an infinite loop. Fix by validating that (offset + 2 + len) does not exceed the limit before accepting the IE or advancing to the next element. This prevents OOB reads and ensures the parser terminates safely on malformed frames.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40103", "url": "https://ubuntu.com/security/CVE-2025-40103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix refcount leak for cifs_sb_tlink Fix three refcount inconsistency issues related to `cifs_sb_tlink`. Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be called after successful calls to `cifs_sb_tlink()`. Three calls fail to update refcount accordingly, leading to possible resource leaks.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-38006", "url": "https://ubuntu.com/security/CVE-2025-38006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: Don't access ifa_index when missing In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but only when the struct ifaddrmsg is provided. Otherwise it will be comparing to uninitialised memory - reproducible in the syzkaller case from dhcpd, or busybox \"ip addr show\". The kernel MCTP implementation has always filtered by ifa_index, so existing userspace programs expecting to dump MCTP addresses must already be passing a valid ifa_index value (either 0 or a real index). BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40323", "url": "https://ubuntu.com/security/CVE-2025-40323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Set fb_display[i]->mode to NULL when the mode is released Recently, we discovered the following issue through syzkaller: BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0. Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2026-23031", "url": "https://ubuntu.com/security/CVE-2026-23031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak In gs_can_open(), the URBs for USB-in transfers are allocated, added to the parent->rx_submitted anchor and submitted. In the complete callback gs_usb_receive_bulk_callback(), the URB is processed and resubmitted. In gs_can_close() the URBs are freed by calling usb_kill_anchored_urbs(parent->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in gs_can_close(). Fix the memory leak by anchoring the URB in the gs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-43324", "url": "https://ubuntu.com/security/CVE-2026-43324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix interrupt synchronization error This fixes an error in synchronization in the dummy-hcd driver. The error has a somewhat involved history. The synchronization mechanism was introduced by commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), which added an emulated \"interrupts enabled\" flag together with code emulating synchronize_irq() (it waits until all current handler callbacks have returned). But the emulated interrupt-disable occurred too late, after the driver containing the handler callback routines had been told that it was unbound and no more callbacks would occur. Commit 4a5d797a9f9c (\"usb: gadget: dummy_hcd: fix gpf in gadget_setup\") tried to fix this by moving the synchronize_irq() emulation code from dummy_stop() to dummy_pullup(), which runs before the unbind callback. There still were races, though, because the emulated interrupt-disable still occurred too late. It couldn't be moved to dummy_pullup(), because that routine can be called for reasons other than an impending unbind. Therefore commits 7dc0c55e9f30 (\"USB: UDC core: Add udc_async_callbacks gadget op\") and 04145a03db9d (\"USB: UDC: Implement udc_async_callbacks in dummy-hcd\") added an API allowing the UDC core to tell dummy-hcd exactly when emulated interrupts and their callbacks should be disabled. That brings us to the current state of things, which is still wrong because the emulated synchronize_irq() occurs before the emulated interrupt-disable! That's no good, beause it means that more emulated interrupts can occur after the synchronize_irq() emulation has run, leading to the possibility that a callback handler may be running when the gadget driver is unbound. To fix this, we have to move the synchronize_irq() emulation code yet again, to the dummy_udc_async_callbacks() routine, which takes care of enabling and disabling emulated interrupt requests. The synchronization will now run immediately after emulated interrupts are disabled, which is where it belongs.", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43327", "url": "https://ubuntu.com/security/CVE-2026-43327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix locking/synchronization error Syzbot testing was able to provoke an addressing exception and crash in the usb_gadget_udc_reset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second (\"driver\") argument of NULL. The bad caller was set_link_state() in dummy_hcd.c, and the problem arose because of a race between a USB reset and driver unbind. These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first. The error responsible for the syzbot crash occurred because the stop_activity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stop_activity() occurs in set_link_state() when handling an emulated USB reset, after the test of dum->ints_enabled and before the increment of dum->callback_usage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->ints_enabled and dum->driver. Normally this other thread would have to wait for dum->callback_usage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callback_usage had not yet been incremented. The fix is to increment dum->callback_usage _before_ calling stop_activity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usb_gadget_udc_reset() safely returns and dum->callback_usage has been decremented again.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31737", "url": "https://ubuntu.com/security/CVE-2026-31737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ftgmac100: fix ring allocation unwind on open failure ftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, and rx_scratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function. Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31738", "url": "https://ubuntu.com/security/CVE-2026-31738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: validate ND option lengths in vxlan_na_create vxlan_na_create() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31747", "url": "https://ubuntu.com/security/CVE-2026-31747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me4000: Fix potential overrun of firmware buffer `me4000_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`. Note: The firmware loading was totally broken before commit ac584af59945 (\"staging: comedi: me4000: fix firmware downloading\"), but that is the most sensible target for this fix.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31748", "url": "https://ubuntu.com/security/CVE-2026-31748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me_daq: Fix potential overrun of firmware buffer `me2600_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Although it checks that the supplied firmware is at least 16 bytes long, it does not check that it is long enough to contain the data stream. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31749", "url": "https://ubuntu.com/security/CVE-2026-31749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: ni_atmio16d: Fix invalid clean-up after failed attach If the driver's COMEDI \"attach\" handler function (`atmio16d_attach()`) returns an error, the COMEDI core will call the driver's \"detach\" handler function (`atmio16d_detach()`) to clean up. This calls `reset_atmio16d()` unconditionally, but depending on where the error occurred in the attach handler, the device may not have been sufficiently initialized to call `reset_atmio16d()`. It uses `dev->iobase` as the I/O port base address and `dev->private` as the pointer to the COMEDI device's private data structure. `dev->iobase` may still be set to its initial value of 0, which would result in undesired writes to low I/O port addresses. `dev->private` may still be `NULL`, which would result in null pointer dereferences. Fix `atmio16d_detach()` by checking that `dev->private` is valid (non-null) before calling `reset_atmio16d()`. This implies that `dev->iobase` was set correctly since that is set up before `dev->private`.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43340", "url": "https://ubuntu.com/security/CVE-2026-43340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Reinit dev->spinlock between attachments to low-level drivers `struct comedi_device` is the main controlling structure for a COMEDI device created by the COMEDI subsystem. It contains a member `spinlock` containing a spin-lock that is initialized by the COMEDI subsystem, but is reserved for use by a low-level driver attached to the COMEDI device (at least since commit 25436dc9d84f (\"Staging: comedi: remove RT code\")). Some COMEDI devices (those created on initialization of the COMEDI subsystem when the \"comedi.comedi_num_legacy_minors\" parameter is non-zero) can be attached to different low-level drivers over their lifetime using the `COMEDI_DEVCONFIG` ioctl command. This can result in inconsistent lock states being reported when there is a mismatch in the spin-lock locking levels used by each low-level driver to which the COMEDI device has been attached. Fix it by reinitializing `dev->spinlock` before calling the low-level driver's `attach` function pointer if `CONFIG_LOCKDEP` is enabled.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31751", "url": "https://ubuntu.com/security/CVE-2026-31751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: dt2815: add hardware detection to prevent crash The dt2815 driver crashes when attached to I/O ports without actual hardware present. This occurs because syzkaller or users can attach the driver to arbitrary I/O addresses via COMEDI_DEVCONFIG ioctl. When no hardware exists at the specified port, inb() operations return 0xff (floating bus), but outb() operations can trigger page faults due to undefined behavior, especially under race conditions: BUG: unable to handle page fault for address: 000000007fffff90 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:dt2815_attach+0x6e0/0x1110 Add hardware detection by reading the status register before attempting any write operations. If the read returns 0xff, assume no hardware is present and fail the attach with -ENODEV. This prevents crashes from outb() operations on non-existent hardware.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31752", "url": "https://ubuntu.com/security/CVE-2026-31752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: validate ND option lengths br_nd_send() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31754", "url": "https://ubuntu.com/security/CVE-2026-31754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix state inconsistency on gadget init failure When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency. When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error, so cdns_role_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles. This leads to a synchronous external abort in xhci_gen_setup() when setting up the host controller: [ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408 [ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switch Fix by calling cdns_drd_gadget_off() in the error path to properly clean up the DRD gadget state.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31755", "url": "https://ubuntu.com/security/CVE-2026-31755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix NULL pointer dereference in ep_queue When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when __cdns3_gadget_ep_queue() is called, causing a kernel crash. Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints. This prevents potential crashes when ep_queue is called on endpoints that are not ready.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31756", "url": "https://ubuntu.com/security/CVE-2026-31756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop() dwc2_gadget_exit_clock_gating() internally calls call_gadget() macro, which expects hsotg->lock to be held since it does spin_unlock/spin_lock around the gadget driver callback invocation. However, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating() without holding the lock. This leads to: - spin_unlock on a lock that is not held (undefined behavior) - The lock remaining held after dwc2_gadget_exit_clock_gating() returns, causing a deadlock when spin_lock_irqsave() is called later in the same function. Fix this by acquiring hsotg->lock before calling dwc2_gadget_exit_clock_gating() and releasing it afterwards, which satisfies the locking requirement of the call_gadget() macro.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31758", "url": "https://ubuntu.com/security/CVE-2026-31758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbtmc: Flush anchored URBs in usbtmc_release When calling usbtmc_release, pending anchored URBs must be flushed or killed to prevent use-after-free errors (e.g. in the HCD giveback path). Call usbtmc_draw_down() to allow anchored URBs to be completed.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31759", "url": "https://ubuntu.com/security/CVE-2026-31759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: fix double free in ulpi_register_interface() error path When device_register() fails, ulpi_register() calls put_device() on ulpi->dev. The device release callback ulpi_dev_release() drops the OF node reference and frees ulpi, but the current error path in ulpi_register_interface() then calls kfree(ulpi) again, causing a double free. Let put_device() handle the cleanup through ulpi_dev_release() and avoid freeing ulpi again in ulpi_register_interface().", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31761", "url": "https://ubuntu.com/security/CVE-2026-31761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Move iio_device_register() to correct location iio_device_register() should be at the end of the probe function to prevent race conditions. Place iio_device_register() at the end of the probe function and place iio_device_unregister() accordingly.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31762", "url": "https://ubuntu.com/security/CVE-2026-31762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix irq resource leak The interrupt handler is setup but only a few lines down if iio_trigger_register() fails the function returns without properly releasing the handler. Add cleanup goto to resolve resource leak. Detected by Smatch: drivers/iio/gyro/mpu3050-core.c:1128 mpu3050_trigger_probe() warn: 'irq' from request_threaded_irq() not released on lines: 1124.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31763", "url": "https://ubuntu.com/security/CVE-2026-31763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix incorrect free_irq() variable The handler for the IRQ part of this driver is mpu3050->trig but, in the teardown free_irq() is called with handler mpu3050. Use correct IRQ handler when calling free_irq().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31770", "url": "https://ubuntu.com/security/CVE-2026-31770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) Fix division by zero in occ_show_power_1() In occ_show_power_1() case 1, the accumulator is divided by update_tag without checking for zero. If no samples have been collected yet (e.g. during early boot when the sensor block is included but hasn't been updated), update_tag is zero, causing a kernel divide-by-zero crash. The 2019 fix in commit 211186cae14d (\"hwmon: (occ) Fix division by zero issue\") only addressed occ_get_powr_avg() used by occ_show_power_2() and occ_show_power_a0(). This separate code path in occ_show_power_1() was missed. Fix this by reusing the existing occ_get_powr_avg() helper, which already handles the zero-sample case and uses mul_u64_u32_div() to multiply before dividing for better precision. Move the helper above occ_show_power_1() so it is visible at the call site. [groeck: Fix alignment problems reported by checkpatch]", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43334", "url": "https://ubuntu.com/security/CVE-2026-43334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: force responder MITM requirements before building the pairing response smp_cmd_pairing_req() currently builds the pairing response from the initiator auth_req before enforcing the local BT_SECURITY_HIGH requirement. If the initiator omits SMP_AUTH_MITM, the response can also omit it even though the local side still requires MITM. tk_request() then sees an auth value without SMP_AUTH_MITM and may select JUST_CFM, making method selection inconsistent with the pairing policy the responder already enforces. When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMP_AUTH_MITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31773", "url": "https://ubuntu.com/security/CVE-2026-31773", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: derive legacy responder STK authentication from MITM state The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved. For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result. This also keeps the legacy path aligned with the Secure Connections code, which already treats JUST_WORKS/JUST_CFM as unauthenticated.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31776", "url": "https://ubuntu.com/security/CVE-2026-31776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix missing SPDIFI1 index handling SPDIF1 DAIO type isn't properly handled in daio_device_index() for hw20k2, and it returned -EINVAL, which ended up with the out-of-bounds array access. Follow the hw20k1 pattern and return the proper index for this type, too.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31778", "url": "https://ubuntu.com/security/CVE-2026-31778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix stack out-of-bounds read in init_card The loop creates a whitespace-stripped copy of the card shortname where `len < sizeof(card->id)` is used for the bounds check. Since sizeof(card->id) is 16 and the local id buffer is also 16 bytes, writing 16 non-space characters fills the entire buffer, overwriting the terminating nullbyte. When this non-null-terminated string is later passed to snd_card_set_id() -> copy_valid_id_string(), the function scans forward with `while (*nid && ...)` and reads past the end of the stack buffer, reading the contents of the stack. A USB device with a product name containing many non-ASCII, non-space characters (e.g. multibyte UTF-8) will reliably trigger this as follows: BUG: KASAN: stack-out-of-bounds in copy_valid_id_string sound/core/init.c:696 [inline] BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c sound/core/init.c:718 The off-by-one has been present since commit bafeee5b1f8d (\"ALSA: snd_usb_caiaq: give better shortname\") from June 2009 (v2.6.31-rc1), which first introduced this whitespace-stripping loop. The original code never accounted for the null terminator when bounding the copy. Fix this by changing the loop bound to `sizeof(card->id) - 1`, ensuring at least one byte remains as the null terminator.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31780", "url": "https://ubuntu.com/security/CVE-2026-31780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation The variable valuesize is declared as u8 but accumulates the total length of all SSIDs to scan. Each SSID contributes up to 33 bytes (IEEE80211_MAX_SSID_LEN + 1), and with WILC_MAX_NUM_PROBED_SSID (10) SSIDs the total can reach 330, which wraps around to 74 when stored in a u8. This causes kmalloc to allocate only 75 bytes while the subsequent memcpy writes up to 331 bytes into the buffer, resulting in a 256-byte heap buffer overflow. Widen valuesize from u8 to u32 to accommodate the full range.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31781", "url": "https://ubuntu.com/security/CVE-2026-31781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ioc32: stop speculation on the drm_compat_ioctl path The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling array_index_nospec() on the index to the function pointer list.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43333", "url": "https://ubuntu.com/security/CVE-2026-43333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject direct access to nullable PTR_TO_BUF pointers check_mem_access() matches PTR_TO_BUF via base_type() which strips PTR_MAYBE_NULL, allowing direct dereference without a null check. Map iterator ctx->key and ctx->value are PTR_TO_BUF | PTR_MAYBE_NULL. On stop callbacks these are NULL, causing a kernel NULL dereference. Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching the existing PTR_TO_BTF_ID pattern.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31415", "url": "https://ubuntu.com/security/CVE-2026-31415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid overflows in ip6_datagram_send_ctl() Yiming Qian reported : I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via `skb_under_panic()` (local DoS). The core issue is a mismatch between: - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type `__u16`) and - a pointer to the *last* provided destination-options header (`opt->dst1opt`) when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided. - `include/net/ipv6.h`: - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible). (lines 291-307, especially 298) - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`: - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen` without rejecting duplicates. (lines 909-933) - `net/ipv6/ip6_output.c:__ip6_append_data()`: - Uses `opt->opt_flen + opt->opt_nflen` to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - `net/ipv6/ip6_output.c:__ip6_make_skb()`: - Calls `ipv6_push_frag_opts()` if `opt->opt_flen` is non-zero. (lines 1930-1934) - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`: - Push size comes from `ipv6_optlen(opt->dst1opt)` (based on the pointed-to header). (lines 1179-1185 and 1206-1211) 1. `opt_flen` is a 16-bit accumulator: - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`. 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs and increments `opt_flen` each time: - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`: - It computes `len = ((hdr->hdrlen + 1) << 3);` - It checks `CAP_NET_RAW` using `ns_capable(net->user_ns, CAP_NET_RAW)`. (line 922) - Then it does: - `opt->opt_flen += len;` (line 927) - `opt->dst1opt = hdr;` (line 928) There is no duplicate rejection here (unlike the legacy `IPV6_2292DSTOPTS` path which rejects duplicates at `net/ipv6/datagram.c:901-904`). If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps while `dst1opt` still points to a large (2048-byte) destination-options header. In the attached PoC (`poc.c`): - 32 cmsgs with `hdrlen=255` => `len = (255+1)*8 = 2048` - 1 cmsg with `hdrlen=0` => `len = 8` - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8` - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header. 3. The transmit path sizes headers using the wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1463-1465`: - `headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;` With wrapped `opt_flen`, `headersize`/headroom decisions underestimate what will be pushed later. 4. When building the final skb, the actual push length comes from `dst1opt` and is not limited by wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1930-1934`: - `if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);` - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes `dst1opt` via `ipv6_push_exthdr()`. - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does: - `skb_push(skb, ipv6_optlen(opt));` - `memcpy(h, opt, ipv6_optlen(opt));` With insufficient headroom, `skb_push()` underflows and triggers `skb_under_panic()` -> `BUG()`: - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`) - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`) - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target netns user namespace (`ns_capable(net->user_ns, CAP_NET_RAW)`). - Root (or any task with `CAP_NET_RAW`) can trigger this without user namespaces. - An unprivileged `uid=1000` user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced `CAP_NET_RAW` (the attached PoC does this). - Local denial of service: kernel BUG/panic (system crash). - ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31422", "url": "https://ubuntu.com/security/CVE-2026-31422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_flow: fix NULL pointer dereference on shared blocks flow_change() calls tcf_block_q() and dereferences q->handle to derive a default baseclass. Shared blocks leave block->q NULL, causing a NULL deref when a flow filter without a fully qualified baseclass is created on a shared block. Check tcf_block_shared() before accessing block->q and return -EINVAL for shared blocks. This avoids the null-deref shown below: ======================================================================= KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:flow_change (net/sched/cls_flow.c:508) Call Trace: tc_new_tfilter (net/sched/cls_api.c:2432) rtnetlink_rcv_msg (net/core/rtnetlink.c:6980) [...] =======================================================================", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31421", "url": "https://ubuntu.com/security/CVE-2026-31421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL pointer dereference on shared blocks The old-method path in fw_classify() calls tcf_block_q() and dereferences q->handle. Shared blocks leave block->q NULL, causing a NULL deref when an empty cls_fw filter is attached to a shared block and a packet with a nonzero major skb mark is classified. Reject the configuration in fw_change() when the old method (no TCA_OPTIONS) is used on a shared block, since fw_classify()'s old-method path needs block->q which is NULL for shared blocks. The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fw_classify (net/sched/cls_fw.c:81) Call Trace: tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860) tc_run (net/core/dev.c:4401) __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31417", "url": "https://ubuntu.com/security/CVE-2026-31417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix overflow when accumulating packets Add a check to ensure that `x25_sock.fraglen` does not overflow. The `fraglen` also needs to be resetted when purging `fragment_queue` in `x25_clear_queues()`.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43014", "url": "https://ubuntu.com/security/CVE-2026-43014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: properly unregister fixed rate clocks The additional resources allocated with clk_register_fixed_rate() need to be released with clk_unregister_fixed_rate(), otherwise they are lost.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43015", "url": "https://ubuntu.com/security/CVE-2026-43015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix clk handling on PCI glue driver removal platform_device_unregister() may still want to use the registered clks during runtime resume callback. Note that there is a commit d82d5303c4c5 (\"net: macb: fix use after free on rmmod\") that addressed the similar problem of clk vs platform device unregistration but just moved the bug to another place. Save the pointers to clks into local variables for reuse after platform device is unregistered. BUG: KASAN: use-after-free in clk_prepare+0x5a/0x60 Read of size 8 at addr ffff888104f85e00 by task modprobe/597 CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x8d/0xba print_report+0x17f/0x496 kasan_report+0xd9/0x180 clk_prepare+0x5a/0x60 macb_runtime_resume+0x13d/0x410 [macb] pm_generic_runtime_resume+0x97/0xd0 __rpm_callback+0xc8/0x4d0 rpm_callback+0xf6/0x230 rpm_resume+0xeeb/0x1a70 __pm_runtime_resume+0xb4/0x170 bus_remove_device+0x2e3/0x4b0 device_del+0x5b3/0xdc0 platform_device_del+0x4e/0x280 platform_device_unregister+0x11/0x50 pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 519: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x8e/0x90 __clk_register+0x458/0x2890 clk_hw_register+0x1a/0x60 __clk_hw_register_fixed_rate+0x255/0x410 clk_register_fixed_rate+0x3c/0xa0 macb_probe+0x1d8/0x42e [macb_pci] local_pci_probe+0xd7/0x190 pci_device_probe+0x252/0x600 really_probe+0x255/0x7f0 __driver_probe_device+0x1ee/0x330 driver_probe_device+0x4c/0x1f0 __driver_attach+0x1df/0x4e0 bus_for_each_dev+0x15d/0x1f0 bus_add_driver+0x486/0x5e0 driver_register+0x23a/0x3d0 do_one_initcall+0xfd/0x4d0 do_init_module+0x18b/0x5a0 load_module+0x5663/0x7950 __do_sys_finit_module+0x101/0x180 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 597: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x180 __kmem_cache_free+0xbc/0x320 clk_unregister+0x6de/0x8d0 macb_remove+0x73/0xc0 [macb_pci] pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31425", "url": "https://ubuntu.com/security/CVE-2026-31425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: ib: reject FRMR registration before IB connection is established rds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_data and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with i_cm_id = NULL because the connection worker has not yet called rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses the control message before any connection establishment, allowing rds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash the kernel. The existing guard in rds_ib_reg_frmr() only checks for !ic (added in commit 9e630bcb7701), which does not catch this case since ic is allocated early and is always non-NULL once the connection object exists. KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920 Call Trace: rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167) rds_ib_map_frmr (net/rds/ib_frmr.c:252) rds_ib_reg_frmr (net/rds/ib_frmr.c:430) rds_ib_get_mr (net/rds/ib_rdma.c:615) __rds_rdma_map (net/rds/rdma.c:295) rds_cmsg_rdma_map (net/rds/rdma.c:860) rds_sendmsg (net/rds/send.c:1363) ____sys_sendmsg do_syscall_64 Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all non-NULL before proceeding with FRMR registration, mirroring the guard already present in rds_ib_post_inv(). Return -ENODEV when the connection is not ready, which the existing error handling in rds_cmsg_send() converts to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to start the connection worker.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43020", "url": "https://ubuntu.com/security/CVE-2026-43020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate LTK enc_size on load Load Long Term Keys stores the user-provided enc_size and later uses it to size fixed-size stack operations when replying to LE LTK requests. An enc_size larger than the 16-byte key buffer can therefore overflow the reply stack buffer. Reject oversized enc_size values while validating the management LTK record so invalid keys never reach the stored key state.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43024", "url": "https://ubuntu.com/security/CVE-2026-43024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject immediate NF_QUEUE verdict nft_queue is always used from userspace nftables to deliver the NF_QUEUE verdict. Immediately emitting an NF_QUEUE verdict is never used by the userspace nft tools, so reject immediate NF_QUEUE verdicts. The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NF_QUEUE immediate verdicts to address this issue.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31424", "url": "https://ubuntu.com/security/CVE-2026-31424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP Weiming Shi says: xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_* constants. This is only correct for families whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING). ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports: - arpt_CLASSIFY - arpt_mangle - arpt_MARK that provide explicit NFPROTO_ARP match/target declarations.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43026", "url": "https://ubuntu.com/security/CVE-2026-43026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT. The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields. Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled. Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43027", "url": "https://ubuntu.com/security/CVE-2026-43027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_helper: pass helper to expect cleanup nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expect_iter_me() never matches any expectation and all of them survive the cleanup. After unregister returns, nfnl_cthelper_del() frees the helper object immediately. Subsequent expectation dumps or packet-driven init_conntrack() calls then dereference the freed exp->helper, causing a use-after-free. Pass the actual helper pointer so expectations referencing it are properly destroyed before the helper object is freed. BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43028", "url": "https://ubuntu.com/security/CVE-2026-43028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: ensure names are nul-terminated Reject names that lack a \\0 character before feeding them to functions that expect c-strings. Fixes tag is the most recent commit that needs this change.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31416", "url": "https://ubuntu.com/security/CVE-2026-31416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: account for netlink header size This is a followup to an old bug fix: NLMSG_DONE needs to account for the netlink header size, not just the attribute size. This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43329", "url": "https://ubuntu.com/security/CVE-2026-43329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: strictly check for maximum number of actions The maximum number of flowtable hardware offload actions in IPv6 is: * ethernet mangling (4 payload actions, 2 for each ethernet address) * SNAT (4 payload actions) * DNAT (4 payload actions) * Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. * Redirect (1 action) Which makes 17, while the maximum is 16. But act_ct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions. Update flow_action_entry_next() calls to check for the maximum number of supported actions. While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31680", "url": "https://ubuntu.com/security/CVE-2026-31680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: flowlabel: defer exclusive option free until RCU teardown `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file RCU read-side lock and prints `fl->opt->opt_nflen` when an option block is present. Exclusive flowlabels currently free `fl->opt` as soon as `fl->users` drops to zero in `fl_release()`. However, the surrounding `struct ip6_flowlabel` remains visible in the global hash table until later garbage collection removes it and `fl_free_rcu()` finally tears it down. A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that early `kfree()` and dereference freed option state, triggering a crash in `ip6fl_seq_show()`. Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43030", "url": "https://ubuntu.com/security/CVE-2026-43030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix regsafe() for pointers to packet In case rold->reg->range == BEYOND_PKT_END && rcur->reg->range == N regsafe() may return true which may lead to current state with valid packet range not being explored. Fix the bug.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43032", "url": "https://ubuntu.com/security/CVE-2026-43032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: pn533: bound the UART receive buffer pn532_receive_buf() appends every incoming byte to dev->recv_skb and only resets the buffer after pn532_uart_rx_is_frame() recognizes a complete frame. A continuous stream of bytes without a valid PN532 frame header therefore keeps growing the skb until skb_put_u8() hits the tail limit. Drop the accumulated partial frame once the fixed receive buffer is full so malformed UART traffic cannot grow the skb past PN532_UART_SKB_BUFF_LEN.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43035", "url": "https://ubuntu.com/security/CVE-2026-43035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to zero to prevent an info-leak When building netlink messages, tc_chain_fill_node() never initializes the tcm_info field of struct tcmsg. Since the allocation is not zeroed, kernel heap memory is leaked to userspace through this 4-byte field. The fix simply zeroes tcm_info alongside the other fields that are already initialized.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43339", "url": "https://ubuntu.com/security/CVE-2026-43339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible UaF in addrconf_permanent_addr() The mentioned helper try to warn the user about an exceptional condition, but the message is delivered too late, accessing the ipv6 after its possible deletion. Reorder the statement to avoid the possible UaF; while at it, place the warning outside the idev->lock as it needs no protection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31423", "url": "https://ubuntu.com/security/CVE-2026-31423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: fix divide-by-zero in rtsc_min() m2sm() converts a u32 slope to a u64 scaled value. For large inputs (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores the difference of two such u64 values in a u32 variable `dsm` and uses it as a divisor. When the difference is exactly 2^32 the truncation yields zero, causing a divide-by-zero oops in the concave-curve intersection path: Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...] Widen `dsm` to u64 and replace do_div() with div64_u64() so the full difference is preserved.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43040", "url": "https://ubuntu.com/security/CVE-2026-43040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak When processing Router Advertisements with user options the kernel builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data The fix is simple, just zeroes the padding fields.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43041", "url": "https://ubuntu.com/security/CVE-2026-43041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak __radix_tree_create() allocates and links intermediate nodes into the tree one by one. If a subsequent allocation fails, the already-linked nodes remain in the tree with no corresponding leaf entry. These orphaned internal nodes are never reclaimed because radix_tree_for_each_slot() only visits slots containing leaf values. The radix_tree API is deprecated in favor of xarray. As suggested by Matthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray instead of fixing the radix_tree itself [1]. xarray properly handles cleanup of internal nodes — xa_destroy() frees all internal xarray nodes when the qrtr_node is released, preventing the leak. [1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43043", "url": "https://ubuntu.com/security/CVE-2026-43043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af-alg - fix NULL pointer dereference in scatterwalk The AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL) when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL exactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent sendmsg() allocates a new SGL and chains it, but fails to clear the end marker on the previous SGL's last data entry. This causes the crypto scatterwalk to hit a premature end, returning NULL on sg_next() and leading to a kernel panic during dereference. Fix this by explicitly unmarking the end of the previous SGL when performing sg_chain() in af_alg_alloc_tsgl().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43046", "url": "https://ubuntu.com/security/CVE-2026-43046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject root items with drop_progress and zero drop_level [BUG] When recovering relocation at mount time, merge_reloc_root() and btrfs_drop_snapshot() both use BUG_ON(level == 0) to guard against an impossible state: a non-zero drop_progress combined with a zero drop_level in a root_item, which can be triggered: ------------[ cut here ]------------ kernel BUG at fs/btrfs/relocation.c:1545! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2 RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545 Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000 Call Trace: merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861 btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195 btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130 open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640 btrfs_fill_super fs/btrfs/super.c:987 [inline] btrfs_get_tree_super fs/btrfs/super.c:1951 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline] btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ... RIP: 0033:0x7f969c9a8fde Code: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f ---[ end trace 0000000000000000 ]--- The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamic metadata fuzzing tool that corrupts btrfs metadata at runtime. [CAUSE] A non-zero drop_progress.objectid means an interrupted btrfs_drop_snapshot() left a resume point on disk, and in that case drop_level must be greater than 0 because the checkpoint is only saved at internal node levels. Although this invariant is enforced when the kernel writes the root item, it is not validated when the root item is read back from disk. That allows on-disk corruption to provide an invalid state with drop_progress.objectid != 0 and drop_level == 0. When relocation recovery later processes such a root item, merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). The same invalid metadata can also trigger the corresponding BUG_ON() in btrfs_drop_snapshot(). [FIX] Fix this by validating the root_item invariant in tree-checker when reading root items from disk: if drop_progress.objectid is non-zero, drop_level must also be non-zero. Reject such malformed metadata with -EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot() and triggers the BUG_ON. After the fix, the same corruption is correctly rejected by tree-checker and the BUG_ON is no longer triggered.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43047", "url": "https://ubuntu.com/security/CVE-2026-43047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Check to ensure report responses match the request It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes. Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43050", "url": "https://ubuntu.com/security/CVE-2026-43050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix use-after-free in sock_def_readable() A race condition exists between lec_atm_close() setting priv->lecd to NULL and concurrent access to priv->lecd in send_to_lecd(), lec_handle_bridge(), and lec_atm_send(). When the socket is freed via RCU while another thread is still using it, a use-after-free occurs in sock_def_readable() when accessing the socket's wait queue. The root cause is that lec_atm_close() clears priv->lecd without any synchronization, while callers dereference priv->lecd without any protection against concurrent teardown. Fix this by converting priv->lecd to an RCU-protected pointer: - Mark priv->lecd as __rcu in lec.h - Use rcu_assign_pointer() in lec_atm_close() and lecd_attach() for safe pointer assignment - Use rcu_access_pointer() for NULL checks that do not dereference the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and lecd_attach() - Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(), lec_handle_bridge() and lec_atm_send() to safely access lecd - Use rcu_assign_pointer() followed by synchronize_rcu() in lec_atm_close() to ensure all readers have completed before proceeding. This is safe since lec_atm_close() is called from vcc_release() which holds lock_sock(), a sleeping lock. - Remove the manual sk_receive_queue drain from lec_atm_close() since vcc_destroy_socket() already drains it after lec_atm_close() returns. v2: Switch from spinlock + sock_hold/put approach to RCU to properly fix the race. The v1 spinlock approach had two issues pointed out by Eric Dumazet: 1. priv->lecd was still accessed directly after releasing the lock instead of using a local copy. 2. The spinlock did not prevent packets being queued after lec_atm_close() drains sk_receive_queue since timer and workqueue paths bypass netif_stop_queue(). Note: Syzbot patch testing was attempted but the test VM terminated unexpectedly with \"Connection to localhost closed by remote host\", likely due to a QEMU AHCI emulation issue unrelated to this fix. Compile testing with \"make W=1 net/atm/lec.o\" passes cleanly.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43051", "url": "https://ubuntu.com/security/CVE-2026-43051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq The wacom_intuos_bt_irq() function processes Bluetooth HID reports without sufficient bounds checking. A maliciously crafted short report can trigger an out-of-bounds read when copying data into the wacom structure. Specifically, report 0x03 requires at least 22 bytes to safely read the processed data and battery status, while report 0x04 (which falls through to 0x03) requires 32 bytes. Add explicit length checks for these report IDs and log a warning if a short report is received.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31555", "url": "https://ubuntu.com/security/CVE-2026-31555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Clear stale exiting pointer in futex_lock_pi() retry path Fuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524 When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'. After wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0\t\t\t CPU1\t\t CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; \t\t\t futex_lock_pi(uaddr) \t\t\t futex_lock_pi_atomic() \t\t\t\t attach_to_pi_owner() \t\t\t\t // observes EXITING \t\t\t\t *exiting = owner; // takes ref \t\t\t\t return -EBUSY \t\t\t wait_for_owner_exiting(-EBUSY, owner) \t\t\t\t put_task_struct(); // drops ref \t\t\t // exiting still points to owner \t\t\t goto retry; \t\t\t futex_lock_pi_atomic() \t\t\t\t lock_pi_update_atomic() \t\t\t\t cmpxchg(uaddr) \t\t\t\t\t*uaddr ^= WAITERS // whatever \t\t\t\t // value changed \t\t\t\t return -EAGAIN; \t\t\t wait_for_owner_exiting(-EAGAIN, exiting) // stale \t\t\t\t WARN_ON_ONCE(exiting) Fix this by resetting upon retry, essentially aligning it with requeue_pi.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43065", "url": "https://ubuntu.com/security/CVE-2026-43065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: always drain queued discard work in ext4_mb_release() While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]: > If the filesystem is initially mounted with the discard option, > deleting files will populate sbi->s_discard_list and queue > s_discard_work. If it is then remounted with nodiscard, the > EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is > neither cancelled nor flushed. [1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing. In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own. Fix it because it's a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-43066", "url": "https://ubuntu.com/security/CVE-2026-43066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths During code review, Joseph found that ext4_fc_replay_inode() calls ext4_get_fc_inode_loc() to get the inode location, which holds a reference to iloc.bh that must be released via brelse(). However, several error paths jump to the 'out' label without releasing iloc.bh: - ext4_handle_dirty_metadata() failure - sync_dirty_buffer() failure - ext4_mark_inode_used() failure - ext4_iget() failure Fix this by introducing an 'out_brelse' label placed just before the existing 'out' label to ensure iloc.bh is always released. Additionally, make ext4_fc_replay_inode() propagate errors properly instead of always returning 0.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31447", "url": "https://ubuntu.com/security/CVE-2026-31447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: reject mount if bigalloc with s_first_data_block != 0 bigalloc with s_first_data_block != 0 is not supported, reject mounting it.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43068", "url": "https://ubuntu.com/security/CVE-2026-43068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal() There's issue as follows: ... EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): error count since last fsck: 1 EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760 EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760 ... According to the log analysis, blocks are always requested from the corrupted block group. This may happen as follows: ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return error ext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out; After commit 9008a58e5dce (\"ext4: make the bitmap read routines return real error codes\") merged, Commit 163a203ddb36 (\"ext4: mark block group as corrupt on block bitmap error\") is no real solution for allocating blocks from corrupted block groups. This is because if 'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then 'ext4_mb_load_buddy()' may return an error. This means that the block allocation will fail. Therefore, check block group if corrupted when ext4_mb_load_buddy() returns error.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31452", "url": "https://ubuntu.com/security/CVE-2026-31452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: convert inline data to extents when truncate exceeds inline size Add a check in ext4_setattr() to convert files from inline data storage to extent-based storage when truncate() grows the file size beyond the inline capacity. This prevents the filesystem from entering an inconsistent state where the inline data flag is set but the file size exceeds what can be stored inline. Without this fix, the following sequence causes a kernel BUG_ON(): 1. Mount filesystem with inode that has inline flag set and small size 2. truncate(file, 50MB) - grows size but inline flag remains set 3. sendfile() attempts to write data 4. ext4_write_inline_data() hits BUG_ON(write_size > inline_capacity) The crash occurs because ext4_write_inline_data() expects inline storage to accommodate the write, but the actual inline capacity (~60 bytes for i_block + ~96 bytes for xattrs) is far smaller than the file size and write request. The fix checks if the new size from setattr exceeds the inode's actual inline capacity (EXT4_I(inode)->i_inline_size) and converts the file to extent-based storage before proceeding with the size change. This addresses the root cause by ensuring the inline data flag and file size remain consistent during truncate operations.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31455", "url": "https://ubuntu.com/security/CVE-2026-31455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: stop reclaim before pushing AIL during unmount The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while background reclaim and inodegc are still running. This is broken independently of any use-after-free issues - background reclaim and inodegc should not be running while the AIL is being pushed during unmount, as inodegc can dirty and insert inodes into the AIL during the flush, and background reclaim can race to abort and free dirty inodes. Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel background reclaim before pushing the AIL. Stop inodegc before cancelling m_reclaim_work because the inodegc worker can re-queue m_reclaim_work via xfs_inodegc_set_reclaimable.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31464", "url": "https://ubuntu.com/security/CVE-2026-31464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done() A malicious or compromised VIO server can return a num_written value in the discover targets MAD response that exceeds max_targets. This value is stored directly in vhost->num_targets without validation, and is then used as the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], which is only allocated for max_targets entries. Indices at or beyond max_targets access kernel memory outside the DMA-coherent allocation. The out-of-bounds data is subsequently embedded in Implicit Logout and PLOGI MADs that are sent back to the VIO server, leaking kernel memory. Fix by clamping num_written to max_targets before storing it.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31467", "url": "https://ubuntu.com/security/CVE-2026-31467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: add GFP_NOIO in the bio completion if needed The bio completion path in the process context (e.g. dm-verity) will directly call into decompression rather than trigger another workqueue context for minimal scheduling latencies, which can then call vm_map_ram() with GFP_KERNEL. Due to insufficient memory, vm_map_ram() may generate memory swapping I/O, which can cause submit_bio_wait to deadlock in some scenarios. Trimmed down the call stack, as follows: f2fs_submit_read_io submit_bio //bio_list is initialized. mmc_blk_mq_recovery z_erofs_endio vm_map_ram __pte_alloc_kernel __alloc_pages_direct_reclaim shrink_folio_list __swap_writepage submit_bio_wait //bio_list is non-NULL, hang!!! Use memalloc_noio_{save,restore}() to wrap up this path.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31469", "url": "https://ubuntu.com/security/CVE-2026-31469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false A UAF issue occurs when the virtio_net driver is configured with napi_tx=N and the device's IFF_XMIT_DST_RELEASE flag is cleared (e.g., during the configuration of tc route filter rules). When IFF_XMIT_DST_RELEASE is removed from the net_device, the network stack expects the driver to hold the reference to skb->dst until the packet is fully transmitted and freed. In virtio_net with napi_tx=N, skbs may remain in the virtio transmit ring for an extended period. If the network namespace is destroyed while these skbs are still pending, the corresponding dst_ops structure has freed. When a subsequent packet is transmitted, free_old_xmit() is triggered to clean up old skbs. It then calls dst_release() on the skb associated with the stale dst_entry. Since the dst_ops (referenced by the dst_entry) has already been freed, a UAF kernel paging request occurs. fix it by adds skb_dst_drop(skb) in start_xmit to explicitly release the dst reference before the skb is queued in virtio_net. Call Trace: Unable to handle kernel paging request at virtual address ffff80007e150000 CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT ... percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P) dst_release+0xe0/0x110 net/core/dst.c:177 skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177 sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255 dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469 napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527 __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net] free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net] start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net] ... Reproduction Steps: NETDEV=\"enp3s0\" config_qdisc_route_filter() { tc qdisc del dev $NETDEV root tc qdisc add dev $NETDEV root handle 1: prio tc filter add dev $NETDEV parent 1:0 \\ \tprotocol ip prio 100 route to 100 flowid 1:1 ip route add 192.168.1.100/32 dev $NETDEV realm 100 } test_ns() { ip netns add testns ip link set $NETDEV netns testns ip netns exec testns ifconfig $NETDEV 10.0.32.46/24 ip netns exec testns ping -c 1 10.0.32.1 ip netns del testns } config_qdisc_route_filter test_ns sleep 2 test_ns", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31473", "url": "https://ubuntu.com/security/CVE-2026-31473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex MEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0) queue teardown paths. This can race request object cleanup against vb2 queue cancellation and lead to use-after-free reports. We already serialize request queueing against STREAMON/OFF with req_queue_mutex. Extend that serialization to REQBUFS, and also take the same mutex in media_request_ioctl_reinit() so REINIT is in the same exclusion domain. This keeps request cleanup and queue cancellation from running in parallel for request-capable devices.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31570", "url": "https://ubuntu.com/security/CVE-2026-31570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gw: fix OOB heap access in cgw_csum_crc8_rel() cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx(): int from = calc_idx(crc8->from_idx, cf->len); int to = calc_idx(crc8->to_idx, cf->len); int res = calc_idx(crc8->result_idx, cf->len); if (from < 0 || to < 0 || res < 0) return; However, the loop and the result write then use the raw s8 fields directly instead of the computed variables: for (i = crc8->from_idx; ...) /* BUG: raw negative index */ cf->data[crc8->result_idx] = ...; /* BUG: raw negative index */ With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame, calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf->data[-64], and the write goes to cf->data[-64]. This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before the start of the canfd_frame on the heap. The companion function cgw_csum_xor_rel() uses `from`/`to`/`res` correctly throughout; fix cgw_csum_crc8_rel() to match. Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62 To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31483", "url": "https://ubuntu.com/security/CVE-2026-31483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/syscalls: Add spectre boundary for syscall dispatch table The s390 syscall number is directly controlled by userspace, but does not have an array_index_nospec() boundary to prevent access past the syscall function pointer tables.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31485", "url": "https://ubuntu.com/security/CVE-2026-31485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-lpspi: fix teardown order issue (UAF) There is a teardown order issue in the driver. The SPI controller is registered using devm_spi_register_controller(), which delays unregistration of the SPI controller until after the fsl_lpspi_remove() function returns. As the fsl_lpspi_remove() function synchronously tears down the DMA channels, a running SPI transfer triggers the following NULL pointer dereference due to use after free: | fsl_lpspi 42550000.spi: I/O Error in DMA RX | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] | Call trace: | fsl_lpspi_dma_transfer+0x260/0x340 [spi_fsl_lpspi] | fsl_lpspi_transfer_one+0x198/0x448 [spi_fsl_lpspi] | spi_transfer_one_message+0x49c/0x7c8 | __spi_pump_transfer_message+0x120/0x420 | __spi_sync+0x2c4/0x520 | spi_sync+0x34/0x60 | spidev_message+0x20c/0x378 [spidev] | spidev_ioctl+0x398/0x750 [spidev] [...] Switch from devm_spi_register_controller() to spi_register_controller() in fsl_lpspi_probe() and add the corresponding spi_unregister_controller() in fsl_lpspi_remove().", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31565", "url": "https://ubuntu.com/security/CVE-2026-31565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix deadlock during netdev reset with active connections Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering device_delete and subsequent client removal. During client removal, uverbs_client waits for QP reference count to reach zero while cma_client holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31494", "url": "https://ubuntu.com/security/CVE-2026-31494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: use the current queue number for stats There's a potential mismatch between the memory reserved for statistics and the amount of memory written. gem_get_sset_count() correctly computes the number of stats based on the active queues, whereas gem_get_ethtool_stats() indiscriminately copies data using the maximum number of queues, and in the case the number of active queues is less than MACB_MAX_QUEUES, this results in a OOB write as observed in the KASAN splat. ================================================================== BUG: KASAN: vmalloc-out-of-bounds in gem_get_ethtool_stats+0x54/0x78 [macb] Write of size 760 at addr ffff80008080b000 by task ethtool/1027 CPU: [...] Tainted: [E]=UNSIGNED_MODULE Hardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 print_report+0x384/0x5e0 kasan_report+0xa0/0xf0 kasan_check_range+0xe8/0x190 __asan_memcpy+0x54/0x98 gem_get_ethtool_stats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] dev_ethtool+0x1220/0x38c0 dev_ioctl+0x4ac/0xca8 sock_do_ioctl+0x170/0x1d8 sock_ioctl+0x484/0x5d8 __arm64_sys_ioctl+0x12c/0x1b8 invoke_syscall+0xd4/0x258 el0_svc_common.constprop.0+0xb4/0x240 do_el0_svc+0x48/0x68 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 The buggy address belongs to a 1-page vmalloc region starting at 0xffff80008080b000 allocated at dev_ethtool+0x11f0/0x38c0 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff00000a333000 pfn:0xa333 flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff) raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== Fix it by making sure the copied size only considers the active number of queues.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31495", "url": "https://ubuntu.com/security/CVE-2026-31495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: use netlink policy range checks Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors. - CTA_PROTOINFO_TCP_STATE: reject values > TCP_CONNTRACK_SYN_SENT2 at policy level, removing the manual >= TCP_CONNTRACK_MAX check. - CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values > TCP_MAX_WSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count. - CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with CTA_FILTER_F_ALL, removing the manual mask checks. - CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding a new mask define grouping all valid expect flags. Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31427", "url": "https://ubuntu.com/security/CVE-2026-31427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp process_sdp() declares union nf_inet_addr rtp_addr on the stack and passes it to the nf_nat_sip sdp_session hook after walking the SDP media descriptions. However rtp_addr is only initialized inside the media loop when a recognized media type with a non-zero port is found. If the SDP body contains no m= lines, only inactive media sections (m=audio 0 ...) or only unrecognized media types, rtp_addr is never assigned. Despite that, the function still calls hooks->sdp_session() with &rtp_addr, causing nf_nat_sdp_session() to format the stale stack value as an IP address and rewrite the SDP session owner and connection lines with it. With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this results in the session-level o= and c= addresses being rewritten to 0.0.0.0 for inactive SDP sessions. Without stack auto-init the rewritten address is whatever happened to be on the stack. Fix this by pre-initializing rtp_addr from the session-level connection address (caddr) when available, and tracking via a have_rtp_addr flag whether any valid address was established. Skip the sdp_session hook entirely when no valid address exists.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31674", "url": "https://ubuntu.com/security/CVE-2026-31674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check() Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS. rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[]. Validate addrnr during rule installation so malformed rules are rejected before the match logic can use an out-of-range value.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31428", "url": "https://ubuntu.com/security/CVE-2026-31428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD __build_packet_message() manually constructs the NFULA_PAYLOAD netlink attribute using skb_put() and skb_copy_bits(), bypassing the standard nla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes are allocated (including NLA alignment padding), only data_len bytes of actual packet data are copied. The trailing nla_padlen(data_len) bytes (1-3 when data_len is not 4-byte aligned) are never initialized, leaking stale heap contents to userspace via the NFLOG netlink socket. Replace the manual attribute construction with nla_reserve(), which handles the tailroom check, header setup, and padding zeroing via __nla_reserve(). The subsequent skb_copy_bits() fills in the payload data on top of the properly initialized attribute.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31497", "url": "https://ubuntu.com/security/CVE-2026-31497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: clamp SCO altsetting table indices btusb_work() maps the number of active SCO links to USB alternate settings through a three-entry lookup table when CVSD traffic uses transparent voice settings. The lookup currently indexes alts[] with data->sco_num - 1 without first constraining sco_num to the number of available table entries. While the table only defines alternate settings for up to three SCO links, data->sco_num comes from hci_conn_num() and is used directly. Cap the lookup to the last table entry before indexing it so the driver keeps selecting the highest supported alternate setting without reading past alts[].", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31498", "url": "https://ubuntu.com/security/CVE-2026-31498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop l2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTED state to support L2CAP reconfiguration (e.g. MTU changes). However, since both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set from the initial configuration, the reconfiguration path falls through to l2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, and retrans_list without freeing the previous allocations and sets chan->sdu to NULL without freeing the existing skb. This leaks all previously allocated ERTM resources. Additionally, l2cap_parse_conf_req() does not validate the minimum value of remote_mps derived from the RFC max_pdu_size option. A zero value propagates to l2cap_segment_sdu() where pdu_len becomes zero, causing the while loop to never terminate since len is never decremented, exhausting all available memory. Fix the double-init by skipping l2cap_ertm_init() and l2cap_chan_ready() when the channel is already in BT_CONNECTED state, while still allowing the reconfiguration parameters to be updated through l2cap_parse_conf_req(). Also add a pdu_len zero check in l2cap_segment_sdu() as a safeguard.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31507", "url": "https://ubuntu.com/security/CVE-2026-31507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffer smc_rx_splice() allocates one smc_spd_priv per pipe_buffer and stores the pointer in pipe_buffer.private. The pipe_buf_operations for these buffers used .get = generic_pipe_buf_get, which only increments the page reference count when tee(2) duplicates a pipe buffer. The smc_spd_priv pointer itself was not handled, so after tee() both the original and the cloned pipe_buffer share the same smc_spd_priv *. When both pipes are subsequently released, smc_rx_pipe_buf_release() is called twice against the same object: 1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct] 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF] KASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), which then escalates to a NULL-pointer dereference and kernel panic via smc_rx_update_consumer() when it chases the freed priv->smc pointer: BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x650 kasan_report+0xc6/0x100 smc_rx_pipe_buf_release+0x78/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smc_rx_update_consumer+0x8d/0x350 Call Trace: smc_rx_pipe_buf_release+0x121/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception Beyond the memory-safety problem, duplicating an SMC splice buffer is semantically questionable: smc_rx_update_cons() would advance the consumer cursor twice for the same data, corrupting receive-window accounting. A refcount on smc_spd_priv could fix the double-free, but the cursor-accounting issue would still need to be addressed separately. The .get callback is invoked by both tee(2) and splice_pipe_to_pipe() for partial transfers; both will now return -EFAULT. Users who need to duplicate SMC socket data must use a copy-based read path.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31679", "url": "https://ubuntu.com/security/CVE-2026-31679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: validate MPLS set/set_masked payload length validate_set() accepted OVS_KEY_ATTR_MPLS as variable-sized payload for SET/SET_MASKED actions. In action handling, OVS expects fixed-size MPLS key data (struct ovs_key_mpls). Use the already normalized key_len (masked case included) and reject non-matching MPLS action key sizes. Reject invalid MPLS action payload lengths early.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31508", "url": "https://ubuntu.com/security/CVE-2026-31508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Avoid releasing netdev before teardown completes The patch cited in the Fixes tag below changed the teardown code for OVS ports to no longer unconditionally take the RTNL. After this change, the netdev_destroy() callback can proceed immediately to the call_rcu() invocation if the IFF_OVS_DATAPATH flag is already cleared on the netdev. The ovs_netdev_detach_dev() function clears the flag before completing the unregistration, and if it gets preempted after clearing the flag (as can happen on an -rt kernel), netdev_destroy() can complete and the device can be freed before the unregistration completes. This leads to a splat like: [ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025 [ 998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0 [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90 [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246 [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000 [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0 [ 998.393944] PKRU: 55555554 [ 998.393946] Call Trace: [ 998.393949] [ 998.393952] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393961] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393975] ? dp_device_event+0x41/0x80 [openvswitch] [ 998.394009] ? __die_body.cold+0x8/0x12 [ 998.394016] ? die_addr+0x3c/0x60 [ 998.394027] ? exc_general_protection+0x16d/0x390 [ 998.394042] ? asm_exc_general_protection+0x26/0x30 [ 998.394058] ? dev_set_promiscuity+0x8d/0xa0 [ 998.394066] ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch] [ 998.394092] dp_device_event+0x41/0x80 [openvswitch] [ 998.394102] notifier_call_chain+0x5a/0xd0 [ 998.394106] unregister_netdevice_many_notify+0x51b/0xa60 [ 998.394110] rtnl_dellink+0x169/0x3e0 [ 998.394121] ? rt_mutex_slowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlink_rcv_msg+0x142/0x3f0 [ 998.394128] ? avc_has_perm_noaudit+0x69/0xf0 [ 998.394130] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 998.394132] netlink_rcv_skb+0x50/0x100 [ 998.394138] netlink_unicast+0x292/0x3f0 [ 998.394141] netlink_sendmsg+0x21b/0x470 [ 998.394145] ____sys_sendmsg+0x39d/0x3d0 [ 998.394149] ___sys_sendmsg+0x9a/0xe0 [ 998.394156] __sys_sendmsg+0x7a/0xd0 [ 998.394160] do_syscall_64+0x7f/0x170 [ 998.394162] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 998.394165] RIP: 0033:0x7fad61bf4724 [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724 [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003 [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2 ---truncated---", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31509", "url": "https://ubuntu.com/security/CVE-2026-31509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix circular locking dependency in nci_close_device nci_close_device() flushes rx_wq and tx_wq while holding req_lock. This causes a circular locking dependency because nci_rx_work() running on rx_wq can end up taking req_lock too: nci_rx_work -> nci_rx_data_packet -> nci_data_exchange_complete -> __sk_destruct -> rawsock_destruct -> nfc_deactivate_target -> nci_deactivate_target -> nci_request -> mutex_lock(&ndev->req_lock) Move the flush of rx_wq after req_lock has been released. This should safe (I think) because NCI_UP has already been cleared and the transport is closed, so the work will see it and return -ENETDOWN. NIPA has been hitting this running the nci selftest with a debug kernel on roughly 4% of the runs.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31510", "url": "https://ubuntu.com/security/CVE-2026-31510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb Before using sk pointer, check if it is null. Fix the following: KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267] CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025 Workqueue: events l2cap_info_timeout RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce veth0_macvtap: entered promiscuous mode RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: __kasan_check_byte+0x12/0x40 lock_acquire+0x79/0x2e0 lock_sock_nested+0x48/0x100 ? l2cap_sock_ready_cb+0x46/0x160 l2cap_sock_ready_cb+0x46/0x160 l2cap_conn_start+0x779/0xff0 ? __pfx_l2cap_conn_start+0x10/0x10 ? l2cap_info_timeout+0x60/0xa0 ? __pfx___mutex_lock+0x10/0x10 l2cap_info_timeout+0x68/0xa0 ? process_scheduled_works+0xa8d/0x18c0 process_scheduled_works+0xb6e/0x18c0 ? __pfx_process_scheduled_works+0x10/0x10 ? assign_work+0x3d5/0x5e0 worker_thread+0xa53/0xfc0 kthread+0x388/0x470 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x51e/0xb90 ? __pfx_ret_from_fork+0x10/0x10 veth1_macvtap: entered promiscuous mode ? __switch_to+0xc7d/0x1450 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- batman_adv: batadv0: Interface activated: batadv_slave_0 batman_adv: batadv0: Interface activated: batadv_slave_1 netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce ieee80211 phy39: Selected rate control algorithm 'minstrel_ht' RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43069", "url": "https://ubuntu.com/security/CVE-2026-43069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_ll: Fix firmware leak on error path Smatch reports: drivers/bluetooth/hci_ll.c:587 download_firmware() warn: 'fw' from request_firmware() not released on lines: 544. In download_firmware(), if request_firmware() succeeds but the returned firmware content is invalid (no data or zero size), the function returns without releasing the firmware, resulting in a resource leak. Fix this by calling release_firmware() before returning when request_firmware() succeeded but the firmware content is invalid.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31408", "url": "https://ubuntu.com/security/CVE-2026-31408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold sco_recv_frame() reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold a reference under the lock. Fix by using sco_sock_hold() to take a reference before releasing the lock, and adding sock_put() on all exit paths.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-31512", "url": "https://ubuntu.com/security/CVE-2026-31512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv() l2cap_ecred_data_rcv() reads the SDU length field from skb->data using get_unaligned_le16() without first verifying that skb contains at least L2CAP_SDULEN_SIZE (2) bytes. When skb->len is less than 2, this reads past the valid data in the skb. The ERTM reassembly path correctly calls pskb_may_pull() before reading the SDU length (l2cap_reassemble_sdu, L2CAP_SAR_START case). Apply the same validation to the Enhanced Credit Based Flow Control data path.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31515", "url": "https://ubuntu.com/security/CVE-2026-31515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_key: validate families in pfkey_send_migrate() syzbot was able to trigger a crash in skb_put() [1] Issue is that pfkey_send_migrate() does not check old/new families, and that set_ipsecrequest() @family argument was truncated, thus possibly overfilling the skb. Validate families early, do not wait set_ipsecrequest(). [1] skbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev: kernel BUG at net/core/skbuff.c:214 ! Call Trace: skb_over_panic net/core/skbuff.c:219 [inline] skb_put+0x159/0x210 net/core/skbuff.c:2655 skb_put_zero include/linux/skbuff.h:2788 [inline] set_ipsecrequest net/key/af_key.c:3532 [inline] pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636 km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848 xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705 xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31518", "url": "https://ubuntu.com/security/CVE-2026-31518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: esp: fix skb leak with espintcp and async crypto When the TX queue for espintcp is full, esp_output_tail_tcp will return an error and not free the skb, because with synchronous crypto, the common xfrm output code will drop the packet for us. With async crypto (esp_output_done), we need to drop the skb when esp_output_tail_tcp returns an error.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31521", "url": "https://ubuntu.com/security/CVE-2026-31521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: module: Fix kernel panic when a symbol st_shndx is out of bounds The module loader doesn't check for bounds of the ELF section index in simplify_symbols(): for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) { \t\tconst char *name = info->strtab + sym[i].st_name; \t\tswitch (sym[i].st_shndx) { \t\tcase SHN_COMMON: \t\t[...] \t\tdefault: \t\t\t/* Divert to percpu allocation if a percpu var. */ \t\t\tif (sym[i].st_shndx == info->index.pcpu) \t\t\t\tsecbase = (unsigned long)mod_percpu(mod); \t\t\telse /** HERE --> **/\t\tsecbase = info->sechdrs[sym[i].st_shndx].sh_addr; \t\t\tsym[i].st_value += secbase; \t\t\tbreak; \t\t} \t} A symbol with an out-of-bounds st_shndx value, for example 0xffff (known as SHN_XINDEX or SHN_HIRESERVE), may cause a kernel panic: BUG: unable to handle page fault for address: ... RIP: 0010:simplify_symbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exception This can happen when module ELF is legitimately using SHN_XINDEX or when it is corrupted. Add a bounds check in simplify_symbols() to validate that st_shndx is within the valid range before using it. This issue was discovered due to a bug in llvm-objcopy, see relevant discussion for details [1]. [1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31522", "url": "https://ubuntu.com/security/CVE-2026-31522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: avoid memory leak in magicmouse_report_fixup() The magicmouse_report_fixup() function was returning a newly kmemdup()-allocated buffer, but never freeing it. The caller of report_fixup() does not take ownership of the returned pointer, but it *is* permitted to return a sub-portion of the input rdesc, whose lifetime is managed by the caller.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31523", "url": "https://ubuntu.com/security/CVE-2026-31523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-pci: ensure we're polling a polled queue A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31524", "url": "https://ubuntu.com/security/CVE-2026-31524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: asus: avoid memory leak in asus_report_fixup() The asus_report_fixup() function was returning a newly allocated kmemdup()-allocated buffer, but never freeing it. Switch to devm_kzalloc() to ensure the memory is managed and freed automatically when the device is removed. The caller of report_fixup() does not take ownership of the returned pointer, but it is permitted to return a pointer whose lifetime is at least that of the input buffer. Also fix a harmless out-of-bounds read by copying only the original descriptor size.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31788", "url": "https://ubuntu.com/security/CVE-2026-31788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: restrict usage in unprivileged domU The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains. In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature. The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest. Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today. The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot. This is XSA-482 --- V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich)", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31540", "url": "https://ubuntu.com/security/CVE-2026-31540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Check set_default_submission() before deferencing When the i915 driver firmware binaries are not present, the set_default_submission pointer is not set. This pointer is dereferenced during suspend anyways. Add a check to make sure it is set before dereferencing. [ 23.289926] PM: suspend entry (deep) [ 23.293558] Filesystems sync: 0.000 seconds [ 23.298010] Freezing user space processes [ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds) [ 23.309766] OOM killer disabled. [ 23.313027] Freezing remaining freezable tasks [ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 23.342038] serial 00:05: disabled [ 23.345719] serial 00:02: disabled [ 23.349342] serial 00:01: disabled [ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 23.361635] ata1.00: Entering standby power mode [ 23.368863] ata2.00: Entering standby power mode [ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 23.452194] #PF: supervisor instruction fetch in kernel mode [ 23.457896] #PF: error_code(0x0010) - not-present page [ 23.463065] PGD 0 P4D 0 [ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI [ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary) [ 23.482512] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 23.496511] Workqueue: async async_run_entry_fn [ 23.501087] RIP: 0010:0x0 [ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246 [ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f [ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000 [ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff [ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8 [ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68 [ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000 [ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0 [ 23.572539] PKRU: 55555554 [ 23.575281] Call Trace: [ 23.577770] [ 23.579905] intel_engines_reset_default_submission+0x42/0x60 [ 23.585695] __intel_gt_unset_wedged+0x191/0x200 [ 23.590360] intel_gt_unset_wedged+0x20/0x40 [ 23.594675] gt_sanitize+0x15e/0x170 [ 23.598290] i915_gem_suspend_late+0x6b/0x180 [ 23.602692] i915_drm_suspend_late+0x35/0xf0 [ 23.607008] ? __pfx_pci_pm_suspend_late+0x10/0x10 [ 23.611843] dpm_run_callback+0x78/0x1c0 [ 23.615817] device_suspend_late+0xde/0x2e0 [ 23.620037] async_suspend_late+0x18/0x30 [ 23.624082] async_run_entry_fn+0x25/0xa0 [ 23.628129] process_one_work+0x15b/0x380 [ 23.632182] worker_thread+0x2a5/0x3c0 [ 23.635973] ? __pfx_worker_thread+0x10/0x10 [ 23.640279] kthread+0xf6/0x1f0 [ 23.643464] ? __pfx_kthread+0x10/0x10 [ 23.647263] ? __pfx_kthread+0x10/0x10 [ 23.651045] ret_from_fork+0x131/0x190 [ 23.654837] ? __pfx_kthread+0x10/0x10 [ 23.658634] ret_from_fork_asm+0x1a/0x30 [ 23.662597] [ 23.664826] Modules linked in: [ 23.667914] CR2: 0000000000000000 [ 23.671271] ------------[ cut here ]------------ (cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad)", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23434", "url": "https://ubuntu.com/security/CVE-2026-23434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: serialize lock/unlock against other NAND operations nand_lock() and nand_unlock() call into chip->ops.lock_area/unlock_area without holding the NAND device lock. On controllers that implement SET_FEATURES via multiple low-level PIO commands, these can race with concurrent UBI/UBIFS background erase/write operations that hold the device lock, resulting in cmd_pending conflicts on the NAND controller. Add nand_get_device()/nand_release_device() around the lock/unlock operations to serialize them against all other NAND controller access.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23398", "url": "https://ubuntu.com/security/CVE-2026-23398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: fix NULL pointer dereference in icmp_tag_validation() icmp_tag_validation() unconditionally dereferences the result of rcu_dereference(inet_protos[proto]) without checking for NULL. The inet_protos[] array is sparse -- only about 15 of 256 protocol numbers have registered handlers. When ip_no_pmtu_disc is set to 3 (hardened PMTU mode) and the kernel receives an ICMP Fragmentation Needed error with a quoted inner IP header containing an unregistered protocol number, the NULL dereference causes a kernel panic in softirq context. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) Add a NULL check before accessing icmp_strict_tag_validation. If the protocol has no registered handler, return false since it cannot perform strict tag validation.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-23438", "url": "https://ubuntu.com/security/CVE-2026-23438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: guard flow control update with global_tx_fc in buffer switching mvpp2_bm_switch_buffers() unconditionally calls mvpp2_bm_pool_update_priv_fc() when switching between per-cpu and shared buffer pool modes. This function programs CM3 flow control registers via mvpp2_cm3_read()/mvpp2_cm3_write(), which dereference priv->cm3_base without any NULL check. When the CM3 SRAM resource is not present in the device tree (the third reg entry added by commit 60523583b07c (\"dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree\")), priv->cm3_base remains NULL and priv->global_tx_fc is false. Any operation that triggers mvpp2_bm_switch_buffers(), for example an MTU change that crosses the jumbo frame threshold, will crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2_cm3_read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2_bm_pool_update_fc+0x40/0x12c mvpp2_bm_pool_update_priv_fc+0x94/0xd8 mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0 mvpp2_change_mtu+0x140/0x380 __dev_set_mtu+0x1c/0x38 dev_set_mtu_ext+0x78/0x118 dev_set_mtu+0x48/0xa8 dev_ifsioc+0x21c/0x43c dev_ioctl+0x2d8/0x42c sock_ioctl+0x314/0x378 Every other flow control call site in the driver already guards hardware access with either priv->global_tx_fc or port->tx_fc. mvpp2_bm_switch_buffers() is the only place that omits this check. Add the missing priv->global_tx_fc guard to both the disable and re-enable calls in mvpp2_bm_switch_buffers(), consistent with the rest of the driver.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23397", "url": "https://ubuntu.com/security/CVE-2026-23397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfnetlink_osf: validate individual option lengths in fingerprints nfnl_osf_add_callback() validates opt_num bounds and string NUL-termination but does not check individual option length fields. A zero-length option causes nf_osf_match_one() to enter the option matching loop even when foptsize sums to zero, which matches packets with no TCP options where ctx->optp is NULL: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:227) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:293) nf_hook_slow (net/netfilter/core.c:623) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) Additionally, an MSS option (kind=2) with length < 4 causes out-of-bounds reads when nf_osf_match_one() unconditionally accesses optp[2] and optp[3] for MSS value extraction. While RFC 9293 section 3.2 specifies that the MSS option is always exactly 4 bytes (Kind=2, Length=4), the check uses \"< 4\" rather than \"!= 4\" because lengths greater than 4 do not cause memory safety issues -- the buffer is guaranteed to be at least foptsize bytes by the ctx->optsize == foptsize check. Reject fingerprints where any option has zero length, or where an MSS option has length less than 4, at add time rather than trusting these values in the packet matching hot path.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-31546", "url": "https://ubuntu.com/security/CVE-2026-31546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL deref in bond_debug_rlb_hash_show rlb_clear_slave intentionally keeps RLB hash-table entries on the rx_hashtbl_used_head list with slave set to NULL when no replacement slave is available. However, bond_debug_rlb_hash_show visites client_info->slave without checking if it's NULL. Other used-list iterators in bond_alb.c already handle this NULL-slave state safely: - rlb_update_client returns early on !client_info->slave - rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalance compare slave values before visiting - lb_req_update_subnet_clients continues if slave is NULL The following NULL deref crash can be trigger in bond_debug_rlb_hash_show: [ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seq_read_iter (fs/seq_file.c:231) [ 1.296341] seq_read (fs/seq_file.c:164) [ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfs_read (fs/read_write.c:572) [ 1.296981] ksys_read (fs/read_write.c:717) [ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) [ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add a NULL check and print \"(none)\" for entries with no assigned slave.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23439", "url": "https://ubuntu.com/security/CVE-2026-23439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n When CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0 (success) without actually creating a socket. Callers such as fou_create() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference. The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764) [...] Call Trace: genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130) This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23396", "url": "https://ubuntu.com/security/CVE-2026-23396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix NULL deref in mesh_matches_local() mesh_matches_local() unconditionally dereferences ie->mesh_config to compare mesh configuration parameters. When called from mesh_rx_csa_frame(), the parsed action-frame elements may not contain a Mesh Configuration IE, leaving ie->mesh_config NULL and triggering a kernel NULL pointer dereference. The other two callers are already safe: - ieee80211_mesh_rx_bcn_presp() checks !elems->mesh_config before calling mesh_matches_local() - mesh_plink_get_event() is only reached through mesh_process_plink_frame(), which checks !elems->mesh_config, too mesh_rx_csa_frame() is the only caller that passes raw parsed elements to mesh_matches_local() without guarding mesh_config. An adjacent attacker can exploit this by sending a crafted CSA action frame that includes a valid Mesh ID IE but omits the Mesh Configuration IE, crashing the kernel. The captured crash log: Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events_unbound cfg80211_wiphy_work [...] Call Trace: ? __pfx_mesh_matches_local (net/mac80211/mesh.c:65) ieee80211_mesh_rx_queued_mgmt (net/mac80211/mesh.c:1686) [...] ieee80211_iface_work (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802) [...] cfg80211_wiphy_work (net/wireless/core.c:426) process_one_work (net/kernel/workqueue.c:3280) ? assign_work (net/kernel/workqueue.c:1219) worker_thread (net/kernel/workqueue.c:3352) ? __pfx_worker_thread (net/kernel/workqueue.c:3385) kthread (net/kernel/kthread.c:436) [...] ret_from_fork_asm (net/arch/x86/entry/entry_64.S:255) This patch adds a NULL check for ie->mesh_config at the top of mesh_matches_local() to return false early when the Mesh Configuration IE is absent.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-23446", "url": "https://ubuntu.com/security/CVE-2026-23446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: Do not perform PM inside suspend callback syzbot reports \"task hung in rpm_resume\" This is caused by aqc111_suspend calling the PM variant of its write_cmd routine. The simplified call trace looks like this: rpm_suspend() usb_suspend_both() - here udev->dev.power.runtime_status == RPM_SUSPENDING aqc111_suspend() - called for the usb device interface aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() - here we call rpm_resume() on our parent rpm_resume() - Here we wait for a status change that will never happen. At this point we block another task which holds rtnl_lock and locks up the whole networking stack. Fix this by replacing the write_cmd calls with their _nopm variants", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23452", "url": "https://ubuntu.com/security/CVE-2026-23452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM: runtime: Fix a race condition related to device removal The following code in pm_runtime_work() may dereference the dev->parent pointer after the parent device has been freed: \t/* Maybe the parent is now able to suspend. */ \tif (parent && !parent->power.ignore_children) { \t\tspin_unlock(&dev->power.lock); \t\tspin_lock(&parent->power.lock); \t\trpm_idle(parent, RPM_ASYNC); \t\tspin_unlock(&parent->power.lock); \t\tspin_lock(&dev->power.lock); \t} Fix this by inserting a flush_work() call in pm_runtime_remove(). Without this patch blktest block/001 triggers the following complaint sporadically: BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160 Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081 Workqueue: pm pm_runtime_work Call Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0 __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160 _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 Allocated by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50 __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23454", "url": "https://ubuntu.com/security/CVE-2026-23454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: fix use-after-free in mana_hwc_destroy_channel() by reordering teardown A potential race condition exists in mana_hwc_destroy_channel() where hwc->caller_ctx is freed before the HWC's Completion Queue (CQ) and Event Queue (EQ) are destroyed. This allows an in-flight CQ interrupt handler to dereference freed memory, leading to a use-after-free or NULL pointer dereference in mana_hwc_handle_resp(). mana_smc_teardown_hwc() signals the hardware to stop but does not synchronize against IRQ handlers already executing on other CPUs. The IRQ synchronization only happens in mana_hwc_destroy_cq() via mana_gd_destroy_eq() -> mana_gd_deregister_irq(). Since this runs after kfree(hwc->caller_ctx), a concurrent mana_hwc_rx_event_handler() can dereference freed caller_ctx (and rxq->msg_buf) in mana_hwc_handle_resp(). Fix this by reordering teardown to reverse-of-creation order: destroy the TX/RX work queues and CQ/EQ before freeing hwc->caller_ctx. This ensures all in-flight interrupt handlers complete before the memory they access is freed.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23391", "url": "https://ubuntu.com/security/CVE-2026-23391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_CT: drop pending enqueued packets on template removal Templates refer to objects that can go away while packets are sitting in nfqueue refer to: - helper, this can be an issue on module removal. - timeout policy, nfnetlink_cttimeout might remove it. The use of templates with zone and event cache filter are safe, since this just copies values. Flush these enqueued packets in case the template rule gets removed.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43060", "url": "https://ubuntu.com/security/CVE-2026-43060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: drop pending enqueued packets on removal Packets sitting in nfqueue might hold a reference to: - templates that specify the conntrack zone, because a percpu area is used and module removal is possible. - conntrack timeout policies and helper, where object removal leave a stale reference. Since these objects can just go away, drop enqueued packets to avoid stale reference to them. If there is a need for finer grain removal, this logic can be revisited to make selective packet drop upon dependencies.", "cve_priority": "high", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2025-68206", "url": "https://ubuntu.com/security/CVE-2025-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: add seqadj extension for natted connections Sequence adjustment may be required for FTP traffic with PASV/EPSV modes. due to need to re-write packet payload (IP, port) on the ftp control connection. This can require changes to the TCP length and expected seq / ack_seq. The easiest way to reproduce this issue is with PASV mode. Example ruleset: table inet ftp_nat { ct helper ftp_helper { type \"ftp\" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set \"ftp_helper\" } } table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { \t\t\t192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { \t\t\t192.168.13.2 : 192.168.100.1/32 } } } Note that the ftp helper gets assigned *after* the dnat setup. The inverse (nat after helper assign) is handled by an existing check in nf_nat_setup_info() and will not show the problem. Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ ftp nat changes do not work as expected in this case: Connected to 192.168.100.1. [..] ftp> epsv EPSV/EPRT on IPv4 off. ftp> ls 227 Entering passive mode (192,168,100,1,209,129). 421 Service not available, remote server has closed connection. Kernel logs: Missing nfct_seqadj_ext_add() setup call WARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41 [..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 .. Fix this by adding the required extension when a conntrack helper is assigned to a connection that has a nat binding.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-23456", "url": "https://ubuntu.com/security/CVE-2026-23456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case In decode_int(), the CONS case calls get_bits(bs, 2) to read a length value, then calls get_uint(bs, len) without checking that len bytes remain in the buffer. The existing boundary check only validates the 2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint() reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte slab-out-of-bounds read. Add a boundary check for len bytes after get_bits() and before get_uint().", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23457", "url": "https://ubuntu.com/security/CVE-2026-23457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp() sip_help_tcp() parses the SIP Content-Length header with simple_strtoul(), which returns unsigned long, but stores the result in unsigned int clen. On 64-bit systems, values exceeding UINT_MAX are silently truncated before computing the SIP message boundary. For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32, causing the parser to miscalculate where the current message ends. The loop then treats trailing data in the TCP segment as a second SIP message and processes it through the SDP parser. Fix this by changing clen to unsigned long to match the return type of simple_strtoul(), and reject Content-Length values that exceed the remaining TCP payload length.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23458", "url": "https://ubuntu.com/security/CVE-2026-23458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct() ctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for the netlink dump callback ctnetlink_exp_ct_dump_table(), but drops the conntrack reference immediately after netlink_dump_start(). When the dump spans multiple rounds, the second recvmsg() triggers the dump callback which dereferences the now-freed conntrack via nfct_help(ct), leading to a use-after-free on ct->ext. The bug is that the netlink_dump_control has no .start or .done callbacks to manage the conntrack reference across dump rounds. Other dump functions in the same file (e.g. ctnetlink_get_conntrack) properly use .start/.done callbacks for this purpose. Fix this by adding .start and .done callbacks that hold and release the conntrack reference for the duration of the dump, and move the nfct_help() call after the cb->args[0] early-return check in the dump callback to avoid dereferencing ct->ext unnecessarily. BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133 CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 ? aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0 Allocated by task 133: kmem_cache_alloc_noprof+0x134/0x440 __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180 Freed by task 0: slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2025-39764", "url": "https://ubuntu.com/security/CVE-2025-39764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: remove refcounting in expectation dumpers Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption. AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcount_inc_not_zero(&exp->use)) to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2026-23460", "url": "https://ubuntu.com/security/CVE-2026-23460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect syzkaller reported a bug [1], and the reproducer is available at [2]. ROSE sockets use four sk->sk_state values: TCP_CLOSE, TCP_LISTEN, TCP_SYN_SENT, and TCP_ESTABLISHED. rose_connect() already rejects calls for TCP_ESTABLISHED (-EISCONN) and TCP_CLOSE with SS_CONNECTING (-ECONNREFUSED), but lacks a check for TCP_SYN_SENT. When rose_connect() is called a second time while the first connection attempt is still in progress (TCP_SYN_SENT), it overwrites rose->neighbour via rose_get_neigh(). If that returns NULL, the socket is left with rose->state == ROSE_STATE_1 but rose->neighbour == NULL. When the socket is subsequently closed, rose_release() sees ROSE_STATE_1 and calls rose_write_internal() -> rose_transmit_link(skb, NULL), causing a NULL pointer dereference. Per connect(2), a second connect() while a connection is already in progress should return -EALREADY. Add this missing check for TCP_SYN_SENT to complete the state validation in rose_connect(). [1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271 [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23462", "url": "https://ubuntu.com/security/CVE-2026-23462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: Fix possible UAF This fixes the following trace caused by not dropping l2cap_conn reference when user->remove callback is called: [ 97.809249] l2cap_conn_free: freeing conn ffff88810a171c00 [ 97.809907] CPU: 1 UID: 0 PID: 1419 Comm: repro_standalon Not tainted 7.0.0-rc1-dirty #14 PREEMPT(lazy) [ 97.809935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 97.809947] Call Trace: [ 97.809954] [ 97.809961] dump_stack_lvl (lib/dump_stack.c:122) [ 97.809990] l2cap_conn_free (net/bluetooth/l2cap_core.c:1808) [ 97.810017] l2cap_conn_del (./include/linux/kref.h:66 net/bluetooth/l2cap_core.c:1821 net/bluetooth/l2cap_core.c:1798) [ 97.810055] l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7347 (discriminator 1) net/bluetooth/l2cap_core.c:7340 (discriminator 1)) [ 97.810086] ? __pfx_l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7341) [ 97.810117] hci_conn_hash_flush (./include/net/bluetooth/hci_core.h:2152 (discriminator 2) net/bluetooth/hci_conn.c:2644 (discriminator 2)) [ 97.810148] hci_dev_close_sync (net/bluetooth/hci_sync.c:5360) [ 97.810180] ? __pfx_hci_dev_close_sync (net/bluetooth/hci_sync.c:5285) [ 97.810212] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810242] ? up_write (./arch/x86/include/asm/atomic64_64.h:87 (discriminator 5) ./include/linux/atomic/atomic-arch-fallback.h:2852 (discriminator 5) ./include/linux/atomic/atomic-long.h:268 (discriminator 5) ./include/linux/atomic/atomic-instrumented.h:3391 (discriminator 5) kernel/locking/rwsem.c:1385 (discriminator 5) kernel/locking/rwsem.c:1643 (discriminator 5)) [ 97.810267] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810290] ? rcu_is_watching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/context_tracking.h:128 kernel/rcu/tree.c:752) [ 97.810320] hci_unregister_dev (net/bluetooth/hci_core.c:504 net/bluetooth/hci_core.c:2716) [ 97.810346] vhci_release (drivers/bluetooth/hci_vhci.c:691) [ 97.810375] ? __pfx_vhci_release (drivers/bluetooth/hci_vhci.c:678) [ 97.810404] __fput (fs/file_table.c:470) [ 97.810430] task_work_run (kernel/task_work.c:235) [ 97.810451] ? __pfx_task_work_run (kernel/task_work.c:201) [ 97.810472] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810495] ? do_raw_spin_unlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlock_debug.c:142 (discriminator 5)) [ 97.810527] do_exit (kernel/exit.c:972) [ 97.810547] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810574] ? __pfx_do_exit (kernel/exit.c:897) [ 97.810594] ? lock_acquire (kernel/locking/lockdep.c:470 (discriminator 6) kernel/locking/lockdep.c:5870 (discriminator 6) kernel/locking/lockdep.c:5825 (discriminator 6)) [ 97.810616] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810639] ? do_raw_spin_lock (kernel/locking/spinlock_debug.c:95 (discriminator 4) kernel/locking/spinlock_debug.c:118 (discriminator 4)) [ 97.810664] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810688] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1)) [ 97.810721] do_group_exit (kernel/exit.c:1093) [ 97.810745] get_signal (kernel/signal.c:3007 (discriminator 1)) [ 97.810772] ? security_file_permission (./arch/x86/include/asm/jump_label.h:37 security/security.c:2366) [ 97.810803] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810826] ? vfs_read (fs/read_write.c:555) [ 97.810854] ? __pfx_get_signal (kernel/signal.c:2800) [ 97.810880] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810905] ? __pfx_vfs_read (fs/read_write.c:555) [ 97.810932] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810960] arch_do_signal_or_restart (arch/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31551", "url": "https://ubuntu.com/security/CVE-2026-31551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Fix static_branch_dec() underflow for aql_disable. syzbot reported static_branch_dec() underflow in aql_enable_write(). [0] The problem is that aql_enable_write() does not serialise concurrent write()s to the debugfs. aql_enable_write() checks static_key_false(&aql_disable.key) and later calls static_branch_inc() or static_branch_dec(), but the state may change between the two calls. aql_disable does not need to track inc/dec. Let's use static_branch_enable() and static_branch_disable(). [0]: val == 0 WARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288 Modules linked in: CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full) Tainted: [U]=USER, [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311 Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 <0f> 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00 RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4 RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a R13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98 FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0 Call Trace: __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline] __static_key_slow_dec kernel/jump_label.c:321 [inline] static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336 aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343 short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383 vfs_write+0x2aa/0x1070 fs/read_write.c:684 ksys_pwrite64 fs/read_write.c:793 [inline] __do_sys_pwrite64 fs/read_write.c:801 [inline] __se_sys_pwrite64 fs/read_write.c:798 [inline] __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f530cf9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012 RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010 RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000 R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978 ", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23463", "url": "https://ubuntu.com/security/CVE-2026-23463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: fix race condition in qman_destroy_fq When QMAN_FQ_FLAG_DYNAMIC_FQID is set, there's a race condition between fq_table[fq->idx] state and freeing/allocating from the pool and WARN_ON(fq_table[fq->idx]) in qman_create_fq() gets triggered. Indeed, we can have: Thread A Thread B qman_destroy_fq() qman_create_fq() qman_release_fqid() qman_shutdown_fq() gen_pool_free() -- At this point, the fqid is available again -- qman_alloc_fqid() -- so, we can get the just-freed fqid in thread B -- fq->fqid = fqid; fq->idx = fqid * 2; WARN_ON(fq_table[fq->idx]); fq_table[fq->idx] = fq; fq_table[fq->idx] = NULL; And adding some logs between qman_release_fqid() and fq_table[fq->idx] = NULL makes the WARN_ON() trigger a lot more. To prevent that, ensure that fq_table[fq->idx] is set to NULL before gen_pool_free() is called by using smp_wmb().", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31683", "url": "https://ubuntu.com/security/CVE-2026-31683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: avoid OGM aggregation when skb tailroom is insufficient When OGM aggregation state is toggled at runtime, an existing forwarded packet may have been allocated with only packet_len bytes, while a later packet can still be selected for aggregation. Appending in this case can hit skb_put overflow conditions. Reject aggregation when the target skb tailroom cannot accommodate the new packet. The caller then falls back to creating a new forward packet instead of appending.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31550", "url": "https://ubuntu.com/security/CVE-2026-31550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: bcm: bcm2835-power: Increase ASB control timeout The bcm2835_asb_control() function uses a tight polling loop to wait for the ASB bridge to acknowledge a request. During intensive workloads, this handshake intermittently fails for V3D's master ASB on BCM2711, resulting in \"Failed to disable ASB master for v3d\" errors during runtime PM suspend. As a consequence, the failed power-off leaves V3D in a broken state, leading to bus faults or system hangs on later accesses. As the timeout is insufficient in some scenarios, increase the polling timeout from 1us to 5us, which is still negligible in the context of a power domain transition. Also, replace the open-coded ktime_get_ns()/ cpu_relax() polling loop with readl_poll_timeout_atomic().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23368", "url": "https://ubuntu.com/security/CVE-2026-23368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: register phy led_triggers during probe to avoid AB-BA deadlock There is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and LED_TRIGGER_PHY are enabled: [ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc <-- Trying to get lock \"triggers_list_lock\" via down_write(&triggers_list_lock); [ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234 [ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c [ 1362.065489] [<80651fc4>] phylink_fwnode_phy_connect+0x15c/0x23c [ 1362.071480] [<8066ee18>] mtk_open+0x7c/0xba0 [ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0 [ 1362.080384] [<806d7668>] __dev_change_flags+0x244/0x24c [ 1362.085598] [<806d7698>] dev_change_flags+0x28/0x78 [ 1362.090528] [<807150e4>] dev_ioctl+0x4c0/0x654 <-- Hold lock \"rtnl_mutex\" by calling rtnl_lock(); [ 1362.094985] [<80694360>] sock_ioctl+0x2f4/0x4e0 [ 1362.099567] [<802e9c4c>] sys_ioctl+0x32c/0xd8c [ 1362.104022] [<80014504>] syscall_common+0x34/0x58 Here LED_TRIGGER_PHY is registering LED triggers during phy_attach while holding RTNL and then taking triggers_list_lock. [ 1362.191101] [<806c2640>] register_netdevice_notifier+0x60/0x168 <-- Trying to get lock \"rtnl_mutex\" via rtnl_lock(); [ 1362.197073] [<805504ac>] netdev_trig_activate+0x194/0x1e4 [ 1362.202490] [<8054e28c>] led_trigger_set+0x1d4/0x360 <-- Hold lock \"triggers_list_lock\" by down_read(&triggers_list_lock); [ 1362.207511] [<8054eb38>] led_trigger_write+0xd8/0x14c [ 1362.212566] [<80381d98>] sysfs_kf_bin_write+0x80/0xbc [ 1362.217688] [<8037fcd8>] kernfs_fop_write_iter+0x17c/0x28c [ 1362.223174] [<802cbd70>] vfs_write+0x21c/0x3c4 [ 1362.227712] [<802cc0c4>] ksys_write+0x78/0x12c [ 1362.232164] [<80014504>] syscall_common+0x34/0x58 Here LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takes triggers_list_lock and then RTNL. A classical AB-BA deadlock. phy_led_triggers_registers() does not require the RTNL, it does not make any calls into the network stack which require protection. There is also no requirement the PHY has been attached to a MAC, the triggers only make use of phydev state. This allows the call to phy_led_triggers_registers() to be placed elsewhere. PHY probe() and release() don't hold RTNL, so solving the AB-BA deadlock.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23303", "url": "https://ubuntu.com/security/CVE-2026-23303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Don't log plaintext credentials in cifs_set_cifscreds When debug logging is enabled, cifs_set_cifscreds() logs the key payload and exposes the plaintext username and password. Remove the debug log to avoid exposing credentials.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23335", "url": "https://ubuntu.com/security/CVE-2026-23335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah() struct irdma_create_ah_resp { // 8 bytes, no padding __u32 ah_id; // offset 0 - SET (uresp.ah_id = ah->sc_ah.ah_info.ah_idx) __u8 rsvd[4]; // offset 4 - NEVER SET <- LEAK }; rsvd[4]: 4 bytes of stack memory leaked unconditionally. Only ah_id is assigned before ib_respond_udata(). The reserved members of the structure were not zeroed.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23336", "url": "https://ubuntu.com/security/CVE-2026-23336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel rfkill_block work in wiphy_unregister() There is a use-after-free error in cfg80211_shutdown_all_interfaces found by syzkaller: BUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220 Read of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326 CPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events cfg80211_rfkill_block_work Call Trace: dump_stack_lvl+0x116/0x1f0 print_report+0xcd/0x630 kasan_report+0xe0/0x110 cfg80211_shutdown_all_interfaces+0x213/0x220 cfg80211_rfkill_block_work+0x1e/0x30 process_one_work+0x9cf/0x1b70 worker_thread+0x6c8/0xf10 kthread+0x3c5/0x780 ret_from_fork+0x56d/0x700 ret_from_fork_asm+0x1a/0x30 The problem arises due to the rfkill_block work is not cancelled when wiphy is being unregistered. In order to fix the issue cancel the corresponding work in wiphy_unregister(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23281", "url": "https://ubuntu.com/security/CVE-2026-23281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix use-after-free in lbs_free_adapter() The lbs_free_adapter() function uses timer_delete() (non-synchronous) for both command_timer and tx_lockup_timer before the structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If a timer callback is executing when lbs_free_adapter() is called, the callback will access freed memory since lbs_cfg_free() frees the containing structure immediately after lbs_free_adapter() returns. Both timer callbacks (lbs_cmd_timeout_handler and lbs_tx_lockup_handler) access priv->driver_lock, priv->cur_cmd, priv->dev, and other fields, which would all be use-after-free violations. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning. This bug was introduced in commit 8f641d93c38a (\"libertas: detect TX lockups and reset hardware\") where del_timer() was used instead of del_timer_sync() in the cleanup path. The command_timer has had the same issue since the driver was first written.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-38562", "url": "https://ubuntu.com/security/CVE-2025-38562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference error in generate_encryptionkey If client send two session setups with krb5 authenticate to ksmbd, null pointer dereference error in generate_encryptionkey could happen. sess->Preauth_HashValue is set to NULL if session is valid. So this patch skip generate encryption key if session is valid.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2026-45920", "url": "https://ubuntu.com/security/CVE-2026-45920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix dirtyclusters double decrement on fs shutdown fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count: WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4] Tracing the failure shows that the warning fires due to an s_dirtyclusters_counter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4_mb_mark_diskspace_used() and the caller ext4_mb_new_blocks(). First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4_handle_dirty_metadata() call(s) made from ext4_mb_mark_context(). The changed value is non-zero at this point, so ext4_mb_mark_diskspace_used() does not exit after the error bubbles up from ext4_mb_mark_context(). Instead, the former decrements both cluster counters and returns the error up to ext4_mb_new_blocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency. To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4_mb_new_blocks() is responsible for acquiring cluster reservation (via ext4_claim_free_clusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45899", "url": "https://ubuntu.com/security/CVE-2026-45899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop extent cache when splitting extent fails When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45985", "url": "https://ubuntu.com/security/CVE-2026-45985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues. Assume we have an unwritten extent, and then DIO writes the second half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set. Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree. [0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone. Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45924", "url": "https://ubuntu.com/security/CVE-2026-45924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths There are two places where ksmbd_vfs_kern_path_end_removing() needs to be called in order to balance what the corresponding successful call to ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and put the taken references. Otherwise there might be potential deadlocks and unbalanced locks which are caught like: BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work 2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660 CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30 Found by Linux Verification Center (linuxtesting.org).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23227", "url": "https://ubuntu.com/security/CVE-2026-23227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/free Exynos Virtual Display driver performs memory alloc/free operations without lock protection, which easily causes concurrency problem. For example, use-after-free can occur in race scenario like this: ``` \tCPU0\t\t\t\tCPU1\t\t\t\tCPU2 \t----\t\t\t\t----\t\t\t\t---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... \t\t\t\t\t\t\t\tdrm_mode_getconnector() \t\t\t\t\t\t\t\t drm_helper_probe_single_connector_modes() \t\t\t\t\t\t\t\t vidi_get_modes() \t\t\t\t\t\t\t\t if (ctx->raw_edid) // true \t\t\t\t\t\t\t\t drm_edid_dup(ctx->raw_edid); \t\t\t\t\t\t\t\t if (!drm_edid) // false \t\t\t\t\t\t\t\t ... \t\t\t\tvidi_connection_ioctl() \t\t\t\t if (vidi->connection) // false \t\t\t\t drm_edid_free(ctx->raw_edid); // free drm_edid \t\t\t\t ... \t\t\t\t\t\t\t\t drm_edid_alloc(drm_edid->edid) \t\t\t\t\t\t\t\t kmemdup(edid); // UAF!! \t\t\t\t\t\t\t\t ... ``` To prevent these vulns, at least in vidi_context, member variables related to memory alloc/free should be protected with ctx->lock.", "cve_priority": "high", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-45958", "url": "https://ubuntu.com/security/CVE-2026-45958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: fix to avoid directly dereferencing user pointer In vidi_connection_ioctl(), vidi->edid(user pointer) is directly dereferenced in the kernel. This allows arbitrary kernel memory access from the user space, so instead of directly accessing the user pointer in the kernel, we should modify it to copy edid to kernel memory using copy_from_user() and use it.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45956", "url": "https://ubuntu.com/security/CVE-2026-45956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl() vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to obtain a struct vidi_context pointer. However, drm_dev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device. This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more. To resolve this issue, we need to store/delete the vidi device pointer in exynos_drm_private->vidi_dev during bind/unbind, and then read this exynos_drm_private->vidi_dev within ioctl() to obtain the correct struct vidi_context pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23100", "url": "https://ubuntu.com/security/CVE-2026-23100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb_pmd_shared() Patch series \"mm/hugetlb: fixes for PMD table sharing (incl. using mmu_gather)\", v3. One functional fix, one performance regression fix, and two related comment fixes. I cleaned up my prototype I recently shared [1] for the performance fix, deferring most of the cleanups I had in the prototype to a later point. While doing that I identified the other things. The goal of this patch set is to be backported to stable trees \"fairly\" easily. At least patch #1 and #4. Patch #1 fixes hugetlb_pmd_shared() not detecting any sharing Patch #2 + #3 are simple comment fixes that patch #4 interacts with. Patch #4 is a fix for the reported performance regression due to excessive IPI broadcasts during fork()+exit(). The last patch is all about TLB flushes, IPIs and mmu_gather. Read: complicated There are plenty of cleanups in the future to be had + one reasonable optimization on x86. But that's all out of scope for this series. Runtime tested, with a focus on fixing the performance regression using the original reproducer [2] on x86. This patch (of 4): We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->pt_share_count to identify sharing. We didn't convert hugetlb_pmd_shared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table. Page migration, like mbind() or migrate_pages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as \"private\" although they are \"shared\", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the pagemap interface. Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-43061", "url": "https://ubuntu.com/security/CVE-2026-43061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Fix TX deadlock when using DMA `dmaengine_terminate_async` does not guarantee that the `__dma_tx_complete` callback will run. The callback is currently the only place where `dma->tx_running` gets cleared. If the transaction is canceled and the callback never runs, then `dma->tx_running` will never get cleared and we will never schedule new TX DMA transactions again. This change makes it so we clear `dma->tx_running` after we terminate the DMA transaction. This is \"safe\" because `serial8250_tx_dma_flush` is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to `dma->tx_running` is serialized.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-23474", "url": "https://ubuntu.com/security/CVE-2026-23474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: Avoid boot crash in RedBoot partition table parser Given CONFIG_FORTIFY_SOURCE=y and a recent compiler, commit 439a1bcac648 (\"fortify: Use __builtin_dynamic_object_size() when available\") produces the warning below and an oops. Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000 ------------[ cut here ]------------ WARNING: lib/string_helpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1 memcmp: detected buffer overflow: 15 byte read of buffer size 14 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONE As Kees said, \"'names' is pointing to the final 'namelen' many bytes of the allocation ... 'namelen' could be basically any length at all. This fortify warning looks legit to me -- this code used to be reading beyond the end of the allocation.\" Since the size of the dynamic allocation is calculated with strlen() we can use strcmp() instead of memcmp() and remain within bounds.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31393", "url": "https://ubuntu.com/security/CVE-2026-31393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present: - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8). - L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5). A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data. Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43062", "url": "https://ubuntu.com/security/CVE-2026-43062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp() l2cap_ecred_reconf_rsp() casts the incoming data to struct l2cap_ecred_conn_rsp (the ECRED *connection* response, 8 bytes with result at offset 6) instead of struct l2cap_ecred_reconf_rsp (2 bytes with result at offset 0). This causes two problems: - The sizeof(*rsp) length check requires 8 bytes instead of the correct 2, so valid L2CAP_ECRED_RECONF_RSP packets are rejected with -EPROTO. - rsp->result reads from offset 6 instead of offset 0, returning wrong data when the packet is large enough to pass the check. Fix by using the correct type. Also pass the already byte-swapped result variable to BT_DBG instead of the raw __le16 field.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31396", "url": "https://ubuntu.com/security/CVE-2026-31396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix use-after-free access to PTP clock PTP clock is registered on every opening of the interface and destroyed on every closing. However it may be accessed via get_ts_info ethtool call which is possible while the interface is just present in the kernel. BUG: KASAN: use-after-free in ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 Read of size 4 at addr ffff8880194345cc by task syz.0.6/948 CPU: 1 PID: 948 Comm: syz.0.6 Not tainted 6.1.164+ #109 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x17f/0x496 mm/kasan/report.c:420 kasan_report+0xd9/0x180 mm/kasan/report.c:524 ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 gem_get_ts_info+0x138/0x1e0 drivers/net/ethernet/cadence/macb_main.c:3349 macb_get_ts_info+0x68/0xb0 drivers/net/ethernet/cadence/macb_main.c:3371 __ethtool_get_ts_info+0x17c/0x260 net/ethtool/common.c:558 ethtool_get_ts_info net/ethtool/ioctl.c:2367 [inline] __dev_ethtool net/ethtool/ioctl.c:3017 [inline] dev_ethtool+0x2b05/0x6290 net/ethtool/ioctl.c:3095 dev_ioctl+0x637/0x1070 net/core/dev_ioctl.c:510 sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215 sock_ioctl+0x577/0x6d0 net/socket.c:1320 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 457: kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:699 [inline] ptp_clock_register+0x144/0x10e0 drivers/ptp/ptp_clock.c:235 gem_ptp_init+0x46f/0x930 drivers/net/ethernet/cadence/macb_ptp.c:375 macb_open+0x901/0xd10 drivers/net/ethernet/cadence/macb_main.c:2920 __dev_open+0x2ce/0x500 net/core/dev.c:1501 __dev_change_flags+0x56a/0x740 net/core/dev.c:8651 dev_change_flags+0x92/0x170 net/core/dev.c:8722 do_setlink+0xaf8/0x3a80 net/core/rtnetlink.c:2833 __rtnl_newlink+0xbf4/0x1940 net/core/rtnetlink.c:3608 rtnl_newlink+0x63/0xa0 net/core/rtnetlink.c:3655 rtnetlink_rcv_msg+0x3c6/0xed0 net/core/rtnetlink.c:6150 netlink_rcv_skb+0x15d/0x430 net/netlink/af_netlink.c:2511 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x6d7/0xa30 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x97e/0xeb0 net/netlink/af_netlink.c:1872 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x14b/0x180 net/socket.c:730 __sys_sendto+0x320/0x3b0 net/socket.c:2152 __do_sys_sendto net/socket.c:2164 [inline] __se_sys_sendto net/socket.c:2160 [inline] __x64_sys_sendto+0xdc/0x1b0 net/socket.c:2160 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 938: kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1729 [inline] slab_free_freelist_hook mm/slub.c:1755 [inline] slab_free mm/slub.c:3687 [inline] __kmem_cache_free+0xbc/0x320 mm/slub.c:3700 device_release+0xa0/0x240 drivers/base/core.c:2507 kobject_cleanup lib/kobject.c:681 [inline] kobject_release lib/kobject.c:712 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1cd/0x350 lib/kobject.c:729 put_device+0x1b/0x30 drivers/base/core.c:3805 ptp_clock_unregister+0x171/0x270 drivers/ptp/ptp_clock.c:391 gem_ptp_remove+0x4e/0x1f0 drivers/net/ethernet/cadence/macb_ptp.c:404 macb_close+0x1c8/0x270 drivers/net/ethernet/cadence/macb_main.c:2966 __dev_close_many+0x1b9/0x310 net/core/dev.c:1585 __dev_close net/core/dev.c:1597 [inline] __dev_change_flags+0x2bb/0x740 net/core/dev.c:8649 dev_change_fl ---truncated---", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31545", "url": "https://ubuntu.com/security/CVE-2026-31545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: nxp-nci: allow GPIOs to sleep Allow the firmware and enable GPIOs to sleep. This fixes a `WARN_ON' and allows the driver to operate GPIOs which are connected to I2C GPIO expanders. -- >8 -- kernel: WARNING: CPU: 3 PID: 2636 at drivers/gpio/gpiolib.c:3880 gpiod_set_value+0x88/0x98 -- >8 --", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31399", "url": "https://ubuntu.com/security/CVE-2026-31399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/bus: Fix potential use after free in asynchronous initialization Dingisoul with KASAN reports a use after free if device_add() fails in nd_async_device_register(). Commit b6eae0f61db2 (\"libnvdimm: Hold reference on parent while scheduling async init\") correctly added a reference on the parent device to be held until asynchronous initialization was complete. However, if device_add() results in an allocation failure the ref count of the device drops to 0 prior to the parent pointer being accessed. Thus resulting in use after free. The bug bot AI correctly identified the fix. Save a reference to the parent pointer to be used to drop the parent reference regardless of the outcome of device_add().", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31400", "url": "https://ubuntu.com/security/CVE-2026-31400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix cache_request leak in cache_release When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request. In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup. The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up. Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, dequeue and free the cache_request.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2024-46715", "url": "https://ubuntu.com/security/CVE-2024-46715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver: iio: add missing checks on iio_info's callback access Some callbacks from iio_info structure are accessed without any check, so if a driver doesn't implement them trying to access the corresponding sysfs entries produce a kernel oops such as: [ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute [...] [ 2203.783416] Call trace: [ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48 [ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120 [ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4 [ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0 [ 2203.802236] vfs_read from ksys_read+0xa4/0xd4 [ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54 [ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0) [ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000 [ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000 [ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0 [ 2203.830363] Code: bad PC value [ 2203.832695] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-09-18 07:15:00 UTC" }, { "cve": "CVE-2026-23113", "url": "https://ubuntu.com/security/CVE-2026-23113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't support ->read_iter(), loop_rw_iter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path: INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000 Call Trace: context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98 There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2025-39748", "url": "https://ubuntu.com/security/CVE-2025-39748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Forget ranges when refining tnum after JSET Syzbot reported a kernel warning due to a range invariant violation on the following BPF program. 0: call bpf_get_netns_cookie 1: if r0 == 0 goto 2: if r0 & Oxffffffff goto The issue is on the path where we fall through both jumps. That path is unreachable at runtime: after insn 1, we know r0 != 0, but with the sign extension on the jset, we would only fallthrough insn 2 if r0 == 0. Unfortunately, is_branch_taken() isn't currently able to figure this out, so the verifier walks all branches. The verifier then refines the register bounds using the second condition and we end up with inconsistent bounds on this unreachable path: 1: if r0 == 0 goto r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2: if r0 & 0xffffffff goto r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0) r0 after reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0) Improving the range refinement for JSET to cover all cases is tricky. We also don't expect many users to rely on JSET given LLVM doesn't generate those instructions. So instead of improving the range refinement for JSETs, Eduard suggested we forget the ranges whenever we're narrowing tnums after a JSET. This patch implements that approach.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2026-43357", "url": "https://ubuntu.com/security/CVE-2026-43357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050-core: fix pm_runtime error handling The return value of pm_runtime_get_sync() is not checked, allowing the driver to access hardware that may fail to resume. The device usage count is also unconditionally incremented. Use pm_runtime_resume_and_get() which propagates errors and avoids incrementing the usage count on failure. In preenable, add pm_runtime_put_autosuspend() on set_8khz_samplerate() failure since postdisable does not run when preenable fails.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43476", "url": "https://ubuntu.com/security/CVE-2026-43476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas() sizeof(num) evaluates to sizeof(size_t) (8 bytes on 64-bit) instead of the intended __be32 element size (4 bytes). Use sizeof(*meas) to correctly match the buffer element type.", "cve_priority": "medium", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43363", "url": "https://ubuntu.com/security/CVE-2026-43363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/apic: Disable x2apic on resume if the kernel expects so When resuming from s2ram, firmware may re-enable x2apic mode, which may have been disabled by the kernel during boot either because it doesn't support IRQ remapping or for other reasons. This causes the kernel to continue using the xapic interface, while the hardware is in x2apic mode, which causes hangs. This happens on defconfig + bare metal + s2ram. Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be disabled, i.e. when x2apic_mode = 0. The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the pre-sleep configuration or initial boot configuration for each CPU, including MSR state: When executing from the power-on reset vector as a result of waking from an S2 or S3 sleep state, the platform firmware performs only the hardware initialization required to restore the system to either the state the platform was in prior to the initial operating system boot, or to the pre-sleep configuration state. In multiprocessor systems, non-boot processors should be placed in the same state as prior to the initial operating system boot. (further ahead) If this is an S2 or S3 wake, then the platform runtime firmware restores minimum context of the system before jumping to the waking vector. This includes: \tCPU configuration. Platform runtime firmware restores the pre-sleep \tconfiguration or initial boot configuration of each CPU (MSR, MTRR, \tfirmware update, SMBase, and so on). Interrupts must be disabled (for \tIA-32 processors, disabled by CLI instruction). \t(and other things) So at least as per the spec, re-enablement of x2apic by the firmware is allowed if \"x2apic on\" is a part of the initial boot configuration. [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization [ bp: Massage. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43365", "url": "https://ubuntu.com/security/CVE-2026-43365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix undersized l_iclog_roundoff values If the superblock doesn't list a log stripe unit, we set the incore log roundoff value to 512. This leads to corrupt logs and unmountable filesystems in generic/617 on a disk with 4k physical sectors... XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197. XFS (sda1): failed to locate log tail XFS (sda1): log mount/recovery failed: error -74 XFS (sda1): log mount failed XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Ending clean mount ...on the current xfsprogs for-next which has a broken mkfs. xfs_info shows this... meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1 data = bsize=4096 blocks=2579968, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=4096 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=268435456 extents = zoned=0 start=0 reserved=0 ...observe that the log section has sectsz=4096 sunit=0, which means that the roundoff factor is 512, not 4096 as you'd expect. We should fix mkfs not to generate broken filesystems, but anyone can fuzz the ondisk superblock so we should be more cautious. I think the inadequate logic predates commit a6a65fef5ef8d0, but that's clearly going to require a different backport.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43370", "url": "https://ubuntu.com/security/CVE-2026-43370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix use-after-free race in VM acquire Replace non-atomic vm->process_info assignment with cmpxchg() to prevent race when parent/child processes sharing a drm_file both try to acquire the same VM after fork(). (cherry picked from commit c7c573275ec20db05be769288a3e3bb2250ec618)", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43373", "url": "https://ubuntu.com/security/CVE-2026-43373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ncsi: fix skb leak in error paths Early return paths in NCSI RX and AEN handlers fail to release the received skb, resulting in a memory leak. Specifically, ncsi_aen_handler() returns on invalid AEN packets without consuming the skb. Similarly, ncsi_rcv_rsp() exits early when failing to resolve the NCSI device, response handler, or request, leaving the skb unfreed.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43380", "url": "https://ubuntu.com/security/CVE-2026-43380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read The q54sj108a2_debugfs_read function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes 'data' as the destination and 'data_char' as the source. Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since 'data' is only 34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the end of the buffer onto the stack. Additionally, the arguments were swapped: it was reading from the zero-initialized 'data_char' and writing to 'data', resulting in all-zero output regardless of the actual I2C read. Fix this by: 1. Expanding 'data_char' to 66 bytes to safely hold the hex output. 2. Correcting the bin2hex() argument order and using the actual read count. 3. Using a pointer to select the correct output buffer for the final simple_read_from_buffer call.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43381", "url": "https://ubuntu.com/security/CVE-2026-43381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dpcd: return EBUSY for aux xfer if the device is asleep If we have runtime suspended, and userspace wants to use /dev/drm_dp_* then just tell it the device is busy instead of crashing in the GSP code. WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy) Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024 RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them awake while fw updates are happening.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43382", "url": "https://ubuntu.com/security/CVE-2026-43382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid double-rtnl_lock ELP metric worker batadv_v_elp_get_throughput() might be called when the RTNL lock is already held. This could be problematic when the work queue item is cancelled via cancel_delayed_work_sync() in batadv_v_elp_iface_disable(). In this case, an rtnl_lock() would cause a deadlock. To avoid this, rtnl_trylock() was used in this function to skip the retrieval of the ethtool information in case the RTNL lock was already held. But for cfg80211 interfaces, batadv_get_real_netdev() was called - which also uses rtnl_lock(). The approach for __ethtool_get_link_ksettings() must also be used instead and the lockless version __batadv_get_real_netdev() has to be called.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-31405", "url": "https://ubuntu.com/security/CVE-2026-31405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-net: fix OOB access in ULE extension header tables The ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables in handle_one_ule_extension() are declared with 255 elements (valid indices 0-254), but the index htype is derived from network-controlled data as (ule_sndu_type & 0x00FF), giving a range of 0-255. When htype equals 255, an out-of-bounds read occurs on the function pointer table, and the OOB value may be called as a function pointer. Add a bounds check on htype against the array size before either table is accessed. Out-of-range values now cause the SNDU to be discarded.", "cve_priority": "high", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-43387", "url": "https://ubuntu.com/security/CVE-2026-43387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: properly validate the data in rtw_get_ie_ex() Just like in commit 154828bf9559 (\"staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser\"), we don't trust the data in the frame so we should check the length better before acting on it", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43386", "url": "https://ubuntu.com/security/CVE-2026-43386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie The current code checks 'i + 5 < in_len' at the end of the if statement. However, it accesses 'in_ie[i + 5]' before that check, which can lead to an out-of-bounds read. Move the length check to the beginning of the conditional to ensure the index is within bounds before accessing the array.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43420", "url": "https://ubuntu.com/security/CVE-2026-43420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix i_nlink underrun during async unlink During async unlink, we drop the `i_nlink` counter before we receive the completion (that will eventually update the `i_nlink`) because \"we assume that the unlink will succeed\". That is not a bad idea, but it races against deletions by other clients (or against the completion of our own unlink) and can lead to an underrun which emits a WARNING like this one: WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68 Modules linked in: CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drop_nlink+0x50/0x68 lr : ceph_unlink+0x6c4/0x720 sp : ffff80012173bc90 x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680 x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647 x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203 x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365 x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74 x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94 x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002 x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8 Call trace: drop_nlink+0x50/0x68 (P) vfs_unlink+0xb0/0x2e8 do_unlinkat+0x204/0x288 __arm64_sys_unlinkat+0x3c/0x80 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0xa4/0xc8 el0_svc+0x18/0x58 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x154/0x158 In ceph_unlink(), a call to ceph_mdsc_submit_request() submits the CEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion. Meanwhile, between this call and the following drop_nlink() call, a worker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT or just a CEPH_MSG_CLIENT_REPLY (the latter of which could be our own completion). These will lead to a set_nlink() call, updating the `i_nlink` counter to the value received from the MDS. If that new `i_nlink` value happens to be zero, it is illegal to decrement it further. But that is exactly what ceph_unlink() will do then. The WARNING can be reproduced this way: 1. Force async unlink; only the async code path is affected. Having no real clue about Ceph internals, I was unable to find out why the MDS wouldn't give me the \"Fxr\" capabilities, so I patched get_caps_for_async_unlink() to always succeed. (Note that the WARNING dump above was found on an unpatched kernel, without this kludge - this is not a theoretical bug.) 2. Add a sleep call after ceph_mdsc_submit_request() so the unlink completion gets handled by a worker thread before drop_nlink() is called. This guarantees that the `i_nlink` is already zero before drop_nlink() runs. The solution is to skip the counter decrement when it is already zero, but doing so without a lock is still racy (TOCTOU). Since ceph_fill_inode() and handle_cap_grant() both hold the `ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, this seems like the proper lock to protect the `i_nlink` updates. I found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using `afs_vnode.cb_lock`). All three have the zero check as well.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43405", "url": "https://ubuntu.com/security/CVE-2026-43405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Use u32 for non-negative values in ceph_monmap_decode() This patch fixes unnecessary implicit conversions that change signedness of blob_len and num_mon in ceph_monmap_decode(). Currently blob_len and num_mon are (signed) int variables. They are used to hold values that are always non-negative and get assigned in ceph_decode_32_safe(), which is meant to assign u32 values. Both variables are subsequently used as unsigned values, and the value of num_mon is further assigned to monmap->num_mon, which is of type u32. Therefore, both variables should be of type u32. This is especially relevant for num_mon. If the value read from the incoming message is very large, it is interpreted as a negative value, and the check for num_mon > CEPH_MAX_MON does not catch it. This leads to the attempt to allocate a very large chunk of memory for monmap, which will most likely fail. In this case, an unnecessary attempt to allocate memory is performed, and -ENOMEM is returned instead of -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43411", "url": "https://ubuntu.com/security/CVE-2026-43411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix divide-by-zero in tipc_sk_filter_connect() A user can set conn_timeout to any value via setsockopt(TIPC_CONN_TIMEOUT), including values less than 4. When a SYN is rejected with TIPC_ERR_OVERLOAD and the retry path in tipc_sk_filter_connect() executes: delay %= (tsk->conn_timeout / 4); If conn_timeout is in the range [0, 3], the integer division yields 0, and the modulo operation triggers a divide-by-zero exception, causing a kernel oops/panic. Fix this by clamping conn_timeout to a minimum of 4 at the point of use in tipc_sk_filter_connect(). Oops: divide error: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+ RIP: 0010:tipc_sk_filter_rcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362) Call Trace: tipc_sk_backlog_rcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406) __release_sock (include/net/sock.h:1185 net/core/sock.c:3213) release_sock (net/core/sock.c:3797) tipc_connect (net/tipc/socket.c:2570) __sys_connect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098)", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43484", "url": "https://ubuntu.com/security/CVE-2026-43484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: core: Avoid bitfield RMW for claim/retune flags Move claimed and retune control flags out of the bitfield word to avoid unrelated RMW side effects in asynchronous contexts. The host->claimed bit shared a word with retune flags. Writes to claimed in __mmc_claim_host() or retune_now in mmc_mq_queue_rq() can overwrite other bits when concurrent updates happen in other contexts, triggering spurious WARN_ON(!host->claimed). Convert claimed, can_retune, retune_now and retune_paused to bool to remove shared-word coupling.", "cve_priority": "low", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43425", "url": "https://ubuntu.com/security/CVE-2026-43425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: kill download URB on timeout mdc800_device_read() submits download_urb and waits for completion. If the timeout fires and the device has not responded, the function returns without killing the URB, leaving it active. A subsequent read() resubmits the same URB while it is still in-flight, triggering the WARN in usb_submit_urb(): \"URB submitted while active\" Check the return value of wait_event_timeout() and kill the URB if it indicates timeout, ensuring the URB is complete before its status is inspected or the URB is resubmitted. Similar to - commit 372c93131998 (\"USB: yurex: fix control-URB timeout handling\") - commit b98d5000c505 (\"media: rc: iguanair: handle timeouts\")", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43426", "url": "https://ubuntu.com/security/CVE-2026-43426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: fix use-after-free in ISR during device removal In usbhs_remove(), the driver frees resources (including the pipe array) while the interrupt handler (usbhs_interrupt) is still registered. If an interrupt fires after usbhs_pipe_remove() but before the driver is fully unbound, the ISR may access freed memory, causing a use-after-free. Fix this by calling devm_free_irq() before freeing resources. This ensures the interrupt handler is both disabled and synchronized (waits for any running ISR to complete) before usbhs_pipe_remove() is called.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43427", "url": "https://ubuntu.com/security/CVE-2026-43427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: class: cdc-wdm: fix reordering issue in read code path Quoting the bug report: Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdm_read() can see the new length and call copy_to_user() on uninitialized memory. This also violates LKMM data race rules [1]. Fix it by using WRITE_ONCE and memory barriers.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43428", "url": "https://ubuntu.com/security/CVE-2026-43428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: core: Limit the length of unkillable synchronous timeouts The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device. To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector. In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43429", "url": "https://ubuntu.com/security/CVE-2026-43429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: Use usb_bulk_msg_killable() with user-specified timeouts The usbtmc driver accepts timeout values specified by the user in an ioctl command, and uses these timeouts for some usb_bulk_msg() calls. Since the user can specify arbitrarily long timeouts and usb_bulk_msg() uses unkillable waits, call usb_bulk_msg_killable() instead to avoid the possibility of the user hanging a kernel thread indefinitely.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43430", "url": "https://ubuntu.com/security/CVE-2026-43430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: yurex: fix race in probe The bbu member of the descriptor must be set to the value standing for uninitialized values before the URB whose completion handler sets bbu is submitted. Otherwise there is a window during which probing can overwrite already retrieved data.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43432", "url": "https://ubuntu.com/security/CVE-2026-43432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix memory leak in xhci_disable_slot() xhci_alloc_command() allocates a command structure and, when the second argument is true, also allocates a completion structure. Currently, the error handling path in xhci_disable_slot() only frees the command structure using kfree(), causing the completion structure to leak. Use xhci_free_command() instead of kfree(). xhci_free_command() correctly frees both the command structure and the associated completion structure. Since the command structure is allocated with zero-initialization, command->in_ctx is NULL and will not be erroneously freed by xhci_free_command(). This bug was found using an experimental static analysis tool we are developing. The tool is based on the LLVM framework and is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available, but we plan to open-source it after our research is published. The bug was originally detected on v6.13-rc1 using our static analysis tool, and we have verified that the issue persists in the latest mainline kernel. We performed build testing on x86_64 with allyesconfig using GCC=11.4.0. Since triggering these error paths in xhci_disable_slot() requires specific hardware conditions or abnormal state, we were unable to construct a test case to reliably trigger these specific error paths at runtime.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43439", "url": "https://ubuntu.com/security/CVE-2026-43439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup: fix race between task migration and iteration When a task is migrated out of a css_set, cgroup_migrate_add_task() first moves it from cset->tasks to cset->mg_tasks via: list_move_tail(&task->cg_list, &cset->mg_tasks); If a css_task_iter currently has it->task_pos pointing to this task, css_set_move_task() calls css_task_iter_skip() to keep the iterator valid. However, since the task has already been moved to ->mg_tasks, the iterator is advanced relative to the mg_tasks list instead of the original tasks list. As a result, remaining tasks on cset->tasks, as well as tasks queued on cset->mg_tasks, can be skipped by iteration. Fix this by calling css_set_skip_task_iters() before unlinking task->cg_list from cset->tasks. This advances all active iterators to the next task on cset->tasks, so iteration continues correctly even when a task is concurrently being migrated. This race is hard to hit in practice without instrumentation, but it can be reproduced by artificially slowing down cgroup_procs_show(). For example, on an Android device a temporary /sys/kernel/cgroup/cgroup_test knob can be added to inject a delay into cgroup_procs_show(), and then: 1) Spawn three long-running tasks (PIDs 101, 102, 103). 2) Create a test cgroup and move the tasks into it. 3) Enable a large delay via /sys/kernel/cgroup/cgroup_test. 4) In one shell, read cgroup.procs from the test cgroup. 5) Within the delay window, in another shell migrate PID 102 by writing it to a different cgroup.procs file. Under this setup, cgroup.procs can intermittently show only PID 101 while skipping PID 103. Once the migration completes, reading the file again shows all tasks as expected. Note that this change does not allow removing the existing css_set_skip_task_iters() call in css_set_move_task(). The new call in cgroup_migrate_add_task() only handles iterators that are racing with migration while the task is still on cset->tasks. Iterators may also start after the task has been moved to cset->mg_tasks. If we dropped css_set_skip_task_iters() from css_set_move_task(), such iterators could keep task_pos pointing to a migrating task, causing css_task_iter_advance() to malfunction on the destination css_set, up to and including crashes or infinite loops. The race window between migration and iteration is very small, and css_task_iter is not on a hot path. In the worst case, when an iterator is positioned on the first thread of the migrating process, cgroup_migrate_add_task() may have to skip multiple tasks via css_set_skip_task_iters(). However, this only happens when migration and iteration actually race, so the performance impact is negligible compared to the correctness fix provided here.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43480", "url": "https://ubuntu.com/security/CVE-2026-43480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisition The acp3x_5682_init() function did not check the return value of clk_get(), which could lead to dereferencing error pointers in rt5682_clk_enable(). Fix this by: 1. Changing clk_get() to the device-managed devm_clk_get(). 2. Adding proper IS_ERR() checks for both clock acquisitions.", "cve_priority": "low", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43445", "url": "https://ubuntu.com/security/CVE-2026-43445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: e1000/e1000e: Fix leak in 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 after a successful 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 would leak. In these commits, a faulty while condition caused an infinite loop in dma_error: Commit 03b1320dfcee (\"e1000e: remove use of skb_dma_map from e1000e driver\") Commit 602c0554d7b0 (\"e1000: remove use of skb_dma_map from e1000 driver\") Commit c1fa347f20f1 (\"e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()\") fixed the infinite loop, but introduced the off-by-one error. This issue may still exist in the igbvf driver, but I did not address it in this patch.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43449", "url": "https://ubuntu.com/security/CVE-2026-43449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_set dev->online_queues is a count incremented in nvme_init_queue. Thus, valid indices are 0 through dev->online_queues − 1. This patch fixes the loop condition to ensure the index stays within the valid range. Index 0 is excluded because it is the admin queue. KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74 CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: nvme-reset-wq nvme_reset_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xea/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xce/0x5d0 mm/kasan/report.c:482 kasan_report+0xdc/0x110 mm/kasan/report.c:595 __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c:379 nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c:3252 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 34 on cpu 1 at 4.241550s: kasan_save_stack+0x2c/0x60 mm/kasan/common.c:57 kasan_save_track+0x1c/0x70 mm/kasan/common.c:78 kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c:570 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5657 [inline] __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c:5663 kmalloc_array_node_noprof include/linux/slab.h:1075 [inline] nvme_pci_alloc_dev drivers/nvme/host/pci.c:3479 [inline] nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534 local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c:324 pci_call_probe drivers/pci/pci-driver.c:392 [inline] __pci_device_probe drivers/pci/pci-driver.c:417 [inline] pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c:451 call_driver_probe drivers/base/dd.c:583 [inline] really_probe+0x29b/0xb70 drivers/base/dd.c:661 __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c:803 driver_probe_device+0x56/0x1f0 drivers/base/dd.c:833 __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c:1159 async_run_entry_fn+0xa6/0x4b0 kernel/async.c:129 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 The buggy address belongs to the object at ffff88800592a000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 244 bytes to the right of allocated 1152-byte region [ffff88800592a000, ffff88800592a480) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff) page_type: f5(slab) raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000 head: 000fffffc0000040 ffff888001042000 00000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43450", "url": "https://ubuntu.com/security/CVE-2026-43450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table() nfnl_cthelper_dump_table() has a 'goto restart' that jumps to a label inside the for loop body. When the \"last\" helper saved in cb->args[1] is deleted between dump rounds, every entry fails the (cur != last) check, so cb->args[1] is never cleared. The for loop finishes with cb->args[0] == nf_ct_helper_hsize, and the 'goto restart' jumps back into the loop body bypassing the bounds check, causing an 8-byte out-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize]. The 'goto restart' block was meant to re-traverse the current bucket when \"last\" is no longer found, but it was placed after the for loop instead of inside it. Move the block into the for loop body so that the restart only occurs while cb->args[0] is still within bounds. BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131 Call Trace: nfnl_cthelper_dump_table+0x9f/0x1b0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 sock_recvmsg+0xde/0xf0 __sys_recvfrom+0x150/0x200 __x64_sys_recvfrom+0x76/0x90 do_syscall_64+0xc3/0x6e0 Allocated by task 1: __kvmalloc_node_noprof+0x21b/0x700 nf_ct_alloc_hashtable+0x65/0xd0 nf_conntrack_helper_init+0x21/0x60 nf_conntrack_init_start+0x18d/0x300 nf_conntrack_standalone_init+0x12/0xc0", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43451", "url": "https://ubuntu.com/security/CVE-2026-43451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: fix entry leak in bridge verdict error path nfqnl_recv_verdict() calls find_dequeue_entry() to remove the queue entry from the queue data structures, taking ownership of the entry. For PF_BRIDGE packets, it then calls nfqa_parse_bridge() to parse VLAN attributes. If nfqa_parse_bridge() returns an error (e.g. NFQA_VLAN present but NFQA_VLAN_TCI missing), the function returns immediately without freeing the dequeued entry or its sk_buff. This leaks the nf_queue_entry, its associated sk_buff, and all held references (net_device refcounts, struct net refcount). Repeated triggering exhausts kernel memory. Fix this by dropping the entry via nfqnl_reinject() with NF_DROP verdict on the error path, consistent with other error handling in this file.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43452", "url": "https://ubuntu.com/security/CVE-2026-43452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: guard option walkers against 1-byte tail reads When the last byte of options is a non-single-byte option kind, walkers that advance with i += op[i + 1] ? : 1 can read op[i + 1] past the end of the option area. Add an explicit i == optlen - 1 check before dereferencing op[i + 1] in xt_tcpudp and xt_dccp option walkers.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43453", "url": "https://ubuntu.com/security/CVE-2026-43453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop() pipapo_drop() passes rulemap[i + 1].n to pipapo_unmap() as the to_offset argument on every iteration, including the last one where i == m->field_count - 1. This reads one element past the end of the stack-allocated rulemap array (declared as rulemap[NFT_PIPAPO_MAX_FIELDS] with NFT_PIPAPO_MAX_FIELDS == 16). Although pipapo_unmap() returns early when is_last is true without using the to_offset value, the argument is evaluated at the call site before the function body executes, making this a genuine out-of-bounds stack read confirmed by KASAN: BUG: KASAN: stack-out-of-bounds in pipapo_drop+0x50c/0x57c [nf_tables] Read of size 4 at addr ffff8000810e71a4 This frame has 1 object: [32, 160) 'rulemap' The buggy address is at offset 164 -- exactly 4 bytes past the end of the rulemap array. Pass 0 instead of rulemap[i + 1].n on the last iteration to avoid the out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43458", "url": "https://ubuntu.com/security/CVE-2026-43458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: caif: hold tty->link reference in ldisc_open and ser_release A reproducer triggers a KASAN slab-use-after-free in pty_write_room() when caif_serial's TX path calls tty_write_room(). The faulting access is on tty->link->port. Hold an extra kref on tty->link for the lifetime of the caif_serial line discipline: get it in ldisc_open() and drop it in ser_release(), and also drop it on the ldisc_open() error path. With this change applied, the reproducer no longer triggers the UAF in my testing.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43459", "url": "https://ubuntu.com/security/CVE-2026-43459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-core: flush delayed work before removing DAIs and widgets When a sound card is unbound while a PCM stream is open, a use-after-free can occur in snd_soc_dapm_stream_event(), called from the close_delayed_work workqueue handler. During unbind, snd_soc_unbind_card() flushes delayed work and then calls soc_cleanup_card_resources(). Inside cleanup, snd_card_disconnect_sync() releases all PCM file descriptors, and the resulting PCM close path can call snd_soc_dapm_stream_stop() which schedules new delayed work with a pmdown_time timer delay. Since this happens after the flush in snd_soc_unbind_card(), the new work is not caught. soc_remove_link_components() then frees DAPM widgets before this work fires, leading to the use-after-free. The existing flush in soc_free_pcm_runtime() also cannot help as it runs after soc_remove_link_components() has already freed the widgets. Add a flush in soc_cleanup_card_resources() after snd_card_disconnect_sync() (after which no new PCM closes can schedule further delayed work) and before soc_remove_link_dais() and soc_remove_link_components() (which tear down the structures the delayed work accesses).", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-23277", "url": "https://ubuntu.com/security/CVE-2026-23277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit teql_master_xmit() calls netdev_start_xmit(skb, slave) to transmit through slave devices, but does not update skb->dev to the slave device beforehand. When a gretap tunnel is a TEQL slave, the transmit path reaches iptunnel_xmit() which saves dev = skb->dev (still pointing to teql0 master) and later calls iptunnel_xmit_stats(dev, pkt_len). This function does: get_cpu_ptr(dev->tstats) Since teql_master_setup() does not set dev->pcpu_stat_type to NETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstats for teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computes NULL + __per_cpu_offset[cpu], resulting in a page fault. BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206) Fix this by setting skb->dev = slave before calling netdev_start_xmit(), so that tunnel xmit functions see the correct slave device with properly allocated tstats.", "cve_priority": "medium", "cve_public_date": "2026-03-20 09:16:00 UTC" }, { "cve": "CVE-2026-43466", "url": "https://ubuntu.com/security/CVE-2026-43466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery In case of a TX error CQE, a recovery flow is triggered, mlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc, desyncing the DMA FIFO producer and consumer. After recovery, the producer pushes new DMA entries at the old dma_fifo_pc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery. The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dma_fifo_cc is already equal to dma_fifo_pc. There is no need to reset either counter, similar to how skb_fifo pc/cc are untouched. Remove the 'dma_fifo_cc = 0' reset. This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90 Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: ? __warn+0x7d/0x110 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0x16d/0x180 ? handle_bug+0x4f/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 ? iommu_dma_unmap_page+0x2e/0x90 dma_unmap_page_attrs+0x10d/0x1b0 mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core] mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core] mlx5e_napi_poll+0x8b/0xac0 [mlx5_core] __napi_poll+0x24/0x190 net_rx_action+0x32a/0x3b0 ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core] ? notifier_call_chain+0x35/0xa0 handle_softirqs+0xc9/0x270 irq_exit_rcu+0x71/0xd0 common_interrupt+0x7f/0xa0 asm_common_interrupt+0x22/0x40", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43469", "url": "https://ubuntu.com/security/CVE-2026-43469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decrement re_receiving on the early exit paths In the event that rpcrdma_post_recvs() fails to create a work request (due to memory allocation failure, say) or otherwise exits early, we should decrement ep->re_receiving before returning. Otherwise we will hang in rpcrdma_xprt_drain() as re_receiving will never reach zero and the completion will never be triggered. On a system with high memory pressure, this can appear as the following hung task: INFO: task kworker/u385:17:8393 blocked for more than 122 seconds. Tainted: G S E 6.19.0 #3 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u385:17 state:D stack:0 pid:8393 tgid:8393 ppid:2 task_flags:0x4248060 flags:0x00080000 Workqueue: xprtiod xprt_autoclose [sunrpc] Call Trace: __schedule+0x48b/0x18b0 ? ib_post_send_mad+0x247/0xae0 [ib_core] schedule+0x27/0xf0 schedule_timeout+0x104/0x110 __wait_for_common+0x98/0x180 ? __pfx_schedule_timeout+0x10/0x10 wait_for_completion+0x24/0x40 rpcrdma_xprt_disconnect+0x444/0x460 [rpcrdma] xprt_rdma_close+0x12/0x40 [rpcrdma] xprt_autoclose+0x5f/0x120 [sunrpc] process_one_work+0x191/0x3e0 worker_thread+0x2e3/0x420 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x273/0x2b0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2025-54505", "url": "https://ubuntu.com/security/CVE-2025-54505", "cve_description": "A transient execution vulnerability within AMD CPUs may allow a local user-privileged attacker to leak data via the floating point divisor unit, potentially resulting in loss of confidentiality.", "cve_priority": "medium", "cve_public_date": "2026-04-27 16:16:00 UTC" }, { "cve": "CVE-2026-31628", "url": "https://ubuntu.com/security/CVE-2026-31628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU: Fix FPDSS on Zen1 Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43472", "url": "https://ubuntu.com/security/CVE-2026-43472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: unshare: fix unshare_fs() handling There's an unpleasant corner case in unshare(2), when we have a CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that case copy_mnt_ns() gets passed current->fs instead of a private copy, which causes interesting warts in proof of correctness] > I guess if private means fs->users == 1, the condition could still be true. Unfortunately, it's worse than just a convoluted proof of correctness. Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS (and current->fs->users == 1). We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and flips current->fs->{pwd,root} to corresponding locations in the new namespace. Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM). We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's destroyed and its mount tree is dissolved, but... current->fs->root and current->fs->pwd are both left pointing to now detached mounts. They are pinning those, so it's not a UAF, but it leaves the calling process with unshare(2) failing with -ENOMEM _and_ leaving it with pwd and root on detached isolated mounts. The last part is clearly a bug. There is other fun related to that mess (races with pivot_root(), including the one between pivot_root() and fork(), of all things), but this one is easy to isolate and fix - treat CLONE_NEWNS as \"allocate a new fs_struct even if it hadn't been shared in the first place\". Sure, we could go for something like \"if both CLONE_NEWNS *and* one of the things that might end up failing after copy_mnt_ns() call in create_new_namespaces() are set, force allocation of new fs_struct\", but let's keep it simple - the cost of copy_fs_struct() is trivial. Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets a freshly allocated fs_struct, yet to be attached to anything. That seriously simplifies the analysis... FWIW, that bug had been there since the introduction of unshare(2) ;-/", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-43473", "url": "https://ubuntu.com/security/CVE-2026-43473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Add NULL checks when resetting request and reply queues The driver encountered a crash during resource cleanup when the reply and request queues were NULL due to freed memory. This issue occurred when the creation of reply or request queues failed, and the driver freed the memory first, but attempted to mem set the content of the freed memory, leading to a system crash. Add NULL pointer checks for reply and request queues before accessing the reply/request memory during cleanup", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-43475", "url": "https://ubuntu.com/security/CVE-2026-43475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT This resolves the follow splat and lock-up when running with PREEMPT_RT enabled on Hyper-V: [ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002 [ 415.140822] INFO: lockdep is turned off. [ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common [ 415.140846] Preemption disabled at: [ 415.140847] [] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)} [ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024 [ 415.140857] Call Trace: [ 415.140861] [ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140863] dump_stack_lvl+0x91/0xb0 [ 415.140870] __schedule_bug+0x9c/0xc0 [ 415.140875] __schedule+0xdf6/0x1300 [ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980 [ 415.140879] ? rcu_is_watching+0x12/0x60 [ 415.140883] schedule_rtlock+0x21/0x40 [ 415.140885] rtlock_slowlock_locked+0x502/0x1980 [ 415.140891] rt_spin_lock+0x89/0x1e0 [ 415.140893] hv_ringbuffer_write+0x87/0x2a0 [ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0 [ 415.140900] ? rcu_is_watching+0x12/0x60 [ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc] [ 415.140904] ? HARDIRQ_verbose+0x10/0x10 [ 415.140908] ? __rq_qos_issue+0x28/0x40 [ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod] [ 415.140926] __blk_mq_issue_directly+0x4a/0xc0 [ 415.140928] blk_mq_issue_direct+0x87/0x2b0 [ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440 [ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0 [ 415.140935] __blk_flush_plug+0xf4/0x150 [ 415.140940] __submit_bio+0x2b2/0x5c0 [ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360 [ 415.140946] submit_bio_noacct_nocheck+0x272/0x360 [ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4] [ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4] [ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4] [ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4] [ 415.141060] generic_perform_write+0x14e/0x2c0 [ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4] [ 415.141083] vfs_write+0x2ca/0x570 [ 415.141087] ksys_write+0x76/0xf0 [ 415.141089] do_syscall_64+0x99/0x1490 [ 415.141093] ? rcu_is_watching+0x12/0x60 [ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0 [ 415.141097] ? rcu_is_watching+0x12/0x60 [ 415.141098] ? lock_release+0x1f0/0x2a0 [ 415.141100] ? rcu_is_watching+0x12/0x60 [ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0 [ 415.141103] ? rcu_is_watching+0x12/0x60 [ 415.141104] ? __schedule+0xb34/0x1300 [ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170 [ 415.141109] ? do_nanosleep+0x8b/0x160 [ 415.141111] ? hrtimer_nanosleep+0x89/0x100 [ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10 [ 415.141116] ? xfd_validate_state+0x26/0x90 [ 415.141118] ? rcu_is_watching+0x12/0x60 [ 415.141120] ? do_syscall_64+0x1e0/0x1490 [ 415.141121] ? do_syscall_64+0x1e0/0x1490 [ 415.141123] ? rcu_is_watching+0x12/0x60 [ 415.141124] ? do_syscall_64+0x1e0/0x1490 [ 415.141125] ? do_syscall_64+0x1e0/0x1490 [ 415.141127] ? irqentry_exit+0x140/0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-23270", "url": "https://ubuntu.com/security/CVE-2026-23270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocks As Paolo said earlier [1]: \"Since the blamed commit below, classify can return TC_ACT_CONSUMED while the current skb being held by the defragmentation engine. As reported by GangMin Kim, if such packet is that may cause a UaF when the defrag engine later on tries to tuch again such packet.\" act_ct was never meant to be used in the egress path, however some users are attaching it to egress today [2]. Attempting to reach a middle ground, we noticed that, while most qdiscs are not handling TC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, we address the issue by only allowing act_ct to bind to clsact/ingress qdiscs and shared blocks. That way it's still possible to attach act_ct to egress (albeit only with clsact). [1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/ [2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23300", "url": "https://ubuntu.com/security/CVE-2026-23300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop When a standalone IPv6 nexthop object is created with a loopback device (e.g., \"ip -6 nexthop add id 100 dev lo\"), fib6_nh_init() misclassifies it as a reject route. This is because nexthop objects have no destination prefix (fc_dst=::), causing fib6_is_reject() to match any loopback nexthop. The reject path skips fib_nh_common_init(), leaving nhc_pcpu_rth_output unallocated. If an IPv4 route later references this nexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and panics. Simplify the check in fib6_nh_init() to only match explicit reject routes (RTF_REJECT) instead of using fib6_is_reject(). The loopback promotion heuristic in fib6_is_reject() is handled separately by ip6_route_info_create_nh(). After this change, the three cases behave as follows: 1. Explicit reject route (\"ip -6 route add unreachable 2001:db8::/64\"): RTF_REJECT is set, enters reject path, skips fib_nh_common_init(). No behavior change. 2. Implicit loopback reject route (\"ip -6 route add 2001:db8::/32 dev lo\"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. ip6_route_info_create_nh() still promotes it to reject afterward. nhc_pcpu_rth_output is allocated but unused, which is harmless. 3. Standalone nexthop object (\"ip -6 nexthop add id 100 dev lo\"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. nhc_pcpu_rth_output is properly allocated, fixing the crash when IPv4 routes reference this nexthop.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23293", "url": "https://ubuntu.com/security/CVE-2026-23293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. If an IPv6 packet is injected into the interface, route_shortcircuit() is called and a NULL pointer dereference happens on neigh_lookup(). BUG: kernel NULL pointer dereference, address: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neigh_lookup+0x20/0x270 [...] Call Trace: vxlan_xmit+0x638/0x1ef0 [vxlan] dev_hard_start_xmit+0x9e/0x2e0 __dev_queue_xmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x12f/0x1590 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix this by adding an early check on route_shortcircuit() when protocol is ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here because VXLAN can be built-in even when IPv6 is built as a module.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23381", "url": "https://ubuntu.com/security/CVE-2026-23381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. Then, if neigh_suppress is enabled and an ICMPv6 Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() will dereference ipv6_stub->nd_tbl which is NULL, passing it to neigh_lookup(). This causes a kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neigh_lookup+0x16/0xe0 [...] Call Trace: ? neigh_lookup+0x16/0xe0 br_do_suppress_nd+0x160/0x290 [bridge] br_handle_frame_finish+0x500/0x620 [bridge] br_handle_frame+0x353/0x440 [bridge] __netif_receive_skb_core.constprop.0+0x298/0x1110 __netif_receive_skb_one_core+0x3d/0xa0 process_backlog+0xa0/0x140 __napi_poll+0x2c/0x170 net_rx_action+0x2c4/0x3a0 handle_softirqs+0xd0/0x270 do_softirq+0x3f/0x60 Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() in the callers. This is in essence disabling NS/NA suppression when IPv6 is disabled.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23372", "url": "https://ubuntu.com/security/CVE-2026-23372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: rawsock: cancel tx_work before socket teardown In rawsock_release(), cancel any pending tx_work and purge the write queue before orphaning the socket. rawsock_tx_work runs on the system workqueue and calls nfc_data_exchange which dereferences the NCI device. Without synchronization, tx_work can race with socket and device teardown when a process is killed (e.g. by SIGKILL), leading to use-after-free or leaked references. Set SEND_SHUTDOWN first so that if tx_work is already running it will see the flag and skip transmitting, then use cancel_work_sync to wait for any in-progress execution to finish, and finally purge any remaining queued skbs.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23339", "url": "https://ubuntu.com/security/CVE-2026-23339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: free skb on nci_transceive early error paths nci_transceive() takes ownership of the skb passed by the caller, but the -EPROTO, -EINVAL, and -EBUSY error paths return without freeing it. Due to issues clearing NCI_DATA_EXCHANGE fixed by subsequent changes the nci/nci_dev selftest hits the error path occasionally in NIPA, and kmemleak detects leaks: unreferenced object 0xff11000015ce6a40 (size 640): comm \"nci_dev\", pid 3954, jiffies 4295441246 hex dump (first 32 bytes): 6b 6b 6b 6b 00 a4 00 0c 02 e1 03 6b 6b 6b 6b 6b kkkk.......kkkkk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk backtrace (crc 7c40cc2a): kmem_cache_alloc_node_noprof+0x492/0x630 __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xc6/0x8f0 sock_alloc_send_pskb+0x326/0x3f0 nfc_alloc_send_skb+0x94/0x1d0 rawsock_sendmsg+0x162/0x4c0 do_syscall_64+0x117/0xfc0", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23340", "url": "https://ubuntu.com/security/CVE-2026-23340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs When shrinking the number of real tx queues, netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush qdiscs for queues which will no longer be used. qdisc_reset_all_tx_gt() currently serializes qdisc_reset() with qdisc_lock(). However, for lockless qdiscs, the dequeue path is serialized by qdisc_run_begin/end() using qdisc->seqlock instead, so qdisc_reset() can run concurrently with __qdisc_run() and free skbs while they are still being dequeued, leading to UAF. This can easily be reproduced on e.g. virtio-net by imposing heavy traffic while frequently changing the number of queue pairs: iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 done With KASAN enabled, this leads to reports like: BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: ... __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 udp_sendmsg+0x13c9/0x1fc0 ... Allocated by task 1270 on cpu 5 at 44.558414s: ... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg+0x13a6/0x1fc0 ... Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a/0x890 ... Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path by taking qdisc->seqlock for TCQ_F_NOLOCK qdiscs, matching the serialization model already used by dev_reset_queue(). Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state reflects an empty queue, avoiding needless re-scheduling.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23304", "url": "https://ubuntu.com/security/CVE-2026-23304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu() l3mdev_master_dev_rcu() can return NULL when the slave device is being un-slaved from a VRF. All other callers deal with this, but we lost the fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu() with commit 4832c30d5458 (\"net: ipv6: put host and anycast routes on device with address\"). KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418) Call Trace: ip6_pol_route (net/ipv6/route.c:2318) fib6_rule_lookup (net/ipv6/fib6_rules.c:115) ip6_route_output_flags (net/ipv6/route.c:2607) vrf_process_v6_outbound (drivers/net/vrf.c:437) I was tempted to rework the un-slaving code to clear the flag first and insert synchronize_rcu() before we remove the upper. But looks like the explicit fallback to loopback_dev is an established pattern. And I guess avoiding the synchronize_rcu() is nice, too.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23420", "url": "https://ubuntu.com/security/CVE-2026-23420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: Fix a locking bug Make sure that wl->mutex is locked before it is unlocked. This has been detected by the Clang thread-safety analyzer.", "cve_priority": "medium", "cve_public_date": "2026-04-03 14:16:00 UTC" }, { "cve": "CVE-2026-23357", "url": "https://ubuntu.com/security/CVE-2026-23357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix deadlock in error path of mcp251x_open The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish. This issue is similar to the one fixed in commit 7dd9c26bd6cf (\"can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\") but for the error path. To solve this issue move the call to free_irq() after the lock is released. Setting `priv->force_quit = 1` beforehand ensure that the IRQ handler will exit right away once it acquired the lock.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23362", "url": "https://ubuntu.com/security/CVE-2026-23362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix locking for bcm_op runtime updates Commit c2aba69d0c36 (\"can: bcm: add locking for bcm_op runtime updates\") added a locking for some variables that can be modified at runtime when updating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup(). Usually the RX_SETUP only handles and filters incoming traffic with one exception: When the RX_RTR_FRAME flag is set a predefined CAN frame is sent when a specific RTR frame is received. Therefore the rx bcm_op uses bcm_can_tx() which uses the bcm_tx_lock that was only initialized in bcm_tx_setup(). Add the missing spin_lock_init() when allocating the bcm_op in bcm_rx_setup() to handle the RTR case properly.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23286", "url": "https://ubuntu.com/security/CVE-2026-23286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix null-ptr-deref in lec_arp_clear_vccs syzkaller reported a null-ptr-deref in lec_arp_clear_vccs(). This issue can be easily reproduced using the syzkaller reproducer. In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared by multiple lec_arp_table entries (e.g., via entry->vcc or entry->recv_vcc). When the underlying VCC is closed, lec_vcc_close() iterates over all ARP entries and calls lec_arp_clear_vccs() for each matched entry. For example, when lec_vcc_close() iterates through the hlists in priv->lec_arp_empty_ones or other ARP tables: 1. In the first iteration, for the first matched ARP entry sharing the VCC, lec_arp_clear_vccs() frees the associated vpriv (which is vcc->user_back) and sets vcc->user_back to NULL. 2. In the second iteration, for the next matched ARP entry sharing the same VCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv from vcc->user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference it via `vcc->pop = vpriv->old_pop`, leading to a null-ptr-deref crash. Fix this by adding a null check for vpriv before dereferencing it. If vpriv is already NULL, it means the VCC has been cleared by a previous call, so we can safely skip the cleanup and just clear the entry's vcc/recv_vcc pointers. The entire cleanup block (including vcc_release_async()) is placed inside the vpriv guard because a NULL vpriv indicates the VCC has already been fully released by a prior iteration — repeating the teardown would redundantly set flags and trigger callbacks on an already-closing socket. The Fixes tag points to the initial commit because the entry->vcc path has been vulnerable since the original code. The entry->recv_vcc path was later added by commit 8d9f73c0ad2f (\"atm: fix a memory leak of vcc->user_back\") with the same pattern, and both paths are fixed here.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23296", "url": "https://ubuntu.com/security/CVE-2026-23296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix refcount leak for tagset_refcnt This leak will cause a hang when tearing down the SCSI host. For example, iscsid hangs with the following call trace: [130120.652718] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured PID: 2528 TASK: ffff9d0408974e00 CPU: 3 COMMAND: \"iscsid\" #0 [ffffb5b9c134b9e0] __schedule at ffffffff860657d4 #1 [ffffb5b9c134ba28] schedule at ffffffff86065c6f #2 [ffffb5b9c134ba40] schedule_timeout at ffffffff86069fb0 #3 [ffffb5b9c134bab0] __wait_for_common at ffffffff8606674f #4 [ffffb5b9c134bb10] scsi_remove_host at ffffffff85bfe84b #5 [ffffb5b9c134bb30] iscsi_sw_tcp_session_destroy at ffffffffc03031c4 [iscsi_tcp] #6 [ffffb5b9c134bb48] iscsi_if_recv_msg at ffffffffc0292692 [scsi_transport_iscsi] #7 [ffffb5b9c134bb98] iscsi_if_rx at ffffffffc02929c2 [scsi_transport_iscsi] #8 [ffffb5b9c134bbf0] netlink_unicast at ffffffff85e551d6 #9 [ffffb5b9c134bc38] netlink_sendmsg at ffffffff85e554ef", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23356", "url": "https://ubuntu.com/security/CVE-2026-23356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: fix \"LOGIC BUG\" in drbd_al_begin_io_nonblock() Even though we check that we \"should\" be able to do lc_get_cumulative() while holding the device->al_lock spinlock, it may still fail, if some other code path decided to do lc_try_lock() with bad timing. If that happened, we logged \"LOGIC BUG for enr=...\", but still did not return an error. The rest of the code now assumed that this request has references for the relevant activity log extents. The implcations are that during an active resync, mutual exclusivity of resync versus application IO is not guaranteed. And a potential crash at this point may not realizs that these extents could have been target of in-flight IO and would need to be resynced just in case. Also, once the request completes, it will give up activity log references it does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put(). Fix: Do not crash the kernel for a condition that is harmless during normal operation: also catch \"e->refcnt == 0\", not only \"e == NULL\" when being noisy about \"al_complete_io() called on inactive extent %u\\n\". And do not try to be smart and \"guess\" whether something will work, then be surprised when it does not. Deal with the fact that it may or may not work. If it does not, remember a possible \"partially in activity log\" state (only possible for requests that cross extent boundaries), and return an error code from drbd_al_begin_io_nonblock(). A latter call for the same request will then resume from where we left off.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23388", "url": "https://ubuntu.com/security/CVE-2026-23388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check metadata block offset is within range Syzkaller reports a \"general protection fault in squashfs_copy_data\" This is ultimately caused by a corrupted index look-up table, which produces a negative metadata block offset. This is subsequently passed to squashfs_copy_data (via squashfs_read_metadata) where the negative offset causes an out of bounds access. The fix is to check that the offset is within range in squashfs_read_metadata. This will trap this and other cases.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23379", "url": "https://ubuntu.com/security/CVE-2026-23379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: fix divide by zero in the offload path Offloading ETS requires computing each class' WRR weight: this is done by averaging over the sums of quanta as 'q_sum' and 'q_psum'. Using unsigned int, the same integer size as the individual DRR quanta, can overflow and even cause division by zero, like it happened in the following splat: Oops: divide error: 0000 [#1] SMP PTI CPU: 13 UID: 0 PID: 487 Comm: tc Tainted: G E 6.19.0-virtme #45 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Call Trace: ets_qdisc_change+0x870/0xf40 [sch_ets] qdisc_create+0x12b/0x540 tc_modify_qdisc+0x6d7/0xbd0 rtnetlink_rcv_msg+0x168/0x6b0 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x1d6/0x2b0 netlink_sendmsg+0x22e/0x470 ____sys_sendmsg+0x38a/0x3c0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x111/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f440b81c77e Code: 4d 89 d8 e8 d4 bc 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff951e4c10 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000481820 RCX: 00007f440b81c77e RDX: 0000000000000000 RSI: 00007fff951e4cd0 RDI: 0000000000000003 RBP: 00007fff951e4c20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff951f4fa8 R13: 00000000699ddede R14: 00007f440bb01000 R15: 0000000000486980 Modules linked in: sch_ets(E) netdevsim(E) ---[ end trace 0000000000000000 ]--- RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]--- Fix this using 64-bit integers for 'q_sum' and 'q_psum'.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23289", "url": "https://ubuntu.com/security/CVE-2026-23289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq() Fix a user triggerable leak on the system call failure path.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23279", "url": "https://ubuntu.com/security/CVE-2026-23279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix NULL pointer dereference in mesh_rx_csa_frame() In mesh_rx_csa_frame(), elems->mesh_chansw_params_ie is dereferenced at lines 1638 and 1642 without a prior NULL check: ifmsh->chsw_ttl = elems->mesh_chansw_params_ie->mesh_ttl; ... pre_value = le16_to_cpu(elems->mesh_chansw_params_ie->mesh_pre_value); The mesh_matches_local() check above only validates the Mesh ID, Mesh Configuration, and Supported Rates IEs. It does not verify the presence of the Mesh Channel Switch Parameters IE (element ID 118). When a received CSA action frame omits that IE, ieee802_11_parse_elems() leaves elems->mesh_chansw_params_ie as NULL, and the unconditional dereference causes a kernel NULL pointer dereference. A remote mesh peer with an established peer link (PLINK_ESTAB) can trigger this by sending a crafted SPECTRUM_MGMT/CHL_SWITCH action frame that includes a matching Mesh ID and Mesh Configuration IE but omits the Mesh Channel Switch Parameters IE. No authentication beyond the default open mesh peering is required. Crash confirmed on kernel 6.17.0-5-generic via mac80211_hwsim: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:ieee80211_mesh_rx_queued_mgmt+0x143/0x2a0 [mac80211] CR2: 0000000000000000 Fix by adding a NULL check for mesh_chansw_params_ie after mesh_matches_local() returns, consistent with how other optional IEs are guarded throughout the mesh code. The bug has been present since v3.13 (released 2014-01-19).", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23367", "url": "https://ubuntu.com/security/CVE-2026-23367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: radiotap: reject radiotap with unknown bits The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator->_next_ns_data isn't initialized (it's only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value. Fix this by moving the rejection of unknown radiotap fields down to after the in-namespace lookup, so it will really use iterator->_next_ns_data only for vendor namespaces, even in case undefined fields are present.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23318", "url": "https://ubuntu.com/security/CVE-2026-23318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Use correct version for UAC3 header validation The entry of the validators table for UAC3 AC header descriptor is defined with the wrong protocol version UAC_VERSION_2, while it should have been UAC_VERSION_3. This results in the validator never matching for actual UAC3 devices (protocol == UAC_VERSION_3), causing their header descriptors to bypass validation entirely. A malicious USB device presenting a truncated UAC3 header could exploit this to cause out-of-bounds reads when the driver later accesses unvalidated descriptor fields. The bug was introduced in the same commit as the recently fixed UAC3 feature unit sub-type typo, and appears to be from the same copy-paste error when the UAC3 section was created from the UAC2 section.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23370", "url": "https://ubuntu.com/security/CVE-2026-23370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data set_new_password() hex dumps the entire buffer, which contains plaintext password data, including current and new passwords. Remove the hex dump to avoid leaking credentials.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23352", "url": "https://ubuntu.com/security/CVE-2026-23352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/efi: defer freeing of boot services memory efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late(). There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area(). More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete. Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM. If the freed memory resides in the areas that memory map for them is still uninitialized, they won't be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages. Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map. Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that's undesirable late in boot when there is concurrency. More robust approach is to only defer freeing of the EFI boot services memory. Split efi_free_boot_services() in two. First efi_unmap_boot_services() collects ranges that should be freed into an array then efi_free_boot_services() later frees them after deferred init is complete.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23382", "url": "https://ubuntu.com/security/CVE-2026-23382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them In commit 2ff5baa9b527 (\"HID: appleir: Fix potential NULL dereference at raw event handle\"), we handle the fact that raw event callbacks can happen even for a HID device that has not been \"claimed\" causing a crash if a broken device were attempted to be connected to the system. Fix up the remaining in-tree HID drivers that forgot to add this same check to resolve the same issue.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23324", "url": "https://ubuntu.com/security/CVE-2026-23324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: usb: etas_es58x: correctly anchor the urb in the read bulk callback When submitting an urb, that is using the anchor pattern, it needs to be anchored before submitting it otherwise it could be leaked if usb_kill_anchored_urbs() is called. This logic is correctly done elsewhere in the driver, except in the read bulk callback so do that here also.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23298", "url": "https://ubuntu.com/security/CVE-2026-23298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ucan: Fix infinite loop from zero-length messages If a broken ucan device gets a message with the message length field set to 0, then the driver will loop for forever in ucan_read_bulk_callback(), hanging the system. If the length is 0, just skip the message and go on to the next one. This has been fixed in the kvaser_usb driver in the past in commit 0c73772cd2b8 (\"can: kvaser_usb: leaf: Fix potential infinite loop in command parsers\"), so there must be some broken devices out there like this somewhere.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23307", "url": "https://ubuntu.com/security/CVE-2026-23307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a message When looking at the data in a USB urb, the actual_length is the size of the buffer passed to the driver, not the transfer_buffer_length which is set by the driver as the max size of the buffer. When parsing the messages in ems_usb_read_bulk_callback() properly check the size both at the beginning of parsing the message to make sure it is big enough for the expected structure, and at the end of the message to make sure we don't overflow past the end of the buffer for the next message.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23290", "url": "https://ubuntu.com/security/CVE-2026-23290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: validate USB endpoints The pegasus driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23365", "url": "https://ubuntu.com/security/CVE-2026-23365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kalmia: validate USB endpoints The kalmia driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23312", "url": "https://ubuntu.com/security/CVE-2026-23312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: validate USB endpoints The kaweth driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23291", "url": "https://ubuntu.com/security/CVE-2026-23291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: properly drop the usb interface reference on disconnect When the device is disconnected from the driver, there is a \"dangling\" reference count on the usb interface that was grabbed in the probe callback. Fix this up by properly dropping the reference after we are done with it.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23253", "url": "https://ubuntu.com/security/CVE-2026-23253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: fix wrong reinitialization of ringbuffer on reopen dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock.", "cve_priority": "high", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-43123", "url": "https://ubuntu.com/security/CVE-2026-43123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: check return value of con2fb_acquire_newinfo() If fbcon_open() fails when called from con2fb_acquire_newinfo() then info->fbcon_par pointer remains NULL which is later dereferenced. Add check for return value of the function con2fb_acquire_newinfo() to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23220", "url": "https://ubuntu.com/security/CVE-2026-23220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error paths The problem occurs when a signed request fails smb2 signature verification check. In __process_request(), if check_sign_req() returns an error, set_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called. set_smb2_rsp_status() set work->next_smb2_rcv_hdr_off as zero. By resetting next_smb2_rcv_hdr_off to zero, the pointer to the next command in the chain is lost. Consequently, is_chained_smb2_message() continues to point to the same request header instead of advancing. If the header's NextCommand field is non-zero, the function returns true, causing __handle_ksmbd_work() to repeatedly process the same failed request in an infinite loop. This results in the kernel log being flooded with \"bad smb2 signature\" messages and high CPU usage. This patch fixes the issue by changing the return value from SERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures that the processing loop terminates immediately rather than attempting to continue from an invalidated offset.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-45911", "url": "https://ubuntu.com/security/CVE-2026-45911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix role switching during resume If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference. The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped. So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usb_hcd_is_primary_hcd+0x0/0x1c lr : cdns_host_resume+0x24/0x5c ... Call trace: usb_hcd_is_primary_hcd+0x0/0x1c (P) cdns_resume+0x6c/0xbc cdns3_controller_resume.isra.0+0xe8/0x17c cdns3_plat_resume+0x18/0x24 platform_pm_resume+0x2c/0x68 dpm_run_callback+0x90/0x248 device_resume+0x100/0x24c dpm_resume+0x190/0x2ec dpm_resume_end+0x18/0x34 suspend_devices_and_enter+0x2b0/0xa44 pm_suspend+0x16c/0x5fc state_store+0x80/0xec kobj_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x130/0x1dc vfs_write+0x240/0x370 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0x108 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-71287", "url": "https://ubuntu.com/security/CVE-2025-71287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memory: mtk-smi: fix device leak on larb probe Make sure to drop the reference taken when looking up the SMI device during larb probe on late probe failure (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23359", "url": "https://ubuntu.com/security/CVE-2026-23359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stack-out-of-bounds write in devmap get_upper_ifindexes() iterates over all upper devices and writes their indices into an array without checking bounds. Also the callers assume that the max number of upper devices is MAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack, but that assumption is not correct and the number of upper devices could be larger than MAX_NEST_DEV (e.g., many macvlans), causing a stack-out-of-bounds write. Add a max parameter to get_upper_ifindexes() to avoid the issue. When there are too many upper devices, return -EOVERFLOW and abort the redirect. To reproduce, create more than MAX_NEST_DEV(8) macvlans on a device with an XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS. Then send a packet to the device to trigger the XDP redirect path.", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43291", "url": "https://ubuntu.com/security/CVE-2026-43291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: nfc: nci: Fix parameter validation for packet data Since commit 9c328f54741b (\"net: nfc: nci: Add parameter validation for packet data\") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct).", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43283", "url": "https://ubuntu.com/security/CVE-2026-43283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle dma_free_coherent() in error path takes priv->rx_buf.alloc_len as the dma handle. This would lead to improper unmapping of the buffer. Change the dma handle to priv->rx_buf.alloc_phys.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43264", "url": "https://ubuntu.com/security/CVE-2026-43264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: of: display_timing: fix refcount leak in of_get_display_timings() of_parse_phandle() returns a device_node with refcount incremented, which is stored in 'entry' and then copied to 'native_mode'. When the error paths at lines 184 or 192 jump to 'entryfail', native_mode's refcount is not decremented, causing a refcount leak. Fix this by changing the goto target from 'entryfail' to 'timingfail', which properly calls of_node_put(native_mode) before cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43202", "url": "https://ubuntu.com/security/CVE-2026-43202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: vt8500lcdfb: fix missing dma_free_coherent() fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not freed if the error path is reached.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43203", "url": "https://ubuntu.com/security/CVE-2026-43203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: fore200e: fix use-after-free in tasklets during device removal When the PCA-200E or SBA-200E adapter is being detached, the fore200e is deallocated. However, the tx_tasklet or rx_tasklet may still be running or pending, leading to use-after-free bug when the already freed fore200e is accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet(). One of the race conditions can occur as follows: CPU 0 (cleanup) | CPU 1 (tasklet) fore200e_pca_remove_one() | fore200e_interrupt() fore200e_shutdown() | tasklet_schedule() kfree(fore200e) | fore200e_tx_tasklet() | fore200e-> // UAF Fix this by ensuring tx_tasklet or rx_tasklet is properly canceled before the fore200e is released. Add tasklet_kill() in fore200e_shutdown() to synchronize with any pending or running tasklets. Moreover, since fore200e_reset() could prevent further interrupts or data transfers, the tasklet_kill() should be placed after fore200e_reset() to prevent the tasklet from being rescheduled in fore200e_interrupt(). Finally, it only needs to do tasklet_kill() when the fore200e state is greater than or equal to FORE200E_STATE_IRQ, since tasklets are uninitialized in earlier states. In a word, the tasklet_kill() should be placed in the FORE200E_STATE_IRQ branch within the switch...case structure. This bug was identified through static analysis.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43149", "url": "https://ubuntu.com/security/CVE-2026-43149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean() The priv->rx_buffer and priv->tx_buffer are alloc'd together as contiguous buffers in uhdlc_init() but freed as two buffers in uhdlc_memclean(). Change the cleanup to only call dma_free_coherent() once on the whole buffer.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43273", "url": "https://ubuntu.com/security/CVE-2026-43273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: supply snapshot context in ceph_zero_partial_object() The ceph_zero_partial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.conf dd if=/dev/urandom of=/mnt/mycephfs/foo bs=64K count=1 mkdir /mnt/mycephfs/.snap/snap1 md5sum /mnt/mycephfs/.snap/snap1/foo fallocate -p -o 0 -l 4096 /mnt/mycephfs/foo echo 3 > /proc/sys/vm/drop/caches md5sum /mnt/mycephfs/.snap/snap1/foo # get different md5sum!!", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43159", "url": "https://ubuntu.com/security/CVE-2026-43159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix null dereference in find_network The variable pwlan has the possibility of being NULL when passed into rtw_free_network_nolock() which would later dereference the variable.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43211", "url": "https://ubuntu.com/security/CVE-2026-43211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: Fix pci_slot_trylock() error handling Commit a4e772898f8b (\"PCI: Add missing bridge lock to pci_bus_lock()\") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails. Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } } After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug. This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread. Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path. [Same patch later posted by Keith at https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com]", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43206", "url": "https://ubuntu.com/security/CVE-2026-43206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8 bytes via memset without checking the buffer size parameter. This allows unprivileged userspace to trigger an out-of bounds kernel memory write by passing a small buffer, leading to potential privilege escalation.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43275", "url": "https://ubuntu.com/security/CVE-2026-43275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Flush exception handling work when RPM level is zero Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0. When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race condition where the driver could attempt to access the host controller to handle an exception after the system had already entered a deep power-down state, resulting in a system crash. Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete and prevents illegal hardware access during the power-down sequence.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43145", "url": "https://ubuntu.com/security/CVE-2026-43145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_rproc: Fix invalid loaded resource table detection imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded resource table even when the current firmware does not provide one. When the device tree contains a \"rsc-table\" entry, priv->rsc_table is non-NULL and denotes where a resource table would be located if one is present in memory. However, when the current firmware has no resource table, rproc->table_ptr is NULL. The function still returns priv->rsc_table, and the remoteproc core interprets this as a valid loaded resource table. Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when there is no resource table for the current firmware (i.e. when rproc->table_ptr is NULL). This aligns the function's semantics with the remoteproc core: a loaded resource table is only reported when a valid table_ptr exists. With this change, starting firmware without a resource table no longer triggers a crash.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43147", "url": "https://ubuntu.com/security/CVE-2026-43147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV\" This reverts commit 05703271c3cd (\"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV\"), which causes a deadlock by recursively taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of pci_stop_and_remove_bus_device(). For example with the following sequence of commands: $ echo > /sys/bus/pci/devices//sriov_numvfs $ echo 1 > /sys/bus/pci/devices//remove A trimmed trace of the deadlock on a mlx5 device is as below: zsh/5715 is trying to acquire lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140 but task is already holding lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110 [<00000259779c844e>] print_deadlock_bug+0x31e/0x330 [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0 [<00000259779bffac>] lock_acquire+0x14c/0x350 [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520 [<000002597896413c>] mutex_lock_nested+0x3c/0x50 [<00000259784a07e4>] sriov_disable+0x34/0x140 [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core] [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core] [<00000259784857fc>] pci_device_remove+0x3c/0xa0 [<000002597851012e>] device_release_driver_internal+0x18e/0x280 [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0 [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80 [<00000259784972c2>] remove_store+0x72/0x90 [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200 [<0000025977d7241c>] vfs_write+0x24c/0x300 [<0000025977d72696>] ksys_write+0x86/0x110 [<000002597895b61c>] __do_syscall+0x14c/0x400 [<000002597896e0ee>] system_call+0x6e/0x90 This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43289", "url": "https://ubuntu.com/security/CVE-2026-43289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kexec: derive purgatory entry from symbol kexec_load_purgatory() derives image->start by locating e_entry inside an SHF_EXECINSTR section. If the purgatory object contains multiple executable sections with overlapping sh_addr, the entrypoint check can match more than once and trigger a WARN. Derive the entry section from the purgatory_start symbol when present and compute image->start from its final placement. Keep the existing e_entry fallback for purgatories that do not expose the symbol. WARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784 Call Trace: bzImage64_load+0x133/0xa00 __do_sys_kexec_file_load+0x2b3/0x5c0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e [me@linux.beauty: move helper to avoid forward declaration, per Baoquan]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43168", "url": "https://ubuntu.com/security/CVE-2026-43168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix reflink preserve cleanup issue commit c06c303832ec (\"ocfs2: fix xattr array entry __counted_by error\") doesn't handle all cases and the cleanup job for preserved xattr entries still has bug: - the 'last' pointer should be shifted by one unit after cleanup an array entry. - current code logic doesn't cleanup the first entry when xh_count is 1. Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43295", "url": "https://ubuntu.com/security/CVE-2026-43295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net() When idtab allocation fails, net is not registered with rio_add_net() yet, so kfree(net) is sufficient to release the memory. Set mport->net to NULL to avoid dangling pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43148", "url": "https://ubuntu.com/security/CVE-2026-43148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/smp: Add check for kcalloc() failure in parse_thread_groups() As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing it to of_property_read_u32_array().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43163", "url": "https://ubuntu.com/security/CVE-2026-43163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/bitmap: fix GPF in write_page caused by resize race A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod] This is a use-after-free race between bitmap_daemon_work() and __bitmap_resize(). The daemon iterates over `bitmap->storage.filemap` without locking, while the resize path frees that storage via md_bitmap_file_unmap(). `quiesce()` does not stop the md thread, allowing concurrent access to freed pages. Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43200", "url": "https://ubuntu.com/security/CVE-2026-43200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functions struct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target); While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specify the parameters in the correct order, pci_primary_epc_epf_unlink() and pci_secondary_epc_epf_unlink() specify the parameters in the wrong order, leading to the below kernel crash when using the unlink command in configfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0 [mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43158", "url": "https://ubuntu.com/security/CVE-2026-43158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix freemap adjustments when adding xattrs to leaf blocks xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) \t\t\t\t\t+ xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where \"rhs\" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 (\"xfs: fix attr leaf header freemap.size underflow\") and the previous patch that resets zero length freemap entries to have base = 0.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43187", "url": "https://ubuntu.com/security/CVE-2026-43187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: delete attr leaf freemap entries when empty Back in commit 2a2b5932db6758 (\"xfs: fix attr leaf header freemap.size underflow\"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the \"pushed-up\" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43130", "url": "https://ubuntu.com/security/CVE-2026-43130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode Commit 4fc82cd907ac (\"iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected\") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system. For example, if a VM fails to connect to the PCIe device, \"virsh destroy\" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd. Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput Although pci_device_is_present() is slower than pci_dev_is_disconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase. Besides, devtlb_invalidation_with_pasid() is called only in the paths below, which are far less frequent than memory map/unmap. 1. mm-struct release 2. {attach,release}_dev 3. set/remove PASID 4. dirty-tracking setup The gain in system stability far outweighs the negligible cost of using pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43133", "url": "https://ubuntu.com/security/CVE-2026-43133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation Commit cc3ed80ae69f (\"KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state\") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01. As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43196", "url": "https://ubuntu.com/security/CVE-2026-43196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: ti: pruss: Fix double free in pruss_clk_mux_setup() In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectly calls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np) on the error path. However, after the devm_add_action_or_reset() returns, the of_node_put(clk_mux_np) is called again, causing a double free. Fix by returning directly, to avoid the duplicate of_node_put().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43242", "url": "https://ubuntu.com/security/CVE-2026-43242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: ti: k3-socinfo: Fix regmap leak on probe failure The mmio regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43278", "url": "https://ubuntu.com/security/CVE-2026-43278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: clear cloned request bio pointer when last clone bio completes Stale rq->bio values have been observed to cause double-initialization of cloned bios in request-based device-mapper targets, leading to use-after-free and double-free scenarios. One such case occurs when using dm-multipath on top of a PCIe NVMe namespace, where cloned request bios are freed during blk_complete_request(), but rq->bio is left intact. Subsequent clone teardown then attempts to free the same bios again via blk_rq_unprep_clone(). The resulting double-free path looks like: nvme_pci_complete_batch() nvme_complete_batch() blk_mq_end_request_batch() blk_complete_request() // called on a DM clone request bio_endio() // first free of all clone bios ... rq->end_io() // end_clone_request() dm_complete_request(tio->orig) dm_softirq_done() dm_done() dm_end_request() blk_rq_unprep_clone() // second free of clone bios Fix this by clearing the clone request's bio pointer when the last cloned bio completes, ensuring that later teardown paths do not attempt to free already-released bios.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43312", "url": "https://ubuntu.com/security/CVE-2026-43312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov5647: Initialize subdev before controls In ov5647_init_controls() we call v4l2_get_subdevdata, but it is initialized by v4l2_i2c_subdev_init() in the probe, which currently happens after init_controls(). This can result in a segfault if the error condition is hit, and we try to access i2c_client, so fix the order.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43182", "url": "https://ubuntu.com/security/CVE-2026-43182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ccs: Avoid possible division by zero Calculating maximum M for scaler configuration involves dividing by MIN_X_OUTPUT_SIZE limit register's value. Albeit the value is presumably non-zero, the driver was missing the check it in fact was. Fix this.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43246", "url": "https://ubuntu.com/security/CVE-2026-43246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c/tw9906: Fix potential memory leak in tw9906_probe() In one of the error paths in tw9906_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43218", "url": "https://ubuntu.com/security/CVE-2026-43218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c/tw9903: Fix potential memory leak in tw9903_probe() In one of the error paths in tw9903_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43135", "url": "https://ubuntu.com/security/CVE-2026-43135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: Add missing unmap in snd_cx23885_hw_params() In error path, add cx23885_alsa_dma_unmap() to release the resource acquired by cx23885_alsa_dma_map().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43257", "url": "https://ubuntu.com/security/CVE-2026-43257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx88: Add missing unmap in snd_cx88_hw_params() In error path, add cx88_alsa_dma_unmap() to release resource acquired by cx88_alsa_dma_map().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43231", "url": "https://ubuntu.com/security/CVE-2026-43231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-keene: fix memory leak in error path Fix a memory leak in usb_keene_probe(). The v4l2 control handler is initialized and controls are added, but if v4l2_device_register() or video_register_device() fails afterward, the handler was never freed, leaking memory. Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensure the control handler is properly freed for all error paths after it is initialized.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43136", "url": "https://ubuntu.com/security/CVE-2026-43136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Check maxfield in hidpp_get_report_length() Do not crash when a report has no fields. Fake USB gadgets can send their own HID report descriptors and can define report structures without valid fields. This can be used to crash the kernel over USB.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43251", "url": "https://ubuntu.com/security/CVE-2026-43251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: prodikeys: Check presence of pm->input_ep82 Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, pm->input_ep82 stays NULL, which leads to a crash later. This does not happen with the real device, but can be provoked by imposing as one.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43140", "url": "https://ubuntu.com/security/CVE-2026-43140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: Do not crash on missing msc->input Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, msc->input stays NULL, leading to a crash at a later time. Detect this condition in the input_configured() hook and reject the device. This is not supposed to happen with actual magic mouse devices, but can be provoked by imposing as a magic mouse USB device.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43152", "url": "https://ubuntu.com/security/CVE-2026-43152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hid-pl: handle probe errors Errors in init must be reported back or we'll follow a NULL pointer the first time FF is used.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43315", "url": "https://ubuntu.com/security/CVE-2026-43315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeeding Drop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failing as it is trivially easy to trigger from userspace by modifying CPUID after loading CR3. E.g. modifying the state restoration selftest like so: --- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main(int argc, char *argv[]) /* Restore state in a new VM. */ vcpu = vm_recreate_with_one_vcpu(vm); - vcpu_load_state(vcpu, state); + + if (stage == 4) { + state->sregs.cr3 = BIT(44); + vcpu_load_state(vcpu, state); + + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36); + __vcpu_nested_state_set(vcpu, &state->nested); + } else { + vcpu_load_state(vcpu, state); + } /* * Restore XSAVE state in a dummy vCPU, first without doing generates: WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd] Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm] CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd] Call Trace: kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm] kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Simply delete the WARN instead of trying to prevent userspace from shoving \"illegal\" state into CR3. For better or worse, KVM's ABI allows userspace to set CPUID after SREGS, and vice versa, and KVM is very permissive when it comes to guest CPUID. I.e. attempting to enforce the virtual CPU model when setting CPUID could break userspace. Given that the WARN doesn't provide any meaningful protection for KVM or benefit for userspace, simply drop it even though the odds of breaking userspace are minuscule. Opportunistically delete a spurious newline.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43270", "url": "https://ubuntu.com/security/CVE-2026-43270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove() In mtk_mdp_probe(), vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43207", "url": "https://ubuntu.com/security/CVE-2026-43207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix error handling in probe function Add mtk_mdp_unregister_m2m_device() on the error handling path to prevent resource leak. Add check for the return value of vpu_get_plat_device() to prevent null pointer dereference. And vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43132", "url": "https://ubuntu.com/security/CVE-2026-43132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: correctly handle dm_bufio_client_create() failure If either of the calls to dm_bufio_client_create() in verity_fec_ctr() fails, then dm_bufio_client_destroy() is later called with an ERR_PTR() argument. That causes a crash. Fix this.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2025-71274", "url": "https://ubuntu.com/security/CVE-2025-71274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: core: fix race in driver_override_show() and use core helper The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string_attr macro with explicit show and store functions. The new driver_override_store uses the standard driver_set_override helper. Since the introduction of driver_set_override, the comments in include/linux/rpmsg.h have stated that this helper must be used to set or clear driver_override, but the implementation was not updated until now. Because driver_set_override modifies and frees the string while holding the device_lock, the new driver_override_show now correctly holds the device_lock during the read operation to prevent the race. Additionally, since rpmsg_string_attr has only ever been used for driver_override, removing the macro simplifies the code.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43233", "url": "https://ubuntu.com/security/CVE-2026-43233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: fix OOB read in decode_choice() In decode_choice(), the boundary check before get_len() uses the variable `len`, which is still 0 from its initialization at the top of the function: unsigned int type, ext, len = 0; ... if (ext || (son->attr & OPEN)) { BYTE_ALIGN(bs); if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */ return H323_ERROR_BOUND; len = get_len(bs); /* OOB read */ When the bitstream is exactly consumed (bs->cur == bs->end), the check nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent get_len() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well. This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nf_conntrack_h323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer. Fix this by checking for 2 bytes (the maximum that get_len() may read) instead of the uninitialized `len`. This matches the pattern used at every other get_len() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43205", "url": "https://ubuntu.com/security/CVE-2026-43205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: validate num_ifs to prevent out-of-bounds write The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes() but never validates it against DPSW_MAX_IF (64). This value controls iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices into the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reports num_ifs >= 64, the loop can write past the array bounds. Add a bound check for num_ifs in dpaa2_switch_init(). dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all ports match the flood filter, the loop fills all 64 slots and the control interface write overflows by one entry. The check uses >= because num_ifs == DPSW_MAX_IF is also functionally broken. build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ...", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43194", "url": "https://ubuntu.com/security/CVE-2026-43194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: consume xmit errors of GSO frames udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min. These tests use veth to simulate GRO. They attach a trivial (\"return XDP_PASS;\") XDP program to the veth to force TSO off and NAPI on. Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]). In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck. The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok | ok ok ok \\\\ \t\t\t snd_nxt \"x\" means packet lost by veth, and \"ok\" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent. So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above). Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely. We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-\"networks\" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix? Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link).", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43156", "url": "https://ubuntu.com/security/CVE-2026-43156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: enable basic endpoint checking pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors: - usb_rcvbulkpipe(dev, 1) for RX data - usb_sndbulkpipe(dev, 2) for TX data - usb_rcvintpipe(dev, 3) for status interrupts A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes. Add a pegasus_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion. Similar fix to - commit 90b7f2961798 (\"net: usb: rtl8150: enable basic endpoint checking\") - commit 9e7021d2aeae (\"net: usb: catc: enable basic endpoint checking\")", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43232", "url": "https://ubuntu.com/security/CVE-2026-43232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets When the FarSync T-series card is being detached, the fst_card_info is deallocated in fst_remove_one(). However, the fst_tx_task or fst_int_task may still be running or pending, leading to use-after-free bugs when the already freed fst_card_info is accessed in fst_process_tx_work_q() or fst_process_int_work_q(). A typical race condition is depicted below: CPU 0 (cleanup) | CPU 1 (tasklet) | fst_start_xmit() fst_remove_one() | tasklet_schedule() unregister_hdlc_device()| | fst_process_tx_work_q() //handler kfree(card) //free | do_bottom_half_tx() | card-> //use The following KASAN trace was captured: ================================================================== BUG: KASAN: slab-use-after-free in do_bottom_half_tx+0xb88/0xd00 Read of size 4 at addr ffff88800aad101c by task ksoftirqd/3/32 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcb/0x5d0 ? do_bottom_half_tx+0xb88/0xd00 kasan_report+0xb8/0xf0 ? do_bottom_half_tx+0xb88/0xd00 do_bottom_half_tx+0xb88/0xd00 ? _raw_spin_lock_irqsave+0x85/0xe0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx___hrtimer_run_queues+0x10/0x10 fst_process_tx_work_q+0x67/0x90 tasklet_action_common+0x1fa/0x720 ? hrtimer_interrupt+0x31f/0x780 handle_softirqs+0x176/0x530 __irq_exit_rcu+0xab/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 41 on cpu 3 at 72.330843s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 __kasan_kmalloc+0x7f/0x90 fst_add_one+0x1a5/0x1cd0 local_pci_probe+0xdd/0x190 pci_device_probe+0x341/0x480 really_probe+0x1c6/0x6a0 __driver_probe_device+0x248/0x310 driver_probe_device+0x48/0x210 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x101/0x190 __device_attach+0x198/0x3a0 device_initial_probe+0x78/0xa0 pci_bus_add_device+0x81/0xc0 pci_bus_add_devices+0x7e/0x190 enable_slot+0x9b9/0x1130 acpiphp_check_bridge.part.0+0x2e1/0x460 acpiphp_hotplug_notify+0x36c/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... Freed by task 41 on cpu 1 at 75.138639s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x135/0x410 fst_remove_one+0x2ca/0x540 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0x364/0x530 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device+0xd/0x20 disable_slot+0x116/0x260 acpiphp_disable_and_eject_slot+0x4b/0x190 acpiphp_hotplug_notify+0x230/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... The buggy address belongs to the object at ffff88800aad1000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 28 bytes inside of freed 1024-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xaad0 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x100000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000003 ffffea00002ab401 00000000ffffffff 00000000ffffffff head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88800aad0f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800aad0f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800aad1000: fa fb ---truncated---", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43134", "url": "https://ubuntu.com/security/CVE-2026-43134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ This adds a check for encryption key size upon receiving L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAP_CR_LE_BAD_KEY_SIZE.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43180", "url": "https://ubuntu.com/security/CVE-2026-43180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls netif_stop_queue() and netif_wake_queue(). These are TX queue flow control functions unrelated to RX multicast configuration. The premature netif_wake_queue() can re-enable TX while tx_urb is still in-flight, leading to a double usb_submit_urb() on the same URB: kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); } kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done } kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active } This triggers the WARN in usb_submit_urb(): \"URB submitted while active\" This is a similar class of bug fixed in rtl8150 by - commit 958baf5eaee3 (\"net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast\"). Also kaweth_set_rx_mode() is already functionally broken, the real set_rx_mode action is performed by kaweth_async_set_rx_mode(), which in turn is not a no-op only at ndo_open() time.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43139", "url": "https://ubuntu.com/security/CVE-2026-43139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix uninitialized saddr in xfrm6_get_saddr() xfrm6_get_saddr() does not check the return value of ipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6_get_saddr() still returns 0 (success). This causes the caller xfrm_tmpl_resolve_one() to use the uninitialized address in xfrm_state_find(), triggering KMSAN warning: ===================================================== BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940 xfrm_state_find+0x2424/0xa940 xfrm_resolve_and_create_bundle+0x906/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 xfrm_lookup_route+0x63/0x2b0 ip_route_output_flow+0x1ce/0x270 udp_sendmsg+0x2ce1/0x3400 inet_sendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64_sys_sendto+0x130/0x200 x64_sys_call+0x332b/0x3e70 do_syscall_64+0xd3/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable tmp.i.i created at: xfrm_resolve_and_create_bundle+0x3e3/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 ===================================================== Fix by checking the return value of ipv6_dev_get_saddr() and propagating the error.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43141", "url": "https://ubuntu.com/security/CVE-2026-43141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut Number of MW LUTs depends on NTB configuration and can be set to zero, in such scenario rounddown_pow_of_two will cause undefined behaviour and should not be performed. This patch ensures that rounddown_pow_of_two is called on valid value.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43241", "url": "https://ubuntu.com/security/CVE-2026-43241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access Number of MW LUTs depends on NTB configuration and can be set to MAX_MWS, This patch protects against invalid index out of bounds access to mw_sizes When invalid access print message to user that configuration is not valid.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43279", "url": "https://ubuntu.com/security/CVE-2026-43279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Add sanity check for OOB writes at silencing At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2025-71267", "url": "https://ubuntu.com/security/CVE-2025-71267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an ATTR_LIST attribute indicates a zero data size while the driver allocates memory for it. When ntfs_load_attr_list() processes a resident ATTR_LIST with data_size set to zero, it still allocates memory because of al_aligned(0). This creates an inconsistent state where ni->attr_list.size is zero, but ni->attr_list.le is non-null. This causes ni_enum_attr_ex to incorrectly assume that no attribute list exists and enumerates only the primary MFT record. When it finds ATTR_LIST, the code reloads it and restarts the enumeration, repeating indefinitely. The mount operation never completes, hanging the kernel thread. This patch adds validation to ensure that data_size is non-zero before memory allocation. When a zero-sized ATTR_LIST is detected, the function returns -EINVAL, preventing a DoS vulnerability.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2025-71265", "url": "https://ubuntu.com/security/CVE-2025-71265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an attribute header indicates an empty run list, while directory entries reference it as containing actual data. In NTFS, setting evcn=-1 with svcn=0 is a valid way to represent an empty run list, and run_unpack() correctly handles this by checking if evcn + 1 equals svcn and returning early without parsing any run data. However, this creates a problem when there is metadata inconsistency, where the attribute header claims to be empty (evcn=-1) but the caller expects to read actual data. When run_unpack() immediately returns success upon seeing this condition, it leaves the runs_tree uninitialized with run->runs as a NULL. The calling function attr_load_runs_range() assumes that a successful return means that the runs were loaded and sets clen to 0, expecting the next run_lookup_entry() call to succeed. Because runs_tree remains uninitialized, run_lookup_entry() continues to fail, and the loop increments vcn by zero (vcn += 0), leading to an infinite loop. This patch adds a retry counter to detect when run_lookup_entry() fails consecutively after attr_load_runs_vcn(). If the run is still not found on the second attempt, it indicates corrupted metadata and returns -EINVAL, preventing the Denial-of-Service (DoS) vulnerability.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2025-71266", "url": "https://ubuntu.com/security/CVE-2025-71266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: check return value of indx_find to avoid infinite loop We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed dentry in the ntfs3 filesystem can cause the kernel to hang during the lookup operations. By setting the HAS_SUB_NODE flag in an INDEX_ENTRY within a directory's INDEX_ALLOCATION block and manipulating the VCN pointer, an attacker can cause the indx_find() function to repeatedly read the same block, allocating 4 KB of memory each time. The kernel lacks VCN loop detection and depth limits, causing memory exhaustion and an OOM crash. This patch adds a return value check for fnd_push() to prevent a memory exhaustion vulnerability caused by infinite loops. When the index exceeds the size of the fnd->nodes array, fnd_push() returns -EINVAL. The indx_find() function checks this return value and stops processing, preventing further memory allocation.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-43225", "url": "https://ubuntu.com/security/CVE-2026-43225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix memory leak on failure path cfg80211_inform_bss_frame() may return NULL on failure. In that case, the allocated buffer 'buf' is not freed and the function returns early, leading to potential memory leak. Fix this by ensuring that 'buf' is freed on both success and failure paths.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43230", "url": "https://ubuntu.com/security/CVE-2026-43230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: Clear reconnect pending bit When canceling the reconnect worker, care must be taken to reset the reconnect-pending bit. If the reconnect worker has not yet been scheduled before it is canceled, the reconnect-pending bit will stay on forever.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43296", "url": "https://ubuntu.com/security/CVE-2026-43296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Workaround SQM/PSE stalls by disabling sticky NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated. work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21) These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43226", "url": "https://ubuntu.com/security/CVE-2026-43226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: No shortcut out of RDS_CONN_ERROR RDS connections carry a state \"rds_conn_path::cp_state\" and transitions from one state to another and are conditional upon an expected state: \"rds_conn_path_transition.\" There is one exception to this conditionality, which is \"RDS_CONN_ERROR\" that can be enforced by \"rds_conn_path_drop\" regardless of what state the condition is currently in. But as soon as a connection enters state \"RDS_CONN_ERROR\", the connection handling code expects it to go through the shutdown-path. The RDS/TCP multipath changes added a shortcut out of \"RDS_CONN_ERROR\" straight back to \"RDS_CONN_CONNECTING\" via \"rds_tcp_accept_one_path\" (e.g. after \"rds_tcp_state_change\"). A subsequent \"rds_tcp_reset_callbacks\" can then transition the state to \"RDS_CONN_RESETTING\" with a shutdown-worker queued. That'll trip up \"rds_conn_init_shutdown\", which was never adjusted to handle \"RDS_CONN_RESETTING\" and subsequently drops the connection with the dreaded \"DR_INV_CONN_STATE\", which leaves \"RDS_SHUTDOWN_WORK_QUEUED\" on forever. So we do two things here: a) Don't shortcut \"RDS_CONN_ERROR\", but take the longer path through the shutdown code. b) Add \"RDS_CONN_RESETTING\" to the expected states in \"rds_conn_init_shutdown\" so that we won't error out and get stuck, if we ever hit weird state transitions like this again.\"", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43190", "url": "https://ubuntu.com/security/CVE-2026-43190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_tcpmss: check remaining length before reading optlen Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload).", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43255", "url": "https://ubuntu.com/security/CVE-2026-43255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix WARNING in usb_tx_block The function usb_tx_block() submits cardp->tx_urb without ensuring that any previous transmission on this URB has completed. If a second call occurs while the URB is still active (e.g. during rapid firmware loading), usb_submit_urb() detects the active state and triggers a warning: 'URB submitted while active'. Fix this by enforcing serialization: call usb_kill_urb() before submitting the new request. This ensures the URB is idle and safe to reuse.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43314", "url": "https://ubuntu.com/security/CVE-2026-43314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: remove fake timeout to avoid leak request Since commit 15f73f5b3e59 (\"blk-mq: move failure injection out of blk_mq_complete_request\"), drivers are responsible for calling blk_should_fake_timeout() at appropriate code paths and opportunities. However, the dm driver does not implement its own timeout handler and relies on the timeout handling of its slave devices. If an io-timeout-fail error is injected to a dm device, the request will be leaked and never completed, causing tasks to hang indefinitely. Reproduce: 1. prepare dm which has iscsi slave device 2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times 3. read/write dm 4. iscsiadm -m node -u Result: hang task like below [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds. [ 862.244133] Tainted: G E 6.19.0-rc1+ #51 [ 862.244337] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000 [ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi] [ 862.245264] Call Trace: [ 862.245587] [ 862.245814] __schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120 [ 862.247688] elevator_change+0x16d/0x460 [ 862.247893] elevator_set_none+0x87/0xf0 [ 862.248798] blk_unregister_queue+0x12e/0x2a0 [ 862.248995] __del_gendisk+0x231/0x7e0 [ 862.250143] del_gendisk+0x12f/0x1d0 [ 862.250339] sd_remove+0x85/0x130 [sd_mod] [ 862.250650] device_release_driver_internal+0x36d/0x530 [ 862.250849] bus_remove_device+0x1dd/0x3f0 [ 862.251042] device_del+0x38a/0x930 [ 862.252095] __scsi_remove_device+0x293/0x360 [ 862.252291] scsi_remove_target+0x486/0x760 [ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi] [ 862.252886] process_one_work+0x633/0xe50 [ 862.253101] worker_thread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] ret_from_fork+0x2a6/0x470 [ 862.255852] ret_from_fork_asm+0x1a/0x30 [ 862.256037] Remove the blk_should_fake_timeout() check from dm, as dm has no native timeout handling and should not attempt to fake timeouts.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-71292", "url": "https://ubuntu.com/security/CVE-2025-71292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: nlink overflow in jfs_rename If nlink is maximal for a directory (-1) and inside that directory you perform a rename for some child directory (not moving from the parent), then the nlink of the first directory is first incremented and later decremented. Normally this is fine, but when nlink = -1 this causes a wrap around to 0, and then drop_nlink issues a warning. After applying the patch syzbot no longer issues any warnings. I also ran some basic fs tests to look for any regressions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43236", "url": "https://ubuntu.com/security/CVE-2026-43236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying the atmel_hlcdc_plane state structure without properly duplicating the drm_plane_state. In particular, state->commit remained set to the old state commit, which can lead to a use-after-free in the next drm_atomic_commit() call. Fix this by calling __drm_atomic_helper_duplicate_plane_state(), which correctly clones the base drm_plane_state (including the ->commit pointer). It has been seen when closing and re-opening the device node while another DRM client (e.g. fbdev) is still attached: ============================================================================= BUG kmalloc-64 (Not tainted): Poison overwritten ----------------------------------------------------------------------------- 0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0 pid=29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28 Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0 pid=169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0 flags=0x200(workingset|zone=0) Object 0xc611b340 @offset=832 fp=0xc611b7c0", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43269", "url": "https://ubuntu.com/security/CVE-2026-43269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback After several commits, the slab memory increases. Some drm_crtc_commit objects are not freed. The atomic_destroy_state callback only put the framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function to put all the objects that are no longer needed. It has been seen after hours of usage of a graphics application or using kmemleak: unreferenced object 0xc63a6580 (size 64): comm \"egt_basic\", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleak_alloc+0x34/0x3c __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43287", "url": "https://ubuntu.com/security/CVE-2026-43287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Account property blob allocations to memcg DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory. Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM. Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43183", "url": "https://ubuntu.com/security/CVE-2026-43183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx25821: Fix a resource leak in cx25821_dev_setup() Add release_mem_region() if ioremap() fails to release the memory region obtained by cx25821_get_resources().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43316", "url": "https://ubuntu.com/security/CVE-2026-43316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: solo6x10: Check for out of bounds chip_id Clang with CONFIG_UBSAN_SHIFT=y noticed a condition where a signed type (literal \"1\" is an \"int\") could end up being shifted beyond 32 bits, so instrumentation was added (and due to the double is_tw286x() call seen via inlining), Clang decides the second one must now be undefined behavior and elides the rest of the function[1]. This is a known problem with Clang (that is still being worked on), but we can avoid the entire problem by actually checking the existing max chip ID, and now there is no runtime instrumentation added at all since everything is known to be within bounds. Additionally use an unsigned value for the shift to remove the instrumentation even without the explicit bounds checking. [hverkuil: fix checkpatch warning for is_tw286x]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43223", "url": "https://ubuntu.com/security/CVE-2026-43223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix URB leak in pvr2_send_request_ex When pvr2_send_request_ex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2_send_request_ex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usb_submit_urb(). Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43302", "url": "https://ubuntu.com/security/CVE-2026-43302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Set DMA segment size to avoid debug warnings When using V3D rendering with CONFIG_DMA_API_DEBUG enabled, the kernel occasionally reports a segment size mismatch. This is because 'max_seg_size' is not set. The kernel defaults to 64K. setting 'max_seg_size' to the maximum will prevent 'debug_dma_map_sg()' from complaining about the over-mapping of the V3D segment length. DMA-API: v3d 1002000000.v3d: mapping sg segment longer than device claims to support [len=8290304] [max=65536] WARNING: CPU: 0 PID: 493 at kernel/dma/debug.c:1179 debug_dma_map_sg+0x330/0x388 CPU: 0 UID: 0 PID: 493 Comm: Xorg Not tainted 6.12.53-yocto-standard #1 Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_dma_map_sg+0x330/0x388 lr : debug_dma_map_sg+0x330/0x388 sp : ffff8000829a3ac0 x29: ffff8000829a3ac0 x28: 0000000000000001 x27: ffff8000813fe000 x26: ffffc1ffc0000000 x25: ffff00010fdeb760 x24: 0000000000000000 x23: ffff8000816a9bf0 x22: 0000000000000001 x21: 0000000000000002 x20: 0000000000000002 x19: ffff00010185e810 x18: ffffffffffffffff x17: 69766564206e6168 x16: 74207265676e6f6c x15: 20746e656d676573 x14: 20677320676e6970 x13: 5d34303334393134 x12: 0000000000000000 x11: 00000000000000c0 x10: 00000000000009c0 x9 : ffff8000800e0b7c x8 : ffff00010a315ca0 x7 : ffff8000816a5110 x6 : 0000000000000001 x5 : 000000000000002b x4 : 0000000000000002 x3 : 0000000000000008 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00010a315280 Call trace: debug_dma_map_sg+0x330/0x388 __dma_map_sg_attrs+0xc0/0x278 dma_map_sgtable+0x30/0x58 drm_gem_shmem_get_pages_sgt+0xb4/0x140 v3d_bo_create_finish+0x28/0x130 [v3d] v3d_create_bo_ioctl+0x54/0x180 [v3d] drm_ioctl_kernel+0xc8/0x140 drm_ioctl+0x2d4/0x4d8", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43124", "url": "https://ubuntu.com/security/CVE-2026-43124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore: ram_core: fix incorrect success return when vmap() fails In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43227", "url": "https://ubuntu.com/security/CVE-2026-43227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/sh_tmu: Always leave device running after probe The TMU device can be used as both a clocksource and a clockevent provider. The driver tries to be smart and power itself on and off, as well as enabling and disabling its clock when it's not in operation. This behavior is slightly altered if the TMU is used as an early platform device in which case the device is left powered on after probe, but the clock is still enabled and disabled at runtime. This has worked for a long time, but recent improvements in PREEMPT_RT and PROVE_LOCKING have highlighted an issue. As the TMU registers itself as a clockevent provider, clockevents_register_device(), it needs to use raw spinlocks internally as this is the context of which the clockevent framework interacts with the TMU driver. However in the context of holding a raw spinlock the TMU driver can't really manage its power state or clock with calls to pm_runtime_*() and clk_*() as these calls end up in other platform drivers using regular spinlocks to control power and clocks. This mix of spinlock contexts trips a lockdep warning. ============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90 For non-PREEMPT_RT builds this is not really an issue, but for PREEMPT_RT builds where normal spinlocks can sleep this might be an issue. Be cautious and always leave the power and clock running after probe.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43313", "url": "https://ubuntu.com/security/CVE-2026-43313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4() In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDE device and then reassigned an ISA device: dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...); dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...); If the first lookup succeeds but the second fails, dev becomes NULL. This leads to a potential null-pointer dereference when dev_dbg() is called: if (errata.piix4.bmisx) dev_dbg(&dev->dev, ...); To prevent this, use two temporary pointers and retrieve each device independently, avoiding overwriting dev with a possible NULL value. [ rjw: Subject adjustment, added an empty code line ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43266", "url": "https://ubuntu.com/security/CVE-2026-43266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EFI/CPER: don't go past the ARM processor CPER record buffer There's a logic inside GHES/CPER to detect if the section_length is too small, but it doesn't detect if it is too big. Currently, if the firmware receives an ARM processor CPER record stating that a section length is big, kernel will blindly trust section_length, producing a very long dump. For instance, a 67 bytes record with ERR_INFO_NUM set 46198 and section length set to 854918320 would dump a lot of data going a way past the firmware memory-mapped area. Fix it by adding a logic to prevent it to go past the buffer if ERR_INFO_NUM is too big, making it report instead: \t[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 \t[Hardware Error]: event severity: recoverable \t[Hardware Error]: Error 0, type: recoverable \t[Hardware Error]: section_type: ARM processor error \t[Hardware Error]: MIDR: 0xff304b2f8476870a \t[Hardware Error]: section length: 854918320, CPER size: 67 \t[Hardware Error]: section length is too big \t[Hardware Error]: firmware-generated error record is incorrect \t[Hardware Error]: ERR_INFO_NUM is 46198 [ rjw: Subject and changelog tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43277", "url": "https://ubuntu.com/security/CVE-2026-43277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: APEI/GHES: ensure that won't go past CPER allocated record The logic at ghes_new() prevents allocating too large records, by checking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB). Yet, the allocation is done with the actual number of pages from the CPER bios table location, which can be smaller. Yet, a bad firmware could send data with a different size, which might be bigger than the allocated memory, causing an OOPS: Unable to handle kernel paging request at virtual address fff00000f9b40000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000 [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 Workqueue: kacpi_notify acpi_os_execute_deferred pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : hex_dump_to_buffer+0x30c/0x4a0 lr : hex_dump_to_buffer+0x328/0x4a0 sp : ffff800080e13880 x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083 x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004 x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083 x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010 x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008 x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020 x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000 x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008 Call trace: hex_dump_to_buffer+0x30c/0x4a0 (P) print_hex_dump+0xac/0x170 cper_estatus_print_section+0x90c/0x968 cper_estatus_print+0xf0/0x158 __ghes_print_estatus+0xa0/0x148 ghes_proc+0x1bc/0x220 ghes_notify_hed+0x5c/0xb8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x80 acpi_hed_notify+0x28/0x40 acpi_ev_notify_dispatch+0x50/0x80 acpi_os_execute_deferred+0x24/0x48 process_one_work+0x15c/0x3b0 worker_thread+0x2d0/0x400 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44) ---[ end trace 0000000000000000 ]--- Prevent that by taking the actual allocated are into account when checking for CPER length. [ rjw: Subject tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43171", "url": "https://ubuntu.com/security/CVE-2026-43171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EFI/CPER: don't dump the entire memory region The current logic at cper_print_fw_err() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory. The end result can be: - the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region. Fix it by checking if the section length is too small before doing a hex dump. [ rjw: Subject tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43184", "url": "https://ubuntu.com/security/CVE-2026-43184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rnbd-srv: Zero the rsp buffer before using it Before using the data buffer to send back the response message, zero it completely. This prevents any stray bytes to be picked up by the client side when there the message is exchanged between different protocol versions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43261", "url": "https://ubuntu.com/security/CVE-2026-43261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Add support for TSV110 Spectre-BHB mitigation The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43262", "url": "https://ubuntu.com/security/CVE-2026-43262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fiemap page fault fix In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault. Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary. Fixes xfstest generic/742.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43209", "url": "https://ubuntu.com/security/CVE-2026-43209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: minix: Add required sanity checking to minix_check_superblock() The fs/minix implementation of the minix filesystem does not currently support any other value for s_log_zone_size than 0. This is also the only value supported in util-linux; see mkfs.minix.c line 511. In addition, this patch adds some sanity checking for the other minix superblock fields, and moves the minix_blocks_needed() checks for the zmap and imap also to minix_check_super_block(). This also closes a related syzbot bug report.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43268", "url": "https://ubuntu.com/security/CVE-2026-43268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: pretend special inodes as regular files Since commit af153bb63a33 (\"vfs: catch invalid modes in may_open()\") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23241", "url": "https://ubuntu.com/security/CVE-2026-23241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: add missing syscalls to read class The \"at\" variant of getxattr() and listxattr() are missing from the audit read class. Calling getxattrat() or listxattrat() on a file to read its extended attributes will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds missing syscalls to the audit read class.", "cve_priority": "medium", "cve_public_date": "2026-03-17 10:16:00 UTC" }, { "cve": "CVE-2025-71239", "url": "https://ubuntu.com/security/CVE-2025-71239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: add fchmodat2() to change attributes class fchmodat2(), introduced in version 6.6 is currently not in the change attribute class of audit. Calling fchmodat2() to change a file attribute in the same fashion than chmod() or fchmodat() will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds fchmodat2() to the change attributes class.", "cve_priority": "medium", "cve_public_date": "2026-03-17 10:15:00 UTC" }, { "cve": "CVE-2026-45964", "url": "https://ubuntu.com/security/CVE-2026-45964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path Commit 5940d1cf9f42 (\"SUNRPC: Rebalance a kref in auth_gss.c\") added a kref_get(&gss_auth->kref) call to balance the gss_put_auth() done in gss_release_msg(), but forgot to add a corresponding kref_put() on the error path when kstrdup_const() fails. If service_name is non-NULL and kstrdup_const() fails, the function jumps to err_put_pipe_version which calls put_pipe_version() and kfree(gss_msg), but never releases the gss_auth reference. This leads to a kref leak where the gss_auth structure is never freed. Add a forward declaration for gss_free_callback() and call kref_put() in the err_put_pipe_version error path to properly release the reference taken earlier.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45870", "url": "https://ubuntu.com/security/CVE-2026-45870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: auth_gss: fix memory leaks in XDR decoding error paths The gssx_dec_ctx(), gssx_dec_status(), and gssx_dec_name() functions allocate memory via gssx_dec_buffer(), which calls kmemdup(). When a subsequent decode operation fails, these functions return immediately without freeing previously allocated buffers, causing memory leaks. The leak in gssx_dec_ctx() is particularly relevant because the caller (gssp_accept_sec_context_upcall) initializes several buffer length fields to non-zero values, resulting in memory allocation: struct gssx_ctx rctxh = { .exported_context_token.len = GSSX_max_output_handle_sz, .mech.len = GSS_OID_MAX_LEN, .src_name.display_name.len = GSSX_max_princ_sz, .targ_name.display_name.len = GSSX_max_princ_sz }; If, for example, gssx_dec_name() succeeds for src_name but fails for targ_name, the memory allocated for exported_context_token, mech, and src_name.display_name remains unreferenced and cannot be reclaimed. Add error handling with goto-based cleanup to free any previously allocated buffers before returning an error.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45948", "url": "https://ubuntu.com/security/CVE-2026-45948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leak in ext4_ext_shift_extents() In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4_find_extent(), leading to a memory leak. Fix this by jumping to the out label to ensure the path is properly released.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45912", "url": "https://ubuntu.com/security/CVE-2026-45912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't cache extent during splitting extent Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful. Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, when ext4_split_extent_at() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4_find_extent() and ext4_cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting. In adition, if the unwritten extent cache is not shrunk during the splitting, ext4_cache_extents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46250", "url": "https://ubuntu.com/security/CVE-2026-46250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: MIPS: Work around LLVM bug when gp is used as global register variable On MIPS, __current_thread_info is defined as global register variable locating in $gp, and is simply assigned with new address during kernel relocation. This however is broken with LLVM, which always restores $gp if it finds $gp is clobbered in any form, including when intentionally through a global register variable. This is against GCC's documentation[1], which requires a callee-saved register used as global register variable not to be restored if it's clobbered. As a result, $gp will continue to point to the unrelocated kernel after the epilog of relocate_kernel(), leading to an early crash in init_idle, [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY [ 0.000000] Tainted: [W]=WARN [ 0.000000] Hardware name: loongson,loongson64v-4core-virtio [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240 [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001 [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002 [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80 [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80 [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90 [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90 [ 0.000000] Hi : 0000000000000000 [ 0.000000] Lo : 0000000000000000 [ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270 [ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270 [ 0.000000] Status: 540000e2\tKX SX UX KERNEL EXL [ 0.000000] Cause : 00000008 (ExcCode 02) [ 0.000000] BadVA : 0000000000000000 [ 0.000000] PrId : 00006305 (ICT Loongson-3) [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000) [ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528 [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000 [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258 [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98 [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [] init_idle+0x130/0x270 [ 0.000000] [] sched_init+0x5c8/0x6c0 [ 0.000000] [] start_kernel+0x27c/0x7a8 This bug has been reported to LLVM[2] and affects version from (at least) 18 to 21. Let's work around this by using inline assembly to assign $gp before a fix is widely available.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45974", "url": "https://ubuntu.com/security/CVE-2026-45974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not found If btrfs_search_slot_for_read() returns 1, it means we did not find any key greater than or equals to the key we asked for, meaning we have reached the end of the tree and therefore the path is not valid. If this happens we need to break out of the loop and stop, instead of continuing and accessing an invalid path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45965", "url": "https://ubuntu.com/security/CVE-2026-45965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix invalid deref of rawdata when export_binary is unset If the export_binary parameter is disabled on runtime, profiles that were loaded before that will still have their rawdata stored in apparmorfs, with a symbolic link to the rawdata on the policy directory. When one of those profiles are replaced, the rawdata is set to NULL, but when trying to resolve the symbolic links to rawdata for that profile, it will try to dereference profile->rawdata->name when profile->rawdata is now NULL causing an oops. Fix it by checking if rawdata is set. [ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088 [ 168.657420] #PF: supervisor read access in kernel mode [ 168.660619] #PF: error_code(0x0000) - not-present page [ 168.663613] PGD 0 P4D 0 [ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI [ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary) [ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330 [ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8 [ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282 [ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158 [ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80 [ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000 [ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80 [ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0 [ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000 [ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0 [ 168.701696] Call Trace: [ 168.702325] [ 168.702995] rawdata_get_link_data+0x1c/0x30 [ 168.704145] vfs_readlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64_sys_readlink+0x1e/0x30 [ 168.708653] x64_sys_call+0x1d77/0x26b0 [ 168.709525] do_syscall_64+0x81/0x500 [ 168.710348] ? do_statx+0x72/0xb0 [ 168.711109] ? putname+0x3e/0x80 [ 168.711845] ? __x64_sys_statx+0xb7/0x100 [ 168.712711] ? x64_sys_call+0x10fc/0x26b0 [ 168.713577] ? do_syscall_64+0xbf/0x500 [ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0 [ 168.715404] ? irqentry_exit+0xb2/0x740 [ 168.716359] ? exc_page_fault+0x90/0x1b0 [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45848", "url": "https://ubuntu.com/security/CVE-2026-45848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix NULL sock in aa_sock_file_perm Deal with the potential that sock and sock-sk can be NULL during socket setup or teardown. This could lead to an oops. The fix for NULL pointer dereference in __unix_needs_revalidation shows this is at least possible for af_unix sockets. While the fix for af_unix sockets applies for newer mediation this is still the fall back path for older af_unix mediation and other sockets, so ensure it is covered.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45970", "url": "https://ubuntu.com/security/CVE-2026-45970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: alb: fix UAF in rlb_arp_recv during bond up/down The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN. However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag. [ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? __pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry. Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45847", "url": "https://ubuntu.com/security/CVE-2026-45847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: remove WARN_ON_ONCE when accessing forward path array Although unlikely, recent support for IPIP tunnels increases chances of reaching this WARN_ON_ONCE if userspace manages to build a sufficiently long forward path. Remove it.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45890", "url": "https://ubuntu.com/security/CVE-2026-45890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen-netback: reject zero-queue configuration from guest A malicious or buggy Xen guest can write \"0\" to the xenbus key \"multi-queue-num-queues\". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range(). On systems with panic_on_warn=1, this allows a guest-to-host denial of service. The Xen network interface specification requires the queue count to be \"greater than zero\". Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45968", "url": "https://ubuntu.com/security/CVE-2026-45968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuidle: Skip governor when only one idle state is available On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash. [ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668 Fix this by adding a bail-out in cpuidle_select() that returns state 0 directly when state_count <= 1, bypassing the governor and keeping the tick running.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45935", "url": "https://ubuntu.com/security/CVE-2026-45935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot In the 'DeleteIndexEntryRoot' case of the 'do_action' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking. Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize); It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to size_t for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow. This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45864", "url": "https://ubuntu.com/security/CVE-2026-45864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent infinite loops caused by the next valid being the same When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1]. Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this. [1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45868", "url": "https://ubuntu.com/security/CVE-2026-45868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix refcount leak in pcs_add_gpio_func() of_parse_phandle_with_args() returns a device_node pointer with refcount incremented in gpiospec.np. The loop iterates through all phandles but never releases the reference, causing a refcount leak on each iteration. Add of_node_put() calls to release the reference after extracting the needed arguments and on the error path when devm_kzalloc() fails. This bug was detected by our static analysis tool and verified by my code review.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45883", "url": "https://ubuntu.com/security/CVE-2026-45883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: sca3000: Fix a resource leak in sca3000_probe() spi->irq from request_threaded_irq() not released when iio_device_register() fails. Add an return value check and jump to a common error handler when iio_device_register() fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45875", "url": "https://ubuntu.com/security/CVE-2026-45875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: arizona: Fix regulator resource leak on wm5102_clear_write_sequencer() failure The wm5102_clear_write_sequencer() helper may return an error and just return, bypassing the cleanup sequence and causing regulators to remain enabled, leading to a resource leak. Change the direct return to jump to the err_reset label to properly free the resources.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45978", "url": "https://ubuntu.com/security/CVE-2026-45978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: greybus: lights: avoid NULL deref gb_lights_light_config() stores channel_count before allocating the channels array. If kcalloc() fails, gb_lights_release() iterates the non-zero count and dereferences light->channels, which is NULL. Allocate channels first and only then publish channels_count so the cleanup path can't walk a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45954", "url": "https://ubuntu.com/security/CVE-2026-45954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe() In au1200fb_drv_probe(), when platform_get_irq fails(), it directly returns from the function with an error code, which causes a memory leak. Replace it with a goto label to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45857", "url": "https://ubuntu.com/security/CVE-2026-45857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: csiostor: Fix dereference of null pointer rn The error exit path when rn is NULL ends up deferencing the null pointer rn via the use of the macro CSIO_INC_STATS. Fix this by adding a new error return path label after the use of the macro to avoid the deference.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45856", "url": "https://ubuntu.com/security/CVE-2026-45856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45852", "url": "https://ubuntu.com/security/CVE-2026-45852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45869", "url": "https://ubuntu.com/security/CVE-2026-45869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: wm97xx: Fix NULL pointer dereference in power_supply_changed() In `probe()`, `request_irq()` is called before allocating/registering a `power_supply` handle. If an interrupt is fired between the call to `request_irq()` and `power_supply_register()`, the `power_supply` handle will be used uninitialized in `power_supply_changed()` in `wm97xx_bat_update()` (triggered from the interrupt handler). This will lead to a `NULL` pointer dereference since Fix this racy `NULL` pointer dereference by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Since the IRQ is the last thing requests in the `probe()` now, remove the error path for freeing it. Instead add one for unregistering the `power_supply` handle when IRQ request fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45916", "url": "https://ubuntu.com/security/CVE-2026-45916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sbs-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Keep the old behavior of just printing a warning in case of any failures during the IRQ request and finishing the probe successfully.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46270", "url": "https://ubuntu.com/security/CVE-2026-46270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: rt9455: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45936", "url": "https://ubuntu.com/security/CVE-2026-45936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: goldfish: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45885", "url": "https://ubuntu.com/security/CVE-2026-45885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cpcap-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45879", "url": "https://ubuntu.com/security/CVE-2026-45879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq25980: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45902", "url": "https://ubuntu.com/security/CVE-2026-45902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45867", "url": "https://ubuntu.com/security/CVE-2026-45867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: act8945a: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45946", "url": "https://ubuntu.com/security/CVE-2026-45946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Commit 1c1f13a006ed (\"power: supply: ab8500: Move to componentized binding\") introduced this issue during a refactorization. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45866", "url": "https://ubuntu.com/security/CVE-2026-45866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: caif: fix use-after-free in caif_serial ldisc_close() There is a use-after-free bug in caif_serial where handle_tx() may access ser->tty after the tty has been freed. The race condition occurs between ldisc_close() and packet transmission: CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldisc_close() tty_kref_put(ser->tty) [tty may be freed here] <-- race window --> caif_xmit() handle_tx() tty = ser->tty // dangling ptr tty->ops->write() // UAF! schedule_work() ser_release() unregister_netdevice() The root cause is that tty_kref_put() is called in ldisc_close() while the network device is still active and can receive packets. Since ser and tty have a 1:1 binding relationship with consistent lifecycles (ser is allocated in ldisc_open and freed in ser_release via unregister_netdevice, and each ser binds exactly one tty), we can safely defer the tty reference release to ser_release() where the network device is unregistered. Fix this by moving tty_kref_put() from ldisc_close() to ser_release(), after unregister_netdevice(). This ensures the tty reference is held as long as the network device exists, preventing the UAF. Note: We save ser->tty before unregister_netdevice() because ser is embedded in netdev's private data and will be freed along with netdev (needs_free_netdev = true). How to reproduce: Add mdelay(500) at the beginning of ldisc_close() to widen the race window, then run the reproducer program [1]. Note: There is a separate deadloop issue in handle_tx() when using PORT_UNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper serial backend). This deadloop exists even without this patch, and is likely caused by inconsistency between uart_write_room() and uart_write() in serial core. It has been addressed in a separate patch [2]. KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in handle_tx+0x5d1/0x620 Read of size 1 at addr ffff8881131e1490 by task caif_uaf_trigge/9929 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xd0/0x630 kasan_report+0xe4/0x120 handle_tx+0x5d1/0x620 dev_hard_start_xmit+0x9d/0x6c0 __dev_queue_xmit+0x6e2/0x4410 packet_xmit+0x243/0x360 packet_sendmsg+0x26cf/0x5500 __sys_sendto+0x4a3/0x520 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0xc9/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f615df2c0d7 Allocated by task 9930: Freed by task 64: Last potentially related work creation: The buggy address belongs to the object at ffff8881131e1000 which belongs to the cache kmalloc-cg-2k of size 2048 The buggy address is located 1168 bytes inside of freed 2048-byte region [ffff8881131e1000, ffff8881131e1800) The buggy address belongs to the physical page: page_owner tracks the page as allocated page last free pid 9778 tgid 9778 stack trace: Memory state around the buggy address: ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-31411", "url": "https://ubuntu.com/security/CVE-2026-31411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: fix crash due to unvalidated vcc pointer in sigd_send() Reproducer available at [1]. The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values. Fix this by introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found. Since struct atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock_hold/sock_put is sufficient to keep the vcc alive while it is being used. Note that there may be a race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety. [1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3", "cve_priority": "medium", "cve_public_date": "2026-04-08 14:16:00 UTC" }, { "cve": "CVE-2026-46259", "url": "https://ubuntu.com/security/CVE-2026-46259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent.", "cve_priority": "high", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45891", "url": "https://ubuntu.com/security/CVE-2026-45891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix double free issue for tx spare buffer In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory. Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory. The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer. Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new `tx_spare` fails. This ensures the error cleanup path only frees genuinely newly allocated buffers.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45873", "url": "https://ubuntu.com/security/CVE-2026-45873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets Userspace provides an optimized representation in case intervals are adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous set checks on start elements for this reason. However, it is possible to add intervals that overlap to this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end \tA B start end A C Restore the check on overlapping start elements to report an overlap.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46267", "url": "https://ubuntu.com/security/CVE-2026-46267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: hci: shdlc: Stop timers and work before freeing context llc_shdlc_deinit() purges SHDLC skb queues and frees the llc_shdlc structure while its timers and state machine work may still be active. Timer callbacks can schedule sm_work, and sm_work accesses SHDLC state and the skb queues. If teardown happens in parallel with a queued/running work item, it can lead to UAF and other shutdown races. Stop all SHDLC timers and cancel sm_work synchronously before purging the queues and freeing the context. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-46249", "url": "https://ubuntu.com/security/CVE-2026-46249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix PF driver crash with kexec kernel booting During a kexec reboot the hardware is not power-cycled, so AF state from the old kernel can persist into the new kernel. When AF and PF drivers are built as modules, the PF driver may probe before AF reinitializes the hardware. The PF driver treats the RVUM block revision as an indication that AF initialization is complete. If this value is left uncleared at shutdown, PF may incorrectly assume AF is ready and access stale hardware state, leading to a crash. Clear the RVUM block revision during AF shutdown to avoid PF mis-detecting AF readiness after kexec.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45915", "url": "https://ubuntu.com/security/CVE-2026-45915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: avoid parent link count underflow in rmdir Corrupted FAT images can leave a directory inode with an incorrect i_nlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls drop_nlink(dir) and can drive i_nlink to 0, triggering the WARN_ON in drop_nlink(). Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45983", "url": "https://ubuntu.com/security/CVE-2026-45983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: never defer requests during idmap lookup During v4 request compound arg decoding, some ops (e.g. SETATTR) can trigger idmap lookup upcalls. When those upcall responses get delayed beyond the allowed time limit, cache_check() will mark the request for deferral and cause it to be dropped. This prevents nfs4svc_encode_compoundres from being executed, and thus the session slot flag NFSD4_SLOT_INUSE never gets cleared. Subsequent client requests will fail with NFSERR_JUKEBOX, given that the slot will be marked as in-use, making the SEQUENCE op fail. Fix this by making sure that the RQ_USEDEFERRAL flag is always clear during nfs4svc_decode_compoundargs(), since no v4 request should ever be deferred.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45862", "url": "https://ubuntu.com/security/CVE-2026-45862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush cache for PASID table before using it When writing the address of a freshly allocated zero-initialized PASID table to a PASID directory entry, do that after the CPU cache flush for this PASID table, not before it, to avoid the time window when this PASID table may be already used by non-coherent IOMMU hardware while its contents in RAM is still some random old data, not zero-initialized.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45860", "url": "https://ubuntu.com/security/CVE-2026-45860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: increase the connection clean up limit to 64 After the optimization to only perform one GC per jiffy, a new problem was introduced. If more than 8 new connections are tracked per jiffy the list won't be cleaned up fast enough possibly reaching the limit wrongly. In order to prevent this issue, only skip the GC if it was already triggered during the same jiffy and the increment is lower than the clean up limit. In addition, increase the clean up limit to 64 connections to avoid triggering GC too often and do more effective GCs. This has been tested using a HTTP server and several performance tools while having nft_connlimit/xt_connlimit or OVS limit configured. Output of slowhttptest + OVS limit at 52000 connections: slow HTTP test status on 340th second: initializing: 0 pending: 432 connected: 51998 error: 0 closed: 0 service available: YES", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45969", "url": "https://ubuntu.com/security/CVE-2026-45969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: playstation: Add missing check for input_ff_create_memless The ps_gamepad_create() function calls input_ff_create_memless() without verifying its return value, which can lead to incorrect behavior or potential crashes when FF effects are triggered. Add a check for the return value of input_ff_create_memless().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-71304", "url": "https://ubuntu.com/security/CVE-2025-71304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: /smack/doi: accept previously used values Writing to /smack/doi a value that has ever been written there in the past disables networking for non-ambient labels. E.g. # cat /smack/doi 3 # netlabelctl -p cipso list Configured CIPSO mappings (1) DOI value : 3 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (3) domain: \"_\" (IPv4) protocol: UNLABELED domain: DEFAULT (IPv4) protocol: CIPSO, DOI = 3 domain: DEFAULT (IPv6) protocol: UNLABELED # cat /smack/ambient _ # cat /proc/$$/attr/smack/current _ # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.964 ms # echo foo >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.956 ms unknown option 86 # echo 4 >/smack/doi # echo 3 >/smack/doi !> [ 214.050395] smk_cipso_doi:691 cipso add rc = -17 # echo 3 >/smack/doi !> [ 249.402261] smk_cipso_doi:678 remove rc = -2 !> [ 249.402261] smk_cipso_doi:691 cipso add rc = -17 # ping -c1 10.1.95.12 !!> ping: 10.1.95.12: Address family for hostname not supported # echo _ >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.617 ms This happens because Smack keeps decommissioned DOIs, fails to re-add them, and consequently refuses to add the “default” domain map: # netlabelctl -p cipso list Configured CIPSO mappings (2) DOI value : 3 mapping type : PASS_THROUGH DOI value : 4 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (2) domain: \"_\" (IPv4) protocol: UNLABELED !> (no ipv4 map for default domain here) domain: DEFAULT (IPv6) protocol: UNLABELED Fix by clearing decommissioned DOI definitions and serializing concurrent DOI updates with a new lock. Also: - allow /smack/doi to live unconfigured, since adding a map (netlbl_cfg_cipsov4_map_add) may fail. CIPSO_V4_DOI_UNKNOWN(0) indicates the unconfigured DOI - add new DOI before removing the old default map, so the old map remains if the add fails (2008-02-04, Casey Schaufler)", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45904", "url": "https://ubuntu.com/security/CVE-2026-45904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling The recent commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug safe\") restructured the EEH driver to improve synchronization with the PCI hotplug layer. However, it inadvertently moved pci_lock_rescan_remove() outside its intended scope in eeh_handle_normal_event(), leading to broken PCI error reporting and improper EEH event triggering. Specifically, eeh_handle_normal_event() acquired pci_lock_rescan_remove() before calling eeh_pe_bus_get(), but eeh_pe_bus_get() itself attempts to acquire the same lock internally, causing nested locking and disrupting normal EEH event handling paths. This patch adds a boolean parameter do_lock to _eeh_pe_bus_get(), with two public wrappers: eeh_pe_bus_get() with locking enabled. eeh_pe_bus_get_nolock() that skips locking. Callers that already hold pci_lock_rescan_remove() now use eeh_pe_bus_get_nolock() to avoid recursive lock acquisition. Additionally, pci_lock_rescan_remove() calls are restored to the correct position—after eeh_pe_bus_get() and immediately before iterating affected PEs and devices. This ensures EEH-triggered PCI removes occur under proper bus rescan locking without recursive lock contention. The eeh_pe_loc_get() function has been split into two functions: eeh_pe_loc_get(struct eeh_pe *pe) which retrieves the loc for given PE. eeh_pe_loc_get_bus(struct pci_bus *bus) which retrieves the location code for given bus. This resolves lockdep warnings such as: [ 84.964298] [ T928] ============================================ [ 84.964304] [ T928] WARNING: possible recursive locking detected [ 84.964311] [ T928] 6.18.0-rc3 #51 Not tainted [ 84.964315] [ T928] -------------------------------------------- [ 84.964320] [ T928] eehd/928 is trying to acquire lock: [ 84.964324] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964342] [ T928] but task is already holding lock: [ 84.964347] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964357] [ T928] other info that might help us debug this: [ 84.964363] [ T928] Possible unsafe locking scenario: [ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928] lock(pci_rescan_remove_lock); [ 84.964378] [ T928] lock(pci_rescan_remove_lock); [ 84.964383] [ T928] *** DEADLOCK *** [ 84.964388] [ T928] May be due to missing lock nesting notation [ 84.964393] [ T928] 1 lock held by eehd/928: [ 84.964397] [ T928] #0: c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964408] [ T928] stack backtrace: [ 84.964414] [ T928] CPU: 2 UID: 0 PID: 928 Comm: eehd Not tainted 6.18.0-rc3 #51 VOLUNTARY [ 84.964417] [ T928] Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_022) hv:phyp pSeries [ 84.964419] [ T928] Call Trace: [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130 (unreliable) [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [ 84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c00000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46253", "url": "https://ubuntu.com/security/CVE-2026-46253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore/ram: fix buffer overflow in persistent_ram_save_old() persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz->old_log when it is NULL, but it unconditionally updates prz->old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1) 9. ramoops_get_next_prz() → persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45919", "url": "https://ubuntu.com/security/CVE-2026-45919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/rt: Skip currently executing CPU in rto_next_cpu() CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts. The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45871", "url": "https://ubuntu.com/security/CVE-2026-45871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Fix missing cleanup on get_burstcount() error get_burstcount() can return -EBUSY on timeout. When this happens, st33zp24_send() returns directly without releasing the locality acquired earlier. Use goto out_err to ensure proper cleanup when get_burstcount() fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45941", "url": "https://ubuntu.com/security/CVE-2026-45941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_infineon: Fix locality leak on get_burstcount() failure get_burstcount() can return -EBUSY on timeout. When this happens, the function returns directly without releasing the locality that was acquired at the beginning of tpm_tis_i2c_send(). Use goto out_err to ensure proper cleanup when get_burstcount() fails.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45984", "url": "https://ubuntu.com/security/CVE-2026-45984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix use-after-free in iomap inline data write path The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45960", "url": "https://ubuntu.com/security/CVE-2026-45960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: return error when node already exists in hfs_bnode_create When hfs_bnode_create() finds that a node is already hashed (which should not happen in normal operation), it currently returns the existing node without incrementing its reference count. This causes a reference count inconsistency that leads to a kernel panic when the node is later freed in hfs_bnode_put(): kernel BUG at fs/hfsplus/bnode.c:676! BUG_ON(!atomic_read(&node->refcnt)) This scenario can occur when hfs_bmap_alloc() attempts to allocate a node that is already in use (e.g., when node 0's bitmap bit is incorrectly unset), or due to filesystem corruption. Returning an existing node from a create path is not normal operation. Fix this by returning ERR_PTR(-EEXIST) instead of the node when it's already hashed. This properly signals the error condition to callers, which already check for IS_ERR() return values.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23243", "url": "https://ubuntu.com/security/CVE-2026-23243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umad: Reject negative data_len in ib_umad_write ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-23242", "url": "https://ubuntu.com/security/CVE-2026-23242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix potential NULL pointer dereference in header processing If siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(), qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data() dereferences qp->rx_fpdu->more_ddp_segs without checking, which may lead to a NULL pointer deref. Only check more_ddp_segs when rx_fpdu is present. KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-23235", "url": "https://ubuntu.com/security/CVE-2026-23235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix out-of-bounds access in sysfs attribute read/write Some f2fs sysfs attributes suffer from out-of-bounds memory access and incorrect handling of integer values whose size is not 4 bytes. For example: vm:~# echo 65537 > /sys/fs/f2fs/vde/carve_out vm:~# cat /sys/fs/f2fs/vde/carve_out 65537 vm:~# echo 4294967297 > /sys/fs/f2fs/vde/atgc_age_threshold vm:~# cat /sys/fs/f2fs/vde/atgc_age_threshold 1 carve_out maps to {struct f2fs_sb_info}->carve_out, which is a 8-bit integer. However, the sysfs interface allows setting it to a value larger than 255, resulting in an out-of-range update. atgc_age_threshold maps to {struct atgc_management}->age_threshold, which is a 64-bit integer, but its sysfs interface cannot correctly set values larger than UINT_MAX. The root causes are: 1. __sbi_store() treats all default values as unsigned int, which prevents updating integers larger than 4 bytes and causes out-of-bounds writes for integers smaller than 4 bytes. 2. f2fs_sbi_show() also assumes all default values are unsigned int, leading to out-of-bounds reads and incorrect access to integers larger than 4 bytes. This patch introduces {struct f2fs_attr}->size to record the actual size of the integer associated with each sysfs attribute. With this information, sysfs read and write operations can correctly access and update values according to their real data size, avoiding memory corruption and truncation.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23234", "url": "https://ubuntu.com/security/CVE-2026-23234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid UAF in f2fs_write_end_io() As syzbot reported an use-after-free issue in f2fs_write_end_io(). It is caused by below race condition: loop device\t\t\t\tumount - worker_thread - loop_process_work - do_req_filebacked - lo_rw_aio - lo_rw_aio_complete - blk_mq_end_request - blk_update_request - f2fs_write_end_io - dec_page_count - folio_end_writeback \t\t\t\t\t- kill_f2fs_super \t\t\t\t\t - kill_block_super \t\t\t\t\t - f2fs_put_super \t\t\t\t\t : free(sbi) : get_pages(, F2FS_WB_CP_DATA) accessed sbi which is freed In kill_f2fs_super(), we will drop all page caches of f2fs inodes before call free(sbi), it guarantee that all folios should end its writeback, so it should be safe to access sbi before last folio_end_writeback(). Let's relocate ckpt thread wakeup flow before folio_end_writeback() to resolve this issue.", "cve_priority": "low", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23236", "url": "https://ubuntu.com/security/CVE-2026-23236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: smscufx: properly copy ioctl memory to kernelspace The UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data from userspace to kernelspace, and instead directly references the memory, which can cause problems if invalid data is passed from userspace. Fix this all up by correctly copying the memory before accessing it within the kernel.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23266", "url": "https://ubuntu.com/security/CVE-2026-23266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: rivafb: fix divide error in nv3_arb() A userspace program can trigger the RIVA NV3 arbitration code by calling the FBIOPUT_VSCREENINFO ioctl on /dev/fb*. When doing so, the driver recomputes FIFO arbitration parameters in nv3_arb(), using state->mclk_khz (derived from the PRAMDAC MCLK PLL) as a divisor without validating it first. In a normal setup, state->mclk_khz is provided by the real hardware and is non-zero. However, an attacker can construct a malicious or misconfigured device (e.g. a crafted/emulated PCI device) that exposes a bogus PLL configuration, causing state->mclk_khz to become zero. Once nv3_get_param() calls nv3_arb(), the division by state->mclk_khz in the gns calculation causes a divide error and crashes the kernel. Fix this by checking whether state->mclk_khz is zero and bailing out before doing the division. The following log reveals it: rivafb: setting virtual Y resolution to 2184 divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 2187 Comm: syz-executor.0 Not tainted 5.18.0-rc1+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:nv3_arb drivers/video/fbdev/riva/riva_hw.c:439 [inline] RIP: 0010:nv3_get_param+0x3ab/0x13b0 drivers/video/fbdev/riva/riva_hw.c:546 Call Trace: nv3CalcArbitration.constprop.0+0x255/0x460 drivers/video/fbdev/riva/riva_hw.c:603 nv3UpdateArbitrationSettings drivers/video/fbdev/riva/riva_hw.c:637 [inline] CalcStateExt+0x447/0x1b90 drivers/video/fbdev/riva/riva_hw.c:1246 riva_load_video_mode+0x8a9/0xea0 drivers/video/fbdev/riva/fbdev.c:779 rivafb_set_par+0xc0/0x5f0 drivers/video/fbdev/riva/fbdev.c:1196 fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1033 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1109 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1188 __x64_sys_ioctl+0x122/0x190 fs/ioctl.c:856", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2025-71233", "url": "https://ubuntu.com/security/CVE-2025-71233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Avoid creating sub-groups asynchronously The asynchronous creation of sub-groups by a delayed work could lead to a NULL pointer dereference when the driver directory is removed before the work completes. The crash can be easily reproduced with the following commands: # cd /sys/kernel/config/pci_ep/functions/pci_epf_test # for i in {1..20}; do mkdir test && rmdir test; done BUG: kernel NULL pointer dereference, address: 0000000000000088 ... Call Trace: configfs_register_group+0x3d/0x190 pci_epf_cfs_work+0x41/0x110 process_one_work+0x18f/0x350 worker_thread+0x25a/0x3a0 Fix this issue by using configfs_add_default_group() API which does not have the deadlock problem as configfs_register_group() and does not require the delayed work handler. [mani: slightly reworded the description and added stable list]", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71232", "url": "https://ubuntu.com/security/CVE-2025-71232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Free sp in error path to fix system crash System crash seen during load/unload test in a loop, [61110.449331] qla2xxx [0000:27:00.0]-0042:0: Disabled MSI-X. [61110.467494] ============================================================================= [61110.467498] BUG qla2xxx_srbs (Tainted: G OE -------- --- ): Objects remaining in qla2xxx_srbs on __kmem_cache_shutdown() [61110.467501] ----------------------------------------------------------------------------- [61110.467502] Slab 0x000000000ffc8162 objects=51 used=1 fp=0x00000000e25d3d85 flags=0x57ffffc0010200(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [61110.467509] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1 [61110.467513] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023 [61110.467515] Call Trace: [61110.467516] [61110.467519] dump_stack_lvl+0x34/0x48 [61110.467526] slab_err.cold+0x53/0x67 [61110.467534] __kmem_cache_shutdown+0x16e/0x320 [61110.467540] kmem_cache_destroy+0x51/0x160 [61110.467544] qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467607] ? __do_sys_delete_module.constprop.0+0x178/0x280 [61110.467613] ? syscall_trace_enter.constprop.0+0x145/0x1d0 [61110.467616] ? do_syscall_64+0x5c/0x90 [61110.467619] ? exc_page_fault+0x62/0x150 [61110.467622] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [61110.467626] [61110.467627] Disabling lock debugging due to kernel taint [61110.467635] Object 0x0000000026f7e6e6 @offset=16000 [61110.467639] ------------[ cut here ]------------ [61110.467639] kmem_cache_destroy qla2xxx_srbs: Slab cache still has objects when called from qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467659] WARNING: CPU: 53 PID: 455206 at mm/slab_common.c:520 kmem_cache_destroy+0x14d/0x160 [61110.467718] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G B OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1 [61110.467720] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023 [61110.467721] RIP: 0010:kmem_cache_destroy+0x14d/0x160 [61110.467724] Code: 99 7d 07 00 48 89 ef e8 e1 6a 07 00 eb b3 48 8b 55 60 48 8b 4c 24 20 48 c7 c6 70 fc 66 90 48 c7 c7 f8 ef a1 90 e8 e1 ed 7c 00 <0f> 0b eb 93 c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 [61110.467725] RSP: 0018:ffffa304e489fe80 EFLAGS: 00010282 [61110.467727] RAX: 0000000000000000 RBX: ffffffffc0d9a860 RCX: 0000000000000027 [61110.467729] RDX: ffff8fd5ff9598a8 RSI: 0000000000000001 RDI: ffff8fd5ff9598a0 [61110.467730] RBP: ffff8fb6aaf78700 R08: 0000000000000000 R09: 0000000100d863b7 [61110.467731] R10: ffffa304e489fd20 R11: ffffffff913bef48 R12: 0000000040002000 [61110.467731] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [61110.467733] FS: 00007f64c89fb740(0000) GS:ffff8fd5ff940000(0000) knlGS:0000000000000000 [61110.467734] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [61110.467735] CR2: 00007f0f02bfe000 CR3: 00000020ad6dc005 CR4: 0000000000770ee0 [61110.467736] PKRU: 55555554 [61110.467737] Call Trace: [61110.467738] [61110.467739] qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467755] ? __do_sys_delete_module.constprop.0+0x178/0x280 Free sp in the error path to fix the crash.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71238", "url": "https://ubuntu.com/security/CVE-2025-71238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix bsg_done() causing double free Kernel panic observed on system, [5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000 [5353358.825194] #PF: supervisor write access in kernel mode [5353358.825195] #PF: error_code(0x0002) - not-present page [5353358.825196] PGD 100006067 P4D 0 [5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI [5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el9_5.x86_64 #1 [5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025 [5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10 [5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246 [5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000 [5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000 [5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000 [5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090 [5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000 [5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000 [5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0 [5353358.825221] PKRU: 55555554 [5353358.825222] Call Trace: [5353358.825223] [5353358.825224] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825229] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825232] ? sg_copy_buffer+0xc8/0x110 [5353358.825236] ? __die_body.cold+0x8/0xd [5353358.825238] ? page_fault_oops+0x134/0x170 [5353358.825242] ? kernelmode_fixup_or_oops+0x84/0x110 [5353358.825244] ? exc_page_fault+0xa8/0x150 [5353358.825247] ? asm_exc_page_fault+0x22/0x30 [5353358.825252] ? memcpy_erms+0x6/0x10 [5353358.825253] sg_copy_buffer+0xc8/0x110 [5353358.825259] qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx] [5353358.825317] qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx] Most routines in qla_bsg.c call bsg_done() only for success cases. However a few invoke it for failure case as well leading to a double free. Validate before calling bsg_done().", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23221", "url": "https://ubuntu.com/security/CVE-2026-23221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: fix use-after-free in driver_override_show() The driver_override_show() function reads the driver_override string without holding the device_lock. However, driver_override_store() uses driver_set_override(), which modifies and frees the string while holding the device_lock. This can result in a concurrent use-after-free if the string is freed by the store function while being read by the show function. Fix this by holding the device_lock around the read operation.", "cve_priority": "low", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23228", "url": "https://ubuntu.com/security/CVE-2026-23228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection() On kthread_run() failure in ksmbd_tcp_new_connection(), the transport is freed via free_transport(), which does not decrement active_num_conn, leaking this counter. Replace free_transport() with ksmbd_tcp_disconnect().", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23169", "url": "https://ubuntu.com/security/CVE-2026-23169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race in mptcp_pm_nl_flush_addrs_doit() syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id() and/or mptcp_pm_nl_is_backup() Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit() which is not RCU ready. list_splice_init_rcu() can not be called here while holding pernet->lock spinlock. Many thanks to Eulgyu Kim for providing a repro and testing our patches.", "cve_priority": "high", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-37786", "url": "https://ubuntu.com/security/CVE-2025-37786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: free routing table on probe failure If complete = true in dsa_tree_setup(), it means that we are the last switch of the tree which is successfully probing, and we should be setting up all switches from our probe path. After \"complete\" becomes true, dsa_tree_setup_cpu_ports() or any subsequent function may fail. If that happens, the entire tree setup is in limbo: the first N-1 switches have successfully finished probing (doing nothing but having allocated persistent memory in the tree's dst->ports, and maybe dst->rtable), and switch N failed to probe, ending the tree setup process before anything is tangible from the user's PoV. If switch N fails to probe, its memory (ports) will be freed and removed from dst->ports. However, the dst->rtable elements pointing to its ports, as created by dsa_link_touch(), will remain there, and will lead to use-after-free if dereferenced. If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirely possible because that is where ds->ops->setup() is, we get a kasan report like this: ================================================================== BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568 Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42 Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 The simplest way to fix the bug is to delete the routing table in its entirety. dsa_tree_setup_routing_table() has no problem in regenerating it even if we deleted links between ports other than those of switch N, because dsa_link_touch() first checks whether the port pair already exists in dst->rtable, allocating if not. The deletion of the routing table in its entirety already exists in dsa_tree_teardown(), so refactor that into a function that can also be called from the tree setup error path. In my analysis of the commit to blame, it is the one which added dsa_link elements to dst->rtable. Prior to that, each switch had its own ds->rtable which is freed when the switch fails to probe. But the tree is potentially persistent memory.", "cve_priority": "low", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2026-23237", "url": "https://ubuntu.com/security/CVE-2026-23237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: classmate-laptop: Add missing NULL pointer checks In a few places in the Classmate laptop driver, code using the accel object may run before that object's address is stored in the driver data of the input device using it. For example, cmpc_accel_sensitivity_store_v4() is the \"show\" method of cmpc_accel_sensitivity_attr_v4 which is added in cmpc_accel_add_v4(), before calling dev_set_drvdata() for inputdev->dev. If the sysfs attribute is accessed prematurely, the dev_get_drvdata(&inputdev->dev) call in in cmpc_accel_sensitivity_store_v4() returns NULL which leads to a NULL pointer dereference going forward. Moreover, sysfs attributes using the input device are added before initializing that device by cmpc_add_acpi_notify_device() and if one of them is accessed before running that function, a NULL pointer dereference will occur. For example, cmpc_accel_sensitivity_attr_v4 is added before calling cmpc_add_acpi_notify_device() and if it is read prematurely, the dev_get_drvdata(&acpi->dev) call in cmpc_accel_sensitivity_show_v4() returns NULL which leads to a NULL pointer dereference going forward. Fix this by adding NULL pointer checks in all of the relevant places.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23238", "url": "https://ubuntu.com/security/CVE-2026-23238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: romfs: check sb_set_blocksize() return value romfs_fill_super() ignores the return value of sb_set_blocksize(), which can fail if the requested block size is incompatible with the block device's configuration. This can be triggered by setting a loop device's block size larger than PAGE_SIZE using ioctl(LOOP_SET_BLOCK_SIZE, 32768), then mounting a romfs filesystem on that device. When sb_set_blocksize(sb, ROMBSIZE) is called with ROMBSIZE=4096 but the device has logical_block_size=32768, bdev_validate_blocksize() fails because the requested size is smaller than the device's logical block size. sb_set_blocksize() returns 0 (failure), but romfs ignores this and continues mounting. The superblock's block size remains at the device's logical block size (32768). Later, when sb_bread() attempts I/O with this oversized block size, it triggers a kernel BUG in folio_set_bh(): kernel BUG at fs/buffer.c:1582! BUG_ON(size > PAGE_SIZE); Fix by checking the return value of sb_set_blocksize() and failing the mount with -EINVAL if it returns 0.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-31687", "url": "https://ubuntu.com/security/CVE-2026-31687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: omap: do not register driver in probe() Commit 11a78b794496 (\"ARM: OMAP: MPUIO wake updates\") registers the omap_mpuio_driver from omap_mpuio_init(), which is called from omap_gpio_probe(). However, it neither makes sense to register drivers from probe() callbacks of other drivers, nor does the driver core allow registering drivers with a device lock already being held. The latter was revealed by commit dc23806a7c47 (\"driver core: enforce device_lock for driver_match_device()\") leading to a potential deadlock condition described in [1]. Additionally, the omap_mpuio_driver is never unregistered from the driver core, even if the module is unloaded. Hence, register the omap_mpuio_driver from the module initcall and unregister it in module_exit().", "cve_priority": "medium", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2025-71235", "url": "https://ubuntu.com/security/CVE-2025-71235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Delay module unload while fabric scan in progress System crash seen during load/unload test in a loop. [105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086 [105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0 [105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000 [105954.384923] FS: 0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000 [105954.384925] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0 [105954.384928] PKRU: 55555554 [105954.384929] Call Trace: [105954.384931] [105954.384934] qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx] [105954.384962] ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx] [105954.384980] ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx] [105954.384999] ? __wake_up_common+0x80/0x190 [105954.385004] ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx] [105954.385023] ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx] [105954.385040] ? __handle_irq_event_percpu+0x3d/0x190 [105954.385044] ? handle_irq_event+0x58/0xb0 [105954.385046] ? handle_edge_irq+0x93/0x240 [105954.385050] ? __common_interrupt+0x41/0xa0 [105954.385055] ? common_interrupt+0x3e/0xa0 [105954.385060] ? asm_common_interrupt+0x22/0x40 The root cause of this was that there was a free (dma_free_attrs) in the interrupt context. There was a device discovery/fabric scan in progress. A module unload was issued which set the UNLOADING flag. As part of the discovery, after receiving an interrupt a work queue was scheduled (which involved a work to be queued). Since the UNLOADING flag is set, the work item was not allocated and the mapped memory had to be freed. The free occurred in interrupt context leading to system crash. Delay the driver unload until the fabric scan is complete to avoid the crash.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71236", "url": "https://ubuntu.com/security/CVE-2025-71236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Validate sp before freeing associated memory System crash with the following signature [154563.214890] nvme nvme2: NVME-FC{1}: controller connect complete [154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Set ZIO exchange threshold to 3. [154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: SET ZIO Activity exchange threshold to 5. [154565.539974] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 0080 0000. [154565.545744] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 00a0 0000. [154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate). [154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate). [154565.553079] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [154565.553080] #PF: supervisor read access in kernel mode [154565.553082] #PF: error_code(0x0000) - not-present page [154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0 [154565.553089] Oops: 0000 1 PREEMPT SMP PTI [154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: loaded Tainted: G OE ------- --- 5.14.0-503.11.1.el9_5.x86_64 #1 [154565.553096] Hardware name: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 09/30/2024 [154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553141] Code: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 <4c> 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b [154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286 [154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002 [154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47 [154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a [154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0 [154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000 [154565.553152] FS: 0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000 [154565.553154] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0 [154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [154565.553159] PKRU: 55555554 [154565.553160] Call Trace: [154565.553162] [154565.553165] ? show_trace_log_lvl+0x1c4/0x2df [154565.553172] ? show_trace_log_lvl+0x1c4/0x2df [154565.553177] ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553215] ? __die_body.cold+0x8/0xd [154565.553218] ? page_fault_oops+0x134/0x170 [154565.553223] ? snprintf+0x49/0x70 [154565.553229] ? exc_page_fault+0x62/0x150 [154565.553238] ? asm_exc_page_fault+0x22/0x30 Check for sp being non NULL before freeing any associated memory", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71237", "url": "https://ubuntu.com/security/CVE-2025-71237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: Fix potential block overflow that cause system hang When a user executes the FITRIM command, an underflow can occur when calculating nblocks if end_block is too small. Since nblocks is of type sector_t, which is u64, a negative nblocks value will become a very large positive integer. This ultimately leads to the block layer function __blkdev_issue_discard() taking an excessively long time to process the bio chain, and the ns_segctor_sem lock remains held for a long period. This prevents other tasks from acquiring the ns_segctor_sem lock, resulting in the hang reported by syzbot in [1]. If the ending block is too small, typically if it is smaller than 4KiB range, depending on the usage of the segment 0, it may be possible to attempt a discard request beyond the device size causing the hang. Exiting successfully and assign the discarded size (0 in this case) to range->len. Although the start and len values in the user input range are too small, a conservative strategy is adopted here to safely ignore them, which is equivalent to a no-op; it will not perform any trimming and will not throw an error. [1] task:segctord state:D stack:28968 pid:6093 tgid:6093 ppid:2 task_flags:0x200040 flags:0x00080000 Call Trace: rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272 nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline] nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684 [ryusuke: corrected part of the commit message about the consequences]", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23229", "url": "https://ubuntu.com/security/CVE-2026-23229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add spinlock protection with virtqueue notification When VM boots with one virtio-crypto PCI device and builtin backend, run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head! It seems that the data virtqueue need protection when it is handled for virtio done notification. If the spinlock protection is added in virtcrypto_done_task(), openssl benchmark with multiple processes works well.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23222", "url": "https://ubuntu.com/security/CVE-2026-23222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly The existing allocation of scatterlists in omap_crypto_copy_sg_lists() was allocating an array of scatterlist pointers, not scatterlist objects, resulting in a 4x too small allocation. Use sizeof(*new_sg) to get the correct object size.", "cve_priority": "high", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23392", "url": "https://ubuntu.com/security/CVE-2026-23392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-45988", "url": "https://ubuntu.com/security/CVE-2026-45988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix re-decryption of RESPONSE packets If a RESPONSE packet gets a temporary failure during processing, it may end up in a partially decrypted state - and then get requeued for a retry. Fix this by just discarding the packet; we will send another CHALLENGE packet and thereby elicit a further response. Similarly, discard an incoming CHALLENGE packet if we get an error whilst generating a RESPONSE; the server will send another CHALLENGE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46195", "url": "https://ubuntu.com/security/CVE-2026-46195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46135", "url": "https://ubuntu.com/security/CVE-2026-46135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.", "cve_priority": "critical", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31402", "url": "https://ubuntu.com/security/CVE-2026-31402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.", "cve_priority": "critical", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43071", "url": "https://ubuntu.com/security/CVE-2026-43071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dcache: Limit the minimal number of bucket to two There is an OOB read problem on dentry_hashtable when user sets 'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260 There will be only one bucket in dentry_hashtable when dhash_entries is set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then, following process will access more than one buckets(which memory region is not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB! Fix it by limiting the minimal number of dentry_hashtable bucket to two, so that 'd_hash_shift' won't exceeds the bit width of type u32.", "cve_priority": "low", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-46119", "url": "https://ubuntu.com/security/CVE-2026-46119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix slab-out-of-bounds access in auth message processing If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY contains a positive value in its result field, it is treated as an error code by ceph_handle_auth_reply() and returned to handle_auth_reply(). Thereafter, an attempt is made to send the preallocated message of type CEPH_MSG_AUTH, where the returned value is interpreted as the size of the front segment to send. If the result value in the message is greater than the size of the memory buffer allocated for the front segment, an out-of-bounds access occurs, and the content of the memory region beyond this buffer is sent out. This patch fixes the issue by treating only negative values in the result field as errors. Positive values are therefore treated as success in the same way as a zero value. Additionally, a BUG_ON is added to __send_prepared_auth_request() comparing the len parameter to front_alloc_len to prevent sending the message if it exceeds the bounds of the allocation and to make it easier to catch any logic flaws leading to this.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-43501", "url": "https://ubuntu.com/security/CVE-2026-43501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: \tskb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards.", "cve_priority": "critical", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46043", "url": "https://ubuntu.com/security/CVE-2026-46043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43493", "url": "https://ubuntu.com/security/CVE-2026-43493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications.", "cve_priority": "high", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-31637", "url": "https://ubuntu.com/security/CVE-2026-31637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: reject undecryptable rxkad response tickets rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether crypto_skcipher_decrypt() succeeded. A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes. Check the decrypt result and abort the connection with RXKADBADTICKET when ticket decryption fails.", "cve_priority": "critical", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31657", "url": "https://ubuntu.com/security/CVE-2026-31657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: hold claim backbone gateways by reference batadv_bla_add_claim() can replace claim->backbone_gw and drop the old gateway's last reference while readers still follow the pointer. The netlink claim dump path dereferences claim->backbone_gw->orig and takes claim->backbone_gw->crc_lock without pinning the underlying backbone gateway. batadv_bla_check_claim() still has the same naked pointer access pattern. Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate on a stable gateway reference until the read-side work is complete. This keeps the dump and claim-check paths aligned with the lifetime rules introduced for the other BLA claim readers.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31685", "url": "https://ubuntu.com/security/CVE-2026-31685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_eui64: reject invalid MAC header for all packets `eui64_mt6()` derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address. The existing guard only rejects an invalid MAC header when `par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()` can still reach `eth_hdr(skb)` even when the MAC header is not valid. Fix this by removing the `par->fragoff != 0` condition so that packets with an invalid MAC header are rejected before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43117", "url": "https://ubuntu.com/security/CVE-2026-43117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() If overlay is used on top of btrfs, dentry->d_sb translates to overlay's super block and fsid assignment will lead to a crash. Use file_inode(file)->i_sb to always get btrfs_sb.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43114", "url": "https://ubuntu.com/security/CVE-2026-43114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry New test case fails unexpectedly when avx2 matching functions are used. The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo. This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f - This is expected to work, because its the same set after all and it was already loaded once. But with avx2, this fails: nft reports a clashing element. The reported clash is of following form: We successfully re-inserted a . b c . d Then we try to insert a . d avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next. Due to incorrect masking, the skip-step finds the next matching element *only considering the first field*, i.e. we return the already reinserted \"a . b\", even though the last field is different and the entry should not have been matched. No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback. Bisection points to 7711f4bb4b36 (\"netfilter: nft_set_pipapo: fix range overlap detection\") but that fix merely uncovers this bug. Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate. The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31478", "url": "https://ubuntu.com/security/CVE-2026-31478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len() After this commit (e2b76ab8b5c9 \"ksmbd: add support for read compound\"), response buffer management was changed to use dynamic iov array. In the new design, smb2_calc_max_out_buf_len() expects the second argument (hdr2_len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31668", "url": "https://ubuntu.com/security/CVE-2026-31668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: separate dst_cache for input and output paths in seg6 lwtunnel The seg6 lwtunnel uses a single dst_cache per encap route, shared between seg6_input_core() and seg6_output_core(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup. Fix this by splitting the cache into cache_input and cache_output, so each path maintains its own cached dst independently.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31659", "url": "https://ubuntu.com/security/CVE-2026-31659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject oversized global TT response buffers batadv_tt_prepare_tvlv_global_data() builds the allocation length for a global TT response in 16-bit temporaries. When a remote originator advertises a large enough global TT, the TT payload length plus the VLAN header offset can exceed 65535 and wrap before kmalloc(). The full-table response path still uses the original TT payload length when it fills tt_change, so the wrapped allocation is too small and batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object before the later packet-size check runs. Fix this by rejecting TT responses whose TVLV value length cannot fit in the 16-bit TVLV payload length field.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31649", "url": "https://ubuntu.com/security/CVE-2026-31649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix integer underflow in chain mode The jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb->len (total length including page fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc); When a packet has a small linear portion (nopaged_len <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax * i pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware. Fix this by introducing a buf_len local variable clamped to min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmac_xmit() handles page fragments afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31669", "url": "https://ubuntu.com/security/CVE-2026-31669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix slab-use-after-free in __inet_lookup_established The ehash table lookups are lockless and rely on SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability during RCU read-side critical sections. Both tcp_prot and tcpv6_prot have their slab caches created with this flag via proto_register(). However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into tcpv6_prot_override during inet_init() (fs_initcall, level 5), before inet6_init() (module_init/device_initcall, level 6) has called proto_register(&tcpv6_prot). At that point, tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab remains NULL permanently. This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so when these sockets are freed without SOCK_RCU_FREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcu_read_lock can then access freed memory, triggering a slab-use-after-free in __inet_lookup_established. Fix this by splitting the IPv6-specific initialization out of mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called from mptcp_proto_v6_init() before protocol registration. This ensures tcpv6_prot_override.slab correctly inherits the SLAB_TYPESAFE_BY_RCU slab cache.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43011", "url": "https://ubuntu.com/security/CVE-2026-43011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix potential double free of skb When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain: x25_queue_rx_frame returns 1 | v x25_state3_machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25_process_rx_frame returns queued=0 | v x25_backlog_rcv at line 452 sees queued=0 and calls kfree_skb(skb) again This would free the same skb twice. Looking at x25_backlog_rcv: net/x25/x25_in.c:x25_backlog_rcv() { ... queued = x25_process_rx_frame(sk, skb); ... if (!queued) kfree_skb(skb); }", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43037", "url": "https://ubuntu.com/security/CVE-2026-43037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip4ip6_err() Oskar Kjos reported the following problem. ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr value. __ip_options_echo() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->__data, a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE). To fix this we clear skb2->cb[], as suggested by Oskar Kjos. Also add minimal IPv4 header validation (version == 4, ihl >= 5).", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43038", "url": "https://ubuntu.com/security/CVE-2026-43038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31682", "url": "https://ubuntu.com/security/CVE-2026-31682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: linearize skb before parsing ND options br_nd_send() parses neighbour discovery options from ns->opt[] and assumes that these options are in the linear part of request. Its callers only guarantee that the ICMPv6 header and target address are available, so the option area can still be non-linear. Parsing ns->opt[] in that case can access data past the linear buffer. Linearize request before option parsing and derive ns from the linear network header.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-23450", "url": "https://ubuntu.com/security/CVE-2026-23450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1]. smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release(). This leads to two issues: 1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed. The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race): CPU A (softirq) CPU B (process ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* No lock on listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash! Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed. Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight. - Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock(). - Use rcu_read_lock() to protect reading sk_user_data. - Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely. Note: smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected. Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied. [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23428", "url": "https://ubuntu.com/security/CVE-2026-23428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of share_conf in compound request smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without validating tcon->t_state. ksmbd_tree_conn_lookup() checks t_state == TREE_CONNECTED on the initial lookup path, but the compound reuse path bypasses this check entirely. If a prior command in the compound (SMB2_TREE_DISCONNECT) sets t_state to TREE_DISCONNECTED and frees share_conf via ksmbd_share_config_put(), subsequent commands dereference the freed share_conf through work->tcon->share_conf. KASAN report: [ 4.144653] ================================================================== [ 4.145059] BUG: KASAN: slab-use-after-free in smb2_write+0xc74/0xe70 [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44 [ 4.145772] [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY [ 4.145871] 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 [ 4.145875] Workqueue: ksmbd-io handle_ksmbd_work [ 4.145888] Call Trace: [ 4.145892] [ 4.145894] dump_stack_lvl+0x64/0x80 [ 4.145910] print_report+0xce/0x660 [ 4.145919] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 4.145928] ? smb2_write+0xc74/0xe70 [ 4.145931] kasan_report+0xce/0x100 [ 4.145934] ? smb2_write+0xc74/0xe70 [ 4.145937] smb2_write+0xc74/0xe70 [ 4.145939] ? __pfx_smb2_write+0x10/0x10 [ 4.145942] ? _raw_spin_unlock+0xe/0x30 [ 4.145945] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 4.145948] ? smb2_tree_disconnect+0x31c/0x480 [ 4.145951] handle_ksmbd_work+0x40f/0x1080 [ 4.145953] process_one_work+0x5fa/0xef0 [ 4.145962] ? assign_work+0x122/0x3e0 [ 4.145964] worker_thread+0x54b/0xf70 [ 4.145967] ? __pfx_worker_thread+0x10/0x10 [ 4.145970] kthread+0x346/0x470 [ 4.145976] ? recalc_sigpending+0x19b/0x230 [ 4.145980] ? __pfx_kthread+0x10/0x10 [ 4.145984] ret_from_fork+0x4fb/0x6c0 [ 4.145992] ? __pfx_ret_from_fork+0x10/0x10 [ 4.145995] ? __switch_to+0x36c/0xbe0 [ 4.145999] ? __pfx_kthread+0x10/0x10 [ 4.146003] ret_from_fork_asm+0x1a/0x30 [ 4.146013] [ 4.146014] [ 4.149858] Allocated by task 44: [ 4.149953] kasan_save_stack+0x33/0x60 [ 4.150061] kasan_save_track+0x14/0x30 [ 4.150169] __kasan_kmalloc+0x8f/0xa0 [ 4.150274] ksmbd_share_config_get+0x1dd/0xdd0 [ 4.150401] ksmbd_tree_conn_connect+0x7e/0x600 [ 4.150529] smb2_tree_connect+0x2e6/0x1000 [ 4.150645] handle_ksmbd_work+0x40f/0x1080 [ 4.150761] process_one_work+0x5fa/0xef0 [ 4.150873] worker_thread+0x54b/0xf70 [ 4.150978] kthread+0x346/0x470 [ 4.151071] ret_from_fork+0x4fb/0x6c0 [ 4.151176] ret_from_fork_asm+0x1a/0x30 [ 4.151286] [ 4.151332] Freed by task 44: [ 4.151418] kasan_save_stack+0x33/0x60 [ 4.151526] kasan_save_track+0x14/0x30 [ 4.151634] kasan_save_free_info+0x3b/0x60 [ 4.151751] __kasan_slab_free+0x43/0x70 [ 4.151861] kfree+0x1ca/0x430 [ 4.151952] __ksmbd_tree_conn_disconnect+0xc8/0x190 [ 4.152088] smb2_tree_disconnect+0x1cd/0x480 [ 4.152211] handle_ksmbd_work+0x40f/0x1080 [ 4.152326] process_one_work+0x5fa/0xef0 [ 4.152438] worker_thread+0x54b/0xf70 [ 4.152545] kthread+0x346/0x470 [ 4.152638] ret_from_fork+0x4fb/0x6c0 [ 4.152743] ret_from_fork_asm+0x1a/0x30 [ 4.152853] [ 4.152900] The buggy address belongs to the object at ffff88810430c180 [ 4.152900] which belongs to the cache kmalloc-96 of size 96 [ 4.153226] The buggy address is located 20 bytes inside of [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0) [ 4.153549] [ 4.153596] The buggy address belongs to the physical page: [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c [ 4.154000] flags: 0x ---truncated---", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23455", "url": "https://ubuntu.com/security/CVE-2026-23455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read. Add a check to ensure len is positive after the decrement.", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43186", "url": "https://ubuntu.com/security/CVE-2026-43186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43185", "url": "https://ubuntu.com/security/CVE-2026-43185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix signededness bug in smb_direct_prepare_negotiation() smb_direct_prepare_negotiation() casts an unsigned __u32 value from sp->max_recv_size and req->preferred_send_size to a signed int before computing min_t(int, ...). A maliciously provided preferred_send_size of 0x80000000 will return as smaller than max_recv_size, and then be used to set the maximum allowed alowed receive size for the next message. By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow. This fix replaces min_t(int, ...) with min_t(u32)", "cve_priority": "critical", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43341", "url": "https://ubuntu.com/security/CVE-2026-43341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31607", "url": "https://ubuntu.com/security/CVE-2026-31607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: validate number_of_packets in usbip_pack_ret_submit() When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the *original* number_of_packets from the CMD_SUBMIT. A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region. KASAN confirmed this with kernel 7.0.0-rc5: BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69 The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40) The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 (\"usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input\") and b78d830f0049 (\"usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input\"). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets. This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size. Kelvin Mbogo's series (\"usb: usbip: fix integer overflow in usbip_recv_iso()\", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit. Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43383", "url": "https://ubuntu.com/security/CVE-2026-43383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-md5: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2025-68263", "url": "https://ubuntu.com/security/CVE-2025-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: ipc: fix use-after-free in ipc_msg_send_request ipc_msg_send_request() waits for a generic netlink reply using an ipc_msg_table_entry on the stack. The generic netlink handler (handle_generic_event()/handle_response()) fills entry->response under ipc_msg_table_lock, but ipc_msg_send_request() used to validate and free entry->response without holding the same lock. Under high concurrency this allows a race where handle_response() is copying data into entry->response while ipc_msg_send_request() has just freed it, leading to a slab-use-after-free reported by KASAN in handle_generic_event(): BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd] Write of size 12 at addr ffff888198ee6e20 by task pool/109349 ... Freed by task: kvfree ipc_msg_send_request [ksmbd] ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd] Fix by: - Taking ipc_msg_table_lock in ipc_msg_send_request() while validating entry->response, freeing it when invalid, and removing the entry from ipc_msg_table. - Returning the final entry->response pointer to the caller only after the hash entry is removed under the lock. - Returning NULL in the error path, preserving the original API semantics. This makes all accesses to entry->response consistent with handle_response(), which already updates and fills the response buffer under ipc_msg_table_lock, and closes the race that allowed the UAF.", "cve_priority": "critical", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2026-46243", "url": "https://ubuntu.com/security/CVE-2026-46243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key.", "cve_priority": "medium", "cve_public_date": "2026-06-01 17:17:00 UTC" }, { "cve": "CVE-2026-43414", "url": "https://ubuntu.com/security/CVE-2026-43414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Completely fix fcport double free In qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free(). When an error happens, this function is called by qla2x00_sp_release(), when kref_put() releases the first and the last reference. qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport(). Doing it one more time after kref_put() is a bad idea.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43407", "url": "https://ubuntu.com/security/CVE-2026-43407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply() This patch fixes an out-of-bounds access in ceph_handle_auth_reply() that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In ceph_handle_auth_reply(), the value of the payload_len field of such a message is stored in a variable of type int. A value greater than INT_MAX leads to an integer overflow and is interpreted as a negative value. This leads to decrementing the pointer address by this value and subsequently accessing it because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. This patch fixes the issue by changing the data type of payload_len to u32. Additionally, the data type of result_msg_len is changed to u32, as it is also a variable holding a non-negative length. Also, an additional layer of sanity checks is introduced, ensuring that directly after reading it from the message, payload_len and result_msg_len are not greater than the overall segment length. BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph] Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262 CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ceph-msgr ceph_con_workfn [libceph] Call Trace: dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x620 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x72/0x210 kasan_report+0xe7/0x130 ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] __asan_report_load_n_noabort+0xf/0x20 ceph_handle_auth_reply+0x642/0x7a0 [libceph] mon_dispatch+0x973/0x23d0 [libceph] ? apparmor_socket_recvmsg+0x6b/0xa0 ? __pfx_mon_dispatch+0x10/0x10 [libceph] ? __kasan_check_write+0x14/0x30i ? mutex_unlock+0x7f/0xd0 ? __pfx_mutex_unlock+0x10/0x10 ? __pfx_do_recvmsg+0x10/0x10 [libceph] ceph_con_process_message+0x1f1/0x650 [libceph] process_message+0x1e/0x450 [libceph] ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] ? save_fpregs_to_fpstate+0xb0/0x230 ? raw_spin_rq_unlock+0x17/0xa0 ? finish_task_switch.isra.0+0x13b/0x760 ? __switch_to+0x385/0xda0 ? __kasan_check_write+0x14/0x30 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 ceph_con_workfn+0x248/0x10c0 [libceph] process_one_work+0x629/0xf80 ? __kasan_check_write+0x14/0x30 worker_thread+0x87f/0x1570 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_try_to_wake_up+0x10/0x10 ? kasan_print_address_stack_frame+0x1f7/0x280 ? __pfx_worker_thread+0x10/0x10 kthread+0x396/0x830 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? __pfx_kthread+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? recalc_sigpending+0x180/0x210 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3f7/0x610 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x385/0xda0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 [ idryomov: replace if statements with ceph_decode_need() for payload_len and result_msg_len ]", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43406", "url": "https://ubuntu.com/security/CVE-2026-43406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in process_message_header() If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in process_message_header(). Perform an explicit bounds check before decoding the message header.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43304", "url": "https://ubuntu.com/security/CVE-2026-43304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.", "cve_priority": "critical", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-37924", "url": "https://ubuntu.com/security/CVE-2025-37924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in kerberos authentication Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbd_free_user but before sess->user is set to NULL.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37778", "url": "https://ubuntu.com/security/CVE-2025-37778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix dangling pointer in krb_authenticate krb_authenticate frees sess->user and does not set the pointer to NULL. It calls ksmbd_krb5_authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2_sess_setup, which calls krb_authenticate, will be accessing free'd memory when it later uses sess->user.", "cve_priority": "high", "cve_public_date": "2025-05-01 14:15:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1104.109 -proposed tracker (LP: #2157390)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] resync retpoline extraction", "", " [ Ubuntu: 5.15.0-186.196 ]", "", " * jammy/linux: 5.15.0-186.196 -proposed tracker (LP: #2157405)", " * [Jammy] Priority inversion problem in epoll for rt kernel (LP: #2154194)", " - eventpoll: Replace rwlock with spinlock", " * CVE-2026-46137", " - mptcp: pm: ADD_ADDR rtx: fix potential data-race", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901)", " - Linux 5.15.208", " - ALSA: asihpi: avoid write overflow check warning", " - can: mcp251x: add error handling for power enable in open and resume", " - ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg0xxx", " - ASoC: soc-core: call missing INIT_LIST_HEAD() for card_aux_list", " - ALSA: usb-audio: Fix quirk flags for NeuralDSP Quad Cortex", " - pinctrl: intel: Fix the revision for new features (1kOhm PD, HW", " debouncer)", " - HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3", " - ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585", " - ASoC: stm32_sai: fix incorrect BCLK polarity for DSP_A/B, LEFT_J", " - soc: aspeed: socinfo: Mask table entries for accurate SoC ID matching", " - arm64: dts: imx8mq: Set the correct gpu_ahb clock frequency", " - PCI: hv: Set default NUMA node to 0 for devices without affinity info", " - drm/vc4: Protect madv read in vc4_gem_object_mmap() with madv_lock", " - epoll: use refcount to reduce ep_mutex contention", " - tracing/probe: reject non-closed empty immediate strings", " - e1000: check return value of e1000_read_eeprom", " - gpio: tegra: fix irq_release_resources calling enable instead of disable", " - i3c: fix uninitialized variable use in i2c setup", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - mips: mm: Allocate tlb_vpn array atomically", " - MIPS: Always record SEGBITS in cpu_data.vmbits", " - MIPS: mm: Suppress TLB uniquification on EHINV hardware", " - MIPS: mm: Rewrite TLB uniquification for the hidden bit feature", " - ALSA: usb-audio: Update for native DSD support quirks", " - usb: storage: Expand range of matched versions for VL817 quirks entry", " - USB: serial: option: add Telit Cinterion FN990A MBIM composition", " - fsl-mc: Use driver_set_override() instead of open-coding", " - checkpatch: add support for Assisted-by tag", " - gfs2: Improve gfs2_consist_inode() usage", " - PCI/ACPI: Restrict program_hpx_type2() to AER bits", " - netfilter: nft_set_pipapo: do not rely on ZERO_SIZE_PTR", " - powerpc64/bpf: do not increment tailcall count when prog is NULL", " - arm64: dts: imx8mq-librem5: Set the DVS voltages lower", " - arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage to 0.81V", " - Revert \"arm64: dts: imx8mq-librem5: Set the DVS voltages lower\"", " - arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V", " - ocfs2: add inline inode consistency check to", " ocfs2_validate_inode_block()", " - rxrpc: Fix key quota calculation for multitoken keys", " - fs/ocfs2: fix comments mentioning i_mutex", " - MPTCP: fix lock class name family in pm_nl_create_listen_socket", " - Revert \"nvme: nvme-fc: Ensure ->ioerr_work is cancelled in", " nvme_fc_delete_ctrl()\"", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", " - s390/xor: Fix xor_xc_2() inline assembly constraints", " - net: add skb_header_pointer_careful() helper", " - x86/uprobes: Fix XOL allocation failure for 32-bit tasks", " - iio: imu: inv_icm42600: fix odr switch when turning buffer off", " - vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check", " - net: usb: lan78xx: Fix double free issue with interrupt buffer", " allocation", " - SAUCE: Revert \"fs/ntfs3: Fixed overflow check in mi_enum_attr()\"", " - SAUCE: Revert \"fs/ntfs3: Sequential field availability check in", " mi_enum_attr()\"", " - SAUCE: Revert \"ntfs3: Add bounds checking to mi_enum_attr()\"", " - cpufreq: governor: Free dbs_data directly when gov->init() fails", " - scripts/dtc: Remove unused dts_version in dtc-lexer.l", " - rxrpc: Fix anonymous key handling", " - iommu: fix a reference count leak in iommu_sva_bind_device()", " - fuse: quiet down complaints in fuse_conn_limit_write", " - ALSA: usb-audio: apply quirk for MOONDROP JU Jiu", " - tty: n_gsm: fix flow control handling in tx path", " - ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free", " - ALSA: usb-audio: Avoid false E-MU sample-rate notifications", " - ALSA: usb-audio: Fix Audio Advantage Micro II SPDIF switch", " - usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable()", " - ALSA: usb-audio: Evaluate packsize caps at the right place", " - firmware: google: framebuffer: Do not mark framebuffer as busy", " - device property: Make modifications of fwnode \"flags\" thread safe", " - driver core: Don't let a device probe until it's ready", " - um: drivers: call kernel_strrchr() explicitly in cow_user.c", " - Revert \"ALSA: usb: Increase volume range that triggers a warning\"", " - lib/ts_kmp: fix integer overflow in pattern length calculation", " - media: i2c: imx219: Check return value of devm_gpiod_get_optional() in", " imx219_probe()", " - ALSA: aoa: i2sbus: fix OF node lifetime handling", " - ALSA: seq_oss: return full count for successful SEQ_FULLSIZE writes", " - nvme-pci: add NVME_QUIRK_DISABLE_WRITE_ZEROES for Kingston OM3SGP4", " - parisc: _llseek syscall is only available for 32-bit userspace", " - selftests/mqueue: Fix incorrectly named file", " - ALSA: caiaq: Fix control_put() result and cache rollback", " - ALSA: 6fire: Fix input volume change detection", " - iio: adc: ad7768-1: fix one-shot mode data acquisition", " - drm/arcpgu: fix device node leak", " - tpm: avoid -Wunused-but-set-variable", " - power: supply: axp288_charger: Do not cancel work before initializing it", " - mmc: block: use single block write in retry", " - tpm: tpm_tis: add error logging for data transfer", " - rtc: ntxec: fix OF node reference imbalance", " - userfaultfd: allow registration of ranges below mmap_min_addr", " - KVM: nSVM: Mark all of vmcb02 dirty when restoring nested state", " - KVM: SVM: Explicitly mark vmcb01 dirty after modifying VMCB intercepts", " - KVM: nSVM: Ensure AVIC is inhibited when restoring a vCPU to guest mode", " - KVM: nSVM: Always inject a #GP if mapping VMCB12 fails on nested VMRUN", " - KVM: nSVM: Clear GIF on nested #VMEXIT(INVALID)", " - KVM: nSVM: Add missing consistency check for nCR3 validity", " - io_uring/poll: fix EPOLL_URING_WAKE sometimes not being honored", " - io_uring/poll: fix backport of io_poll_add() changes", " - mtd: docg3: Convert to platform remove callback returning void", " - taskstats: set version in TGID exit notifications", " - crypto: arm64/aes - Fix 32-bit aes_mac_update() arg treated as 64-bit", " - crypto: atmel-ecc - Release client on allocation failure", " - crypto: hisilicon - Fix dma_unmap_single() direction", " - IB/core: Fix zero dmac race in neighbor resolution", " - ktest: Fix the month in the name of the failure directory", " - seg6: fix seg6 lwtunnel output redirect for L2 reduced encap mode", " - driver core: Add kernel-doc for DEV_FLAG_COUNT enum value", " - ALSA: caiaq: Fix potentially leftover ep1_in_urb at error path", " - ALSA: caiaq: Don't abort when no input device is available", " - drm/amdgpu: fix zero-size GDS range init on RDNA4", " - ALSA: caiaq: fix usb_dev refcount leak on probe failure", " - ACPI: scan: Use acpi_dev_put() in object add error paths", " - ACPI: CPPC: Fix related_cpus inconsistency during CPU hotplug", " - ACPI: video: force native backlight on HP OMEN 16 (8A44)", " - spi: rockchip: fix controller deregistration", " - um: virt-pci: Fix build failure", " - ipmi:ssif: Fix a shutdown race", " - ipmi:ssif: Remove unnecessary indention", " - ipmi:ssif: NULL thread on error", " - ALSA: usb-audio: Fix UAC3 cluster descriptor size check", " - USB: omap_udc: DMA: Don't enable burst 4 mode", " - USB: serial: option: add Telit Cinterion LE910Cx compositions", " - usb: ulpi: fix memory leak on ulpi_register() error paths", " - ALSA: firewire-tascam: Do not drop unread control events", " - xfrm: provide message size for XFRM_MSG_MAPPING", " - spi: zynqmp-gqspi: fix controller deregistration", " - parisc: Fix IRQ leak in LASI driver", " - hwmon: (ltc2992) Clamp threshold writes to hardware range", " - hwmon: (ltc2992) Fix u32 overflow in power read path", " - hwmon: (corsair-psu) Close HID device on probe errors", " - extcon: ptn5150: handle pending IRQ events during system resume", " - hv_sock: fix ARM64 support", " - udf: reject descriptors with oversized CRC length", " - thermal/drivers/sprd: Fix temperature clamping in", " sprd_thm_temp_to_rawdata", " - thermal/drivers/sprd: Fix raw temperature clamping in", " sprd_thm_rawdata_to_temp", " - cpuidle: powerpc: avoid double clear when breaking snooze", " - ASoC: fsl_easrc: fix comment typo", " - ASoC: Intel: bytcr_wm5102: Fix MCLK leak on platform_clock_control error", " - dm: don't report warning when doing deferred remove", " - dm-verity-fec: correctly reject too-small FEC devices", " - dm-verity-fec: correctly reject too-small hash devices", " - s390/debug: Reject zero-length input in debug_input_flush_fn()", " - PCI/AER: Clear only error bits in PCIe Device Status", " - PCI/AER: Stop ruling out unbound devices as error source", " - power: supply: max17042: avoid overflow when determining health", " - mptcp: use MPJoinSynAckHMacFailure for SynAck HMAC failure", " - mptcp: use MPTCP_RST_EMPTCP for ACK HMAC validation failure", " - mptcp: sockopt: set timestamp flags on subflow socket, not msk", " - platform/x86: hp-wmi: Ignore backlight and FnLock events", " - media: uvcvideo: Enable VB2_DMABUF for metadata stream", " - media: i2c: ov8856: free control handler on error in", " ov8856_init_controls()", " - regulator: max77650: fix OF node reference imbalance", " - media: rc: streamzap: Error handling in probe", " - regulator: act8945a: fix OF node reference imbalance", " - regulator: bd9571mwv: fix OF node reference imbalance", " - media: dib8000: avoid division by 0 in dib8000_set_dds()", " - media: i2c: imx412: Assert reset GPIO during probe", " - spi: mtk-nor: fix controller deregistration", " - spi: imx: fix runtime pm leak on probe deferral", " - spi: orion: fix clock imbalance on registration failure", " - drm/radeon: add missing revision check for CI", " - drm/amdgpu/gfx9: drop unnecessary 64-bit fence flag check in KIQ", " - drm/amdgpu/pm: add missing revision check for CI", " - drm/amdgpu/pm: align Hawaii mclk workaround with radeon", " - drm/amdgpu/vcn3: Avoid overflow on msg bound check", " - bcache: fix uninitialized closure object", " - fs/omfs: reject s_sys_blocksize smaller than OMFS_DIR_START", " - drbd: Balance RCU calls in drbd_adm_dump_devices()", " - nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()", " - pstore/ram: fix resource leak when ioremap() fails", " - devres: fix missing node debug info in devm_krealloc()", " - thermal/drivers/spear: Fix error condition for reading st,thermal-flags", " - debugfs: check for NULL pointer in debugfs_create_str()", " - irqchip/irq-pic32-evic: Address warning related to wrong printf()", " formatter", " - locking: Fix rwlock support in ", " - firmware: dmi: Correct an indexing error in dmi.h", " - wifi: mwifiex: Fix memory leak in mwifiex_11n_aggregate_pkt()", " - wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished", " irq_prepare_bcn_tasklet", " - dpaa2: add independent dependencies for FSL_DPAA2_SWITCH", " - [Config] Disable FSL_DPAA2_SWITCH on armhf, ppc64el", " - dpaa2: compile dpaa2 even CONFIG_FSL_DPAA2_ETH=n", " - kernel: param: rename locate_module_kobject", " - kernel: globalize lookup_or_create_module_kobject()", " - params: Replace __modinit with __init_or_module", " - module: Fix freeing of charp module parameters when CONFIG_SYSFS=n", " - bpf, devmap: Remove unnecessary if check in for loop", " - bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path", " - r8152: fix incorrect register write to USB_UPHY_XTAL", " - powerpc/crash: fix backup region offset update to elfcorehdr", " - macvlan: annotate data-races around port->bc_queue_len_used", " - wifi: brcmfmac: Fix error pointer dereference", " - bpf-lsm: Make bpf_lsm_userns_create() sleepable", " - bpf: Drop task_to_inode and inet_conn_established from lsm sleepable", " hooks", " - net: bcmgenet: fix off-by-one in bcmgenet_put_txcb", " - netfilter: xt_socket: enable defrag after all other checks", " - netfilter: nft_fwd_netdev: check ttl/hl before forwarding", " - 6pack: propagage new tty types", " - net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf", " - net/rds: Optimize rds_ib_laddr_check", " - net/rds: Restrict use of RDS/IB to the initial network namespace", " - ppp: require CAP_NET_ADMIN in target netns for unattached ioctls", " - bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb", " - Bluetooth: L2CAP: Fix printing wrong information if SDU length exceeds", " MTU", " - Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error", " - Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER", " - Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp", " - net: phy: qcom: at803x: Use the correct bit to disable extended next", " page", " - sctp: fix missing encap_port propagation for GSO fragments", " - net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master", " - drm/komeda: fix integer overflow in AFBC framebuffer size check", " - ASoC: sti: Return errors from regmap_field_alloc()", " - ASoC: sti: use managed regmap_field allocations", " - dm cache: fix null-deref with concurrent writes in passthrough mode", " - dm cache: fix write path cache coherency in passthrough mode", " - dm cache policy smq: fix missing locks in invalidating cache blocks", " - dm cache: fix concurrent write failure in passthrough mode", " - dm cache: support shrinking the origin device", " - dm cache: fix dirty mapping checking in passthrough mode switching", " - dm cache metadata: fix memory leak on metadata abort retry", " - dm log: fix out-of-bounds write due to region_count overflow", " - spi: fsl-qspi: Use reinit_completion() for repeated operations", " - drm/sun4i: Fix resource leaks", " - dm init: ensure device probing has finished in dm-mod.waitfor=", " - fbdev: matroxfb: Mark variable with __maybe_unused to avoid W=1 build", " break", " - spi: hisi-kunpeng: prevent infinite while() loop in hisi_spi_flush_fifo", " - drm/msm/dsi: rename MSM8998 DSI version from V2_2_0 to V2_0_0", " - drm/panel: simple: Correct G190EAN01 prepare timing", " - ALSA: core: Validate compress device numbers without dynamic minors", " - drm/amd/pm/ci: Use highest MCLK on CI when MCLK DPM is disabled", " - drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs", " - drm/amd/pm/smu7: Fix SMU7 voltage dependency on display clock", " - drm/amd/pm/ci: Fix powertune defaults for Hawaii 0x67B0", " - drm/amd/pm/ci: Clear EnabledForActivity field for memory levels", " - drm/amd/pm/ci: Fill DW8 fields from SMC", " - drm/amd/pm/smu7: Add SCLK cap for quirky Hawaii board", " - ALSA: hda/realtek: Whitespace fix", " - ALSA: hda/realtek: fix code style (ERROR: else should follow close brace", " '}')", " - drm/msm/a6xx: Fix HLSQ register dumping", " - drm/msm/a6xx: Use barriers while updating HFI Q headers", " - pmdomain: ti: omap_prm: Fix a reference leak on device node", " - pmdomain: imx: scu-pd: Fix device_node reference leak during ->probe()", " - ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_arc_mode_put()", " - ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_mode_put()", " - ASoC: fsl_easrc: Check the variable range in fsl_easrc_iec958_put_bits()", " - ASoC: fsl_easrc: Fix value type in fsl_easrc_iec958_get_bits()", " - ASoC: fsl_easrc: Change the type for iec958 channel status controls", " - PCI: Enable AtomicOps only if Root Port supports them", " - Documentation: fix a hugetlbfs reservation statement", " - selftest: memcg: skip memcg_sock test if address family not supported", " - PCI: Add PCIE_PME_TO_L2_TIMEOUT_US L2 ready timeout value", " - PCI: tegra194: Fix polling delay for L2 state", " - PCI: tegra194: Increase LTSSM poll time on surprise link down", " - PCI: tegra194: Disable LTSSM after transition to Detect on surprise link", " down", " - PCI: tegra194: Use devm_gpiod_get_optional() to parse \"nvidia,refclk-", " select\"", " - PCI: tegra194: Disable direct speed change for Endpoint mode", " - ALSA: sc6000: Use standard print API", " - ALSA: sc6000: Keep the programmed board state in card-private data", " - ktest: Avoid undef warning when WARNINGS_FILE is unset", " - ktest: Honor empty per-test option overrides", " - ktest: Run POST_KTEST hooks on failure and cancellation", " - quota: Fix race of dquot_scan_active() with quota deactivation", " - gfs2: add some missing log locking", " - gfs2: prevent NULL pointer dereference during unmount", " - efi/capsule-loader: fix incorrect sizeof in phys array reallocation", " - ksmbd: fix use-after-free from async crypto on Qualcomm crypto engine", " - ARM: dts: mediatek: mt7623: fix efuse fallback compatible", " - memory: tegra124-emc: Fix dll_change check", " - memory: tegra30-emc: Fix dll_change check", " - soc: qcom: ocmem: use scoped device node handling to simplify error", " paths", " - soc: qcom: ocmem: register reasons for probe deferrals", " - soc: qcom: ocmem: return -EPROBE_DEFER is ocmem is not available", " - arm64: dts: qcom: sdm845-xiaomi-beryllium: Mark l1a regulator as powered", " during boot", " - unshare: fix nsproxy leak in ksys_unshare() on set_cred_ucounts()", " failure", " - ocfs2/dlm: validate qr_numregions in dlm_match_regions()", " - ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison", " - soc: qcom: aoss: compare against normalized cooling state", " - ocfs2: fix listxattr handling when the buffer is full", " - ocfs2: validate bg_bits during freefrag scan", " - ocfs2: validate group add input before caching", " - dmaengine: dw-axi-dmac: Remove unnecessary return statement from void", " function", " - dmaengine: mxs-dma: Fix missing return value from", " of_dma_controller_register()", " - tracing: Rebuild full_name on each hist_field_name() call", " - ima: check return value of crypto_shash_final() in boot aggregate", " - HID: asus: make asus_resume adhere to linux kernel coding standards", " - HID: asus: do not abort probe when not necessary", " - mtd: physmap_of_gemini: Fix disabled pinctrl state check", " - mtd: spi-nor: core: correct the op.dummy.nbytes when check read", " operations", " - mtd: spi-nor: swp: check SR_TB flag when getting tb_mask", " - mtd: parsers: ofpart: call of_node_put() only in ofpart_fail path", " - mtd: parsers: ofpart: call of_node_get() for dedicated subpartitions", " - mtd: rawnand: sunxi: fix sunxi_nfc_hw_ecc_read_extra_oob", " - HID: usbhid: fix deadlock in hid_post_reset()", " - pinctrl: pinctrl-pic32: Fix resource leak", " - perf branch: Avoid incrementing NULL", " - perf: tools: cs-etm: Fix print issue for Coresight debug in ETE/TRBE", " trace", " - pinctrl: abx500: Fix type of 'argument' variable", " - perf expr: Return -EINVAL for syntax error in expr__find_ids()", " - perf util: Kill die() prototype, dead for a long time", " - i3c: mipi-i3c-hci: fix IBI payload length calculation for final status", " - driver core: device.h: remove extern from function prototypes", " - driver core: Move dev_err_probe() to where it belogs", " - dev_printk: add new dev_err_probe() helpers", " - backlight: sky81452-backlight: Check return value of", " devm_gpiod_get_optional() in sky81452_bl_parse_dt()", " - platform/surface: surfacepro3_button: Drop wakeup source on remove", " - leds: lgm-sso: Remove duplicate assignments for priv->mmap", " - tty: hvc: remove HVC_IUCV_MAGIC", " - tty: hvc_iucv: fix off-by-one in number of supported devices", " - platform/x86: panasonic-laptop: Fix OPTD notifier registration and", " cleanup", " - mfd: mc13xxx-core: Fix memory leak in mc13xxx_add_subdevice_pdata()", " - nfs/blocklayout: Fix compilation error (`make W=1`) in", " bl_write_pagelist()", " - fs/ntfs3: terminate the cached volume label after UTF-8 conversion", " - platform/x86: dell_rbu: avoid uninit value usage in packet_size_write()", " - platform/x86: dell-wmi-sysman: bound enumeration string aggregation", " - RDMA/core: Prefer NLA_NUL_STRING", " - scsi: sg: Resolve soft lockup issue when opening /dev/sgX", " - scsi: target: core: Fix integer overflow in UNMAP bounds check", " - dt-bindings: clock: qcom,gcc-sc8180x: Add missing GDSCs", " - clk: qcom: gcc-sc8180x: Add missing GDSCs", " - clk: qcom: gcc-sc8180x: Use retention for USB power domains", " - clk: qcom: gcc-sc8180x: Use retention for PCIe power domains", " - clk: qcom: dispcc-sm8250: Use shared ops on the mdss vsync clk", " - clk: qcom: dispcc-sm8250: Enable parents for pixel clocks", " - clk: imx: imx6q: Fix device node reference leak in pll6_bypassed()", " - clk: imx: imx6q: Fix device node reference leak in", " of_assigned_ldb_sels()", " - clk: imx8mq: Correct the CSI PHY sels", " - clk: qoriq: avoid format string warning", " - clk: xgene: Fix mapping leak in xgene_pllclk_init()", " - dt-bindings: clock: qcom,dispcc-sc7180: Define MDSS resets", " - clk: qcom: dispcc-sc7180: Add missing MDSS resets", " - lib/hexdump: print_hex_dump_bytes() calls print_hex_dump_debug()", " - crypto: sa2ul - Fix AEAD fallback algorithm names", " - crypto: ccp - copy IV using skcipher ivsize", " - PCMCIA: Fix garbled log messages for KERN_CONT", " - net/sched: sch_cake: fix NAT destination port not being updated in", " cake_update_flowkeys", " - nexthop: fix IPv6 route referencing IPv4 nexthop", " - net/sched: taprio: stop going through private ops for dequeue and peek", " - net/sched: taprio: replace safety precautions with comments", " - net/sched: taprio: continue with other TXQs if one dequeue() failed", " - net/sched: taprio: refactor one skb dequeue from TXQ to separate", " function", " - net/sched: taprio: rename close_time to end_time", " - net/sched: taprio: fix use-after-free in advance_sched() on schedule", " switch", " - tcp: annotate data-races around (tp->write_seq - tp->snd_nxt)", " - i40e: don't advertise IFF_SUPP_NOFCS", " - e1000e: Unroll PTP in probe error handling", " - ipv6: fix possible UAF in icmpv6_rcv()", " - sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks", " - dissector: do not set invalid PPP protocol", " - flow_dissector: Add number of vlan tags dissector", " - flow_dissector: Add PPPoE dissectors", " - pppoe: drop PFC frames", " - netfilter: nft_osf: restrict it to ipv4", " - netfilter: conntrack: remove sprintf usage", " - netfilter: xtables: restrict several matches to inet family", " - ipvs: fix MTU check for GSO packets in tunnel mode", " - netfilter: nfnetlink_osf: fix out-of-bounds read on option matching", " - netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check", " - arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number", " - ksmbd: destroy tree_conn_ida in ksmbd_session_destroy()", " - ksmbd: scope conn->binding slowpath to bound sessions only", " - net/rds: zero per-item info buffer before handing it to visitors", " - net_sched: sch_hhf: annotate data-races in hhf_dump_stats()", " - net/sched: sch_pie: annotate data-races in pie_dump_stats()", " - net/sched: sch_fq_codel: remove data-races from fq_codel_dump_stats()", " - net: sched: gred/red: remove unused variables in struct red_stats", " - net/sched: sch_red: annotate data-races in red_dump_stats()", " - net/sched: sch_sfb: annotate data-races in sfb_dump_stats()", " - nfp: fix swapped arguments in nfp_encode_basic_qdr() calls", " - tipc: fix double-free in tipc_buf_append()", " - vhost_net: fix sleeping with preempt-disabled in vhost_net_busy_poll()", " - fs/adfs: validate nzones in adfs_validate_bblk()", " - rtc: abx80x: Disable alarm feature if no interrupt attached", " - fbdev: offb: fix PCI device reference leak on probe failure", " - mailbox: mailbox-test: free channels on probe error", " - cgroup/rdma: fix integer overflow in rdmacg_try_charge()", " - mailbox: add sanity check for channel array", " - mailbox: mailbox-test: don't free the reused channel", " - mailbox: mailbox-test: initialize struct earlier", " - mailbox: mailbox-test: make data_ready a per-instance variable", " - btrfs: fix double-decrement of bytes_may_use in", " submit_one_async_extent()", " - tracing: branch: Fix inverted check on stat tracer registration", " - drm/amdgpu: fix spelling typos", " - drm/amdgpu/uvd3.1: Don't validate the firmware when already validated", " - drm/amdgpu/gfx6: Support harvested SI chips with disabled TCCs (v2)", " - netfilter: xt_policy: fix strict mode inbound policy matching", " - netfilter: nf_conntrack_sip: don't use simple_strtoul", " - scsi: sr: Add memory allocation failure handling for get_capabilities()", " - cdrom, scsi: sr: propagate read-only status to block layer via", " set_disk_ro()", " - netdevsim: zero initialize struct iphdr in dummy sk_buff", " - net: sched: sch_netem: Refactor code in 4-state loss generator", " - net/sched: netem: fix probability gaps in 4-state loss model", " - net/sched: netem: fix queue limit check to include reordered packets", " - net/sched: netem: validate slot configuration", " - net: sched: choke: remove unused variables in struct choke_sched_data", " - net/sched: sch_choke: annotate data-races in choke_dump_stats()", " - net/sched: sch_fq_pie: annotate data-races in fq_pie_dump_stats()", " - vrf: Fix a potential NPD when removing a port from a VRF", " - net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()", " - net: usb: rtl8150: free skb on usb_submit_urb() failure in xmit", " - NFC: trf7970a: Ignore antenna noise when checking for RF field", " - net: phy: dp83869: fix setting CLK_O_SEL field.", " - ASoC: codecs: ab8500: Fix casting of private data", " - netfilter: skip recording stale or retransmitted INIT", " - sctp: discard stale INIT after handshake completion", " - ipv4: rename and move ip_route_output_tunnel()", " - ipv4: remove \"proto\" argument from udp_tunnel_dst_lookup()", " - ipv4: add new arguments to udp_tunnel_dst_lookup()", " - ipv6: rename and move ip6_dst_lookup_tunnel()", " - net/sched: sch_cake: annotate data-races in cake_dump_stats() (V)", " - ALSA: hda/conexant: add a new hda codec SN6140", " - ALSA: hda/conexant: fix some typos", " - ALSA: hda/conexant: Renaming the codec with device ID 0x1f86 and 0x1f87", " - ALSA: hda/conexant: Fix missing error check for jack detection", " - drm/amd/display: Allow DCE link encoder without AUX registers", " - drm/amd/display: Read EDID from VBIOS embedded panel info", " - btrfs: tracepoints: fix sleep while in atomic context in", " btrfs_sync_file()", " - flow_dissector: do not dissect PPPoE PFC frames", " - flow_dissector: Do not count vlan tags inside tunnel payload", " - net/sched: sch_pie: annotate more data-races in pie_dump_stats()", " - crypto: af_alg - Cap AEAD AD length to 0x80000000", " - i40e: Cleanup PTP pins on probe failure", " - audit: fix incorrect inheritable capability in CAPSET records", " - netfilter: nft_ct: fix missing expect put in obj eval", " - net: atlantic: preserve PCI wake-from-D3 on shutdown when WOL enabled", " - audit: enforce AUDIT_LOCKED for AUDIT_TRIM and AUDIT_MAKE_EQUIV", " - KVM: Reject wrapped offset in kvm_reset_dirty_gfn()", " - KVM: x86: Fix Xen hypercall tracepoint argument assignment", " - drm/i915/dp: Fix VSC dynamic range signaling for RGB formats", " - ALSA: usb-audio: Bound MIDI endpoint descriptor scans", " - ceph: fix a buffer leak in __ceph_setxattr()", " - powerpc/warp: Fix error handling in pika_dtm_thread", " - libceph: Fix potential out-of-bounds access in osdmap_decode()", " - libceph: Fix potential null-ptr-deref in decode_choose_args()", " - libceph: Fix potential out-of-bounds access in crush_decode()", " - libceph: handle rbtree insertion error in decode_choose_args()", " - iommu/vt-d: Disable DMAR for Intel Q35 IGFX", " - drm/i915: skip __i915_request_skip() for already signaled requests", " - drm/panfrost: Fix wait_bo ioctl leaking positive return from", " dma_resv_wait_timeout()", " - drm/gma500/oaktrail_hdmi: fix i2c adapter leak on setup", " - s390/debug: Reject zero-length input before trimming a newline", " - Revert \"x86/vdso: Fix output operand size of RDPID\"", " - sysfs: don't remove existing directory on update failure", " - hwmon: (pmbus/adm1266) widen blackbox-info buffer to I2C_SMBUS_BLOCK_MAX", " - ALSA: ua101: Reject too-short USB descriptors", " - ALSA: asihpi: Fix potential OOB array access at reading cache", " - net: wwan: iosm: fix potential memory leaks in ipc_imem_init()", " - Bluetooth: bnep: Fix UAF read of dev->name", " - phonet/pep: disable BH around forwarded sk_receive_skb()", " - net: bcmgenet: keep RBUF EEE/PM disabled", " - netfilter: ip6t_hbh: reject oversized option lists", " - netfilter: nf_queue: hold bridge skb->dev while queued", " - netfilter: ipset: stop hash:* range iteration at end", " - ring-buffer: Fix reporting of missed events in iterator", " - vsock/vmci: fix UAF when peer resets connection during handshake", " - wifi: ath11k: clear shared SRNG pointer state on restart", " - ipv4: raw: reject IP_HDRINCL packets with ihl < 5", " - ixgbevf: fix use-after-free in VEPA multicast source pruning", " - wifi: cfg80211: advance loop vars in cfg80211_merge_profile()", " - tracing: Do not call map->ops->elt_free() if elt_alloc() fails", " - scsi: isci: Fix use-after-free in device removal path", " - spi: sprd: fix error pointer deref after DMA setup failure", " - spi: ti-qspi: fix use-after-free after DMA setup failure", " - RDMA/siw: Reject MPA FPDU length underflow before signed receive math", " - device property: set fwnode->secondary to NULL in fwnode_init()", " - drm/bridge: it66121: acquire reset GPIO in probe", " - drm/bridge: megachips: remove bridge when irq request fails", " - drm/amd/display: Fix integer overflow in bios_get_image()", " - drm/amd/display: Validate payload length and link_index in", " dc_process_dmub_aux_transfer_async", " - batman-adv: mcast: fix use-after-free in orig_node RCU release", " - batman-adv: clear current gateway during teardown", " - batman-adv: dat: handle forward allocation error", " - batman-adv: fix fragment reassembly length accounting", " - batman-adv: fix tp_meter counter underflow during shutdown", " - batman-adv: frag: disallow unicast fragment in fragment", " - batman-adv: bla: fix report_work leak on backbone_gw purge", " - batman-adv: tp_meter: avoid use of uninit sender vars", " - batman-adv: tt: fix negative last_changeset_len", " - batman-adv: tt: fix negative tt_buff_len", " - hwmon: (pmbus/adm1266) seed timestamp from the real-time clock", " - hwmon: (pmbus/adm1266) reject implausible blackbox record_count", " - hwmon: (pmbus/adm1266) include PEC byte in pmbus_block_xfer read buffer", " - hwmon: (pmbus/adm1266) bounce blackbox records through a protocol-sized", " buffer", " - hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR", " - hwmon: (pmbus/adm1266) don't clobber GPIO bits before PDIO read in", " get_multiple", " - hwmon: (pmbus/adm1266) register the gpio_chip after pmbus_do_probe()", " - hwmon: (pmbus/adm1266) register the nvmem device after pmbus_do_probe()", " - hwmon: (pmbus/adm1266) reject short block-read responses in the GPIO", " accessors", " - firmware: arm_ffa: Check for NULL FF-A ID table while driver", " registration", " - firmware: arm_ffa: Skip free_pages on RX buffer alloc failure", " - kunit: config: Enable KUNIT_DEBUGFS by default", " - kunit: config: KUNIT_DEBUGFS should depend on DEBUG_FS", " - ARM: integrator: Fix early initialization", " - netfilter: x_tables: unregister the templates first", " - tcp: Fix imbalanced icsk_accept_queue count.", " - ice: fix locking in ice_dcb_rebuild()", " - phy: marvell: mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register", " access", " - irqchip/ath79-cpu: Remove unused function", " - net: ethernet: cortina: Make RX SKB per-port", " - net: ethernet: cortina: Drop half-assembled SKB", " - net: ethernet: cortina: Carry over frag counter", " - net: ethernet: cs89x0: remove stale CONFIG_MACH_MX31ADS reference", " - wifi: ath11k: fix error path leaks in some WMI WOW calls", " - HID: quirks: really enable the intended work around for appledisplay", " - ethtool: fix ethnl_bitmap32_not_zero() bit interval semantics", " - drm/msm: Fix iommu_map_sgtable() return value check and avoid WARN", " - net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring", " - net: tls: prevent chain-after-chain in plain text SG", " - drm/msm/snapshot: fix dumping of the unaligned regions", " - net: dsa: mt7530: sync driver-specific behavior of MT7531 variants", " - net: dsa: mt7530: fix FDB entries not aging out with short timeout", " - net: dsa: mt7530: rename mt753x_bpdu_port_fw enum to mt753x_to_cpu_fw", " - net: dsa: mt7530: preserve VLAN tags on trapped link-local frames", " - net: mana: Fix TOCTOU double-fetch of hwc_msg_id from DMA buffer", " - platform/x86: adv_swbutton: Check ACPI_HANDLE() against NULL", " - platform/x86: hp_accel: Check ACPI_COMPANION() against NULL", " - platform/x86: intel-hid: Check ACPI_HANDLE() against NULL", " - platform/x86: intel-vbtn: Check ACPI_HANDLE() against NULL", " - RDMA/rtrs: Fix use-after-free in path file creation cleanup", " - net: bridge: Flush multicast groups when snooping is disabled", " - bridge: mcast: Fix a possible use-after-free when removing a bridge port", " - tracing: Avoid NULL return from hist_field_name() on truncation", " - net: ag71xx: check error for platform_get_irq", " - string: add mem_is_zero() helper to check if memory area is all zeros", " - gpiolib: cdev: use !mem_is_zero() instead of memchr_inv(s, 0, n)", " - gpio: cdev: check if uAPI v2 config attributes are correctly zeroed", " - net: mana: validate rx_req_idx to prevent out-of-bounds array access", " - Linux 5.15.209", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46275", " - Bluetooth: hci_uart: fix UAFs and race conditions in close and init", " paths", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-23141", " - KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory", " accesses", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43052", " - wifi: mac80211: check tdls flag in ieee80211_tdls_oper", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-22107", " - net: dsa: sja1105: fix kasan out-of-bounds warning in", " sja1105_table_delete_entry()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-21863", " - io_uring: prevent opcode speculation", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46274", " - io-wq: check that the predecessor is hashed in io_wq_remove_pending()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45846", " - bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45844", " - netfilter: arp_tables: fix IEEE1394 ARP payload parsing", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45843", " - slip: bound decode() reads against the compressed packet length", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45842", " - slip: reject VJ receive packets on instances with no rstate array", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45841", " - netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45840", " - openvswitch: cap upcall PID array size and pre-size vport replies", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46319", " - net/sched: act_ct: Only release RCU read lock after ct_ft", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45839", " - bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45838", " - bpf: fix end-of-list detection in cgroup_storage_get_next_key()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46214", " - vsock/virtio: fix accept queue count leak on transport mismatch", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46234", " - vsock: fix buffer size clamping order", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45836", " - Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46231", " - batman-adv: bla: put backbone reference on failed claim hash insert", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46233", " - batman-adv: bla: only purge non-released claims", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46212", " - batman-adv: bla: prevent use-after-free when deleting claims", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46238", " - batman-adv: stop caching unowned originator pointers in BAT IV", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46206", " - batman-adv: reject new tp_meter sessions during teardown", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46198", " - batman-adv: fix integer overflow on buff_pos", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46227", " - sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in", " SCTP_SENDALL", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46220", " - drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46197", " - drm/amdkfd: validate SVM ioctl nattr against buffer size", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46209", " - drm/gem: Fix inconsistent plane dimension calculation in", " drm_gem_fb_init_with_funcs()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46230", " - drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46219", " - spi: mpc52xx: fix use-after-free on unbind", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46236", " - media: rc: xbox_remote: heed DMA restrictions", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46205", " - staging: media: atomisp: Disallow all private IOCTLs", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46168", " - mptcp: fix scheduling with atomic in timestamp sockopt", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46189", " - RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46133", " - RDMA/rxe: Reject unknown opcodes before ICRC processing", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46127", " - RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46178", " - RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46112", " - RDMA/hns: Fix unlocked call to hns_roce_qp_remove()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46304", " - nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46161", " - md/raid10: fix divide-by-zero in setup_geo() with zero far_copies", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46124", " - isofs: validate block number from NFS file handle in isofs_export_iget", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46303", " - isofs: validate Rock Ridge CE continuation extent against volume size", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46294", " - dm: fix a buffer overflow in ioctl processing", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46107", " - dm-thin: fix metadata refcount underflow", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46301", " - spi: topcliff-pch: fix use-after-free on unbind", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46273", " - ibmveth: Disable GSO for packets with small MSS", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43502", " - net/rds: handle zerocopy send cleanup before the message is queued", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46120", " - ip6_gre: Use cached t->net in ip6erspan_changelink().", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46184", " - sound: ua101: fix division by zero at probe", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46132", " - net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in", " rtnl_fill_vfinfo", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46150", " - fanotify: fix false positive on permission events", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45834", " - Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45835", " - Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46186", " - Bluetooth: virtio_bt: validate rx pkt_type header length", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46123", " - Bluetooth: virtio_bt: clamp rx length before skb_put", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46172", " - ipv6: xfrm6: release dst on error in xfrm6_rcv_encap()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46146", " - ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46167", " - usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46151", " - usb: usblp: fix heap leak in IEEE 1284 device ID via short response", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46122", " - wifi: b43: enforce bounds check on firmware key index in b43_rx()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46307", " - wifi: ath5k: do not access array OOB", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46187", " - wifi: rsi: fix kthread lifetime race between self-exit and external-stop", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46163", " - wifi: b43legacy: enforce bounds check on firmware key index in RX path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46044", " - ipmi:ssif: Clean up kthread on errors", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43496", " - net/sched: sch_red: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-56727", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31489", " - spi: meson-spicc: Fix double-put in remove path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31476", " - ksmbd: do not expire session on binding failure", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43497", " - fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46108", " - ipmi:si: Return state to normal if message allocation fails", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46128", " - ipmi: Check event message buffer response for bad data", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46177", " - ipmi: Add limits to event and receive message requests", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46149", " - scsi: target: configfs: Bound snprintf() return in", " tg_pt_gp_members_show()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46101", " - netfilter: reject zero shift in nft_bitwise", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46099", " - net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46033", " - crypto: authencesn - reject short ahash digests during instance creation", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46062", " - ntfs3: fix integer overflow in run_unpack() volume boundary check", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46072", " - ntfs3: add buffer boundary checks to run_unpack()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46023", " - dm mirror: fix integer overflow in create_dirty_log()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46077", " - crypto: atmel-tdes - fix DMA sync direction", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45986", " - crypto: ccree - fix a memory leak in cc_mac_digest()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46019", " - crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46015", " - tcp: call sk_data_ready() after listener migration", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46040", " - inotify: fix watch count leak when fsnotify_add_inode_mark_locked()", " fails", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46070", " - md/raid5: validate payload size before accessing journal metadata", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46051", " - md/raid5: fix soft lockup in retry_aligned_read()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46046", " - ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46285", " - mtd: docg3: fix use-after-free in docg3_release()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46082", " - KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45987", " - KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46024", " - libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46037", " - ipv4: icmp: validate reply type before using icmp_pointers", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46027", " - net/smc: avoid early lgr access in smc_clc_wait_msg", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46053", " - net: rds: fix MR cleanup on copy error", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46004", " - ALSA: caiaq: Handle probe errors properly", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46050", " - md/raid10: fix deadlock with check operation and nowait requests", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46049", " - ALSA: ctxfi: Add fallback to default RSR for S/PDIF", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46002", " - ext2: reject inodes with zero i_nlink and valid mode in ext2_iget()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46047", " - net: qrtr: ns: Fix use-after-free in driver remove()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46009", " - PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46102", " - net: strparser: fix skb_head leak in strp_abort_strp()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46098", " - net: caif: clear client service pointer on teardown", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46088", " - ALSA: control: Validate buf_len before strnlen() in", " snd_ctl_elem_init_enum_names()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46080", " - ocfs2: split transactions in dio completion to avoid credit exhaustion", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-21739", " - scsi: ufs: core: Fix use-after free in init error and remove paths", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46064", " - ibmasm: fix heap over-read in ibmasm_send_i2o_message()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45994", " - ibmasm: fix OOB reads in command_file_write due to missing size checks", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46022", " - misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46006", " - drm/nouveau: fix u32 overflow in pushbuf reloc bounds check", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46018", " - ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31696", " - rxrpc: Fix missing validation of ticket length in non-XDR key preparsing", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31697", " - crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31698", " - crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command", " failed", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31699", " - crypto: ccp: Don't attempt to copy CSR to userspace if PSP command", " failed", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31701", " - ALSA: caiaq: take a reference on the USB device in create_card()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31694", " - fuse: reject oversized dirents in page cache", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31716", " - fs/ntfs3: validate rec->used in journal-replay file record check", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31676", " - rxrpc: only handle RESPONSE during service challenge", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31409", " - ksmbd: unset conn->binding on failed binding request", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-53596", " - drivers: base: Free devm resources when unregistering a device", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-50012", " - cpufreq: Avoid a bad reference count on CPU node", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38192", " - net: clear the dst when changing skb protocol", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-21712", " - md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43328", " - cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error", " path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23066", " - rxrpc: Fix recvmsg() unconditional requeue", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-50248", " - ntfs3: Add bounds checking to mi_enum_attr()", " - fs/ntfs3: Sequential field availability check in mi_enum_attr()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-27407", " - fs/ntfs3: Fixed overflow check in mi_enum_attr()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-45896", " - fs/ntfs3: Add more attributes checks in mi_enum_attr()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-52737", " - btrfs: lock the inode in shared mode before starting fiemap", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38626", " - f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-46770", " - ice: Add netif_device_attach/detach into PF reset flow", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38105", " - ALSA: usb-audio: Kill timer properly at removal", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-27389", " - pstore: inode: Only d_invalidate() is needed", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-52682", " - f2fs: fix to wait on block writeback for post_read case", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-56719", " - net: stmmac: fix TSO DMA API usage causing oops", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-41079", " - nvmet: always initialize cqe.result", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-53545", " - drm/amdgpu: unmap and remove csa_va properly", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-68239", " - binfmt_misc: restore write access before closing files opened by", " open_exec()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38659", " - gfs2: No more self recovery", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-49961", " - bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-47809", " - dlm: fix possible lkb_resource null dereference", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38250", " - Bluetooth: hci_core: Fix use-after-free in vhci_flush()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43281", " - mailbox: Prevent out-of-bounds access in of_mbox_index_xlate()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23157", " - btrfs: do not strictly require dirty metadata threshold for metadata", " writepages", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23141", " - btrfs: send: check for inline extents in range_is_hole_in_parent()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-40005", " - spi: cadence-quadspi: Implement refcount to handle unbind during busy", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-53629", " - fs: dlm: fix use after free in midcomms commit", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-71221", " - dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23204", " - net/sched: cls_u32: use skb_header_pointer_careful()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-71161", " - dm-verity: disable recursive forward error correction", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-50552", " - blk-mq: use quiesced elevator switch when reinitializing queues", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-36922", " - wifi: iwlwifi: read txq->read_ptr under lock", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-53221", " - f2fs: fix null-ptr-deref in f2fs_submit_page_bio()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-56657", " - ALSA: control: Avoid WARN() for symlink errors", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-49803", " - netdevsim: Fix memory leak of nsim_dev->fa_cookie", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-50116", " - tty: n_gsm: fix deadlock and link starvation in outgoing data path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31586", " - mm: blk-cgroup: fix use-after-free in cgwb_release_workfn()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31598", " - ocfs2: fix possible deadlock between unlink and dio_end_io_write", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31642", " - rxrpc: Fix call removal to use RCU safe deletion", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31664", " - xfrm: clear trailing padding in build_polexpire()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43075", " - ocfs2: fix out-of-bounds write in ocfs2_write_end_inline", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43076", " - ocfs2: validate inline data i_size during inode read", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23444", " - wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38710", " - gfs2: Validate i_depth for exhash directories", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23442", " - ipv6: add NULL checks for idev in SRv6 paths", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31594", " - PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-50073", " - net: tap: NULL pointer derefence in dev_parse_header_protocol when", " skb->dev is null", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31576", " - media: hackrf: fix to not free memory after the device is registered in", " hackrf_probe()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43058", " - media: vidtv: fix pass-by-value structs causing MSAN warnings", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31577", " - nilfs2: fix NULL i_assoc_inode dereference in", " nilfs_mdt_save_to_shadow_map", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31578", " - media: as102: fix to not free memory after the device is registered in", " as102_usb_probe()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31580", " - bcache: fix cached_dev.sb_bio use-after-free and crash", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31581", " - ALSA: 6fire: fix use-after-free on disconnect", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31583", " - media: em28xx: fix use-after-free in em28xx_v4l2_open()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31585", " - media: vidtv: fix nfeeds state corruption on start_streaming failure", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31686", " - mm/kasan: fix double free for kasan pXds", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31588", " - KVM: x86: Use scratch field in MMIO fragment to hold small write values", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31630", " - rxrpc: proc: size address buffers for %pISpc output", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23399", " - nf_tables: nft_dynset: fix possible stateful expression memleak in error", " path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-35865", " - smb: client: fix potential UAF in smb2_is_valid_oplock_break()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31590", " - KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31596", " - ocfs2: handle invalid dinode in ocfs2_group_extend", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31597", " - ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31599", " - media: vidtv: fix NULL pointer dereference in", " vidtv_channel_pmt_match_sections", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31602", " - ALSA: ctxfi: Limit PTP to a single page", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31603", " - staging: sm750fb: fix division by zero in ps_to_hz()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31605", " - fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31615", " - usb: gadget: renesas_usb3: validate endpoint index in standard request", " handlers", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31616", " - usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31617", " - usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31618", " - fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31619", " - ALSA: fireworks: bound device-supplied status before string array lookup", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31622", " - NFC: digital: Bounds check NFC-A cascade depth in SDD response handler", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31623", " - net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31624", " - HID: core: clamp report_size in s32ton() to avoid undefined shift", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31625", " - HID: alps: fix NULL pointer dereference in alps_raw_event()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31626", " - staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31627", " - i2c: s3c24xx: check the size of the SMBUS message before using it", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31532", " - can: raw: fix ro->uniq use-after-free in raw_rcv()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31629", " - nfc: llcp: add missing return after LLCP_CLOSED checks", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31407", " - netfilter: conntrack: add missing netlink policy validations", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43079", " - perf/x86/intel/uncore: Skip discovery table for offline dies", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43080", " - l2tp: Drop large packets with UDP encap", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31673", " - af_unix: read UNIX_DIAG_VFS data under unix_state_lock", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31681", " - netfilter: xt_multiport: validate range encoding in checkentry", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43085", " - netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43089", " - xfrm_user: fix info leak in build_mapping()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43093", " - xsk: tighten UMEM headroom validation to account for tailroom and min", " frame", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43098", " - nfc: s3fwrn5: allocate rx skb before consuming bytes", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43099", " - ipv4: icmp: fix null-ptr-deref in icmp_build_probe()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43103", " - net: lapbether: handle NETDEV_PRE_TYPE_CHANGE", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31684", " - net: sched: act_csum: validate nested VLAN headers", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43074", " - eventpoll: defer struct eventpoll free to RCU grace period", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43104", " - drm/vc4: Fix a memory leak in hang state error path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43105", " - drm/vc4: Fix memory leak of BO array in hang state", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43110", " - wifi: brcmfmac: validate bsscfg indices in IF events", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43111", " - HID: roccat: fix use-after-free in roccat_report_event", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43112", " - fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43113", " - wifi: wl1251: validate packet IDs before indexing tx_frames", " * Jammy update: v5.15.207 upstream stable release (LP: #2156629)", " - Buffer overflow in drivers/xen/sys-hypervisor.c", " - xen/privcmd: fix double free via VMA splitting", " - Linux 5.15.204", " - Linux 5.15.205", " - Linux 5.15.206", " - Linux 5.15.207", " * Jammy update: v5.15.207 upstream stable release (LP: #2156629) //", " CVE-2025-54518 // CVE-2026-46174", " - x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op", " cache", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550)", " - ARM: clean up the memset64() C wrapper", " - Revert \"UBUNTU: SAUCE: Fix skb_vlan_inet_prepare() usage\"", " - ip6_tunnel: Fix usage of skb_vlan_inet_prepare()", " - scsi: lpfc: Properly set WC for DPP mapping", " - scsi: ufs: core: Always initialize the UIC done completion", " - scsi: ufs: core: Move link recovery for hibern8 exit failure to", " wl_resume", " - ALSA: usb-audio: Cap the packet size pre-calculations", " - ALSA: usb-audio: Use inclusive terms", " - btrfs: fix incorrect key offset in error message in", " check_dev_extent_item()", " - memory: mtk-smi: Convert to platform remove callback returning void", " - ARM: OMAP2+: add missing of_node_put before break and return", " - ARM: omap2: Fix reference count leaks in omap_control_init()", " - scsi: ata: Call scsi_done() directly", " - ata: libata-scsi: drop DPRINTK calls for cdb translation", " - ata: libata: remove pointless VPRINTK() calls", " - ata: libata-scsi: refactor ata_scsi_translate()", " - drm/tegra: dsi: fix device leak on probe", " - mfd: qcom-pm8xxx: switch away from using chained IRQ handlers", " - mfd: qcom-pm8xxx: Convert to platform remove callback returning void", " - mfd: qcom-pm8xxx: Fix OF populate on driver rebind", " - mfd: omap-usb-host: Convert to platform remove callback returning void", " - mfd: omap-usb-host: Fix OF populate on driver rebind", " - clk: tegra: tegra124-emc: fix device leak on set_rate()", " - usb: cdns3: remove redundant if branch", " - usb: cdns3: call cdns_power_is_lost() only once in cdns_resume()", " - ALSA: hda/conexant: Add quirk for HP ZBook Studio G4", " - hwmon: (max16065) Use READ/WRITE_ONCE to avoid compiler optimization", " induced race", " - fbcon: Use delayed work for cursor", " - fbcon: Extract fbcon_open/release helpers", " - fbcon: move more common code into fb_open()", " - ALSA: hda/conexant: Fix headphone jack handling on Acer Swift SF314", " - net: arcnet: com20020-pci: fix support for 2.5Mbit cards", " - eventpoll: Fix integer overflow in ep_loop_check_proc()", " - platform/x86: dell-wmi: Add audio/mic mute key codes", " - selftests: mptcp: more stable simult_flows tests", " - platform/x86: thinkpad_acpi: Fix errors reading battery thresholds", " - net: ethernet: ti: am65-cpsw-nuss/cpsw-ale: Fix multicast entry handling", " in ALE table", " - net: dpaa2: replace dpaa2_mac_is_type_fixed() with", " dpaa2_mac_is_type_phy()", " - net: dpaa2-switch: assign port_priv->mac after dpaa2_mac_connect() call", " - net: dpaa2-switch replace direct MAC access with", " dpaa2_switch_port_has_mac()", " - net: dpaa2-switch: serialize changes to priv->mac with a mutex", " - dpaa2-switch: do not clear any interrupts automatically", " - dpaa2-switch: Fix interrupt storm after receiving bad if_id in IRQ", " handler", " - indirect_call_wrapper: do not reevaluate function pointer", " - xen/acpi-processor: fix _CST detection using undersized evaluation", " buffer", " - amd-xgbe: fix sleep while atomic on suspend/resume", " - net: nfc: nci: Fix zero-length proprietary notifications", " - nfc: nci: clear NCI_DATA_EXCHANGE before calling completion callback", " - net: stmmac: Fix error handling in VLAN add and delete paths", " - ACPI: PM: Save NVS memory on Lenovo G70-35", " - ACPI: OSI: Add DMI quirk for Acer Aspire One D255", " - scsi: ses: Fix devices attaching to different hosts", " - ALSA: usb-audio: Avoid implicit feedback mode on DIYINHK USB Audio 2.0", " - ALSA: usb-audio: Check max frame size for implicit feedback mode, too", " - powerpc/uaccess: Fix inline assembly for clang build on PPC32", " - remoteproc: sysmon: Correct subsys_name_len type in QMI request", " - remoteproc: mediatek: Unprepare SCP clock during system suspend", " - powerpc: 83xx: km83xx: Fix keymile vendor prefix", " - bonding: handle BOND_LINK_FAIL, BOND_LINK_BACK as valid link states", " - ASoC: soc-core: drop delayed_work_pending() check before flush", " - ASoC: soc-core: accept zero format at snd_soc_runtime_set_dai_fmt()", " - ASoC: core: Exit all links before removing their components", " - ASoC: core: Do not call link_exit() on uninitialized rtd objects", " - can: hi311x: hi3110_open(): add check for hi3110_power_enable() return", " value", " - regulator: pca9450: Make IRQ optional", " - regulator: pca9450: Correct interrupt type", " - sched: idle: Make skipping governor callbacks more consistent", " - i40e: fix src IP mask checks and memcpy argument names in cloud filter", " - ACPI: OSL: fix __iomem type on return from acpi_os_map_generic_address()", " - ASoC: detect empty DMI strings", " - octeontx2-af: devlink: fix NIX RAS reporter recovery condition", " - net: usb: lan78xx: fix silent drop of packets with checksum errors", " - net: usb: lan78xx: skip LTM configuration for LAN7850", " - usb/core/quirks: Add Huawei ME906S-device to wakeup quirk", " - usb: misc: uss720: properly clean up reference in uss720_probe()", " - usb: core: don't power off roothub PHYs if phy_set_mode() fails", " - usb: cdc-acm: Restore CAP_BRK functionnality to CH343", " - USB: usbcore: Introduce usb_bulk_msg_killable()", " - usb: mdc800: handle signal and read racing", " - mm/tracing: rss_stat: ensure curr is false from kthread context", " - mmc: mmci: Fix device_node reference leak in of_get_dml_pipe_index()", " - libceph: reject preamble if control segment is empty", " - libceph: admit message frames only in CEPH_CON_S_OPEN state", " - time: add kernel-doc in time.c", " - time/jiffies: Mark jiffies_64_to_clock_t() notrace", " - device property: Allow secondary lookup in fwnode_get_next_child_node()", " - irqchip/gic-v3-its: Limit number of per-device MSIs to the range the ITS", " supports", " - net: mana: Ring doorbell at 4 CQ wraparounds", " - ice: fix retry for AQ command 0x06EE", " - parisc: Increase initial mapping to 64 MB with KALLSYMS", " - parisc: Fix initial page table creation for boot", " - net: ethernet: arc: emac: quiesce interrupts before requesting IRQ", " - tracing: Fix trace_buf_size= cmdline parameter with sizes >= 2G", " - lib/bootconfig: fix off-by-one in xbc_verify_tree() unclosed brace error", " - lib/bootconfig: fix snprintf truncation check in", " xbc_node_compose_key_after()", " - lib/bootconfig: check bounds before writing in __xbc_open_brace()", " - btrfs: abort transaction on failure to update root in the received", " subvol ioctl", " - iio: dac: ds4424: reject -128 RAW value", " - iio: chemical: sps30_serial: fix buffer size in sps30_serial_read_meas()", " - iio: potentiometer: mcp4131: fix double application of wiper shift", " - iio: chemical: bme680: Fix measurement wait duration calculation", " - iio: gyro: mpu3050-i2c: fix pm_runtime error handling", " - iio: imu: inv_icm42600: fix odr switch to the same value", " - i3c: mipi-i3c-hci: Use ETIMEDOUT instead of ETIME for timeout errors", " - i3c: mipi-i3c-hci: Restart DMA ring correctly after dequeue abort", " - i3c: mipi-i3c-hci: Add missing TID field to no-op command descriptor", " - l2tp: do not use sock_hold() in pppol2tp_session_get_sock()", " - mmc: sdhci-pci-gli: fix GL9750 DMA write corruption", " - mmc: sdhci: fix timing selection for 1-bit bus width", " - mtd: rawnand: pl353: make sure optimal timings are applied", " - mtd: rawnand: cadence: Fix error check for dma_alloc_coherent() in", " cadence_nand_init()", " - iommu/vt-d: Fix intel iommu iotlb sync hardlockup and retry", " - serial: 8250_pci: add support for the AX99100", " - serial: 8250: Add late synchronize_irq() to shutdown to handle DW UART", " BUSY", " - serial: uartlite: fix PM runtime usage count underflow on probe", " - drm/radeon: apply state adjust rules to some additional HAINAN vairants", " - mm/hugetlb: make detecting shared pte more reliable", " - mm/hugetlb: fix copy_hugetlb_page_range() to use ->pt_share_count", " - mm/hugetlb: fix two comments related to huge_pmd_unshare()", " - mm/rmap: fix two comments related to huge_pmd_unshare()", " - mm/hugetlb: fix excessive IPI broadcasts when unsharing PMD tables using", " mmu_gather", " - net: stmmac: dwmac-loongson: Set clk_csr_i to 100-150MHz", " - net: Handle napi_schedule() calls from non-interrupt", " - ext4: always allocate blocks only from groups inode can use", " - wifi: cfg80211: move scan done work to wiphy work", " - drm/amd/display: Use GFP_ATOMIC in dc_create_stream_for_sink", " - mptcp: pm: avoid sending RM_ADDR over same subflow", " - btrfs: tree-checker: fix misleading root drop_level error message", " - of: Add cleanup.h based auto release via __free(device_node) markings", " - firmware: arm_scpi: Fix device_node reference leak in probe path", " - Bluetooth: LE L2CAP: Disconnect if received packet's SDU exceeds IMTU", " - Bluetooth: LE L2CAP: Disconnect if sum of payload sizes exceed SDU", " - Bluetooth: SMP: make SM/PER/KDU/BI-04-C happy", " - Bluetooth: qca: fix ROM version reading on WCN3998 chips", " - netfilter: xt_time: use unsigned int for monthday bit shift", " - net: bcmgenet: increase WoL poll timeout", " - net: mana: Improve the HWC error handling", " - sched: idle: Consolidate the handling of two special cases", " - igc: fix missing update of skb->tail in igc_xmit_frame()", " - wifi: wlcore: Return -ENOMEM instead of -EAGAIN if there is not enough", " headroom", " - ACPI: processor: Fix previous acpi_processor_errata_piix4() fix", " - net: macb: fix uninitialized rx_fs_lock", " - net: dsa: bcm_sf2: fix missing clk_disable_unprepare() in error paths", " - hwmon: (pmbus/isl68137) Fix unchecked return value and use sysfs_emit()", " - i2c: fsi: Fix a potential leak in fsi_i2c_probe()", " - mtd: rawnand: brcmnand: skip DMA during panic write", " - lib/bootconfig: check xbc_init_node() return in override path", " - tools/bootconfig: fix fd leak in load_xbc_file() on fstat failure", " - sh: platform_early: remove pdev->driver_override check", " - bpf: Release module BTF IDR before module unload", " - platform/x86: intel-hid: Add Dell 14 Plus 2-in-1 to dmi_vgbs_allow_list", " - nvme-pci: cap queue creation to used queues", " - platform/x86: intel-hid: Enable 5-button array on ThinkPad X1 Fold 16", " Gen 1", " - platform/x86: touchscreen_dmi: Add quirk for y-inverted Goodix", " touchscreen on SUPI S10", " - HID: magicmouse: fix battery reporting for Apple Magic Trackpad 2", " - net: usb: r8152: add TRENDnet TUC-ET2G", " - HID: mcp2221: cancel last I2C command on read error", " - ASoC: fsl_easrc: Fix event generation in fsl_easrc_iec958_set_reg()", " - ASoC: fsl_easrc: Fix event generation in fsl_easrc_iec958_put_bits()", " - dma-buf: Include ioctl.h in UAPI header", " - ALSA: hda/realtek: Add headset jack quirk for Thinkpad X390", " - xfrm: call xdo_dev_state_delete during state update", " - xfrm: Fix the usage of skb->sk", " - can: statistics: add missing atomic access in hot path", " - pinctrl: mediatek: common: Fix probe failure for devices without EINT", " - ionic: fix persistent MAC address override on PF", " - rtnetlink: count IFLA_INFO_SLAVE_KIND in if_nlmsg_size", " - platform/olpc: olpc-xo175-ec: Fix overflow error message to print inlen", " - net: enetc: fix the output issue of 'ethtool --show-ring'", " - dma-mapping: add missing `inline` for `dma_free_attrs`", " - netlink: introduce NLA_POLICY_MAX_BE", " - netfilter: nft_payload: reject out-of-range attributes via policy", " - netlink: hide validation union fields from kdoc", " - netlink: introduce bigendian integer types", " - netlink: allow be16 and be32 types in all uint policy checks", " - regmap: Synchronize cache for the page selector", " - RDMA/rw: Fall back to direct SGE on MR pool exhaustion", " - RDMA/irdma: Update ibqp state to error if QP is already in error state", " - RDMA/irdma: Remove a NOP wait_event() in irdma_modify_qp_roce()", " - RDMA/irdma: Clean up unnecessary dereference of event->cm_node", " - RDMA/irdma: Remove reset check from irdma_modify_qp_to_err()", " - RDMA/irdma: Return EINVAL for invalid arp index error", " - scsi: scsi_transport_sas: Fix the maximum channel scanning issue", " - x86/efi: efi_unmap_boot_services: fix calculation of ranges_to_free size", " - drm/i915/gmbus: fix spurious timeout on 512-byte burst reads", " - ASoC: Intel: catpt: Fix the device initialization", " - ACPICA: include/acpi/acpixf.h: Fix indentation", " - ACPICA: Allow address_space_handler Install and _REG execution as 2", " separate steps", " - ACPI: EC: Fix EC address space handler unregistration", " - ACPI: EC: Fix ECDT probe ordering issues", " - hwmon: (adm1177) fix sysfs ABI violation and current unit conversion", " - sysctl: fix uninitialized variable in proc_do_large_bitmap", " - ASoC: adau1372: Fix unchecked clk_prepare_enable() return value", " - ASoC: adau1372: Fix clock leak on PLL lock failure", " - s390/barrier: Make array_index_mask_nospec() __always_inline", " - cpufreq: conservative: Reset requested_freq on limits change", " - alarmtimer: Fix argument order in alarm_timer_forward()", " - scsi: ses: Handle positive SCSI error from ses_recv_diag()", " - jbd2: gracefully abort on checkpointing state corruptions", " - ext4: make recently_deleted() properly work with lazy itable", " initialization", " - phy: ti: j721e-wiz: Fix device node reference leak in", " wiz_get_lane_phy_types()", " - dmaengine: xilinx: xilinx_dma: Fix dma_device directions", " - dmaengine: xilinx: xilinx_dma: Fix residue calculation for cyclic DMA", " - dmaengine: xilinx: xilinx_dma: Fix unmasked residue subtraction", " - btrfs: fix super block offset in error message in btrfs_validate_super()", " - btrfs: fix lost error when running device stats on multiple devices fs", " - dmaengine: idxd: Remove usage of the deprecated ida_simple_xx() API", " - dmaengine: idxd: Fix freeing the allocated ida too late", " - dmaengine: xilinx_dma: Program interrupt delay timeout", " - dmaengine: xilinx_dma: Fix reset related timeout with two-channel AXIDMA", " - btrfs: don't take device_list_mutex when querying zone info", " - objtool: Fix Clang jump table detection", " - dt-bindings: auxdisplay: ht16k33: Use unevaluatedProperties to fix", " common property warning", " - tg3: Fix race for querying speed/duplex", " - net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec", " - netfilter: ipset: use nla_strcmp for IPSET_ATTR_NAME attr", " - net/mlx5: Avoid \"No data available\" when FW version queries fail", " - net: hsr: fix VLAN add unwind on slave errors", " - hwmon: (pxe1610) Check return value of page-select write in probe", " - hwmon: (tps53679) Fix device ID comparison and printing in", " tps53676_identify()", " - hwmon: (occ) Fix missing newline in occ_show_extended()", " - riscv: kgdb: fix several debug register assignment bugs", " - USB: serial: option: add MeiG Smart SRM825WN", " - MIPS: Fix the GCC version check for `__multi3' workaround", " - drm/ast: dp501: Fix initialization of SCU2C", " - USB: serial: io_edgeport: add support for Blackbox IC135A", " - USB: serial: option: add support for Rolling Wireless RW135R-GL", " - USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam", " - Input: synaptics-rmi4 - fix a locking bug in an error path", " - Input: i8042 - add TUXEDO InfinityBook Max 16 Gen10 AMD to i8042 quirk", " table", " - Input: xpad - add support for Razer Wolverine V3 Pro", " - iio: dac: ad5770r: fix error return in ad5770r_read_raw()", " - iio: light: vcnl4035: fix scan buffer on big-endian", " - iio: imu: st_lsm6dsx: Set FIFO ODR for accelerometer and gyroscope only", " - iio: gyro: mpu3050: Fix out-of-sequence free_irq()", " - usb: quirks: add DELAY_INIT quirk for another Silicon Motion flash drive", " - usb: ehci-brcm: fix sleep during atomic", " - nvmet-tcp: fix use-before-check of sg in bounds validation", " - phy: renesas: rcar-gen3-usb2: Fix role detection on unbind/bind", " - phy: renesas: rcar-gen3-usb2: Move IRQ request in probe", " - phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver", " data", " - phy: renesas: rcar-gen3-usb2: Assert PLL reset on PHY power off", " - cdc-acm: new quirk for EPSON HMD", " - thunderbolt: Fix property read in nhi_wake_supported()", " - usb: gadget: dummy_hcd: fix premature URB completion when ZLP follows", " partial transfer", " - can: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on", " usb_submit_urb() error", " - can: gs_usb: gs_usb_receive_bulk_callback(): fix error message", " - Input: uinput - take event lock when submitting FF request \"event\"", " - media: uvcvideo: Use heuristic to find stream entity", " - arm64: dts: hisilicon: poplar: Correct PCIe reset GPIO polarity", " - arm64: dts: hisilicon: hi3798cv200: Add missing dma-ranges", " - net: qualcomm: qca_uart: report the consumed byte on RX skb allocation", " failure", " - rxrpc: Fix key/keyring checks in setsockopt(RXRPC_SECURITY_KEY/KEYRING)", " - netlink: add nla be16/32 types to minlen array", " - xen/privcmd: unregister xenstore notifier on module exit", " - Revert \"mptcp: add needs_id for netlink appending addr\"", " - ext4: fix the might_sleep() warnings in kvfree()", " - dmaengine: sh: rz-dmac: Move CHCTRL updates under spinlock", " - dmaengine: sh: rz-dmac: Protect the driver specific lists", " - net: macb: Move devm_{free,request}_irq() out of spin lock area", " - x86/cpu: Enable FSGSBASE early in cpu_init_exception_handling()", " - i2c: cp2615: replace deprecated strncpy with strscpy", " - io_uring/poll: correctly handle io_poll_add() return value on update", " - Linux 5.15.203", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-71150", " - ksmbd: Fix refcount leak when invalid session is found on session lookup", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23395", " - Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31549", " - i2c: cp2615: fix serial string NULL-deref at probe", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31433", " - ksmbd: fix potencial OOB in get_file_all_info() for compound requests", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31480", " - tracing: Fix potential deadlock in cpu hotplug with osnoise", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31466", " - mm/huge_memory: fix folio isn't locked in softleaf_to_folio()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43054", " - scsi: target: tcm_loop: Drain commands in target_reset handler", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23401", " - KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO", " SPTE", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31454", " - xfs: save ailp before dropping the AIL lock in push callbacks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31446", " - ext4: fix use-after-free in update_super_work when racing with umount", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31450", " - ext4: publish jinode after initialization", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31726", " - usb: gadget: uvc: fix NULL pointer dereference during unbind race", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31728", " - usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31721", " - usb: gadget: f_hid: move list and spinlock inits from bind to alloc", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31670", " - net: rfkill: prevent unlimited numbers of rfkill events from being", " created", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31634", " - rxrpc: fix reference count leak in rxrpc_server_keyring()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31651", " - mmc: vub300: fix NULL-deref on disconnect", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31656", " - drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31658", " - net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31660", " - nfc: pn533: allocate rx skb before consuming bytes", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31661", " - wifi: brcmsmac: Fix dma_free_coherent() size", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31662", " - tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31665", " - netfilter: nft_ct: fix use-after-free in timeout object destroy", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2024-56557", " - iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2024-36898", " - gpiolib: cdev: fix uninitialised kfifo", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-40016", " - media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31667", " - Input: uinput - fix circular locking dependency with ff-core", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31671", " - xfrm_user: fix info leak in build_report()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31672", " - wifi: rt2x00usb: fix devres lifetime", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43336", " - lib/crypto: chacha: Zeroize permuted_state before it leaves scope", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31695", " - wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2024-56584", " - io_uring/tctx: work around xa_store() allocation error issue", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31720", " - usb: gadget: f_uac1_legacy: validate control request size", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43342", " - usb: gadget: f_rndis: Protect RNDIS options with mutex", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43343", " - usb: gadget: f_subset: Fix unbalanced refcnt in geth_free", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-68256", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-40103", " - smb: client: Fix refcount leak for cifs_sb_tlink", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-38006", " - net: mctp: Don't access ifa_index when missing", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-40323", " - fbcon: Set fb_display[i]->mode to NULL when the mode is released", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23031", " - can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43324", " - USB: dummy-hcd: Fix interrupt synchronization error", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43327", " - USB: dummy-hcd: Fix locking/synchronization error", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31737", " - net: ftgmac100: fix ring allocation unwind on open failure", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31738", " - vxlan: validate ND option lengths in vxlan_na_create", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31747", " - comedi: me4000: Fix potential overrun of firmware buffer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31748", " - comedi: me_daq: Fix potential overrun of firmware buffer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31749", " - comedi: ni_atmio16d: Fix invalid clean-up after failed attach", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43340", " - comedi: Reinit dev->spinlock between attachments to low-level drivers", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31751", " - comedi: dt2815: add hardware detection to prevent crash", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31752", " - bridge: br_nd_send: validate ND option lengths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31754", " - usb: cdns3: gadget: fix state inconsistency on gadget init failure", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31755", " - usb: cdns3: gadget: fix NULL pointer dereference in ep_queue", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31756", " - usb: dwc2: gadget: Fix spin_lock/unlock mismatch in", " dwc2_hsotg_udc_stop()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31758", " - usb: usbtmc: Flush anchored URBs in usbtmc_release", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31759", " - usb: ulpi: fix double free in ulpi_register_interface() error path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31761", " - iio: gyro: mpu3050: Move iio_device_register() to correct location", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31762", " - iio: gyro: mpu3050: Fix irq resource leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31763", " - iio: gyro: mpu3050: Fix incorrect free_irq() variable", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31770", " - hwmon: (occ) Fix division by zero in occ_show_power_1()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43334", " - Bluetooth: SMP: force responder MITM requirements before building the", " pairing response", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31773", " - Bluetooth: SMP: derive legacy responder STK authentication from MITM", " state", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31776", " - ALSA: ctxfi: Fix missing SPDIFI1 index handling", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31778", " - ALSA: caiaq: fix stack out-of-bounds read in init_card", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31780", " - wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31781", " - drm/ioc32: stop speculation on the drm_compat_ioctl path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43333", " - bpf: reject direct access to nullable PTR_TO_BUF pointers", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31415", " - ipv6: avoid overflows in ip6_datagram_send_ctl()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31422", " - net/sched: cls_flow: fix NULL pointer dereference on shared blocks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31421", " - net/sched: cls_fw: fix NULL pointer dereference on shared blocks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31417", " - net/x25: Fix overflow when accumulating packets", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43014", " - net: macb: properly unregister fixed rate clocks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43015", " - net: macb: fix clk handling on PCI glue driver removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31425", " - rds: ib: reject FRMR registration before IB connection is established", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43020", " - Bluetooth: MGMT: validate LTK enc_size on load", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43024", " - netfilter: nf_tables: reject immediate NF_QUEUE verdict", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31424", " - netfilter: x_tables: restrict xt_check_match/xt_check_target extensions", " for NFPROTO_ARP", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43026", " - netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43027", " - netfilter: nf_conntrack_helper: pass helper to expect cleanup", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43028", " - netfilter: x_tables: ensure names are nul-terminated", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31416", " - netfilter: nfnetlink_log: account for netlink header size", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43329", " - netfilter: flowtable: strictly check for maximum number of actions", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31680", " - net: ipv6: flowlabel: defer exclusive option free until RCU teardown", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43030", " - bpf: Fix regsafe() for pointers to packet", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43032", " - NFC: pn533: bound the UART receive buffer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43035", " - net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to", " zero to prevent an info-leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43339", " - ipv6: prevent possible UaF in addrconf_permanent_addr()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31423", " - net/sched: sch_hfsc: fix divide-by-zero in rtsc_min()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43040", " - net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX", " fields to zero to prevent an info-leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43041", " - net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory", " leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43043", " - crypto: af-alg - fix NULL pointer dereference in scatterwalk", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43046", " - btrfs: reject root items with drop_progress and zero drop_level", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43047", " - HID: multitouch: Check to ensure report responses match the request", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43050", " - atm: lec: fix use-after-free in sock_def_readable()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43051", " - HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31555", " - futex: Clear stale exiting pointer in futex_lock_pi() retry path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43065", " - ext4: always drain queued discard work in ext4_mb_release()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43066", " - ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31447", " - ext4: reject mount if bigalloc with s_first_data_block != 0", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43068", " - ext4: avoid allocate block from corrupted group in", " ext4_mb_find_by_goal()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31452", " - ext4: convert inline data to extents when truncate exceeds inline size", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31455", " - xfs: stop reclaim before pushing AIL during unmount", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31464", " - scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31467", " - erofs: add GFP_NOIO in the bio completion if needed", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31469", " - virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and", " napi_tx is false", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31473", " - media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31570", " - can: gw: fix OOB heap access in cgw_csum_crc8_rel()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31483", " - s390/syscalls: Add spectre boundary for syscall dispatch table", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31485", " - spi: spi-fsl-lpspi: fix teardown order issue (UAF)", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31565", " - RDMA/irdma: Fix deadlock during netdev reset with active connections", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31494", " - net: macb: use the current queue number for stats", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31495", " - netfilter: ctnetlink: use netlink policy range checks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31427", " - netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in", " process_sdp", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31674", " - netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31428", " - netfilter: nfnetlink_log: fix uninitialized padding leak in", " NFULA_PAYLOAD", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31497", " - Bluetooth: btusb: clamp SCO altsetting table indices", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31498", " - Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31507", " - net/smc: fix double-free of smc_spd_priv when tee() duplicates splice", " pipe buffer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31679", " - openvswitch: validate MPLS set/set_masked payload length", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31508", " - net: openvswitch: Avoid releasing netdev before teardown completes", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31509", " - nfc: nci: fix circular locking dependency in nci_close_device", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31510", " - Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43069", " - Bluetooth: hci_ll: Fix firmware leak on error path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31408", " - Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing", " sock_hold", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31512", " - Bluetooth: L2CAP: Validate PDU length before reading SDU length in", " l2cap_ecred_data_rcv()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31515", " - af_key: validate families in pfkey_send_migrate()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31518", " - esp: fix skb leak with espintcp and async crypto", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31521", " - module: Fix kernel panic when a symbol st_shndx is out of bounds", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31522", " - HID: magicmouse: avoid memory leak in magicmouse_report_fixup()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31523", " - nvme-pci: ensure we're polling a polled queue", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31524", " - HID: asus: avoid memory leak in asus_report_fixup()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31788", " - xen/privcmd: restrict usage in unprivileged domU", " - xen/privcmd: add boot control for restricted usage in domU", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31540", " - drm/i915/gt: Check set_default_submission() before deferencing", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23434", " - mtd: rawnand: serialize lock/unlock against other NAND operations", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23398", " - icmp: fix NULL pointer dereference in icmp_tag_validation()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23438", " - net: mvpp2: guard flow control update with global_tx_fc in buffer", " switching", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23397", " - nfnetlink_osf: validate individual option lengths in fingerprints", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31546", " - net: bonding: fix NULL deref in bond_debug_rlb_hash_show", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23439", " - udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23396", " - wifi: mac80211: fix NULL deref in mesh_matches_local()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23446", " - net: usb: aqc111: Do not perform PM inside suspend callback", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23452", " - PM: runtime: Fix a race condition related to device removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23454", " - net: mana: fix use-after-free in mana_hwc_destroy_channel() by", " reordering teardown", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23391", " - netfilter: xt_CT: drop pending enqueued packets on template removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43060", " - netfilter: nft_ct: drop pending enqueued packets on removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-68206", " - netfilter: nft_ct: add seqadj extension for natted connections", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23456", " - netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23457", " - netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in", " sip_help_tcp()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23458", " - netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-39764", " - netfilter: ctnetlink: remove refcounting in expectation dumpers", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23460", " - net/rose: fix NULL pointer dereference in rose_transmit_link on", " reconnect", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23462", " - Bluetooth: HIDP: Fix possible UAF", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31551", " - wifi: mac80211: Fix static_branch_dec() underflow for aql_disable.", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23463", " - soc: fsl: qbman: fix race condition in qman_destroy_fq", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31683", " - batman-adv: avoid OGM aggregation when skb tailroom is insufficient", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31550", " - pmdomain: bcm: bcm2835-power: Increase ASB control timeout", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23368", " - net: phy: register phy led_triggers during probe to avoid AB-BA deadlock", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23303", " - smb: client: Don't log plaintext credentials in cifs_set_cifscreds", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23335", " - RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23336", " - wifi: cfg80211: cancel rfkill_block work in wiphy_unregister()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23281", " - wifi: libertas: fix use-after-free in lbs_free_adapter()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-38562", " - ksmbd: fix null pointer dereference error in generate_encryptionkey", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45920", " - ext4: fix dirtyclusters double decrement on fs shutdown", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45899", " - ext4: drop extent cache when splitting extent fails", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45985", " - ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting", " I/O", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45924", " - ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23227", " - drm/exynos: vidi: use ctx->lock to protect struct vidi_context member", " variables related to memory alloc/free", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45958", " - drm/exynos: vidi: fix to avoid directly dereferencing user pointer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45956", " - drm/exynos: vidi: use priv->vidi_dev for ctx lookup in", " vidi_connection_ioctl()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23100", " - mm/hugetlb: fix hugetlb_pmd_shared()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43061", " - serial: 8250: Fix TX deadlock when using DMA", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23474", " - mtd: Avoid boot crash in RedBoot partition table parser", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31393", " - Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43062", " - Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31396", " - net: macb: fix use-after-free access to PTP clock", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31545", " - NFC: nxp-nci: allow GPIOs to sleep", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31399", " - nvdimm/bus: Fix potential use after free in asynchronous initialization", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31400", " - sunrpc: fix cache_request leak in cache_release", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2024-46715", " - driver: iio: add missing checks on iio_info's callback access", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23113", " - io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-39748", " - bpf: Forget ranges when refining tnum after JSET", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43357", " - iio: gyro: mpu3050-core: fix pm_runtime error handling", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43476", " - iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43363", " - x86/apic: Disable x2apic on resume if the kernel expects so", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43365", " - xfs: fix undersized l_iclog_roundoff values", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43370", " - drm/amdgpu: Fix use-after-free race in VM acquire", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43373", " - net: ncsi: fix skb leak in error paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43380", " - hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43381", " - nouveau/dpcd: return EBUSY for aux xfer if the device is asleep", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43382", " - batman-adv: Avoid double-rtnl_lock ELP metric worker", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31405", " - media: dvb-net: fix OOB access in ULE extension header tables", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43387", " - staging: rtl8723bs: properly validate the data in rtw_get_ie_ex()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43386", " - staging: rtl8723bs: fix potential out-of-bounds read in", " rtw_restruct_wmm_ie", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43420", " - ceph: fix i_nlink underrun during async unlink", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43405", " - libceph: Use u32 for non-negative values in ceph_monmap_decode()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43411", " - tipc: fix divide-by-zero in tipc_sk_filter_connect()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43484", " - mmc: core: Avoid bitfield RMW for claim/retune flags", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43425", " - usb: image: mdc800: kill download URB on timeout", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43426", " - usb: renesas_usbhs: fix use-after-free in ISR during device removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43427", " - usb: class: cdc-wdm: fix reordering issue in read code path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43428", " - USB: core: Limit the length of unkillable synchronous timeouts", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43429", " - USB: usbtmc: Use usb_bulk_msg_killable() with user-specified timeouts", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43430", " - usb: yurex: fix race in probe", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43432", " - usb: xhci: Fix memory leak in xhci_disable_slot()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43439", " - cgroup: fix race between task migration and iteration", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43480", " - ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock", " acquisition", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43445", " - e1000/e1000e: Fix leak in DMA error cleanup", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43449", " - nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_set", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43450", " - netfilter: nfnetlink_cthelper: fix OOB read in", " nfnl_cthelper_dump_table()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43451", " - netfilter: nfnetlink_queue: fix entry leak in bridge verdict error path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43452", " - netfilter: x_tables: guard option walkers against 1-byte tail reads", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43453", " - netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43458", " - serial: caif: hold tty->link reference in ldisc_open and ser_release", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43459", " - ASoC: soc-core: flush delayed work before removing DAIs and widgets", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23277", " - net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL", " slave xmit", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43466", " - net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43469", " - xprtrdma: Decrement re_receiving on the early exit paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-54505 // CVE-2026-31628", " - x86/CPU: Fix FPDSS on Zen1", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43472", " - unshare: fix unshare_fs() handling", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43473", " - scsi: mpi3mr: Add NULL checks when resetting request and reply queues", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43475", " - scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23270", " - net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared", " blocks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23300", " - net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23293", " - net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23381", " - net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23372", " - nfc: rawsock: cancel tx_work before socket teardown", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23339", " - nfc: nci: free skb on nci_transceive early error paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23340", " - net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless", " qdiscs", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23304", " - ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23420", " - wifi: wlcore: Fix a locking bug", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23357", " - can: mcp251x: fix deadlock in error path of mcp251x_open", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23362", " - can: bcm: fix locking for bcm_op runtime updates", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23286", " - atm: lec: fix null-ptr-deref in lec_arp_clear_vccs", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23296", " - scsi: core: Fix refcount leak for tagset_refcnt", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23356", " - drbd: fix \"LOGIC BUG\" in drbd_al_begin_io_nonblock()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23388", " - Squashfs: check metadata block offset is within range", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23379", " - net/sched: ets: fix divide by zero in the offload path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23289", " - IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23279", " - wifi: mac80211: fix NULL pointer dereference in mesh_rx_csa_frame()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23367", " - wifi: radiotap: reject radiotap with unknown bits", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23318", " - ALSA: usb-audio: Use correct version for UAC3 header validation", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23370", " - platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23352", " - x86/efi: defer freeing of boot services memory", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23382", " - HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23324", " - can: usb: etas_es58x: correctly anchor the urb in the read bulk callback", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23298", " - can: ucan: Fix infinite loop from zero-length messages", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23307", " - can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a", " message", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23290", " - net: usb: pegasus: validate USB endpoints", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23365", " - net: usb: kalmia: validate USB endpoints", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23312", " - net: usb: kaweth: validate USB endpoints", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23291", " - nfc: pn533: properly drop the usb interface reference on disconnect", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23253", " - media: dvb-core: fix wrong reinitialization of ringbuffer on reopen", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43123", " - fbcon: check return value of con2fb_acquire_newinfo()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23220", " - ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error", " paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45911", " - usb: cdns3: fix role switching during resume", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-71287", " - memory: mtk-smi: fix device leak on larb probe", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23359", " - bpf: Fix stack-out-of-bounds write in devmap", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272)", " - auxdisplay: arm-charlcd: fix release_mem_region() size", " - i3c: remove i2c board info from i2c_dev_desc", " - i3c: Move device name assignment after i3c_bus_init", " - fs: add for 'init_fs'", " - gfs2: Add metapath_dibh helper", " - btrfs: qgroup: return correct error when deleting qgroup relation item", " - md/raid10: fix any_working flag handling in raid10_sync_request", " - iomap: fix submission side handling of completion side errors", " - PM: wakeup: Handle empty list in wakeup_sources_walk_start()", " - PM: sleep: wakeirq: harden dev_pm_clear_wake_irq() against races", " - libbpf: Fix dumping big-endian bitfields", " - libbpf: Fix OOB read in btf_dump_get_bitfield_value", " - ARM: VDSO: Patch out __vdso_clock_getres() if unavailable", " - crypto: cavium - fix dma_free_coherent() size", " - crypto: octeontx - fix dma_free_coherent() size", " - hrtimer: Fix trace oddity", " - crypto: hisilicon/trng - modifying the order of header files", " - crypto: hisilicon/trng - support tfms sharing the device", " - scsi: efct: Use IRQF_ONESHOT and default primary handler", " - EDAC/altera: Remove IRQF_ONESHOT", " - mfd: wm8350-core: Use IRQF_ONESHOT", " - EDAC/i5000: Fix snprintf() size calculation in calculate_dimm_size()", " - EDAC/i5400: Fix snprintf() limit calculation in calculate_dimm_size()", " - clk: qcom: Return correct error code in qcom_cc_probe_by_index()", " - arm64: dts: qcom: sdm630: correct QFPROM byte offsets", " - arm64: dts: qcom: sdm630: fix gpu_speed_bin size", " - arm64: dts: qcom: sdm845-oneplus: Don't mark ts supply boot-on", " - ARM: dts: allwinner: sun5i-a13-utoo-p66: delete \"power-gpios\" property", " - powerpc/uaccess: Move barrier_nospec() out of", " allow_read_{from/write}_user()", " - soc: qcom: cmd-db: Use devm_memremap() to fix memory leak in", " cmd_db_dev_probe", " - ARM: dts: lpc32xx: Set motor PWM #pwm-cells property value to 3 cells", " - arm: dts: lpc32xx: add clocks property to Motor Control PWM device tree", " node", " - arm64: dts: amlogic: axg: assign the MMC signal clocks", " - arm64: dts: amlogic: gx: assign the MMC signal clocks", " - arm64: dts: amlogic: g12: assign the MMC B and C signal clocks", " - arm64: dts: amlogic: g12: assign the MMC A signal clock", " - arm64: dts: qcom: sdm845-db845c: specify power for WiFi CH1", " - smack: /smack/doi must be > 0", " - drm/amdgpu: Use explicit VCN instance 0 in SR-IOV init", " - regulator: core: move supply check earlier in set_machine_constraints()", " - media: ccs: Accommodate C-PHY into the calculation", " - media: uvcvideo: Fix allocation for small frame sizes", " - platform/chrome: cros_ec_lightbar: Fix response size initialization", " - spi: tools: Add include folder to .gitignore", " - PCI: mediatek: Fix IRQ domain leak when MSI allocation fails", " - PCI: Do not attempt to set ExtTag for VFs", " - PCI/portdrv: Fix potential resource leak", " - netfilter: nf_conncount: make nf_conncount_gc_list() to disable BH", " - PCI: Mark 3ware-9650SA Root Port Extended Tags as broken", " - tcp: tcp_tx_timestamp() must look at the rtx queue", " - wifi: ath10k: sdio: add missing lock protection in", " ath10k_sdio_fw_crashed_dump()", " - PCI: Initialize RCB from pci_configure_device()", " - ucount: check for CAP_SYS_RESOURCE using ns_capable_noaudit()", " - bonding: only set speed/duplex to unknown, if getting speed failed", " - netfilter: nft_set_hash: fix get operation on big endian", " - ethtool: add support to set/get tx copybreak buf size via ethtool", " - net: hns3: add support to set/get tx copybreak buf size via ethtool for", " hns3 driver", " - net: hns3: remove the way to set tx spare buf via module parameter", " - net: hns3: fix ethtool tx copybreak buf size indicating not aligned", " issue", " - net: hns3: add max order judgement for tx spare buffer", " - ionic: Rate limit unknown xcvr type messages", " - octeontx2-pf: Unregister devlink on probe failure", " - RDMA/rtrs: server: remove dead code", " - IB/cache: update gid cache on client reregister event", " - RDMA/hns: Notify ULP of remaining soft-WCs during reset", " - power: supply: ab8500_bmdata: Use standard phandle", " - power: supply: ab8500: Use core battery parser", " - power: reset: nvmem-reboot-mode: respect cell size for nvmem_cell_write", " - power: supply: bq27xxx: fix wrong errno when bus ops are unsupported", " - RDMA/rtrs-srv: Refactor the handling of failure case in map_cont_bufs", " - RDMA/rtrs-srv: Correct the checking of ib_map_mr_sg", " - RDMA/rtrs-srv: fix SG mapping", " - mtd: rawnand: cadence: Fix return type of CDMA send-and-wait helper", " - crypto: ccp - Add an S4 restore flow", " - RDMA/core: Fix a couple of obvious typos in comments", " - svcrdma: Remove queue-shortening warnings", " - svcrdma: Clean up comment in svc_rdma_accept()", " - svcrdma: Increase the per-transport rw_ctx count", " - svcrdma: Reduce the number of rdma_rw contexts per-QP", " - RDMA/core: add rdma_rw_max_sge() helper for SQ sizing", " - mtd: parsers: ofpart: fix OF node refcount leak in", " parse_fixed_partitions()", " - RDMA/uverbs: Add __GFP_NOWARN to ib_uverbs_unmarshall_recv() kmalloc", " - pNFS: fix a missing wake up while waiting on NFS_LAYOUT_DRAIN", " - nvdimm: virtio_pmem: serialize flush requests", " - tracing: Remove duplicate ENABLE_EVENT_STR and DISABLE_EVENT_STR macros", " - clk: qcom: rcg2: compute 2d using duty fraction directly", " - clk: meson: gxbb: Limit the HDMI PLL OD to /4 on GXL/GXM SoCs", " - clk: qcom: gcc-msm8953: Remove ALWAYS_ON flag from cpp_gdsc", " - clk: Move clk_{save,restore}_context() to COMMON_CLK section", " - clk: qcom: dispcc-sdm845: Enable parents for pixel clocks", " - dmaengine: mediatek: uart-apdma: Fix above 4G addressing TX/RX", " - dma: dma-axi-dmac: fix SW cyclic transfers", " - serial: imx: change SERIAL_IMX_CONSOLE to bool", " - serial: SH_SCI: improve \"DMA support\" prompt", " - mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms", " - coresight: etm3x: Fix cpulocked warning on cpuhp", " - Revert \"mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms\"", " - drivers: iio: mpu3050: use dev_err_probe for regulator request", " - usb: bdc: fix sleep during atomic", " - pinctrl: equilibrium: Fix device node reference leak in pinbank_init()", " - ovl: Fix uninit-value in ovl_fill_real", " - pinctrl: qcom: Update macro name to LPI specific", " - pinctrl: qcom: Update lpi pin group custiom functions with framework", " generic functions", " - pinctrl: qcom: Extract chip specific LPASS LPI code", " - [Config] Enable CONFIG_PINCTRL_SM8250_LPASS_LPI=m", " - pinctrl: qcom: sm8250-lpass-lpi: Fix i2s2_data_groups definition", " - backlight: qcom-wled: Support ovp values for PMI8994", " - ACPI: CPPC: Fix remaining for_each_possible_cpu() to use online CPUs", " - selftests: mlxsw: tc_restrictions: Fix test failure with new iproute2", " - net/rds: rds_sendmsg should not discard payload_len", " - selftests: forwarding: vxlan_bridge_1d: fix test failure with", " br_netfilter enabled", " - netfilter: nf_conntrack_h323: don't pass uninitialised l3num value", " - ipv6: fix a race in ip6_sock_set_v6only()", " - bpftool: Fix truncated netlink dumps", " - octeontx2-af: Fix default entries mcam entry action", " - apparmor: fix rlimit for posix cpu timers", " - drm/i915/acpi: free _DSM package when no connectors", " - ext4: use optimized mballoc scanning regardless of inode format", " - ata: pata_ftide010: Fix some DMA timings", " - perf callchain: Fix srcline printing with inlines", " - libperf: Don't remove -g when EXTRA_CFLAGS are used", " - libperf build: Always place libperf includes first", " - rtc: interface: Alarm race handling should not discard preceding error", " - hfsplus: fix volume corruption issue for generic/498", " - i3c: master: svc: Initialize 'dev' to NULL in svc_i3c_master_ibi_isr()", " - tools/power cpupower: Reset errno before strtoull()", " - s390/purgatory: Add -Wno-default-const-init-unsafe to KBUILD_CFLAGS", " - x86/xen/pvh: Enable PAE mode for 32-bit guest only when CONFIG_X86_PAE", " is set", " - ACPICA: Abort AML bytecode execution when executing AML_FATAL_OP", " - s390/perf: Disable register readout on sampling events", " - xenbus: Use .freeze/.thaw to handle xenbus devices", " - blk-mq-debugfs: add missing debugfs_mutex in", " blk_mq_debugfs_register_hctxs()", " - sparc: Synchronize user stack on fork and clone", " - sparc: don't reference obsolete termio struct for TC* constants", " - bpf: verifier improvement in 32bit shift sign extension pattern", " - clocksource/drivers/timer-integrator-ap: Add missing Kconfig dependency", " on OF", " - mailbox: bcm-ferxrm-mailbox: Use default primary handler", " - char: tpm: cr50: Remove IRQF_ONESHOT", " - arm64: tegra: smaug: Add usb-role-switch support", " - parisc: Prevent interrupts during reboot", " - media: dvb-core: dmxdevfilter must always flush bufs", " - spi: stm32: fix Overrun issue at < 8bpw", " - media: omap3isp: isp_video_mbus_to_pix/pix_to_mbus fixes", " - media: omap3isp: isppreview: always clamp in preview_try_format()", " - media: omap3isp: set initial format", " - ASoC: wm8962: Add WM8962_ADC_MONOMIX to \"3D Coefficients\" mask", " - ASoC: wm8962: Don't report a microphone if it's shorted to ground on", " plug", " - media: adv7180: fix frame interval in progressive mode", " - drm/amdkfd: Fix GART PTE for non-4K pagesize in svm_migrate_gart_map()", " - hyper-v: Mark inner union in hv_kvp_exchg_msg_value as packed", " - virt: vbox: uapi: Mark inner unions in packed structs as packed", " - drm/atmel-hlcdc: don't reject the commit if the src rect has fractional", " parts", " - HID: multitouch: add eGalaxTouch EXC3188 support", " - HID: elecom: Add support for ELECOM HUGE Plus M-HT1MRBK", " - gpio: aspeed-sgpio: Change the macro to support deferred probe", " - spi: spi-mem: Protect dirmap_create() with spi_mem_access_start/end", " - ASoC: es8328: Add error unwind in resume", " - modpost: Amend ppc64 save/restfpr symnames for -Os build", " - ALSA: usb-audio: Add iface reset and delay quirk for AB13X USB Audio", " - jfs: Add missing set_freezable() for freezable kthread", " - iommu/arm-smmu-v3: Improve CMDQ lock fairness and efficiency", " - ipv6: annotate data-races in ip6_multipath_hash_{policy,fields}()", " - ipv6: exthdrs: annotate data-race over multiple sysctl", " - ext4: mark group add fast-commit ineligible", " - ext4: mark group extend fast-commit ineligible", " - netfilter: nf_conntrack: Add allow_clash to generic protocol handler", " - openrisc: define arch-specific version of nop()", " - net: usb: r8152: fix transmit queue timeout", " - net: hns3: extend HCLGE_FD_AD_QID to 11 bits", " - wifi: iwlegacy: add missing mutex protection in il4965_store_tx_power()", " - wifi: iwlegacy: add missing mutex protection in", " il3945_store_measurement()", " - ipv4: fib: Annotate access to struct fib_alias.fa_state.", " - Bluetooth: hci_conn: use mod_delayed_work for active mode timeout", " - Bluetooth: btusb: Add device ID for Realtek RTL8761BU", " - wifi: ath10k: fix lock protection in", " ath10k_wmi_event_peer_sta_ps_state_chg()", " - net: usb: sr9700: remove code to drive nonexistent multicast filter", " - vmw_vsock: bypass false-positive Wnonnull warning with gcc-16", " - PCI: Mark ASM1164 SATA controller to avoid bus reset", " - PCI/AER: Clear stale errors on reporting agents upon probe", " - PCI: Fix pci_slot_lock () device locking", " - PCI: Add ACS quirk for Qualcomm Hamoa & Glymur", " - PCI: Mark Nvidia GB10 to avoid bus reset", " - myri10ge: avoid uninitialized variable use", " - nfc: nxp-nci: remove interrupt trigger type", " - RDMA/rtrs-clt: For conn rejection use actual err number", " - scsi: buslogic: Reduce stack usage", " - tracing: Fix false sharing in hwlat get_sample()", " - mailbox: sprd: mask interrupts that are not handled", " - remoteproc: mediatek: Break lock dependency to `prepare_lock`", " - mailbox: sprd: clear delivery flag before handling TX done", " - clk: microchip: core: correct return value on *_get_parent()", " - m68k: nommu: fix memmove() with differently aligned src and dest for", " 68000", " - staging: rtl8723bs: fix missing status update on sdio_alloc_irq()", " failure", " - serial: 8250_dw: handle clock enable errors in runtime_resume", " - misc: eeprom: Fix EWEN/EWDS/ERAL commands for 93xx56 and 93xx66", " - serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA", " termination is done", " - fix it87_wdt early reboot by reporting running timer", " - binder: don't use %pK through printk", " - phy: mvebu-cp110-utmi: fix dr_mode property read from dts", " - phy: fsl-imx8mq-usb: disable bind/unbind platform driver feature", " - Revert \"mfd: da9052-spi: Change read-mask to write-mask\"", " - iio: Use IRQF_NO_THREAD", " - iio: magnetometer: Remove IRQF_ONESHOT", " - MIPS: Loongson: Make cpumask_of_node() robust against NUMA_NO_NODE", " - fs/ntfs3: avoid calling run_get_entry() when run == NULL in", " ntfs_read_run_nb_ra()", " - include: uapi: netfilter_bridge.h: Cover for musl libc", " - ARM: 9467/1: mm: Don't use %pK through printk", " - drm/amd/display: Avoid updating surface with the same surface under MPO", " - drm/amdgpu: Adjust usleep_range in fence wait", " - ALSA: usb-audio: Update the number of packets properly at receiving", " - drm/amdgpu: Add HAINAN clock adjustment", " - drm/radeon: Add HAINAN clock adjustment", " - btrfs: replace BUG() with error handling in __btrfs_balance()", " - lan78xx: Fix memory allocation bug", " - net: usb: lan78xx: scan all MDIO addresses on LAN7801", " - wifi: cfg80211: wext: fix IGTK key ID off-by-one", " - Bluetooth: L2CAP: Fix invalid response to L2CAP_ECRED_RECONF_REQ", " - Bluetooth: hci_qca: Cleanup on all setup failures", " - Bluetooth: L2CAP: Fix response to L2CAP_ECRED_CONN_REQ", " - tipc: fix duplicate publication key in tipc_service_insert_publ()", " - RDMA/core: Fix stale RoCE GIDs during netdev events at registration", " - RDMA/efa: Fix typo in efa_alloc_mr()", " - fpga: dfl: use subsys_initcall to allow built-in drivers to be added", " - arm64: Disable branch profiling for all arm64 code", " - media: cx25821: Add missing unmap in snd_cx25821_hw_params()", " - media: i2c: ov5647: Correct pixel array offset", " - media: i2c: ov5647: Correct minimum VBLANK value", " - media: i2c: ov5647: Sensor should report RAW color space", " - media: i2c: ov5647: Fix PIXEL_RATE value for VGA mode", " - media: i2c: ov5647: use our own mutex for the ctrl lock", " - dm-integrity: fix a typo in the code for write/discard race", " - clk: tegra: tegra124-emc: Fix potential memory leak in", " tegra124_clk_register_emc()", " - s390/pci: Handle futile config accesses of disabled devices directly", " - dm-unstripe: fix mapping bug when there are multiple targets in a table", " - arm64: dts: rockchip: Do not enable hdmi_sound node on Pinebook Pro", " - media: venus: vdec: fix error state assignment for zero bytesused", " - drm: of: drm_of_panel_bridge_remove(): fix device_node leak", " - mm, page_alloc, thp: prevent reclaim for __GFP_THISNODE THP allocations", " - selftests/mm/charge_reserved_hugetlb: drop mount size for hugetlbfs", " - xfs: mark data structures corrupt on EIO and ENODATA", " - xfs: fix remote xattr valuelblk check", " - nfsd: fix return error code for nfsd_map_name_to_[ug]id", " - usb: gadget: tegra-xudc: Add handling for BLCG_COREPLL_PWRDN", " - bus: fsl-mc: fix an error handling in fsl_mc_device_add()", " - dm mpath: make pg_init_delay_msecs settable", " - iio: gyro: itg3200: Fix unchecked return value in read_raw", " - PCI/IOV: Fix race between SR-IOV enable/disable and hotplug", " - arm64: Fix non-atomic __READ_ONCE() with CONFIG_LTO=y", " - btrfs: continue trimming remaining devices on failure", " - usb: dwc2: fix resume failure if dr_mode is host", " - mtd: rawnand: pl353: Fix software ECC support", " - tipc: fix RCU dereference race in tipc_aead_users_dec()", " - net: cpsw_new: Fix unnecessary netdev unregistration in cpsw_probe()", " error path", " - parisc: kernel: replace kfree() with put_device() in create_tree_node()", " - MIPS: rb532: Fix MMIO UART resource registration", " - net: ethernet: marvell: skge: remove incorrect conflicting PCI ID", " - tracing: Fix to set write permission to per-cpu buffer_size_kb", " - net: intel: fix PCI device ID conflict between i40e and ipw2200", " - fbdev: ffb: fix corrupted video output on Sun FFB1", " - drm/amdgpu: keep vga memory on MacBooks with switchable graphics", " - NTB: ntb_transport: Fix too small buffer for debugfs_name", " - Linux 5.15.202", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43291", " - net: nfc: nci: Fix parameter validation for packet data", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43283", " - net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43264", " - fbdev: of: display_timing: fix refcount leak in of_get_display_timings()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43202", " - fbdev: vt8500lcdfb: fix missing dma_free_coherent()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43203", " - atm: fore200e: fix use-after-free in tasklets during device removal", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43149", " - net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43273", " - ceph: supply snapshot context in ceph_zero_partial_object()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43159", " - staging: rtl8723bs: fix null dereference in find_network", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43211", " - PCI: Fix pci_slot_trylock() error handling", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43206", " - drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43275", " - scsi: ufs: core: Flush exception handling work when RPM level is zero", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43145", " - remoteproc: imx_rproc: Fix invalid loaded resource table detection", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43147", " - Revert \"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling", " SR-IOV\"", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43289", " - kexec: derive purgatory entry from symbol", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43168", " - ocfs2: fix reflink preserve cleanup issue", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43295", " - rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43148", " - powerpc/smp: Add check for kcalloc() failure in parse_thread_groups()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43163", " - md/bitmap: fix GPF in write_page caused by resize race", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43200", " - PCI: endpoint: Fix swapped parameters in", " pci_{primary/secondary}_epc_epf_unlink() functions", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43158", " - xfs: fix freemap adjustments when adding xattrs to leaf blocks", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43187", " - xfs: delete attr leaf freemap entries when empty", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43130", " - iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in", " scalable mode", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43133", " - KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43196", " - soc: ti: pruss: Fix double free in pruss_clk_mux_setup()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43242", " - soc: ti: k3-socinfo: Fix regmap leak on probe failure", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43278", " - dm: clear cloned request bio pointer when last clone bio completes", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43312", " - media: i2c: ov5647: Initialize subdev before controls", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43182", " - media: ccs: Avoid possible division by zero", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43246", " - media: i2c/tw9906: Fix potential memory leak in tw9906_probe()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43218", " - media: i2c/tw9903: Fix potential memory leak in tw9903_probe()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43135", " - media: cx23885: Add missing unmap in snd_cx23885_hw_params()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43257", " - media: cx88: Add missing unmap in snd_cx88_hw_params()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43231", " - media: radio-keene: fix memory leak in error path", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43136", " - HID: logitech-hidpp: Check maxfield in hidpp_get_report_length()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43251", " - HID: prodikeys: Check presence of pm->input_ep82", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43140", " - HID: magicmouse: Do not crash on missing msc->input", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43152", " - HID: hid-pl: handle probe errors", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43315", " - KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3()", " succeeding", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43270", " - media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43207", " - media: mtk-mdp: Fix error handling in probe function", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43132", " - dm-verity: correctly handle dm_bufio_client_create() failure", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71274", " - rpmsg: core: fix race in driver_override_show() and use core helper", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43233", " - netfilter: nf_conntrack_h323: fix OOB read in decode_choice()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43205", " - dpaa2-switch: validate num_ifs to prevent out-of-bounds write", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43194", " - net: consume xmit errors of GSO frames", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43156", " - net: usb: pegasus: enable basic endpoint checking", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43232", " - net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43134", " - Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43180", " - net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43139", " - xfrm6: fix uninitialized saddr in xfrm6_get_saddr()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43141", " - ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43241", " - ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43279", " - ALSA: usb-audio: Add sanity check for OOB writes at silencing", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71267", " - fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71265", " - fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent", " metadata", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71266", " - fs: ntfs3: check return value of indx_find to avoid infinite loop", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43225", " - staging: rtl8723bs: fix memory leak on failure path", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43230", " - net/rds: Clear reconnect pending bit", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43296", " - octeontx2-af: Workaround SQM/PSE stalls by disabling sticky", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43226", " - net/rds: No shortcut out of RDS_CONN_ERROR", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43190", " - netfilter: xt_tcpmss: check remaining length before reading optlen", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43255", " - wifi: libertas: fix WARNING in usb_tx_block", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43314", " - dm: remove fake timeout to avoid leak request", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71292", " - jfs: nlink overflow in jfs_rename", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43236", " - drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43269", " - drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43287", " - drm: Account property blob allocations to memcg", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43183", " - media: cx25821: Fix a resource leak in cx25821_dev_setup()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43316", " - media: solo6x10: Check for out of bounds chip_id", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43223", " - media: pvrusb2: fix URB leak in pvr2_send_request_ex", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43302", " - drm/v3d: Set DMA segment size to avoid debug warnings", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43124", " - pstore: ram_core: fix incorrect success return when vmap() fails", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43227", " - clocksource/drivers/sh_tmu: Always leave device running after probe", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43313", " - ACPI: processor: Fix NULL-pointer dereference in", " acpi_processor_errata_piix4()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43266", " - EFI/CPER: don't go past the ARM processor CPER record buffer", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43277", " - APEI/GHES: ensure that won't go past CPER allocated record", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43171", " - EFI/CPER: don't dump the entire memory region", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43184", " - rnbd-srv: Zero the rsp buffer before using it", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43261", " - arm64: Add support for TSV110 Spectre-BHB mitigation", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43262", " - gfs2: fiemap page fault fix", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43209", " - minix: Add required sanity checking to minix_check_superblock()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43268", " - hfsplus: pretend special inodes as regular files", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-23241", " - audit: add missing syscalls to read class", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71239", " - audit: add fchmodat2() to change attributes class", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45964", " - SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45870", " - SUNRPC: auth_gss: fix memory leaks in XDR decoding error paths", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45948", " - ext4: fix memory leak in ext4_ext_shift_extents()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45912", " - ext4: don't cache extent during splitting extent", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46250", " - MIPS: Work around LLVM bug when gp is used as global register variable", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45974", " - btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not", " found", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45965", " - apparmor: fix invalid deref of rawdata when export_binary is unset", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45848", " - apparmor: fix NULL sock in aa_sock_file_perm", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45970", " - bonding: alb: fix UAF in rlb_arp_recv during bond up/down", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45847", " - net: remove WARN_ON_ONCE when accessing forward path array", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45890", " - xen-netback: reject zero-queue configuration from guest", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45968", " - cpuidle: Skip governor when only one idle state is available", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45935", " - fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45864", " - fs/ntfs3: prevent infinite loops caused by the next valid being the same", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45868", " - pinctrl: single: fix refcount leak in pcs_add_gpio_func()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45883", " - iio: sca3000: Fix a resource leak in sca3000_probe()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45875", " - mfd: arizona: Fix regulator resource leak on", " wm5102_clear_write_sequencer() failure", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45978", " - staging: greybus: lights: avoid NULL deref", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45954", " - fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45857", " - scsi: csiostor: Fix dereference of null pointer rn", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45856", " - RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45852", " - RDMA/rxe: Fix double free in rxe_srq_from_init", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45869", " - power: supply: wm97xx: Fix NULL pointer dereference in", " power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45916", " - power: supply: sbs-battery: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46270", " - power: supply: rt9455: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45936", " - power: supply: goldfish: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45885", " - power: supply: cpcap-battery: Fix use-after-free in", " power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45879", " - power: supply: bq25980: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45902", " - power: supply: bq256xx: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45867", " - power: supply: act8945a: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45946", " - power: supply: ab8500: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45866", " - serial: caif: fix use-after-free in caif_serial ldisc_close()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-31411", " - net: atm: fix crash due to unvalidated vcc pointer in sigd_send()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46259", " - procfs: fix missing RCU protection when reading real_parent in", " do_task_stat()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45891", " - net: hns3: fix double free issue for tx spare buffer", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45873", " - netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46267", " - nfc: hci: shdlc: Stop timers and work before freeing context", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46249", " - octeontx2-af: Fix PF driver crash with kexec kernel booting", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45915", " - fat: avoid parent link count underflow in rmdir", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45983", " - nfsd: never defer requests during idmap lookup", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45862", " - iommu/vt-d: Flush cache for PASID table before using it", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45860", " - netfilter: nf_conncount: increase the connection clean up limit to 64", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45969", " - HID: playstation: Add missing check for input_ff_create_memless", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71304", " - smack: /smack/doi: accept previously used values", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45904", " - powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event", " handling", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46253", " - pstore/ram: fix buffer overflow in persistent_ram_save_old()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45919", " - sched/rt: Skip currently executing CPU in rto_next_cpu()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45871", " - tpm: st33zp24: Fix missing cleanup on get_burstcount() error", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45941", " - tpm: tpm_i2c_infineon: Fix locality leak on get_burstcount() failure", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45984", " - gfs2: Fix use-after-free in iomap inline data write path", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45960", " - hfsplus: return error when node already exists in hfs_bnode_create", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-23243", " - RDMA/umad: Reject negative data_len in ib_umad_write", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-23242", " - RDMA/siw: Fix potential NULL pointer dereference in header processing", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198)", " - crypto: octeontx - Fix length check to avoid truncation in", " ucode_load_store", " - scsi: qla2xxx: Query FW again before proceeding with login", " - ALSA: hda/realtek: Fix headset mic for TongFang X6AR55xU", " - gpio: sprd: Change sprd_gpio lock to raw_spin_lock", " - drm/tegra: hdmi: sor: Fix error: variable ‘j’ set but not used", " - platform/x86: panasonic-laptop: Fix sysfs group leak in error path", " - gpiolib: acpi: Fix gpio count with string references", " - Revert \"wireguard: device: enable threaded NAPI\"", " - selftests: mptcp: pm: ensure unknown flags are ignored", " - crypto: virtio - Remove duplicated virtqueue_kick in", " virtio_crypto_skcipher_crypt_req", " - bus: fsl-mc: Replace snprintf and sprintf with sysfs_emit in sysfs show", " functions", " - scsi: qla2xxx: Use named initializers for port_[d]state_str", " - scsi: qla2xxx: Remove dead code (GNN ID)", " - scsi: qla2xxx: Reduce fabric scan duplicate code", " - PCI: endpoint: Automatically create a function specific attributes group", " - PCI: endpoint: Remove unused field in struct pci_epf_group", " - USB: serial: option: add Telit FN920C04 RNDIS compositions", " - Linux 5.15.201", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23235", " - f2fs: fix out-of-bounds access in sysfs attribute read/write", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23234", " - f2fs: fix to avoid UAF in f2fs_write_end_io()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23236", " - fbdev: smscufx: properly copy ioctl memory to kernelspace", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23266", " - fbdev: rivafb: fix divide error in nv3_arb()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71233", " - PCI: endpoint: Avoid creating sub-groups asynchronously", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71232", " - scsi: qla2xxx: Free sp in error path to fix system crash", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71238", " - scsi: qla2xxx: Fix bsg_done() causing double free", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23221", " - bus: fsl-mc: fix use-after-free in driver_override_show()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23228", " - smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23169", " - mptcp: fix race in mptcp_pm_nl_flush_addrs_doit()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-37786", " - net: dsa: free routing table on probe failure", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23237", " - platform/x86: classmate-laptop: Add missing NULL pointer checks", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23238", " - romfs: check sb_set_blocksize() return value", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-31687", " - gpio: omap: do not register driver in probe()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71235", " - scsi: qla2xxx: Delay module unload while fabric scan in progress", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71236", " - scsi: qla2xxx: Validate sp before freeing associated memory", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71237", " - nilfs2: Fix potential block overflow that cause system hang", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23229", " - crypto: virtio - Add spinlock protection with virtqueue notification", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23222", " - crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly", " * CVE-2026-23392", " - netfilter: nf_tables: register hooks last when adding new", " chain/flowtable", " - netfilter: nf_tables: release flowtable after rcu grace period on error", " * CVE-2026-45988", " - rxrpc: Fix re-decryption of RESPONSE packets", " * CVE-2026-46195", " - smb: client: validate dacloffset before building DACL pointers", " * CVE-2026-46135", " - nvmet-tcp: fix race between ICReq handling and queue teardown", " * CVE-2026-31402", " - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache", " * CVE-2026-43071", " - dcache: Limit the minimal number of bucket to two", " * CVE-2026-46119", " - libceph: Fix slab-out-of-bounds access in auth message processing", " * CVE-2026-43501", " - ipv6: rpl: reserve mac_len headroom when recompressed SRH grows", " * CVE-2026-46043", " - RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv", " * CVE-2026-43493", " - crypto: pcrypt - Fix handling of MAY_BACKLOG requests", " * CVE-2026-31637", " - rxrpc: reject undecryptable rxkad response tickets", " * CVE-2026-31657", " - batman-adv: hold claim backbone gateways by reference", " * CVE-2026-31685", " - netfilter: ip6t_eui64: reject invalid MAC header for all packets", " * CVE-2026-43117", " - btrfs: tracepoints: get correct superblock from dentry in event", " btrfs_sync_file()", " * CVE-2026-43114", " - netfilter: nft_set_pipapo_avx2: don't return non-matching entry on", " expiry", " * CVE-2026-31478", " - ksmbd: replace hardcoded hdr2_len with offsetof() in", " smb2_calc_max_out_buf_len()", " * CVE-2026-31668", " - seg6: separate dst_cache for input and output paths in seg6 lwtunnel", " * CVE-2026-31659", " - batman-adv: reject oversized global TT response buffers", " * CVE-2026-31649", " - net: stmmac: fix integer underflow in chain mode", " * CVE-2026-31669", " - mptcp: fix slab-use-after-free in __inet_lookup_established", " * CVE-2026-43011", " - net/x25: Fix potential double free of skb", " * CVE-2026-43037", " - ip6_tunnel: clear skb2->cb[] in ip4ip6_err()", " * CVE-2026-43038", " - ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()", " * CVE-2026-31682", " - bridge: br_nd_send: linearize skb before parsing ND options", " * CVE-2026-23450", " - net/smc: Only save the original clcsock callback functions", " - net/smc: Fix slab-out-of-bounds issue in fallback", " - net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()", " * CVE-2026-23428", " - ksmbd: fix use-after-free of share_conf in compound request", " * CVE-2026-23455", " - netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()", " * CVE-2026-43186", " - ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()", " * CVE-2026-43185", " - ksmbd: fix signededness bug in smb_direct_prepare_negotiation()", " * CVE-2026-43341", " - net/ipv6: ioam6: prevent schema length wraparound in trace fill", " * CVE-2026-31607", " - usbip: validate number_of_packets in usbip_pack_ret_submit()", " * CVE-2026-43383", " - net/tcp-md5: Fix MAC comparison to be constant-time", " * CVE-2025-68263", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " * CVE-2026-46243", " - smb: client: reject userspace cifs.spnego descriptions", " * CVE-2026-43414", " - scsi: qla2xxx: Completely fix fcport double free", " * CVE-2026-43407", " - libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply()", " * CVE-2026-43406", " - libceph: prevent potential out-of-bounds reads in", " process_message_header()", " * CVE-2026-43304", " - libceph: define and enforce CEPH_MAX_KEY_LEN", " * CVE-2025-37924", " - ksmbd: fix use-after-free in kerberos authentication", " * CVE-2025-37778", " - ksmbd: Fix dangling pointer in krb_authenticate", "" ], "package": "linux-kvm", "version": "5.15.0-1104.109", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2157390, 1786013, 2157405, 2154194, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156629, 2156629, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198 ], "author": "Hannah Peuckmann ", "date": "Tue, 30 Jun 2026 09:18:47 +0200" } ], "notes": "linux-headers-5.15.0-1104-kvm version '5.15.0-1104.109' (source package linux-kvm version '5.15.0-1104.109') was added. linux-headers-5.15.0-1104-kvm version '5.15.0-1104.109' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1103-kvm. As such we can use the source package version of the removed package, '5.15.0-1103.108', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-image-5.15.0-1104-kvm", "from_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1103.108", "version": null }, "to_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1104.109", "version": "5.15.0-1104.109" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 5.15.0-1104.109", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed-kvm", "version": "5.15.0-1104.109", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Hannah Peuckmann ", "date": "Tue, 30 Jun 2026 09:21:14 +0200" } ], "notes": "linux-image-5.15.0-1104-kvm version '5.15.0-1104.109' (source package linux-signed-kvm version '5.15.0-1104.109') was added. linux-image-5.15.0-1104-kvm version '5.15.0-1104.109' has the same source package name, linux-signed-kvm, as removed package linux-image-5.15.0-1103-kvm. As such we can use the source package version of the removed package, '5.15.0-1103.108', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-kvm-headers-5.15.0-1104", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1103.108", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1104.109", "version": "5.15.0-1104.109" }, "cves": [ { "cve": "CVE-2026-46137", "url": "https://ubuntu.com/security/CVE-2026-46137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: fix potential data-race This mptcp_pm_add_timer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bh_lock_sock(). If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46275", "url": "https://ubuntu.com/security/CVE-2026-46275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart. The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the `hu` struct. When the scheduled work executes later, it blindly dereferences the freed `hu` struct. Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently. Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities.", "cve_priority": "high", "cve_public_date": "2026-06-08 16:16:00 UTC" }, { "cve": "CVE-2025-23141", "url": "https://ubuntu.com/security/CVE-2025-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where \"accepting\" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit can access guest memory. The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triple_fault_event_test selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario. ============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted ----------------------------- include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2026-43052", "url": "https://ubuntu.com/security/CVE-2026-43052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check tdls flag in ieee80211_tdls_oper When NL80211_TDLS_ENABLE_LINK is called, the code only checks if the station exists but not whether it is actually a TDLS station. This allows the operation to proceed for non-TDLS stations, causing unintended side effects like modifying channel context and HT protection before failing. Add a check for sta->sta.tdls early in the ENABLE_LINK case, before any side effects occur, to ensure the operation is only allowed for actual TDLS peers.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2025-22107", "url": "https://ubuntu.com/security/CVE-2025-22107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry() There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-21863", "url": "https://ubuntu.com/security/CVE-2025-21863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: prevent opcode speculation sqe->opcode is used for different tables, make sure we santitise it against speculations.", "cve_priority": "low", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2026-46274", "url": "https://ubuntu.com/security/CVE-2026-46274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io-wq: check that the predecessor is hashed in io_wq_remove_pending() io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0]. Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory. Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot.", "cve_priority": "high", "cve_public_date": "2026-06-08 16:16:00 UTC" }, { "cve": "CVE-2026-45846", "url": "https://ubuntu.com/security/CVE-2026-45846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst() bareudp_fill_metadata_dst() passes bareudp->sock to udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check. The socket is only created in bareudp_open() and NULLed in bareudp_stop(), so calling this function while the device is down triggers a NULL dereference via sock->sk. BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160) Call Trace: bareudp_fill_metadata_dst (drivers/net/bareudp.c:532) do_execute_actions (net/openvswitch/actions.c:901) ovs_execute_actions (net/openvswitch/actions.c:1589) ovs_packet_cmd_execute (net/openvswitch/datapath.c:700) genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1209) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths in the same driver.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45844", "url": "https://ubuntu.com/security/CVE-2026-45844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: arp_tables: fix IEEE1394 ARP payload parsing Weiming Shi says: \"arp_packet_match() unconditionally parses the ARP payload assuming two hardware addresses are present (source and target). However, IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address field, and arp_hdr_len() already accounts for this by returning a shorter length for ARPHRD_IEEE1394 devices. As a result, on IEEE1394 interfaces arp_packet_match() advances past a nonexistent target hardware address and reads the wrong bytes for both the target device address comparison and the target IP address. This causes arptables rules to match against garbage data, leading to incorrect filtering decisions: packets that should be accepted may be dropped and vice versa. The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already handles this correctly by skipping the target hardware address for ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match().\" Mangle the original patch to always return 0 (no match) in case user matches on the target hardware address which is never present in IEEE1394. Note that this returns 0 (no match) for either normal and inverse match because matching in the target hardware address in ARPHRD_IEEE1394 has never been supported by arptables. This is intentional, matching on the target hardware address should never evaluate true for ARPHRD_IEEE1394. Moreover, adjust arpt_mangle to drop the packet too as AI suggests: In arpt_mangle, the logic assumes a standard ARP layout. Because IEEE1394 (FireWire) omits the target hardware address, the linear pointer arithmetic miscalculates the offset for the target IP address. This causes mangling operations to write to the wrong location, leading to packet corruption. To ensure safety, this patch drops packets (NF_DROP) when mangling is requested for these fields on IEEE1394 devices, as the current implementation cannot correctly map the FireWire ARP payload. This omits both mangling target hardware and IP address. Even if IP address mangling should be possible in IEEE1394, this would require to adjust arpt_mangle offset calculation, which has never been supported. Based on patch from Weiming Shi .", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45843", "url": "https://ubuntu.com/security/CVE-2026-45843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: bound decode() reads against the compressed packet length slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code. A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets. Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45842", "url": "https://ubuntu.com/security/CVE-2026-45842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: reject VJ receive packets on instances with no rstate array slhc_init() accepts rslots == 0 as a valid configuration, with the documented meaning of 'no receive compression'. In that case the allocation loop in slhc_init() is skipped, so comp->rstate stays NULL and comp->rslot_limit stays 0 (from the kzalloc of struct slcompress). The receive helpers do not defend against that configuration. slhc_uncompress() dereferences comp->rstate[x] when the VJ header carries an explicit connection ID, and slhc_remember() later assigns cs = &comp->rstate[...] after only comparing the packet's slot number to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the range check, and the code dereferences a NULL rstate. The configuration is reachable in-tree through PPP. PPPIOCSMAXCID stores its argument in a signed int, and (val >> 16) uses arithmetic shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1 is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because /dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path is reachable from an unprivileged user namespace. Once the malformed VJ state is installed, any inbound VJ-compressed or VJ-uncompressed frame that selects slot 0 crashes the kernel in softirq context: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519) Call Trace: ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466) ppp_input (drivers/net/ppp/ppp_generic.c:2359) ppp_async_process (drivers/net/ppp/ppp_async.c:492) tasklet_action_common (kernel/softirq.c:926) handle_softirqs (kernel/softirq.c:623) run_ksoftirqd (kernel/softirq.c:1055) smpboot_thread_fn (kernel/smpboot.c:160) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) Reject the receive side on such instances instead of touching rstate. slhc_uncompress() falls through to its existing 'bad' label, which bumps sls_i_error and enters the toss state. slhc_remember() mirrors that with an explicit sls_i_error increment followed by slhc_toss(); the sls_i_runt counter is not used here because a missing rstate is an internal configuration state, not a runt packet. The transmit path is unaffected: the only in-tree caller that picks rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and slip.c always calls slhc_init(16, 16), so comp->tstate remains valid and slhc_compress() continues to work.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45841", "url": "https://ubuntu.com/security/CVE-2026-45841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO nf_osf_match_one() computes ctx->window % f->wss.val in the OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a subsequent matching TCP SYN divides by zero and panics the kernel. Reject the bogus fingerprint in nfnl_osf_add_callback() above the per-option for-loop. f->wss is per-fingerprint, not per-option, so the check must run regardless of f->opt_num (including 0). Also reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that as \"should not happen\". Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:220) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:348) nf_hook_slow (net/netfilter/core.c:622) ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv (include/linux/skbuff.h:1162) __netif_receive_skb_one_core (net/core/dev.c:6181) process_backlog (net/core/dev.c:6642) __napi_poll (net/core/dev.c:7710) net_rx_action (net/core/dev.c:7945) handle_softirqs (kernel/softirq.c:622)", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45840", "url": "https://ubuntu.com/security/CVE-2026-45840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: cap upcall PID array size and pre-size vport replies The vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENL_UNS_ADMIN_PERM. kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Kernel panic - not syncing: Fatal exception Reject attempts to set more PIDs than nr_cpu_ids in ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply size in ovs_vport_cmd_msg_size() based on that bound, similar to the existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the two sides stay consistent.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46319", "url": "https://ubuntu.com/security/CVE-2026-46319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: Only release RCU read lock after ct_ft When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero() is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft object. This vulnerability can lead to privilege escalation. Analysis from zdi-disclosures@trendmicro.com: When initializing act_ct, tcf_ct_init() is called, which internally triggers tcf_ct_flow_table_get(). static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params) { struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ... } static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params) { void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj; } At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft from zones_ht . The lookup is performed within an RCU read critical section through rcu_read_lock() / rcu_read_unlock(), which prevents the object from being freed. However, at the point of function return, rcu_read_unlock() has already been called, and there is nothing preventing ct_ft from being freed before reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomes the race window, during which ct_ft can be freed. Free Process: tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put(). static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft) { if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); } } At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work static void tcf_ct_flow_table_cleanup_work(struct work_struct *work) { struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE); } tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes between [1] and [2], UAF occurs. This race condition has a very short race window, making it generally difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was inserted after[1]", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-45839", "url": "https://ubuntu.com/security/CVE-2026-45839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec() CO-RE accessor strings are colon-separated indices that describe a path from a root BTF type to a target field, e.g. \"0:1:2\" walks through nested struct members. bpf_core_parse_spec() parses each component with sscanf(\"%d\"), so negative values like -1 are silently accepted. The subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the upper bound and always pass for negative values because C integer promotion converts the __u16 btf_vlen result to int, making the comparison (int)(-1) >= (int)(N) false for any positive N. When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff, producing an out-of-bounds read far past the members array. A crafted BPF program with a negative CO-RE accessor on any struct that exists in vmlinux BTF (e.g. task_struct) crashes the kernel deterministically during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y (default on major distributions). The bug is reachable with CAP_BPF: BUG: unable to handle page fault for address: ffffed11818b6626 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full) RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354) RAX: 00000000ffffffff Call Trace: bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321) bpf_core_apply (kernel/bpf/btf.c:9507) check_core_relo (kernel/bpf/verifier.c:19475) bpf_check (kernel/bpf/verifier.c:26031) bpf_prog_load (kernel/bpf/syscall.c:3089) __sys_bpf (kernel/bpf/syscall.c:6228) CO-RE accessor indices are inherently non-negative (struct member index, array element index, or enumerator index), so reject them immediately after parsing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45838", "url": "https://ubuntu.com/security/CVE-2026-45838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix end-of-list detection in cgroup_storage_get_next_key() list_next_entry() never returns NULL -- when the current element is the last entry it wraps to the list head via container_of(). The subsequent NULL check is therefore dead code and get_next_key() never returns -ENOENT for the last element, instead reading storage->key from a bogus pointer that aliases internal map fields and copying the result to userspace. Replace it with list_entry_is_head() so the function correctly returns -ENOENT when there are no more entries.", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46214", "url": "https://ubuntu.com/security/CVE-2026-46214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix accept queue count leak on transport mismatch virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listener to reject all new connections. Fix by moving sk_acceptq_added() to after the transport validation, matching the pattern used by vmci_transport and hyperv_transport.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46234", "url": "https://ubuntu.com/security/CVE-2026-46234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: fix buffer size clamping order In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint. This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size. Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45836", "url": "https://ubuntu.com/security/CVE-2026-45836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46231", "url": "https://ubuntu.com/security/CVE-2026-46231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: put backbone reference on failed claim hash insert When batadv_bla_add_claim() fails to insert a new claim into the hash, it leaked a reference to the backbone_gw for which the claim was intended. Call batadv_backbone_gw_put() on the error path to release the reference and avoid leaking the backbone_gw object.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46233", "url": "https://ubuntu.com/security/CVE-2026-46233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: only purge non-released claims When batadv_bla_purge_claims() goes through the list of claims, it is only traversing the hash list with an rcu_read_lock(). Due to a potential parallel batadv_claim_put(), it can happen that it encounters a claim which was actually in the process of being released+freed by batadv_claim_release(). In this case, backbone_gw is set to NULL before the delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is then no longer allowed because it would cause a NULL-ptr derefence. To avoid this, only claims with a valid reference counter must be purged. All others are already taken care of.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46212", "url": "https://ubuntu.com/security/CVE-2026-46212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: prevent use-after-free when deleting claims When batadv_bla_del_backbone_claims() removes all claims for a backbone, it does this by dropping the link entry in the hash list. This list entry itself was one of the references which need to be dropped at the same time via batadv_claim_put(). But the batadv_claim_put() must not be done before the last access to the claim object in this function. Otherwise the claim might be freed already by the batadv_claim_release() function before the list entry was dropped.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46238", "url": "https://ubuntu.com/security/CVE-2026-46238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop caching unowned originator pointers in BAT IV BAT IV keeps the last-hop neighbor address in each neigh_node, but some paths also cache an originator pointer derived from a temporary lookup. That pointer is not owned by the neigh_node and may no longer refer to a live originator entry after purge handling runs. Stop storing the auxiliary originator pointer in the BAT IV neighbor state. When BAT IV needs the neighbor originator data, resolve it from the stored neighbor address and drop the reference again after use. [sven: avoid bonding logic for outgoing OGM]", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46206", "url": "https://ubuntu.com/security/CVE-2026-46206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject new tp_meter sessions during teardown Prevent tp_meter from starting new sender or receiver sessions after mesh_state has left BATADV_MESH_ACTIVE.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46198", "url": "https://ubuntu.com/security/CVE-2026-46198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix integer overflow on buff_pos Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size check is done using the int type in batadv_iv_ogm_aggr_packet whereas the buff_pos variable uses the s16 type. This could lead to an out-of-bound read.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46227", "url": "https://ubuntu.com/security/CVE-2026-46227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the \"sk != asoc->base.sk\" and \"asoc->base.dead\" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 (\"sctp: walk the list of asoc safely\") was added for.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46220", "url": "https://ubuntu.com/security/CVE-2026-46220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission sdma_v4_0_ring_emit_fence() contains two BUG_ON(addr & 0x3) assertions that verify fence writeback addresses are dword-aligned. These assertions can be reached from unprivileged userspace via crafted DRM_IOCTL_AMDGPU_CS submissions, causing a fatal kernel panic in a scheduler worker thread. Replace both BUG_ON() calls with WARN_ON() to log the condition without crashing the kernel. A misaligned fence address at this point indicates a driver bug, but crashing the kernel is never the correct response when the assertion is reachable from userspace. The CS IOCTL path is the correct place to filter invalid submissions; the ring emission callback is too late to do anything about it. (cherry picked from commit b90250bd933afd1ba94d86d6b13821997b22b18e)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46197", "url": "https://ubuntu.com/security/CVE-2026-46197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: validate SVM ioctl nattr against buffer size Validate nattr field against the buffer size, preventing out-of-bounds buffer access via user-controlled attribute count. (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46209", "url": "https://ubuntu.com/security/CVE-2026-46209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1); However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value. A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46230", "url": "https://ubuntu.com/security/CVE-2026-46230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg Check bounds against the end of the BO whenever we access the msg.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46219", "url": "https://ubuntu.com/security/CVE-2026-46219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix use-after-free on unbind The state machine work is scheduled by the interrupt handler and therefore needs to be cancelled after disabling interrupts to avoid a potential use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46236", "url": "https://ubuntu.com/security/CVE-2026-46236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: xbox_remote: heed DMA restrictions The buffer for IO must not be part of the device structure because that violates the DMA coherency rules.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46205", "url": "https://ubuntu.com/security/CVE-2026-46205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: media: atomisp: Disallow all private IOCTLs Disallow all private IOCTLs. These aren't quite as safe as one could assume of IOCTL handlers; disable them for now. Instead of removing the code, return in the beginning of the function if cmd is non-zero in order to keep static checkers happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46168", "url": "https://ubuntu.com/security/CVE-2026-46168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix scheduling with atomic in timestamp sockopt Using lock_sock_fast() (atomic context) around sock_set_timestamp() and sock_set_timestamping() is unsafe, as both helpers can sleep. Replace lock_sock_fast() with sleepable lock_sock()/release_sock() to avoid scheduling while atomic panic.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46189", "url": "https://ubuntu.com/security/CVE-2026-46189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path Sashiko points out that pvrdma_uar_free() is already called within pvrdma_dealloc_ucontext(), so calling it before triggers a double free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46133", "url": "https://ubuntu.com/security/CVE-2026-46133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject unknown opcodes before ICRC processing Even after applying commit 7244491dab34 (\"RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv\"), a single unauthenticated UDP packet can still trigger panic. That patch handled payload_size() underflow only for valid opcodes with short packets, not for packets carrying an unknown opcode. The unknown-opcode OOB read described below predates that commit and reaches back to the initial Soft RoCE driver. The check added there reads pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The rxe_opcode[] array has 256 entries but is only populated for defined IB opcodes; any other entry (for example opcode 0xff) is zero-initialized, so length == 0 and the check degenerates to pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES which underflows when length == 0 and passes a huge value to rxe_crc32(), causing an out-of-bounds read of the skb payload. Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma link add rxe0 type rxe netdev eth0 A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and QPN=IB_MULTICAST_QPN triggers: BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170 Read of size 1 at addr ... The buggy address is located 0 bytes to the right of allocated 704-byte region Call Trace: crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 Subsequent packets with the same shape fault on unmapped memory and panic the kernel. The trigger requires only module load and \"rdma link add\"; no QP, no connection, and no authentication. Fix this by rejecting packets whose opcode has no rxe_opcode[] entry, detected via the zero mask or zero length, before any length arithmetic runs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46127", "url": "https://ubuntu.com/security/CVE-2026-46127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp() Sashiko points out that pd->uctx isn't initialized until late in the function so all these error flow references are NULL and will crash. Use the uctx that isn't NULL.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46178", "url": "https://ubuntu.com/security/CVE-2026-46178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq() Sashiko points out that mlx4_srq_alloc() was not undone during error unwind, add the missing call to mlx4_srq_free().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46112", "url": "https://ubuntu.com/security/CVE-2026-46112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix unlocked call to hns_roce_qp_remove() Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory. Grab the same locks the other two callers use.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46304", "url": "https://ubuntu.com/security/CVE-2026-46304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the final controller reference through nvmet_cq_put(). If that triggers nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on the same nvmet-wq. Call chain: nvmet_tcp_schedule_release_queue() kref_put(&queue->kref, nvmet_tcp_release_queue) nvmet_tcp_release_queue() queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq process_one_work() nvmet_tcp_release_queue_work() nvmet_cq_put(&queue->nvme_cq) nvmet_cq_destroy() nvmet_ctrl_put(cq->ctrl) nvmet_ctrl_free() flush_work(&ctrl->async_event_work) <--- nvmet_wq Previously Scheduled by :- \t\t nvmet_add_async_event \t\t queue_work(nvmet_wq, &ctrl->async_event_work); This trips lockdep with a possible recursive locking warning. [ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55 [ 5223.061801] loop0: detected capacity change from 0 to 2097152 [ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 [ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420) [ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349. [ 5223.128453] nvme nvme1: new ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349 [ 5233.199447] nvme nvme1: Removing ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\" [ 5233.227718] ============================================ [ 5233.231283] WARNING: possible recursive locking detected [ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N [ 5233.238434] -------------------------------------------- [ 5233.241852] kworker/u192:6/2413 is trying to acquire lock: [ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 [ 5233.251438] but task is already holding lock: [ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.261125] other info that might help us debug this: [ 5233.265333] Possible unsafe locking scenario: [ 5233.269217] CPU0 [ 5233.270795] ---- [ 5233.272436] lock((wq_completion)nvmet-wq); [ 5233.275241] lock((wq_completion)nvmet-wq); [ 5233.278020] *** DEADLOCK *** [ 5233.281793] May be due to missing lock nesting notation [ 5233.286195] 3 locks held by kworker/u192:6/2413: [ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0 [ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 [ 5233.304290] stack backtrace: [ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full) [ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST [ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp] [ 5233.306532] Call Trace: [ 5233.306534] [ 5233.306536] dump_stack_lvl+0x73/0xb0 [ 5233.306552] print_deadlock_bug+0x225/0x2f0 [ 5233.306556] __lock_acquire+0x13f0/0x2290 [ 5233.306563] lock_acquire+0xd0/0x300 [ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306571] ? __flush_work+0x20b/0x530 [ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306577] touch_wq_lockdep_map+0x3b/0x90 [ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90 [ 52 ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46161", "url": "https://ubuntu.com/security/CVE-2026-46161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix divide-by-zero in setup_geo() with zero far_copies setup_geo() extracts near_copies (nc) and far_copies (fc) from the user-provided layout parameter without checking for zero. When fc=0 with the \"improved\" far set layout selected, 'geo->far_set_size = disks / fc' triggers a divide-by-zero. Validate nc and fc immediately after extraction, returning -1 if either is zero.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46124", "url": "https://ubuntu.com/security/CVE-2026-46124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate block number from NFS file handle in isofs_export_iget isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker- controlled block number (ifid->block or ifid->parent_block) from the NFS file handle to isofs_export_iget(), which only rejects block == 0 before calling isofs_iget() and ultimately sb_bread(). A crafted file handle with fh_len sufficient to pass the check added by commit 0405d4b63d08 (\"isofs: Prevent the use of too small fid\") can still drive the server to read any in-range block on the backing device as if it were an iso_directory_record. That earlier fix was assigned CVE-2025-37780. sb_bread() on an out-of-range block returns NULL cleanly via the EIO path, so there is no memory-safety violation. For in-range reads of adjacent-partition data on the same block device, the unrelated bytes end up in iso_inode_info fields that reach the NFS client as dentry metadata. The deployment surface (isofs exported over NFS from loop-mounted images) is narrow and requires an authenticated NFS peer, but the malformed-file-handle class is reportable as hardening next to the existing CVE-2025-37780 fix. Reject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent() call sites with a single line.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46303", "url": "https://ubuntu.com/security/CVE-2026-46303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b (\"[PATCH] rock.c: handle corrupted directories\") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 (\"isofs: Fix infinite looping over CE entries\") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.", "cve_priority": "medium", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46294", "url": "https://ubuntu.com/security/CVE-2026-46294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a buffer overflow in ioctl processing Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the \"outptr\" variable to the next 8-byte boundary: \toutptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The \"for\" loop is iterated again, it executes: \tremaining = len - (outptr - outbuf); 5. If \"outptr\" points past \"outbuf + len\", the arithmetics wraps around and the variable \"remaining\" contains unusually high number 6. With \"remaining\" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, \"outptr = align_ptr(outptr)\" can't overshoot the input buffer and the bug can't happen accidentally", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46107", "url": "https://ubuntu.com/security/CVE-2026-46107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-thin: fix metadata refcount underflow There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count. If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in \"device mapper: space map common: unable to decrement block\" errors. Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46301", "url": "https://ubuntu.com/security/CVE-2026-46301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: topcliff-pch: fix use-after-free on unbind Give the driver a chance to flush its queue before releasing the DMA buffers on driver unbind", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46273", "url": "https://ubuntu.com/security/CVE-2026-46273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmveth: Disable GSO for packets with small MSS Some physical adapters on Power systems do not support segmentation offload when the MSS is less than 224 bytes. Attempting to send such packets causes the adapter to freeze, stopping all traffic until manually reset. Implement ndo_features_check to disable GSO for packets with small MSS values. The network stack will perform software segmentation instead. The 224-byte minimum matches ibmvnic commit (\"ibmvnic: Enforce stronger sanity checks on GSO packets\") which uses the same physical adapters in SEA configurations. The issue occurs specifically when the hardware attempts to perform segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets (gso_segs == 1) do not trigger the problematic LSO code path and are transmitted normally without segmentation. Add an ndo_features_check callback to disable GSO when MSS < 224 bytes. Also call vlan_features_check() to ensure proper handling of VLAN packets, particularly QinQ (802.1ad) configurations where the hardware parser may not support certain offload features. Validated using iptables to force small MSS values. Without the fix, the adapter freezes. With the fix, packets are segmented in software and transmission succeeds. Comprehensive regression testing completedd (MSS tests, performance, stability).", "cve_priority": "high", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-43502", "url": "https://ubuntu.com/security/CVE-2026-43502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: handle zerocopy send cleanup before the message is queued A zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket. The purge path currently infers zerocopy state from rm->m_rs, so an unqueued message can be cleaned up as if it owned normal payload pages. However, zerocopy ownership is really determined by the presence of op_mmp_znotifier, regardless of whether the message has reached the socket queue. Capture op_mmp_znotifier up front in rds_message_purge() and use it as the cleanup discriminator. If the message is already associated with a socket, keep the existing completion path. Otherwise, drop the pinned page accounting directly and release the notifier before putting the payload pages. This keeps early send failure cleanup consistent with the zerocopy lifetime rules without changing the normal queued completion path.", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46120", "url": "https://ubuntu.com/security/CVE-2026-46120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: Use cached t->net in ip6erspan_changelink(). After commit 5e72ce3e3980 (\"net: ipv6: Use link netns in newlink() of rtnl_link_ops\"), ip6erspan_newlink() correctly resolves the per-netns ip6gre hash via link_net. ip6erspan_changelink() was not converted in that series and still uses dev_net(dev), which diverges from the device's creation netns after IFLA_NET_NS_FD migration. This re-inserts the tunnel into the wrong per-netns hash. The original netns keeps a stale entry. When that netns is later destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a slab-use-after-free reported by KASAN, followed by a kernel BUG at net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify(). Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). ip6gre_changelink() earlier in the same file already uses the cached t->net; only ip6erspan_changelink() has the wrong shape.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46184", "url": "https://ubuntu.com/security/CVE-2026-46184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sound: ua101: fix division by zero at probe Add a missing sanity check for bNrChannels in detect_usb_format() to prevent a division by zero in playback_urb_complete() and capture_urb_complete(). USB core does not validate class-specific descriptor fields such as bNrChannels, so drivers must verify them before use. If a device provides bNrChannels = 0, frame_bytes becomes zero and is later used as a divisor in the URB completion handlers, leading to a kernel crash.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46132", "url": "https://ubuntu.com/security/CVE-2026-46132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack without initialisation: \tstruct ifla_vf_broadcast vf_broadcast; The struct contains a single fixed 32-byte field: \t/* include/uapi/linux/if_link.h */ \tstruct ifla_vf_broadcast { \t\t__u8 broadcast[32]; \t}; The function then copies dev->broadcast into it using dev->addr_len as the length: \tmemcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len); On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via: \tnla_put(skb, IFLA_VF_BROADCAST, \t\tsizeof(vf_broadcast), &vf_broadcast) leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK request, repeatable. The other vf_* structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vf_vlan_info, node_guid and port_guid a few lines above. vf_broadcast was simply missed when it was added. Reachability: any unprivileged local process can open AF_NETLINK / NETLINK_ROUTE without capabilities and send RTM_GETLINK with an IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nla_put() when reproduced. Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf_* structs in the same function.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46150", "url": "https://ubuntu.com/security/CVE-2026-46150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fanotify: fix false positive on permission events fsnotify_get_mark_safe() may return false for a mark on an unrelated group, which results in bypassing the permission check. Fix by skipping over detached marks that are not in the current group.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45834", "url": "https://ubuntu.com/security/CVE-2026-45834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-45835", "url": "https://ubuntu.com/security/CVE-2026-45835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46186", "url": "https://ubuntu.com/security/CVE-2026-46186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: validate rx pkt_type header length virtbt_rx_handle() reads the leading pkt_type byte from the RX skb and forwards the remainder to hci_recv_frame() for every event/ACL/SCO/ISO type, without checking that the remaining payload is at least the fixed HCI header for that type. After the preceding patch bounds the backend-supplied used.len to [1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches hci_recv_frame() with skb->len already pulled to 0. If the byte happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification fast-path in hci_dev_classify_pkt_type() dereferences hci_acl_hdr(skb)->handle whenever the HCI device has an active CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of uninitialized RX-buffer data. The same hazard exists for every packet type the driver accepts because none of the switch cases in virtbt_rx_handle() check skb->len against the per-type minimum HCI header size before handing the frame to the core. After stripping pkt_type, require skb->len to cover the fixed header size for the selected type (event 2, ACL 4, SCO 3, ISO 4) before calling hci_recv_frame(); drop ratelimited otherwise. Unknown pkt_type values still take the original kfree_skb() default path. Use bt_dev_err_ratelimited() because both the length and pkt_type values come from an untrusted backend that can otherwise flood the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46123", "url": "https://ubuntu.com/security/CVE-2026-46123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: clamp rx length before skb_put virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one(). Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device. The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory. Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle(). Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log. Same class of bug as commit c04db81cd028 (\"net/9p: Fix buffer overflow in USB transport layer\"), which hardened the USB 9p transport against unchecked device-reported length.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46172", "url": "https://ubuntu.com/security/CVE-2026-46172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: xfrm6: release dst on error in xfrm6_rcv_encap() xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6_route_input_lookup() returns a referenced dst entry even when the lookup resolves to an error route. If dst->error is set, xfrm6_rcv_encap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries. Release the dst before jumping to the drop path.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46146", "url": "https://ubuntu.com/security/CVE-2026-46146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3() The convert_chmap_v3() has a loop with its increment size of cs_desc->wLength, but we forgot to validate cs_desc->wLength itself, which may lead to potential endless loop by a malformed descriptor. Add a proper size check to abort the loop for plugging the hole.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46167", "url": "https://ubuntu.com/security/CVE-2026-46167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. Ideally that short command should be detected and error out, but many printers are known to send \"incorrect\" responses back so we can't just do that. statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl. usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller. Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no \"leak\" of information happening.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46151", "url": "https://ubuntu.com/security/CVE-2026-46151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix heap leak in IEEE 1284 device ID via short response usblp_ctrl_msg() collapses the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GET_DEVICE_ID control transfer short and the driver has no way to know. usblp_cache_device_id_string() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves device_id_string[2..1022] holding stale kmalloc heap. That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf(\"%s\", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device. Fix this up by just zapping the buffer with zeros before each request sent to the device.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46122", "url": "https://ubuntu.com/security/CVE-2026-46122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43: enforce bounds check on firmware key index in b43_rx() The firmware-controlled key index in b43_rx() can exceed the dev->key[] array size (58 entries). The existing B43_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read. Make the B43_WARN_ON check enforcing by dropping the frame when the firmware returns an invalid key index.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46307", "url": "https://ubuntu.com/security/CVE-2026-46307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath5k: do not access array OOB Vincent reports: > The ath5k driver seems to do an array-index-out-of-bounds access as > shown by the UBSAN kernel message: > UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20 > index 4 is out of range for type 'ieee80211_tx_rate [4]' > ... > Call Trace: > > dump_stack_lvl+0x5d/0x80 > ubsan_epilogue+0x5/0x2b > __ubsan_handle_out_of_bounds.cold+0x46/0x4b > ath5k_tasklet_tx+0x4e0/0x560 [ath5k] > tasklet_action_common+0xb5/0x1c0 It is real. 'ts->ts_final_idx' can be 3 on 5212, so: info->status.rates[ts->ts_final_idx + 1].idx = -1; with the array defined as: struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES]; while the size is: #define IEEE80211_TX_MAX_RATES 4 is indeed bogus. Set this 'idx = -1' sentinel only if the array index is less than the array size. As mac80211 will not look at rates beyond the size (IEEE80211_TX_MAX_RATES). Note: The effect of the OOB write is negligible. It just overwrites the next member of info->status, i.e. ack_signal.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46187", "url": "https://ubuntu.com/security/CVE-2026-46187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: fix kthread lifetime race between self-exit and external-stop RSI driver use both self-exit(kthread_complete_and_exit) and external-stop (kthread_stop) when killing a kthread. Generally, kthread_stop() is called first, and in this case, no particular issues occur. However, in rare instances where kthread_complete_and_exit() is called first and then kthread_stop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again. Therefore, to prevent this with minimal modification, you must remove kthread_stop() and change the code to wait until the self-exit operation is completed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46163", "url": "https://ubuntu.com/security/CVE-2026-46163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43legacy: enforce bounds check on firmware key index in RX path Same fix as b43: the firmware-controlled key index in b43legacy_rx() can exceed dev->max_nr_keys. The existing B43legacy_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read of dev->key[]. Make the check enforcing by dropping the frame for invalid indices.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46044", "url": "https://ubuntu.com/security/CVE-2026-46044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:ssif: Clean up kthread on errors If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43496", "url": "https://ubuntu.com/security/CVE-2026-43496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peeked When red qdisc has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] [ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq] [ 78.672148][ T363] ? __pfx__printk+0x10/0x10 [ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0 [ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0 [ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red] [ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf] [ 78.673566][ T363] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead.", "cve_priority": "medium", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2024-56727", "url": "https://ubuntu.com/security/CVE-2024-56727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c Adding error pointer check after calling otx2_mbox_get_rsp().", "cve_priority": "medium", "cve_public_date": "2024-12-29 12:15:00 UTC" }, { "cve": "CVE-2026-31489", "url": "https://ubuntu.com/security/CVE-2026-31489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: meson-spicc: Fix double-put in remove path meson_spicc_probe() registers the controller with devm_spi_register_controller(), so teardown already drops the controller reference via devm cleanup. Calling spi_controller_put() again in meson_spicc_remove() causes a double-put.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31476", "url": "https://ubuntu.com/security/CVE-2026-31476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: do not expire session on binding failure When a multichannel session binding request fails (e.g. wrong password), the error path unconditionally sets sess->state = SMB2_SESSION_EXPIRED. However, during binding, sess points to the target session looked up via ksmbd_session_lookup_slowpath() -- which belongs to another connection's user. This allows a remote attacker to invalidate any active session by simply sending a binding request with a wrong password (DoS). Fix this by skipping session expiration when the failed request was a binding attempt, since the session does not belong to the current connection. The reference taken by ksmbd_session_lookup_slowpath() is still correctly released via ksmbd_user_session_put().", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43497", "url": "https://ubuntu.com/security/CVE-2026-43497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages to userspace but sets no vm_ops on the VMA. This means the kernel cannot track active mmaps. When dlfb_realloc_framebuffer() replaces the backing buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated. On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages while userspace PTEs still reference them, resulting in a use-after-free: the process retains read/write access to freed kernel pages. Add vm_operations_struct with open/close callbacks that maintain an atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(), check mmap_count and return -EBUSY if the buffer is currently mapped, preventing buffer replacement while userspace holds stale PTEs. Tested with PoC using dummy_hcd + raw_gadget USB device emulation.", "cve_priority": "low", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46108", "url": "https://ubuntu.com/security/CVE-2026-46108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:si: Return state to normal if message allocation fails There were places where nothing would get started if a message allocation failed, so the driver needs to return to normal state.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46128", "url": "https://ubuntu.com/security/CVE-2026-46128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Check event message buffer response for bad data The event message buffer response data size got checked later when processing, but check it right after the response comes back. It appears some BMCs may return an empty message instead of an error when fetching events. There are apparently some new BMCs that make this error, so we need to compensate.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46177", "url": "https://ubuntu.com/security/CVE-2026-46177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Add limits to event and receive message requests The driver would just fetch events and receive messages until the BMC said it was done. To avoid issues with BMCs that never say they are done, add a limit of 10 fetches at a time. In addition, an si interface has an attn state it can return from the hardware which is supposed to cause a flag fetch to see if the driver needs to fetch events or message or a few other things. If the attn bit gets stuck, it's a similar problem. So allow messages in between flag fetches so the driver itself doesn't get stuck. This is a more general fix than the previous fix for the specific bad BMC, but should fix the more general issue of a BMC that won't stop saying it has data. This has been there from the beginning of the driver. It's not a bug per-se, but it is accounting for bugs in BMCs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46149", "url": "https://ubuntu.com/security/CVE-2026-46149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show() target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered. Commit 27e06650a5ea (\"scsi: target: target_core_configfs: Add length check to avoid buffer overflow\") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46101", "url": "https://ubuntu.com/security/CVE-2026-46101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: reject zero shift in nft_bitwise Reject zero shift operands for nft_bitwise left and right shift expressions during initialization. The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour. Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46099", "url": "https://ubuntu.com/security/CVE-2026-46099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels seg6_input_core() and rpl_input() call ip6_route_input() which sets a NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking dst_hold() unconditionally. On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpu_rt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence: ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1] rt_genid_bump_ipv6() -> bumps fib6_sernum [fib6_sernum from W to Z] ip6_route_output() -> ip6_pol_route() -> FIB lookup resolves fib6_nh [nhid=N] -> rt6_get_pcpu_route() pcpu_rt->sernum != fib6_sernum [W <> Z, stale] -> prev = xchg(rt6i_pcpu, NULL) -> dst_release(prev) [prev is pcpu_rt, refcount 1->0, dead] dst = skb_dst(skb) [dst is the dead pcpu_rt] dst_cache_set_ip6(dst) -> dst_hold() on dead dst -> WARN / use-after-free For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release the pcpu_rt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6_nh and its rt6i_pcpu entry. Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after ip6_route_input() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6_route_output() already returns a refcounted dst.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46033", "url": "https://ubuntu.com/security/CVE-2026-46033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject short ahash digests during instance creation authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46062", "url": "https://ubuntu.com/security/CVE-2026-46062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix integer overflow in run_unpack() volume boundary check The volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses raw addition which can wrap around for large lcn and len values, bypassing the validation. Use check_add_overflow() as is already done for the adjacent prev_lcn + dlcn and vcn64 + len checks added by commit 3ac37e100385 (\"ntfs3: Fix integer overflow in run_unpack()\"). Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46072", "url": "https://ubuntu.com/security/CVE-2026-46072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: add buffer boundary checks to run_unpack() run_unpack() checks `run_buf < run_last` at the top of the while loop but then reads size_size and offset_size bytes via run_unpack_s64() without verifying they fit within the remaining buffer. A crafted NTFS image with truncated run data in an MFT attribute triggers an OOB heap read of up to 15 bytes when the filesystem is mounted. Add boundary checks before each run_unpack_s64() call to ensure the declared field size does not exceed the remaining buffer. Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46023", "url": "https://ubuntu.com/security/CVE-2026-46023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm mirror: fix integer overflow in create_dirty_log() The argument count calculation in create_dirty_log() performs `*args_used = 2 + param_count` before validating against argc. When a user provides a param_count close to UINT_MAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent `argc < *args_used` check to be bypassed. The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array. Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46077", "url": "https://ubuntu.com/security/CVE-2026-46077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-tdes - fix DMA sync direction Before DMA output is consumed by the CPU, ->dma_addr_out must be synced with dma_sync_single_for_cpu() instead of dma_sync_single_for_device(). Using the wrong direction can return stale cache data on non-coherent platforms.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45986", "url": "https://ubuntu.com/security/CVE-2026-45986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccree - fix a memory leak in cc_mac_digest() Add cc_unmap_result() if cc_map_hash_request_final() fails to prevent potential memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46019", "url": "https://ubuntu.com/security/CVE-2026-46019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the first page using free_page(), leaking the remaining 3 pages. Use free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46015", "url": "https://ubuntu.com/security/CVE-2026-46015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: call sk_data_ready() after listener migration When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46040", "url": "https://ubuntu.com/security/CVE-2026-46040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails When fsnotify_add_inode_mark_locked() fails in inotify_new_watch(), the error path calls inotify_remove_from_idr() but does not call dec_inotify_watches() to undo the preceding inc_inotify_watches(). This leaks a watch count, and repeated failures can exhaust the max_user_watches limit with -ENOSPC even when no watches are active. Prior to commit 1cce1eea0aff (\"inotify: Convert to using per-namespace limits\"), the watch count was incremented after fsnotify_add_mark_locked() succeeded, so this path was not affected. The conversion moved inc_inotify_watches() before the mark insertion without adding the corresponding rollback. Add the missing dec_inotify_watches() call in the error path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46070", "url": "https://ubuntu.com/security/CVE-2026-46070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: validate payload size before accessing journal metadata r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block. A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets. Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46051", "url": "https://ubuntu.com/security/CVE-2026-46051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix soft lockup in retry_aligned_read() When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46046", "url": "https://ubuntu.com/security/CVE-2026-46046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all() The commit c8e008b60492 (\"ext4: ignore xattrs past end\") introduced a refcount leak in when block_csum is false. ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to get iloc.bh, but never releases it with brelse().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46285", "url": "https://ubuntu.com/security/CVE-2026-46285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: docg3: fix use-after-free in docg3_release() In docg3_release(), the docg3 pointer is obtained from cascade->floors[0]->priv before the loop that calls doc_release_device() on each floor. doc_release_device() frees the docg3 struct via kfree(docg3) at line 1881. After the loop, docg3->cascade->bch dereferences the already-freed pointer. Fix this by accessing cascade->bch directly, which is equivalent since docg3->cascade points back to the same cascade struct, and is already available as a local variable. This also removes the now-unused docg3 local variable.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46082", "url": "https://ubuntu.com/security/CVE-2026-46082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. [sean: tag for stable@]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45987", "url": "https://ubuntu.com/security/CVE-2026-45987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2 After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46024", "url": "https://ubuntu.com/security/CVE-2026-46024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply() If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for both protocol and result, this is currently not treated as an error. In case of ac->negotiating == true and ac->protocol > 0, this leads to setting ac->protocol = 0 and ac->ops = NULL. Thereafter, the check for ac->protocol != protocol returns false, and init_protocol() is not called. Subsequently, ac->ops->handle_reply() is called, which leads to a null pointer dereference, because ac->ops is still NULL. This patch changes the check for ac->protocol != protocol to !ac->protocol, as this also includes the case when the protocol was set to zero in the message. This causes the message to be treated as containing a bad auth protocol.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46037", "url": "https://ubuntu.com/security/CVE-2026-46037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: validate reply type before using icmp_pointers Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type. That value is outside the range covered by icmp_pointers[], which only describes the traditional ICMP types up to NR_ICMP_TYPES. Avoid consulting icmp_pointers[] for reply types outside that range, and use array_index_nospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46027", "url": "https://ubuntu.com/security/CVE-2026-46027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid early lgr access in smc_clc_wait_msg A CLC decline can be received while the handshake is still in an early stage, before the connection has been associated with a link group. The decline handling in smc_clc_wait_msg() updates link-group level sync state for first-contact declines, but that state only exists after link group setup has completed. Guard the link-group update accordingly and keep the per-socket peer diagnosis handling unchanged. This preserves the existing sync_err handling for established link-group contexts and avoids touching link-group state before it is available.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46053", "url": "https://ubuntu.com/security/CVE-2026-46053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: fix MR cleanup on copy error __rds_rdma_map() hands sg/pages ownership to the transport after get_mr() succeeds. If copying the generated cookie back to user space fails after that point, the error path must not free those resources again before dropping the MR reference. Remove the duplicate unpin/free from the put_user() failure branch so that MR teardown is handled only through the existing final cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46004", "url": "https://ubuntu.com/security/CVE-2026-46004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Handle probe errors properly The probe procedure of setup_card() in caiaq driver doesn't treat the error cases gracefully, e.g. the error from snd_card_register() calls snd_card_free() but continues. This would lead to a UAF for the further calls like snd_usb_caiaq_control_init(), as Berk suggested in another patch in the link below. However, the problem is not only that; in general, this function drops the all error handlings (as it's a void function) although its caller can propagate an error to snd_probe(), which eventually calls snd_card_free() as a proper error path. That said, we should treat each error case in setup_card(), and just return the error code promptly, which is then handled later as a fatal error in snd_probe(). This patch achieves it by changing the setup_card() to return an error code. Also, the superfluous snd_card_free() call is removed, too. Note that card->private_free can be set still safely at returning an error. All called functions in card_free() have checks of the unassigned resources or NULL checks.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46050", "url": "https://ubuntu.com/security/CVE-2026-46050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix deadlock with check operation and nowait requests When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b (\"raid10: cleanup memleak at raid10_make_request\") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case. This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0. Output of r10conf state of the array when we hit this condition: crash> struct r10conf \tbarrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0, Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier(): md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46049", "url": "https://ubuntu.com/security/CVE-2026-46049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Add fallback to default RSR for S/PDIF spdif_passthru_playback_get_resources() uses atc->pll_rate as the RSR for the MSR calculation loop. However, pll_rate is only updated in atc_pll_init() and not in hw_pll_init(), so it remains 0 after the card init. When spdif_passthru_playback_setup() skips atc_pll_init() for 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin indefinitely. Add fallback to use atc->rsr when atc->pll_rate is 0. This reflects the hardware state, since hw_card_init() already configures the PLL to the default RSR.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46002", "url": "https://ubuntu.com/security/CVE-2026-46002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext2: reject inodes with zero i_nlink and valid mode in ext2_iget() ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is zero or i_dtime is set, treating them as deleted. However, the case of i_nlink == 0 with a non-zero mode and zero dtime slips through. Since ext2 has no orphan list, such a combination can only result from filesystem corruption - a legitimate inode deletion always sets either i_dtime or clears i_mode before freeing the inode. A crafted image can exploit this gap to present such an inode to the VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via ext2_unlink(), ext2_rename() and ext2_rmdir(): WARNING: CPU: 3 PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295 vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477 do_unlinkat+0x53e/0x730 fs/namei.c:4541 __x64_sys_unlink+0xc6/0x110 fs/namei.c:4587 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 646 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rename+0x35e/0x850 fs/ext2/namei.c:374 vfs_rename+0xf2f/0x2060 fs/namei.c:5021 do_renameat2+0xbe2/0xd50 fs/namei.c:5178 __x64_sys_rename+0x7e/0xa0 fs/namei.c:5223 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 634 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311 vfs_rmdir+0x204/0x690 fs/namei.c:4348 do_rmdir+0x372/0x3e0 fs/namei.c:4407 __x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Extend the existing i_nlink == 0 check to also catch this case, reporting the corruption via ext2_error() and returning -EFSCORRUPTED. This rejects the inode at load time and prevents it from reaching any of the namei.c paths. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46047", "url": "https://ubuntu.com/security/CVE-2026-46047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Fix use-after-free in driver remove() In the remove callback, if a packet arrives after destroy_workqueue() is called, but before sock_release(), the qrtr_ns_data_ready() callback will try to queue the work, causing use-after-free issue. Fix this issue by saving the default 'sk_data_ready' callback during qrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback at the start of remove(). This ensures that even if a packet arrives after destroy_workqueue(), the work struct will not be dereferenced. Note that it is also required to ensure that the RX threads are completed before destroying the workqueue, because the threads could be using the qrtr_ns_data_ready() callback.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46009", "url": "https://ubuntu.com/security/CVE-2026-46009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to do later. This leads to an oops when .allow_link fails or when .drop_link is performed. Remove the helper. Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46102", "url": "https://ubuntu.com/security/CVE-2026-46102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: strparser: fix skb_head leak in strp_abort_strp() When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46098", "url": "https://ubuntu.com/security/CVE-2026-46098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: caif: clear client service pointer on teardown `caif_connect()` can tear down an existing client after remote shutdown by calling `caif_disconnect_client()` followed by `caif_free_client()`. `caif_free_client()` releases the service layer referenced by `adap_layer->dn`, but leaves that pointer stale. When the socket is later destroyed, `caif_sock_destructor()` calls `caif_free_client()` again and dereferences the freed service pointer. Clear the client/service links before releasing the service object so repeated teardown becomes harmless.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46088", "url": "https://ubuntu.com/security/CVE-2026-46088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names() snd_ctl_elem_init_enum_names() advances pointer p through the names buffer while decrementing buf_len. If buf_len reaches zero but items remain, the next iteration calls strnlen(p, 0). While strnlen(p, 0) returns 0 and would hit the existing name_len == 0 error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks maxlen against __builtin_dynamic_object_size(). When Clang loses track of p's object size inside the loop, this triggers a BRK exception panic before the return value is examined. Add a buf_len == 0 guard at the loop entry to prevent calling fortified strnlen() on an exhausted buffer. Found by kernel fuzz testing through Xiaomi Smartphone.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46080", "url": "https://ubuntu.com/security/CVE-2026-46080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: split transactions in dio completion to avoid credit exhaustion During ocfs2 dio operations, JBD2 may report warnings via following call trace: ocfs2_dio_end_io_write ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_split_extent ocfs2_try_to_merge_extent ocfs2_extend_rotate_transaction ocfs2_extend_trans jbd2__journal_restart start_this_handle output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449 To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to handle extents in a batch of transaction. Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode should only be removed from the orphan list after the extent tree update is complete. This ensures that if a crash occurs in the middle of extent tree updates, we won't leave stale blocks beyond EOF. This patch also changes the logic for updating the inode size and removing orphan, making it similar to ext4_dio_write_end_io(). Both operations are performed only when everything looks good. Finally, thanks to Jans and Joseph for providing the bug fix prototype and suggestions.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-21739", "url": "https://ubuntu.com/security/CVE-2025-21739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix use-after free in init error and remove paths devm_blk_crypto_profile_init() registers a cleanup handler to run when the associated (platform-) device is being released. For UFS, the crypto private data and pointers are stored as part of the ufs_hba's data structure 'struct ufs_hba::crypto_profile'. This structure is allocated as part of the underlying ufshcd and therefore Scsi_host allocation. During driver release or during error handling in ufshcd_pltfrm_init(), this structure is released as part of ufshcd_dealloc_host() before the (platform-) device associated with the crypto call above is released. Once this device is released, the crypto cleanup code will run, using the just-released 'struct ufs_hba::crypto_profile'. This causes a use-after-free situation: Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0 In other words, the initialisation code flow is: platform-device probe ufshcd_pltfrm_init() ufshcd_alloc_host() scsi_host_alloc() allocation of struct ufs_hba creation of scsi-host devices devm_blk_crypto_profile_init() devm registration of cleanup handler using platform-device and during error handling of ufshcd_pltfrm_init() or during driver removal: ufshcd_dealloc_host() scsi_host_put() put_device(scsi-host) release of struct ufs_hba put_device(platform-device) crypto cleanup handler To fix this use-after free, change ufshcd_alloc_host() to register a devres action to automatically cleanup the underlying SCSI device on ufshcd destruction, without requiring explicit calls to ufshcd_dealloc_host(). This way: * the crypto profile and all other ufs_hba-owned resources are destroyed before SCSI (as they've been registered after) * a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as it's not needed anymore * no future drivers using ufshcd_alloc_host() could ever forget adding the cleanup", "cve_priority": "low", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2026-46064", "url": "https://ubuntu.com/security/CVE-2026-46064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix heap over-read in ibmasm_send_i2o_message() The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO. Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure. Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controller's free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it. Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45994", "url": "https://ubuntu.com/security/CVE-2026-45994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix OOB reads in command_file_write due to missing size checks The command_file_write() handler allocates a kernel buffer of exactly count bytes and copies user data into it, but does not validate the buffer against the dot command protocol before passing it to get_dot_command_size() and get_dot_command_timeout(). Since both the allocation size (count) and the header fields (command_size, data_size) are independently user-controlled, an attacker can cause get_dot_command_size() to return a value exceeding the allocation, triggering OOB reads in get_dot_command_timeout() and an out-of-bounds memcpy_toio() that leaks kernel heap memory to the service processor. Fix with two guards: reject writes smaller than sizeof(struct dot_command_header) before allocation, then after copying user data reject commands where the buffer is smaller than the total size declared by the header (sizeof(header) + command_size + data_size). This ensures all subsequent header and payload field accesses stay within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46022", "url": "https://ubuntu.com/security/CVE-2026-46022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt() ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60). A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started. The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes: queue_begin + reader * sizeof(struct remote_input) with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception. Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46006", "url": "https://ubuntu.com/security/CVE-2026-46006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix u32 overflow in pushbuf reloc bounds check nouveau_gem_pushbuf_reloc_apply() validates each relocation with if (r->reloc_bo_offset + 4 > nvbo->bo.base.size) but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size. Cast to u64 so the addition happens in 64-bit arithmetic. [ Add Fixes: tag. - Danilo ]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46018", "url": "https://ubuntu.com/security/CVE-2026-46018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES parse_uac2_sample_rate_range() caps the number of enumerated rates at MAX_NR_RATES, but it only breaks out of the current rate loop. A malformed UAC2 RANGE response with additional triplets continues parsing the remaining triplets and repeatedly prints \"invalid uac2 rates\" while probe still holds register_mutex. Stop the whole parse once the cap is reached and return the number of rates collected so far.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-31696", "url": "https://ubuntu.com/security/CVE-2026-31696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing validation of ticket length in non-XDR key preparsing In rxrpc_preparse(), there are two paths for parsing key payloads: the XDR path (for large payloads) and the non-XDR path (for payloads <= 28 bytes). While the XDR path (rxrpc_preparse_xdr_rxkad()) correctly validates the ticket length against AFSTOKEN_RK_TIX_MAX, the non-XDR path fails to do so. This allows an unprivileged user to provide a very large ticket length. When this key is later read via rxrpc_read(), the total token size (toksize) calculation results in a value that exceeds AFSTOKEN_LENGTH_MAX, triggering a WARN_ON(). [ 2001.302904] WARNING: CPU: 2 PID: 2108 at net/rxrpc/key.c:778 rxrpc_read+0x109/0x5c0 [rxrpc] Fix this by adding a check in the non-XDR parsing path of rxrpc_preparse() to ensure the ticket length does not exceed AFSTOKEN_RK_TIX_MAX, bringing it into parity with the XDR parsing logic.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31697", "url": "https://ubuntu.com/security/CVE-2026-31697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388 CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31698", "url": "https://ubuntu.com/security/CVE-2026-31698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033 CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31699", "url": "https://ubuntu.com/security/CVE-2026-31699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405 CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31701", "url": "https://ubuntu.com/security/CVE-2026-31701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: take a reference on the USB device in create_card() The caiaq driver stores a pointer to the parent USB device in cdev->chip.dev but never takes a reference on it. The card's private_free callback, snd_usb_caiaq_card_free(), can run asynchronously via snd_card_free_when_closed() after the USB device has already been disconnected and freed, so any access to cdev->chip.dev in that path dereferences a freed usb_device. On top of the refcounting issue, the current card_free implementation calls usb_reset_device(cdev->chip.dev). A reset in a free callback is inappropriate: the device is going away, the call takes the device lock in a teardown context, and the reset races with the disconnect path that the callback is already cleaning up after. Take a reference on the USB device in create_card() with usb_get_dev(), drop it with usb_put_dev() in the free callback, and remove the usb_reset_device() call.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31694", "url": "https://ubuntu.com/security/CVE-2026-31694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject oversized dirents in page cache fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31716", "url": "https://ubuntu.com/security/CVE-2026-31716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate rec->used in journal-replay file record check check_file_record() validates rec->total against the record size but never validates rec->used. The do_action() journal-replay handlers read rec->used from disk and use it to compute memmove lengths: DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next)) When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall. This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay Fix this up by bounding rec->used correctly. This is much like commit b2bc7c44ed17 (\"fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\") which checked different values in this same switch statement.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31676", "url": "https://ubuntu.com/security/CVE-2026-31676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31409", "url": "https://ubuntu.com/security/CVE-2026-31409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: unset conn->binding on failed binding request When a multichannel SMB2_SESSION_SETUP request with SMB2_SESSION_REQ_FLAG_BINDING fails ksmbd sets conn->binding = true but never clears it on the error path. This leaves the connection in a binding state where all subsequent ksmbd_session_lookup_all() calls fall back to the global sessions table. This fix it by clearing conn->binding = false in the error path.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2023-53596", "url": "https://ubuntu.com/security/CVE-2023-53596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: base: Free devm resources when unregistering a device In the current code, devres_release_all() only gets called if the device has a bus and has been probed. This leads to issues when using bus-less or driver-less devices where the device might never get freed if a managed resource holds a reference to the device. This is happening in the DRM framework for example. We should thus call devres_release_all() in the device_del() function to make sure that the device-managed actions are properly executed when the device is unregistered, even if it has neither a bus nor a driver. This is effectively the same change than commit 2f8d16a996da (\"devres: release resources on device_del()\") that got reverted by commit a525a3ddeaca (\"driver core: free devres in device_release\") over memory leaks concerns. This patch effectively combines the two commits mentioned above to release the resources both on device_del() and device_release() and get the best of both worlds.", "cve_priority": "low", "cve_public_date": "2025-10-04 16:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2025-38192", "url": "https://ubuntu.com/security/CVE-2025-38192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: clear the dst when changing skb protocol A not-so-careful NAT46 BPF program can crash the kernel if it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10) The output interface has a 4->6 program attached at ingress. We try to loop the multicast skb back to the sending socket. Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr and changes skb->protocol to v6. We enter ip6_rcv_core which tries to use skb_dst(). But the dst is still an IPv4 one left after IPv4 mcast output. Clear the dst in all BPF helpers which change the protocol. Try to preserve metadata dsts, those may carry non-routing metadata.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-21712", "url": "https://ubuntu.com/security/CVE-2025-21712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime After commit ec6bb299c7c3 (\"md/md-bitmap: add 'sync_size' into struct md_bitmap_stats\"), following panic is reported: Oops: general protection fault, probably for non-canonical address RIP: 0010:bitmap_get_stats+0x2b/0xa0 Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Root cause is that bitmap_get_stats() can be called at anytime if mddev is still there, even if bitmap is destroyed, or not fully initialized. Deferenceing bitmap in this case can crash the kernel. Meanwhile, the above commit start to deferencing bitmap->storage, make the problem easier to trigger. Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2026-43328", "url": "https://ubuntu.com/security/CVE-2026-43328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error path When kobject_init_and_add() fails, cpufreq_dbs_governor_init() calls kobject_put(&dbs_data->attr_set.kobj). The kobject release callback cpufreq_dbs_data_release() calls gov->exit(dbs_data) and kfree(dbs_data), but the current error path then calls gov->exit(dbs_data) and kfree(dbs_data) again, causing a double free. Keep the direct kfree(dbs_data) for the gov->init() failure path, but after kobject_init_and_add() has been called, let kobject_put() handle the cleanup through cpufreq_dbs_data_release().", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-23066", "url": "https://ubuntu.com/security/CVE-2026-23066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recvmsg() unconditional requeue If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at the front of the recvmsg queue already has its mutex locked, it requeues the call - whether or not the call is already queued. The call may be on the queue because MSG_PEEK was also passed and so the call was not dequeued or because the I/O thread requeued it. The unconditional requeue may then corrupt the recvmsg queue, leading to things like UAFs or refcount underruns. Fix this by only requeuing the call if it isn't already on the queue - and moving it to the front if it is already queued. If we don't queue it, we have to put the ref we obtained by dequeuing it. Also, MSG_PEEK doesn't dequeue the call so shouldn't call rxrpc_notify_socket() for the call if we didn't use up all the data on the queue, so fix that also.", "cve_priority": "high", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-27407", "url": "https://ubuntu.com/security/CVE-2024-27407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fixed overflow check in mi_enum_attr()", "cve_priority": "high", "cve_public_date": "2024-05-17 12:15:00 UTC" }, { "cve": "CVE-2023-45896", "url": "https://ubuntu.com/security/CVE-2023-45896", "cve_description": "ntfs3 in the Linux kernel through 6.8.0 allows a physically proximate attacker to read kernel memory by mounting a filesystem (e.g., if a Linux distribution is configured to allow unprivileged mounts of removable media) and then leveraging local access to trigger an out-of-bounds read. A length value can be larger than the amount of memory allocated. NOTE: the supplier's perspective is that there is no vulnerability when an attack requires an attacker-modified filesystem image.", "cve_priority": "medium", "cve_public_date": "2024-08-28 05:15:00 UTC" }, { "cve": "CVE-2023-52737", "url": "https://ubuntu.com/security/CVE-2023-52737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: lock the inode in shared mode before starting fiemap Currently fiemap does not take the inode's lock (VFS lock), it only locks a file range in the inode's io tree. This however can lead to a deadlock if we have a concurrent fsync on the file and fiemap code triggers a fault when accessing the user space buffer with fiemap_fill_next_extent(). The deadlock happens on the inode's i_mmap_lock semaphore, which is taken both by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by syzbot and triggers a trace like the following: task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 wait_on_state fs/btrfs/extent-io-tree.c:707 [inline] wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751 lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742 find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488 writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863 __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174 extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091 extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211 do_writepages+0x3c3/0x680 mm/page-writeback.c:2581 filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388 __filemap_fdatawrite_range mm/filemap.c:421 [inline] filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439 btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline] start_ordered_ops fs/btrfs/file.c:1737 [inline] btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839 generic_write_sync include/linux/fs.h:2885 [inline] btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684 call_write_iter include/linux/fs.h:2189 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9 RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006 RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8 INFO: task syz-executor361:5697 blocked for more than 145 seconds. Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095 __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260 btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526 do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947 wp_page_shared+0x15e/0x380 mm/memory.c:3295 handle_pte_fault mm/memory.c:4949 [inline] __handle_mm_fault mm/memory.c:5073 [inline] handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219 do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428 handle_page_fault arch/x86/mm/fault.c:1519 [inline] exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233 Code: 74 0a 89 (...) RSP: 0018:ffffc9000570f330 EFLAGS: 000502 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-05-21 16:15:00 UTC" }, { "cve": "CVE-2025-38626", "url": "https://ubuntu.com/security/CVE-2025-38626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode w/ \"mode=lfs\" mount option, generic/299 will cause system panic as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2835! Call Trace: f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720 The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may trigger foreground gc only if it allocates any physical block, it will be a little bit later when there is multiple threads writing data w/ aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so f2fs_map_blocks() does block allocations aggressively. In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_blocks().", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2024-46770", "url": "https://ubuntu.com/security/CVE-2024-46770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Add netif_device_attach/detach into PF reset flow Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. getting coalesce settings can result in a NULL pointer dereference seen below. Reproduction steps: Once the driver is fully initialized, trigger reset: \t# echo 1 > /sys/class/net//device/reset when reset is in progress try to get coalesce settings using ethtool: \t# ethtool -c BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7 RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice] RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206 RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000 R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40 FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0 Call Trace: ice_get_coalesce+0x17/0x30 [ice] coalesce_prepare_data+0x61/0x80 ethnl_default_doit+0xde/0x340 genl_family_rcv_msg_doit+0xf2/0x150 genl_rcv_msg+0x1b3/0x2c0 netlink_rcv_skb+0x5b/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x19c/0x290 netlink_sendmsg+0x222/0x490 __sys_sendto+0x1df/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7faee60d8e27 Calling netif_device_detach() before reset makes the net core not call the driver when ethtool command is issued, the attempt to execute an ethtool command during reset will result in the following message: netlink error: No such device instead of NULL pointer dereference. Once reset is done and ice_rebuild() is executing, the netif_device_attach() is called to allow for ethtool operations to occur again in a safe manner.", "cve_priority": "medium", "cve_public_date": "2024-09-18 08:15:00 UTC" }, { "cve": "CVE-2025-38105", "url": "https://ubuntu.com/security/CVE-2025-38105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Kill timer properly at removal The USB-audio MIDI code initializes the timer, but in a rare case, the driver might be freed without the disconnect call. This leaves the timer in an active state while the assigned object is released via snd_usbmidi_free(), which ends up with a kernel warning when the debug configuration is enabled, as spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be killed properly. While we're at it, replace the existing timer_delete_sync() at the disconnect callback with timer_shutdown_sync(), too.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2024-27389", "url": "https://ubuntu.com/security/CVE-2024-27389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore: inode: Only d_invalidate() is needed Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning: WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410 Using the combo of d_drop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use d_invalidate() and update the code to not bother checking for error codes that can never happen. ---", "cve_priority": "medium", "cve_public_date": "2024-05-01 13:15:00 UTC" }, { "cve": "CVE-2023-52682", "url": "https://ubuntu.com/security/CVE-2023-52682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait on block writeback for post_read case If inode is compressed, but not encrypted, it missed to call f2fs_wait_on_block_writeback() to wait for GCed page writeback in IPU write path. Thread A\t\t\t\tGC-Thread \t\t\t\t\t- f2fs_gc \t\t\t\t\t - do_garbage_collect \t\t\t\t\t - gc_data_segment \t\t\t\t\t - move_data_block \t\t\t\t\t - f2fs_submit_page_write \t\t\t\t\t migrate normal cluster's block via \t\t\t\t\t meta_inode's page cache - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_submit_page_bio IRQ - f2fs_read_end_io \t\t\t\t\tIRQ \t\t\t\t\told data overrides new data due to \t\t\t\t\tout-of-order GC and common IO. \t\t\t\t\t- f2fs_read_end_io", "cve_priority": "medium", "cve_public_date": "2024-05-17 15:15:00 UTC" }, { "cve": "CVE-2024-56719", "url": "https://ubuntu.com/security/CVE-2024-56719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix TSO DMA API usage causing oops Commit 66600fac7a98 (\"net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data\") moved the assignment of tx_skbuff_dma[]'s members to be later in stmmac_tso_xmit(). The buf (dma cookie) and len stored in this structure are passed to dma_unmap_single() by stmmac_tx_clean(). The DMA API requires that the dma cookie passed to dma_unmap_single() is the same as the value returned from dma_map_single(). However, by moving the assignment later, this is not the case when priv->dma_cap.addr64 > 32 as \"des\" is offset by proto_hdr_len. This causes problems such as: dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed and with DMA_API_DEBUG enabled: DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes] Fix this by maintaining \"des\" as the original DMA cookie, and use tso_des to pass the offset DMA cookie to stmmac_tso_allocator(). Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/", "cve_priority": "medium", "cve_public_date": "2024-12-29 09:15:00 UTC" }, { "cve": "CVE-2024-41079", "url": "https://ubuntu.com/security/CVE-2024-41079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: always initialize cqe.result The spec doesn't mandate that the first two double words (aka results) for the command queue entry need to be set to 0 when they are not used (not specified). Though, the target implemention returns 0 for TCP and FC but not for RDMA. Let's make RDMA behave the same and thus explicitly initializing the result field. This prevents leaking any data from the stack.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2023-53545", "url": "https://ubuntu.com/security/CVE-2023-53545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: unmap and remove csa_va properly Root PD BO should be reserved before unmap and remove a bo_va from VM otherwise lockdep will complain. v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian) [14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu] [14616.937096] Call Trace: [14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu] [14616.937187] drm_file_free+0x1d6/0x300 [drm] [14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm] [14616.937220] drm_release+0x5e/0x100 [drm] [14616.937234] __fput+0x9f/0x280 [14616.937239] ____fput+0xe/0x20 [14616.937241] task_work_run+0x61/0x90 [14616.937246] exit_to_user_mode_prepare+0x215/0x220 [14616.937251] syscall_exit_to_user_mode+0x2a/0x60 [14616.937254] do_syscall_64+0x48/0x90 [14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd", "cve_priority": "medium", "cve_public_date": "2025-10-04 16:15:00 UTC" }, { "cve": "CVE-2025-68239", "url": "https://ubuntu.com/security/CVE-2025-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: restore write access before closing files opened by open_exec() bm_register_write() opens an executable file using open_exec(), which internally calls do_open_execat() and denies write access on the file to avoid modification while it is being executed. However, when an error occurs, bm_register_write() closes the file using filp_close() directly. This does not restore the write permission, which may cause subsequent write operations on the same file to fail. Fix this by calling exe_file_allow_write_access() before filp_close() to restore the write permission properly.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-38659", "url": "https://ubuntu.com/security/CVE-2025-38659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: No more self recovery When a node withdraws and it turns out that it is the only node that has the filesystem mounted, gfs2 currently tries to replay the local journal to bring the filesystem back into a consistent state. Not only is that a very bad idea, it has also never worked because gfs2_recover_func() will refuse to do anything during a withdraw. However, before even getting to this point, gfs2_recover_func() dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free before commit 04133b607a78 (\"gfs2: Prevent double iput for journal on error\") and is a NULL pointer dereference since then. Simply get rid of self recovery to fix that.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2022-49961", "url": "https://ubuntu.com/security/CVE-2022-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg->precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored state. To show a concrete example of the problem: 0000000000000000 : 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 10: r2 = -1 0000000000000058 : 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit 00000000000000b8 : 23: w0 = 0 24: exit For the first case, the single line execution's exploration will prune the search at insn 14 for the branch insn 9's second leg as it will be verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will always be 0 so at runtime we don't get error for being greater than UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just sees reg->precise as false for both r2 registers in both states, hence considers them equal for purposes of states_equal. If we propagated precise markers using the backtracking support, we would use the precise marking to then ensure that old r2 (UINT_MAX) was within the new r2 (1) and this would never be true, so the verification would rightfully fail. The end result is that the out of bounds access at instruction 19 would be permitted without this fix. Note that reg->precise is always set to true when user does not have CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static or global functions)), hence this is only a problem when precision marks need to be explicitly propagated (i.e. privileged users with CAP_BPF). A simplified test case has been included in the next patch to prevent future regressions.", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2024-47809", "url": "https://ubuntu.com/security/CVE-2024-47809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix possible lkb_resource null dereference This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded. The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference. In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.", "cve_priority": "medium", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2025-38250", "url": "https://ubuntu.com/security/CVE-2025-38250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix use-after-free in vhci_flush() syzbot reported use-after-free in vhci_flush() without repro. [0] From the splat, a thread close()d a vhci file descriptor while its device was being used by iotcl() on another thread. Once the last fd refcnt is released, vhci_release() calls hci_unregister_dev(), hci_free_dev(), and kfree() for struct vhci_data, which is set to hci_dev->dev->driver_data. The problem is that there is no synchronisation after unlinking hdev from hci_dev_list in hci_unregister_dev(). There might be another thread still accessing the hdev which was fetched before the unlink operation. We can use SRCU for such synchronisation. Let's run hci_dev_reset() under SRCU and wait for its completion in hci_unregister_dev(). Another option would be to restore hci_dev->destruct(), which was removed in commit 587ae086f6e4 (\"Bluetooth: Remove unused hci-destruct cb\"). However, this would not be a good solution, as we should not run hci_unregister_dev() while there are in-flight ioctl() requests, which could lead to another data-race KCSAN splat. Note that other drivers seem to have the same problem, for exmaple, virtbt_remove(). [0]: BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718 CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name ---truncated---", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2026-43281", "url": "https://ubuntu.com/security/CVE-2026-43281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate() Although it is guided that `#mbox-cells` must be at least 1, there are many instances of `#mbox-cells = <0>;` in the device tree. If that is the case and the corresponding mailbox controller does not provide `fw_xlate` and of_xlate` function pointers, `fw_mbox_index_xlate()` will be used by default and out-of-bounds accesses could occur due to lack of bounds check in that function.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23157", "url": "https://ubuntu.com/security/CVE-2026-23157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not strictly require dirty metadata threshold for metadata writepages [BUG] There is an internal report that over 1000 processes are waiting at the io_schedule_timeout() of balance_dirty_pages(), causing a system hang and trigger a kernel coredump. The kernel is v6.4 kernel based, but the root problem still applies to any upstream kernel before v6.18. [CAUSE] From Jan Kara for his wisdom on the dirty page balance behavior first. This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB. Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there's dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying. When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit. So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in that cgroup. So that means the only way to reduce the dirty pages of that cgroup is to writeback the dirty pages of btrfs btree inode, and only after that those processes can exit balance_dirty_pages(). Now back to the btrfs part, btree_writepages() is responsible for writing back dirty btree inode pages. The problem here is, there is a btrfs internal threshold that if the btree inode's dirty bytes are below the 32M threshold, it will not do any writeback. This behavior is to batch as much metadata as possible so we won't write back those tree blocks and then later re-COW them again for another modification. This internal 32MiB is higher than the existing dirty page size (28MiB), meaning no writeback will happen, causing a deadlock between btrfs and cgroup: - Btrfs doesn't want to write back btree inode until more dirty pages - Cgroup/MM doesn't want more dirty pages for btrfs btree inode Thus any process touching that btree inode is put into sleep until the number of dirty pages is reduced. Thanks Jan Kara a lot for the analysis of the root cause. [ENHANCEMENT] Since kernel commit b55102826d7d (\"btrfs: set AS_KERNEL_FILE on the btree_inode\"), btrfs btree inode pages will only be charged to the root cgroup which should have a much larger limit than btrfs' 32MiB threshold. So it should not affect newer kernels. But for all current LTS kernels, they are all affected by this problem, and backporting the whole AS_KERNEL_FILE may not be a good idea. Even for newer kernels I still think it's a good idea to get rid of the internal threshold at btree_writepages(), since for most cases cgroup/MM has a better view of full system memory usage than btrfs' fixed threshold. For internal callers using btrfs_btree_balance_dirty() since that function is already doing internal threshold check, we don't need to bother them. But for external callers of btree_writepages(), just respect their requests and write back whatever they want, ignoring the internal btrfs threshold to avoid such deadlock on btree inode dirty page balancing.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23141", "url": "https://ubuntu.com/security/CVE-2026-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: check for inline extents in range_is_hole_in_parent() Before accessing the disk_bytenr field of a file extent item we need to check if we are dealing with an inline extent. This is because for inline extents their data starts at the offset of the disk_bytenr field. So accessing the disk_bytenr means we are accessing inline data or in case the inline data is less than 8 bytes we can actually cause an invalid memory access if this inline extent item is the first item in the leaf or access metadata from other items.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-40005", "url": "https://ubuntu.com/security/CVE-2025-40005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: Implement refcount to handle unbind during busy driver support indirect read and indirect write operation with assumption no force device removal(unbind) operation. However force device removal(removal) is still available to root superuser. Unbinding driver during operation causes kernel crash. This changes ensure driver able to handle such operation for indirect read and indirect write by implementing refcount to track attached devices to the controller and gracefully wait and until attached devices remove operation completed before proceed with removal operation.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2023-53629", "url": "https://ubuntu.com/security/CVE-2023-53629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: dlm: fix use after free in midcomms commit While working on processing dlm message in softirq context I experienced the following KASAN use-after-free warning: [ 151.760477] ================================================================== [ 151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347 [ 151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828 [ 151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014 [ 151.768726] Call Trace: [ 151.769277] [ 151.769748] dump_stack_lvl+0x5b/0x86 [ 151.770556] print_report+0x180/0x4c8 [ 151.771378] ? kasan_complete_mode_report_info+0x7c/0x1e0 [ 151.772241] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.773069] kasan_report+0x93/0x1a0 [ 151.773668] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.774514] __asan_load4+0x7e/0xa0 [ 151.775089] dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.775890] ? create_message.isra.29.constprop.64+0x57/0xc0 [ 151.776770] send_common+0x19f/0x1b0 [ 151.777342] ? remove_from_waiters+0x60/0x60 [ 151.778017] ? lock_downgrade+0x410/0x410 [ 151.778648] ? __this_cpu_preempt_check+0x13/0x20 [ 151.779421] ? rcu_lockdep_current_cpu_online+0x88/0xc0 [ 151.780292] _convert_lock+0x46/0x150 [ 151.780893] convert_lock+0x7b/0xc0 [ 151.781459] dlm_lock+0x3ac/0x580 [ 151.781993] ? 0xffffffffc0540000 [ 151.782522] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.783379] ? dlm_scan_rsbs+0xa70/0xa70 [ 151.784003] ? preempt_count_sub+0xd6/0x130 [ 151.784661] ? is_module_address+0x47/0x70 [ 151.785309] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.786166] ? 0xffffffffc0540000 [ 151.786693] ? lockdep_init_map_type+0xc3/0x360 [ 151.787414] ? 0xffffffffc0540000 [ 151.787947] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.789004] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.789858] ? 0xffffffffc0540000 [ 151.790392] ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture] [ 151.791347] ? delay_tsc+0x94/0xc0 [ 151.791898] torture_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.792735] ? torture_start+0x30/0x30 [dlm_locktorture] [ 151.793606] lock_torture+0x177/0x270 [dlm_locktorture] [ 151.794448] ? torture_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture] [ 151.795539] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.796476] ? do_raw_spin_lock+0x11e/0x1e0 [ 151.797152] ? mark_held_locks+0x34/0xb0 [ 151.797784] ? _raw_spin_unlock_irqrestore+0x30/0x70 [ 151.798581] ? __kthread_parkme+0x79/0x110 [ 151.799246] ? trace_preempt_on+0x2a/0xf0 [ 151.799902] ? __kthread_parkme+0x79/0x110 [ 151.800579] ? preempt_count_sub+0xd6/0x130 [ 151.801271] ? __kasan_check_read+0x11/0x20 [ 151.801963] ? __kthread_parkme+0xec/0x110 [ 151.802630] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.803569] kthread+0x192/0x1d0 [ 151.804104] ? kthread_complete_and_exit+0x30/0x30 [ 151.804881] ret_from_fork+0x1f/0x30 [ 151.805480] [ 151.806111] Allocated by task 1347: [ 151.806681] kasan_save_stack+0x26/0x50 [ 151.807308] kasan_set_track+0x25/0x30 [ 151.807920] kasan_save_alloc_info+0x1e/0x30 [ 151.808609] __kasan_slab_alloc+0x63/0x80 [ 151.809263] kmem_cache_alloc+0x1ad/0x830 [ 151.809916] dlm_allocate_mhandle+0x17/0x20 [ 151.810590] dlm_midcomms_get_mhandle+0x96/0x260 [ 151.811344] _create_message+0x95/0x180 [ 151.811994] create_message.isra.29.constprop.64+0x57/0xc0 [ 151.812880] send_common+0x129/0x1b0 [ 151.813467] _convert_lock+0x46/0x150 [ 151.814074] convert_lock+0x7b/0xc0 [ 151.814648] dlm_lock+0x3ac/0x580 [ 151.815199] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.816258] torture_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.817129] lock_t ---truncated---", "cve_priority": "high", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2025-71221", "url": "https://ubuntu.com/security/CVE-2025-71221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue() Add proper locking in mmp_pdma_residue() to prevent use-after-free when accessing descriptor list and descriptor contents. The race occurs when multiple threads call tx_status() while the tasklet on another CPU is freeing completed descriptors: CPU 0 CPU 1 ----- ----- mmp_pdma_tx_status() mmp_pdma_residue() -> NO LOCK held list_for_each_entry(sw, ..) DMA interrupt dma_do_tasklet() -> spin_lock(&desc_lock) list_move(sw->node, ...) spin_unlock(&desc_lock) | dma_pool_free(sw) <- FREED! -> access sw->desc <- UAF! This issue can be reproduced when running dmatest on the same channel with multiple threads (threads_per_chan > 1). Fix by protecting the chain_running list iteration and descriptor access with the chan->desc_lock spinlock.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23204", "url": "https://ubuntu.com/security/CVE-2026-23204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: use skb_header_pointer_careful() skb_header_pointer() does not fully validate negative @offset values. Use skb_header_pointer_careful() instead. GangMin Kim provided a report and a repro fooling u32_classify(): BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0 net/sched/cls_u32.c:221", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-71161", "url": "https://ubuntu.com/security/CVE-2025-71161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: disable recursive forward error correction There are two problems with the recursive correction: 1. It may cause denial-of-service. In fec_read_bufs, there is a loop that has 253 iterations. For each iteration, we may call verity_hash_for_block recursively. There is a limit of 4 nested recursions - that means that there may be at most 253^4 (4 billion) iterations. Red Hat QE team actually created an image that pushes dm-verity to this limit - and this image just makes the udev-worker process get stuck in the 'D' state. 2. It doesn't work. In fec_read_bufs we store data into the variable \"fio->bufs\", but fio bufs is shared between recursive invocations, if \"verity_hash_for_block\" invoked correction recursively, it would overwrite partially filled fio->bufs.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2022-50552", "url": "https://ubuntu.com/security/CVE-2022-50552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: use quiesced elevator switch when reinitializing queues The hctx's run_work may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally. nvme nvme0: resetting controller nvme nvme0: 32/0/0 default/read/poll queues BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:kyber_has_work+0x29/0x70 ... Call Trace: __blk_mq_do_dispatch_sched+0x83/0x2b0 __blk_mq_sched_dispatch_requests+0x12e/0x170 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x2b/0x50 process_one_work+0x1ef/0x380 worker_thread+0x2d/0x3e0", "cve_priority": "low", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2024-36922", "url": "https://ubuntu.com/security/CVE-2024-36922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: read txq->read_ptr under lock If we read txq->read_ptr without lock, we can read the same value twice, then obtain the lock, and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in the WARN_ONCE() a little later. Fix that by reading txq->read_ptr under lock.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2024-53221", "url": "https://ubuntu.com/security/CVE-2024-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix null-ptr-deref in f2fs_submit_page_bio() There's issue as follows when concurrently installing the f2fs.ko module and mounting the f2fs file system: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs] Call Trace: f2fs_submit_page_bio+0x126/0x8b0 [f2fs] __get_meta_page+0x1d4/0x920 [f2fs] get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs] validate_checkpoint+0xac/0x290 [f2fs] f2fs_get_valid_checkpoint+0x207/0x950 [f2fs] f2fs_fill_super+0x1007/0x39b0 [f2fs] mount_bdev+0x183/0x250 legacy_get_tree+0xf4/0x1e0 vfs_get_tree+0x88/0x340 do_new_mount+0x283/0x5e0 path_mount+0x2b2/0x15b0 __x64_sys_mount+0x1fe/0x270 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Above issue happens as the biset of the f2fs file system is not initialized before register \"f2fs_fs_type\". To address above issue just register \"f2fs_fs_type\" at the last in init_f2fs_fs(). Ensure that all f2fs file system resources are initialized.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-56657", "url": "https://ubuntu.com/security/CVE-2024-56657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Avoid WARN() for symlink errors Using WARN() for showing the error of symlink creations don't give more information than telling that something goes wrong, since the usual code path is a lregister callback from each control element creation. More badly, the use of WARN() rather confuses fuzzer as if it were serious issues. This patch downgrades the warning messages to use the normal dev_err() instead of WARN(). For making it clearer, add the function name to the prefix, too.", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2022-49803", "url": "https://ubuntu.com/security/CVE-2022-49803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Fix memory leak of nsim_dev->fa_cookie kmemleak reports this issue: unreferenced object 0xffff8881bac872d0 (size 8): comm \"sh\", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie .. nsim_drv_remove() The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To fix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove().", "cve_priority": "medium", "cve_public_date": "2025-05-01 15:16:00 UTC" }, { "cve": "CVE-2022-50116", "url": "https://ubuntu.com/security/CVE-2022-50116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix deadlock and link starvation in outgoing data path The current implementation queues up new control and user packets as needed and processes this queue down to the ldisc in the same code path. That means that the upper and the lower layer are hard coupled in the code. Due to this deadlocks can happen as seen below while transmitting data, especially during ldisc congestion. Furthermore, the data channels starve the control channel on high transmission load on the ldisc. Introduce an additional control channel data queue to prevent timeouts and link hangups during ldisc congestion. This is being processed before the user channel data queue in gsm_data_kick(), i.e. with the highest priority. Put the queue to ldisc data path into a workqueue and trigger it whenever new data has been put into the transmission queue. Change gsm_dlci_data_sweep() accordingly to fill up the transmission queue until TX_THRESH_HI. This solves the locking issue, keeps latency low and provides good performance on high data load. Note that now all packets from a DLCI are removed from the internal queue if the associated DLCI was closed. This ensures that no data is sent by the introduced write task to an already closed DLCI. BUG: spinlock recursion on CPU#0, test_v24_loop/124 lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0 CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x34/0x44 do_raw_spin_lock+0x76/0xa0 _raw_spin_lock_irqsave+0x72/0x80 uart_write_room+0x3b/0xc0 gsm_data_kick+0x14b/0x240 [n_gsm] gsmld_write_wakeup+0x35/0x70 [n_gsm] tty_wakeup+0x53/0x60 tty_port_default_wakeup+0x1b/0x30 serial8250_tx_chars+0x12f/0x220 serial8250_handle_irq.part.0+0xfe/0x150 serial8250_default_handle_irq+0x48/0x80 serial8250_interrupt+0x56/0xa0 __handle_irq_event_percpu+0x78/0x1f0 handle_irq_event+0x34/0x70 handle_fasteoi_irq+0x90/0x1e0 __common_interrupt+0x69/0x100 common_interrupt+0x48/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:__do_softirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00 RSP: 0018:ffffc90000003f98 EFLAGS: 00000286 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7 RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? __do_softirq+0x73/0x34e irq_exit_rcu+0xb5/0x100 common_interrupt+0xa4/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50 Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 3d 97 33 ff 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44 RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? _raw_spin_unlock_irqrestore+0x23/0x50 gsmtty_write+0x65/0x80 [n_gsm] n_tty_write+0x33f/0x530 ? swake_up_all+0xe0/0xe0 file_tty_write.constprop.0+0x1b1/0x320 ? n_tty_flush_buffer+0xb0/0xb0 new_sync_write+0x10c/0x190 vfs_write+0x282/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f3e5e35c15c Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2026-31586", "url": "https://ubuntu.com/security/CVE-2026-31586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: blk-cgroup: fix use-after-free in cgwb_release_workfn() cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) ** Stack based on commit 66672af7a095 (\"Add linux-next specific files for 20260410\") I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh (The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.) Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31598", "url": "https://ubuntu.com/security/CVE-2026-31598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible deadlock between unlink and dio_end_io_write ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key. Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir \t ocfs2_expand_inline_dir \t down_write(&oi->ip_alloc_sem) <- Lock B Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode) Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31642", "url": "https://ubuntu.com/security/CVE-2026-31642", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call removal to use RCU safe deletion Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop. This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by: Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that. rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31664", "url": "https://ubuntu.com/security/CVE-2026-31664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear trailing padding in build_polexpire() build_expire() clears the trailing padding bytes of struct xfrm_user_expire after setting the hard field via memset_after(), but the analogous function build_polexpire() does not do this for struct xfrm_user_polexpire. The padding bytes after the __u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners, leaking kernel heap memory contents. Add the missing memset_after() call, matching build_expire().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43075", "url": "https://ubuntu.com/security/CVE-2026-43075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix out-of-bounds write in ocfs2_write_end_inline KASAN reports a use-after-free write of 4086 bytes in ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF. The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk id_count field to determine whether a write fits in inline data. On a corrupted filesystem, id_count can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer. Call trace (crash path): vfs_copy_file_range (fs/read_write.c:1634) do_splice_direct splice_direct_to_actor iter_file_splice_write ocfs2_file_write_iter generic_perform_write ocfs2_write_end ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949) ocfs2_write_end_inline (fs/ocfs2/aops.c:1915) memcpy_from_folio <-- KASAN: write OOB So add id_count upper bound check in ocfs2_validate_inode_block() to alongside the existing i_size check to fix it.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43076", "url": "https://ubuntu.com/security/CVE-2026-43076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate inline data i_size during inode read When reading an inode from disk, ocfs2_validate_inode_block() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's i_size can exceed the actual inline data capacity (id_count). This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory. In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry() Fix by adding a validation check in ocfs2_validate_inode_block() to ensure inodes with inline data have i_size <= id_count. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-23444", "url": "https://ubuntu.com/security/CVE-2026-23444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do. Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free. Document the skb ownership guarantee in the function's kdoc.", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2025-38710", "url": "https://ubuntu.com/security/CVE-2025-38710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Validate i_depth for exhash directories A fuzzer test introduced corruption that ends up with a depth of 0 in dir_e_read(), causing an undefined shift by 32 at: index = hash >> (32 - dip->i_depth); As calculated in an open-coded way in dir_make_exhash(), the minimum depth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 is invalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time. So we can avoid the undefined behaviour by checking for depth values lower than the minimum in gfs2_dinode_in(). Values greater than the maximum are already being checked for there. Also switch the calculation in dir_make_exhash() to use ilog2() to clarify how the depth is calculated. Tested with the syzkaller repro.c and xfstests '-g quick'.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2026-23442", "url": "https://ubuntu.com/security/CVE-2026-23442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: add NULL checks for idev in SRv6 paths __in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER). Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31594", "url": "https://ubuntu.com/security/CVE-2026-31594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to perform later. This leads to an oops when .allow_link fails or when .drop_link is performed. The following is an example oops of the former case: Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pci_epc_remove_epf+0x78/0xe0 (P) pci_primary_epc_epf_link+0x88/0xa8 configfs_symlink+0x1f4/0x5a0 vfs_symlink+0x134/0x1d8 do_symlinkat+0x88/0x138 __arm64_sys_symlinkat+0x74/0xe0 [...] Remove the helper, and drop pci_epc_put(). EPC device refcounting is tied to the configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2022-50073", "url": "https://ubuntu.com/security/CVE-2022-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null Fixes a NULL pointer derefence bug triggered from tap driver. When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null (in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb) virtio_net_hdr_to_skb calls dev_parse_header_protocol which needs skb->dev field to be valid. The line that trigers the bug is in dev_parse_header_protocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->header_ops || !dev->header_ops->parse_protocol) 22e1: mov 0x10(%rbx),%rax 22e5:\t mov 0x230(%rax),%rax Setting skb->dev before the call in tap.c fixes the issue. BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tap_get_user+0x3f1/0x540 [tap] tap_sendmsg+0x56/0x362 [tap] ? get_tx_bufs+0xc2/0x1e0 [vhost_net] handle_tx_copy+0x114/0x670 [vhost_net] handle_tx+0xb0/0xe0 [vhost_net] handle_tx_kick+0x15/0x20 [vhost_net] vhost_worker+0x7b/0xc0 [vhost] ? vhost_vring_call_reset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2026-31576", "url": "https://ubuntu.com/security/CVE-2026-31576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: hackrf: fix to not free memory after the device is registered in hackrf_probe() In hackrf driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open hackrf fd \t\t\t\t\t\t.... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... \t\t\t\t\t\tsys_ioctl(fd, ...); \t\t\t\t\t\t v4l2_ioctl(); \t\t\t\t\t\t video_is_registered() // UAF!! \t\t\t\t\t\t.... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t v4l2_release() // UAF!! \t\t\t\t\t\t hackrf_video_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked. However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver's release() is invoked. Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven't been released yet. And since release() free memory too, race to use-after-free and double-free vuln occur. To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43058", "url": "https://ubuntu.com/security/CVE-2026-43058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix pass-by-value structs causing MSAN warnings vidtv_ts_null_write_into() and vidtv_ts_pcr_write_into() take their argument structs by value, causing MSAN to report uninit-value warnings. While only vidtv_ts_null_write_into() has triggered a report so far, both functions share the same issue. Fix by passing both structs by const pointer instead, avoiding the stack copy of the struct along with its MSAN shadow and origin metadata. The functions do not modify the structs, which is enforced by the const qualifier.", "cve_priority": "medium", "cve_public_date": "2026-05-02 07:16:00 UTC" }, { "cve": "CVE-2026-31577", "url": "https://ubuntu.com/security/CVE-2026-31577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map The DAT inode's btree node cache (i_assoc_inode) is initialized lazily during btree operations. However, nilfs_mdt_save_to_shadow_map() assumes i_assoc_inode is already initialized when copying dirty pages to the shadow map during GC. If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before any btree operation has occurred on the DAT inode, i_assoc_inode is NULL leading to a general protection fault. Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always initialized before any GC operation can use it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31578", "url": "https://ubuntu.com/security/CVE-2026-31578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: as102: fix to not free memory after the device is registered in as102_usb_probe() In as102_usb driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open as102 fd \t\t\t\t\t\t.... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t as102_release() // UAF!! \t\t\t\t\t\t as102_usb_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a USB character device registered with usb_register_dev() is later unregistered (via usb_deregister_dev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked. In as102, as102_usb_probe() calls usb_register_dev() and then, on an error path, does usb_deregister_dev() and frees as102_dev_t right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102_release() --> as102_usb_release() and access or free as102_dev_t again, occur a race to use-after-free and double-free vuln. The fix is to never kfree(as102_dev_t) directly once usb_register_dev() has succeeded. After deregistration, defer freeing memory to .release(). In other words, let release() perform the last kfree when the final open FD is closed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31580", "url": "https://ubuntu.com/security/CVE-2026-31580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bcache: fix cached_dev.sb_bio use-after-free and crash In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention: ``` [6888366.280350] Call Trace: [6888366.280452] blk_update_request+0x14e/0x370 [6888366.280561] blk_mq_end_request+0x1a/0x130 [6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd] [6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd] [6888366.280903] __complete_request+0x22/0x70 [libceph] [6888366.281032] osd_dispatch+0x15e/0xb40 [libceph] [6888366.281164] ? inet_recvmsg+0x5b/0xd0 [6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph] [6888366.281405] ceph_con_process_message+0x79/0x140 [libceph] [6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph] [6888366.281661] ceph_con_workfn+0x329/0x680 [libceph] ``` After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped. Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio. This patch hopes to wait for sb_write to complete in cached_dev_free. It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31581", "url": "https://ubuntu.com/security/CVE-2026-31581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: fix use-after-free on disconnect In usb6fire_chip_abort(), the chip struct is allocated as the card's private data (via snd_card_new with sizeof(struct sfire_chip)). When snd_card_free_when_closed() is called and no file handles are open, the card and embedded chip are freed synchronously. The subsequent chip->card = NULL write then hits freed slab memory. Call trace: usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline] usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953 Fix by moving the card lifecycle out of usb6fire_chip_abort() and into usb6fire_chip_disconnect(). The card pointer is saved in a local before any teardown, snd_card_disconnect() is called first to prevent new opens, URBs are aborted while chip is still valid, and snd_card_free_when_closed() is called last so chip is never accessed after the card may be freed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31583", "url": "https://ubuntu.com/security/CVE-2026-31583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free in em28xx_v4l2_open() em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock, creating a race with em28xx_v4l2_init()'s error path and em28xx_v4l2_fini(), both of which free the em28xx_v4l2 struct and set dev->v4l2 to NULL under dev->lock. This race leads to two issues: - use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler, since the video_device is embedded in the freed em28xx_v4l2 struct. - NULL pointer dereference in em28xx_resolution_set() when accessing v4l2->norm, since dev->v4l2 has been set to NULL. Fix this by moving the mutex_lock() before the dev->v4l2 read and adding a NULL check for dev->v4l2 under the lock.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31585", "url": "https://ubuntu.com/security/CVE-2026-31585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix nfeeds state corruption on start_streaming failure syzbot reported a memory leak in vidtv_psi_service_desc_init [1]. When vidtv_start_streaming() fails inside vidtv_start_feed(), the nfeeds counter is left incremented even though no feed was actually started. This corrupts the driver state: subsequent start_feed calls see nfeeds > 1 and skip starting the mux, while stop_feed calls eventually try to stop a non-existent stream. This state corruption can also lead to memory leaks, since the mux and channel resources may be partially allocated during a failed start_streaming but never cleaned up, as the stop path finds dvb->streaming == false and returns early. Fix by decrementing nfeeds back when start_streaming fails, keeping the counter in sync with the actual number of active feeds. [1] BUG: memory leak unreferenced object 0xffff888145b50820 (size 32): comm \"syz.0.17\", pid 6068, jiffies 4294944486 backtrace (crc 90a0c7d4): vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31686", "url": "https://ubuntu.com/security/CVE-2026-31686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/kasan: fix double free for kasan pXds kasan_free_pxd() assumes the page table is always struct page aligned. But that's not always the case for all architectures. E.g. In case of powerpc with 64K pagesize, PUD table (of size 4096) comes from slab cache named pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's just directly pass the start of the pxd table which is passed as the 1st argument. This fixes the below double free kasan issue seen with PMEM: radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages ================================================================== BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20 Free of addr c0000003c38e0000 by task ndctl/2164 CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeries Call Trace: dump_stack_lvl+0x88/0xc4 (unreliable) print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140 kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec ---- interrupt: 3000 at 0x7fff93b3d3f4 NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000 REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392) MSR: 800000000280f033 CR: 48888208 XER: 00000000 <...> NIP [00007fff93b3d3f4] 0x7fff93b3d3f4 LR [00007fff93b3d3f4] 0x7fff93b3d3f4 ---- interrupt: 3000 The buggy address belongs to the object at c0000003c38e0000 which belongs to the cache pgtable-2^9 of size 4096 The buggy address is located 0 bytes inside of 4096-byte region [c0000003c38e0000, c0000003c38e1000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:c0000003bfd63e01 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) page_type: f5(slab) raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected [ 138.953636] [ T2164] Memory state around the buggy address: [ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953669] [ T2164] ^ [ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953692] [ T2164] ================================================================== [ 138.953701] [ T2164] Disabling lock debugging due to kernel taint", "cve_priority": "low", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2026-31588", "url": "https://ubuntu.com/security/CVE-2026-31588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use scratch field in MMIO fragment to hold small write values When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value. This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, *and* both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable. The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by overwrite the data value with garbage. Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *al ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31630", "url": "https://ubuntu.com/security/CVE-2026-31630", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: proc: size address buffers for %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with \"%pISpc\". That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23399", "url": "https://ubuntu.com/security/CVE-2026-23399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nf_tables: nft_dynset: fix possible stateful expression memleak in error path If cloning the second stateful expression in the element via GFP_ATOMIC fails, then the first stateful expression remains in place without being released.   unreferenced object (percpu) 0x607b97e9cab8 (size 16):     comm \"softirq\", pid 0, jiffies 4294931867     hex dump (first 16 bytes on cpu 3):       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     backtrace (crc 0):       pcpu_alloc_noprof+0x453/0xd80       nft_counter_clone+0x9c/0x190 [nf_tables]       nft_expr_clone+0x8f/0x1b0 [nf_tables]       nft_dynset_new+0x2cb/0x5f0 [nf_tables]       nft_rhash_update+0x236/0x11c0 [nf_tables]       nft_dynset_eval+0x11f/0x670 [nf_tables]       nft_do_chain+0x253/0x1700 [nf_tables]       nft_do_chain_ipv4+0x18d/0x270 [nf_tables]       nf_hook_slow+0xaa/0x1e0       ip_local_deliver+0x209/0x330", "cve_priority": "medium", "cve_public_date": "2026-03-28 08:15:00 UTC" }, { "cve": "CVE-2024-35865", "url": "https://ubuntu.com/security/CVE-2024-35865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.", "cve_priority": "medium", "cve_public_date": "2024-05-19 09:15:00 UTC" }, { "cve": "CVE-2026-31590", "url": "https://ubuntu.com/security/CVE-2026-31590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION Drop the WARN in sev_pin_memory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing: struct kvm_enc_region range = { .addr = 0, .size = -1ul, }; __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range); Note, the checks in sev_mem_enc_register_region() that presumably exist to verify the incoming address+size are completely worthless, as both \"addr\" and \"size\" are u64s and SEV is 64-bit only, i.e. they _can't_ be greater than ULONG_MAX. That wart will be cleaned up in the near future. \tif (range->addr > ULONG_MAX || range->size > ULONG_MAX) \t\treturn -EINVAL; Opportunistically add a comment to explain why the code calculates the number of pages the \"hard\" way, e.g. instead of just shifting @ulen.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31596", "url": "https://ubuntu.com/security/CVE-2026-31596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle invalid dinode in ocfs2_group_extend [BUG] kernel BUG at fs/ocfs2/resize.c:308! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308 Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe Call Trace: ... ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... [CAUSE] ocfs2_group_extend() assumes that the global bitmap inode block returned from ocfs2_inode_lock() has already been validated and BUG_ONs when the signature is not a dinode. That assumption is too strong for crafted filesystems because the JBD2-managed buffer path can bypass structural validation and return an invalid dinode to the resize ioctl. [FIX] Validate the dinode explicitly in ocfs2_group_extend(). If the global bitmap buffer does not contain a valid dinode, report filesystem corruption with ocfs2_error() and fail the resize operation instead of crashing the kernel.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31597", "url": "https://ubuntu.com/security/CVE-2026-31597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY, as documented in mm/filemap.c: \"If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap().\" When this happens, a concurrent munmap() can call remove_vma() and free the vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call dereferences it -- a use-after-free. Fix this by saving ip_blkno as a plain integer before calling filemap_fault(), and removing vma from the trace event. Since ip_blkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31599", "url": "https://ubuntu.com/security/CVE-2026-31599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections syzbot reported a general protection fault in vidtv_psi_desc_assign [1]. vidtv_psi_pmt_stream_init() can return NULL on memory allocation failure, but vidtv_channel_pmt_match_sections() does not check for this. When tail is NULL, the subsequent call to vidtv_psi_desc_assign(&tail->descriptor, desc) dereferences a NULL pointer offset, causing a general protection fault. Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean up the already-allocated stream chain and return. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629 Call Trace: vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline] vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479 vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31602", "url": "https://ubuntu.com/security/CVE-2026-31602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Limit PTP to a single page Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic. ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ct_vm_map() tries to access beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count remain unchanged.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31603", "url": "https://ubuntu.com/security/CVE-2026-31603", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: sm750fb: fix division by zero in ps_to_hz() ps_to_hz() is called from hw_sm750_crtc_set_mode() without validating that pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO causes a division by zero. Fix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent with other framebuffer drivers.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31605", "url": "https://ubuntu.com/security/CVE-2026-31605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31615", "url": "https://ubuntu.com/security/CVE-2026-31615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: renesas_usb3: validate endpoint index in standard request handlers The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math. This is just like what was done in commit ee0d382feb44 (\"usb: gadget: aspeed_udc: validate endpoint index for ast udc\") for the aspeed driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31616", "url": "https://ubuntu.com/security/CVE-2026-31616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete() A broken/bored/mean USB host can overflow the skb_shared_info->frags[] array on a Linux gadget exposing a Phonet function by sending an unbounded sequence of full-page OUT transfers. pn_rx_complete() finalizes the skb only when req->actual < req->length, where req->length is set to PAGE_SIZE by the gadget. If the host always sends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never be reset and each completion will add another fragment via skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17), subsequent frag stores overwrite memory adjacent to the shinfo on the heap. Drop the skb and account a length error when the frag limit is reached, matching the fix applied in t7xx by commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\").", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31617", "url": "https://ubuntu.com/security/CVE-2026-31617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb() The block_len read from the host-supplied NTB header is checked against ntb_max but has no lower bound. When block_len is smaller than opts->ndp_size, the bounds check of: \tndp_index > (block_len - opts->ndp_size) will underflow producing a huge unsigned value that ndp_index can never exceed, defeating the check entirely. The same underflow occurs in the datagram index checks against block_len - opts->dpe_size. With those checks neutered, a malicious USB host can choose ndp_index and datagram offsets that point past the actual transfer, and the skb_put_data() copies adjacent kernel memory into the network skb. Fix this by rejecting block lengths that cannot hold at least the NTB header plus one NDP. This will make block_len - opts->ndp_size and block_len - opts->dpe_size both well-defined. Commit 8d2b1a1ec9f5 (\"CDC-NCM: avoid overflow in sanity checking\") fixed a related class of issues on the host side of NCM.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31618", "url": "https://ubuntu.com/security/CVE-2026-31618", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31619", "url": "https://ubuntu.com/security/CVE-2026-31619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: fireworks: bound device-supplied status before string array lookup The status field in an EFW response is a 32-bit value supplied by the firewire device. efr_status_names[] has 17 entries so a status value outside that range goes off into the weeds when looking at the %s value. Even worse, the status could return EFR_STATUS_INCOMPLETE which is 0x80000000, and is obviously not in that array of potential strings. Fix this up by properly bounding the index against the array size and printing \"unknown\" if it's not recognized.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31622", "url": "https://ubuntu.com/security/CVE-2026-31622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: digital: Bounds check NFC-A cascade depth in SDD response handler The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3 or 4 bytes to target->nfcid1 on each round, but the number of cascade rounds is controlled entirely by the peer device. The peer sets the cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the cascade-incomplete bit in the SEL_RES (deciding whether another round follows). ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver actually enforces this. This means a malicious peer can keep the cascade running, writing past the heap-allocated nfc_target with each round. Fix this by rejecting the response when the accumulated UID would exceed the buffer. Commit e329e71013c9 (\"NFC: nci: Bounds check struct nfc_target arrays\") fixed similar missing checks against the same field on the NCI path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31623", "url": "https://ubuntu.com/security/CVE-2026-31623", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete() A malicious USB device claiming to be a CDC Phonet modem can overflow the skb_shared_info->frags[] array by sending an unbounded sequence of full-page bulk transfers. Drop the skb and increment the length error when the frag limit is reached. This matches the same fix that commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\") did for the t7xx driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31624", "url": "https://ubuntu.com/security/CVE-2026-31624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: clamp report_size in s32ton() to avoid undefined shift s32ton() shifts by n-1 where n is the field's report_size, a value that comes directly from a HID device. The HID parser bounds report_size only to <= 256, so a broken HID device can supply a report descriptor with a wide field that triggers shift exponents up to 256 on a 32-bit type when an output report is built via hid_output_field() or hid_set_field(). Commit ec61b41918587 (\"HID: core: fix shift-out-of-bounds in hid_report_raw_event\") added the same n > 32 clamp to the function snto32(), but s32ton() was never given the same fix as I guess syzbot hadn't figured out how to fuzz a device the same way. Fix this up by just clamping the max value of n, just like snto32() does.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31625", "url": "https://ubuntu.com/security/CVE-2026-31625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: alps: fix NULL pointer dereference in alps_raw_event() Commit ecfa6f34492c (\"HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them\") attempted to fix up the HID drivers that had missed the previous fix that was done in 2ff5baa9b527 (\"HID: appleir: Fix potential NULL dereference at raw event handle\"), but the alps driver was missed. Fix this up by properly checking in the hid-alps driver that it had been claimed correctly before attempting to process the raw event.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31626", "url": "https://ubuntu.com/security/CVE-2026-31626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify() Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using uninitialized data. Smatch warns that only 6 bytes are copied to this 8-byte (u64) variable, leaving the last two bytes uninitialized: drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify() warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes) Initializing the variable at the start of the function fixes this warning and ensures predictable behavior.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31627", "url": "https://ubuntu.com/security/CVE-2026-31627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: s3c24xx: check the size of the SMBUS message before using it The first byte of an i2c SMBUS message is the size, and it should be verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX before processing it. This is the same logic that was added in commit a6e04f05ce0b (\"i2c: tegra: check msg length in SMBUS block read\") to the i2c tegra driver.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31532", "url": "https://ubuntu.com/security/CVE-2026-31532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: fix ro->uniq use-after-free in raw_rcv() raw_release() unregisters raw CAN receive filters via can_rx_unregister(), but receiver deletion is deferred with call_rcu(). This leaves a window where raw_rcv() may still be running in an RCU read-side critical section after raw_release() frees ro->uniq, leading to a use-after-free of the percpu uniq storage. Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific socket destructor. can_rx_unregister() takes an extra reference to the socket and only drops it from the RCU callback, so freeing uniq from sk_destruct ensures the percpu area is not released until the relevant callbacks have drained. [mkl: applied manually]", "cve_priority": "high", "cve_public_date": "2026-04-23 12:17:00 UTC" }, { "cve": "CVE-2026-31629", "url": "https://ubuntu.com/security/CVE-2026-31629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: add missing return after LLCP_CLOSED checks In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket state is LLCP_CLOSED, the code correctly calls release_sock() and nfc_llcp_sock_put() but fails to return. Execution falls through to the remainder of the function, which calls release_sock() and nfc_llcp_sock_put() again. This results in a double release_sock() and a refcount underflow via double nfc_llcp_sock_put(), leading to a use-after-free. Add the missing return statements after the LLCP_CLOSED branches in both functions to prevent the fall-through.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31407", "url": "https://ubuntu.com/security/CVE-2026-31407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: add missing netlink policy validations Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink. These attributes are used by the kernel without any validation. Extend the netlink policies accordingly. Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-43079", "url": "https://ubuntu.com/security/CVE-2026-43079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Skip discovery table for offline dies This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0. WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore] Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at \"pmu->boxes[die] = box\" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43080", "url": "https://ubuntu.com/security/CVE-2026-43080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: Drop large packets with UDP encap syzbot reported a WARN on my patch series [1]. The actual issue is an overflow of 16-bit UDP length field, and it exists in the upstream code. My series added a debug WARN with an overflow check that exposed the issue, that's why syzbot tripped on my patches, rather than on upstream code. syzbot's repro: r0 = socket$pppl2tp(0x18, 0x1, 0x1) r1 = socket$inet6_udp(0xa, 0x2, 0x0) connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c) connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\\x00', '\\xff\\xff', @empty}}}}, 0x32) writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)=\"ee\", 0x34000}], 0x1) It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP encapsulation, and l2tp_xmit_core doesn't check for overflows when it assigns the UDP length field. The value gets trimmed to 16 bites. Add an overflow check that drops oversized packets and avoids sending packets with trimmed UDP length to the wire. syzbot's stack trace (with my patch applied): len >= 65536u WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957 Modules linked in: CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline] RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline] RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327 Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f RSP: 0018:ffffc90003d67878 EFLAGS: 00010293 RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000 RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004 R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900 R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000 FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0 Call Trace: pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x503/0x550 net/socket.c:1195 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1 vfs_writev+0x33c/0x990 fs/read_write.c:1059 do_writev+0x154/0x2e0 fs/read_write.c:1105 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f636479c629 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629 RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31673", "url": "https://ubuntu.com/security/CVE-2026-31673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: read UNIX_DIAG_VFS data under unix_state_lock Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unix_release_sock() clears u->path under unix_state_lock() and drops the path reference after unlocking. Read the inode and device numbers for UNIX_DIAG_VFS while holding unix_state_lock(), then emit the netlink attribute after dropping the lock. This keeps the VFS data stable while the reply is being built.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31681", "url": "https://ubuntu.com/security/CVE-2026-31681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_multiport: validate range encoding in checkentry ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end. The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule. Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43085", "url": "https://ubuntu.com/security/CVE-2026-43085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator When batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send() appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSG_DONE message body. Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes the nfgenmsg payload via nfnl_fill_hdr(), consistent with how __build_packet_message() already constructs NFULNL_MSG_PACKET headers.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43089", "url": "https://ubuntu.com/security/CVE-2026-43089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_mapping() struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43093", "url": "https://ubuntu.com/security/CVE-2026-43093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: tighten UMEM headroom validation to account for tailroom and min frame The current headroom validation in xdp_umem_reg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skb_shared_info stored at the end of XSK frame would be corrupted. HW typically works with 128-aligned sizes so let us provide this value as bare minimum. Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43098", "url": "https://ubuntu.com/security/CVE-2026-43098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: s3fwrn5: allocate rx skb before consuming bytes s3fwrn82_uart_read() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already deliver a complete frame before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43099", "url": "https://ubuntu.com/security/CVE-2026-43099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: fix null-ptr-deref in icmp_build_probe() ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing this error pointer to dev_hold() will cause a kernel crash with null-ptr-deref. Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting \"No Such Interface\".", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43103", "url": "https://ubuntu.com/security/CVE-2026-43103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lapbether: handle NETDEV_PRE_TYPE_CHANGE lapbeth_data_transmit() expects the underlying device type to be ARPHRD_ETHER. Returning NOTIFY_BAD from lapbeth_device_event() makes sure bonding driver can not break this expectation.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31684", "url": "https://ubuntu.com/security/CVE-2026-31684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_csum: validate nested VLAN headers tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43074", "url": "https://ubuntu.com/security/CVE-2026-43074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: defer struct eventpoll free to RCU grace period In certain situations, ep_free() in eventpoll.c will kfree the epi->ep eventpoll struct while it still being used by another concurrent thread. Defer the kfree() to an RCU callback to prevent UAF.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43104", "url": "https://ubuntu.com/security/CVE-2026-43104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix a memory leak in hang state error path When vc4_save_hang_state() encounters an early return condition, it returns without freeing the previously allocated `kernel_state`, leaking memory. Add the missing kfree() calls by consolidating the early return paths into a single place.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43105", "url": "https://ubuntu.com/security/CVE-2026-43105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix memory leak of BO array in hang state The hang state's BO array is allocated separately with kzalloc() in vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the missing kfree() for the BO array before freeing the hang state struct.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43110", "url": "https://ubuntu.com/security/CVE-2026-43110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: validate bsscfg indices in IF events brcmf_fweh_handle_if_event() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check. Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array. [add missing wifi prefix]", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43111", "url": "https://ubuntu.com/security/CVE-2026-43111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: fix use-after-free in roccat_report_event roccat_report_event() iterates over the device->readers list without holding the readers_lock. This allows a concurrent roccat_release() to remove and free a reader while it's still being accessed, leading to a use-after-free. Protect the readers list traversal with the readers_lock mutex.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43112", "url": "https://ubuntu.com/security/CVE-2026-43112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath When cifs_sanitize_prepath is called with an empty string or a string containing only delimiters (e.g., \"/\"), the current logic attempts to check *(cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read. This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL. The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.", "cve_priority": "low", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43113", "url": "https://ubuntu.com/security/CVE-2026-43113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wl1251: validate packet IDs before indexing tx_frames wl1251_tx_packet_cb() uses the firmware completion ID directly to index the fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it. Reject completion IDs that fall outside wl->tx_frames[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2025-54518", "url": "https://ubuntu.com/security/CVE-2025-54518", "cve_description": "Improper isolation of shared resources within the CPU operation cache on Zen 2-based products could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation.", "cve_priority": "high", "cve_public_date": "2026-05-15 05:16:00 UTC" }, { "cve": "CVE-2026-46174", "url": "https://ubuntu.com/security/CVE-2026-46174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2025-71150", "url": "https://ubuntu.com/security/CVE-2025-71150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix refcount leak when invalid session is found on session lookup When a session is found but its state is not SMB2_SESSION_VALID, It indicates that no valid session was found, but it is missing to decrement the reference count acquired by the session lookup, which results in a reference count leak. This patch fixes the issue by explicitly calling ksmbd_user_session_put to release the reference to the session.", "cve_priority": "medium", "cve_public_date": "2026-01-23 15:16:00 UTC" }, { "cve": "CVE-2026-23395", "url": "https://ubuntu.com/security/CVE-2026-23395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ Currently the code attempts to accept requests regardless of the command identifier which may cause multiple requests to be marked as pending (FLAG_DEFER_SETUP) which can cause more than L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer causing an overflow. The spec is quite clear that the same identifier shall not be used on subsequent requests: 'Within each signaling channel a different Identifier shall be used for each successive request or indication.' https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d So this attempts to check if there are any channels pending with the same identifier and rejects if any are found.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31549", "url": "https://ubuntu.com/security/CVE-2026-31549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: cp2615: fix serial string NULL-deref at probe The cp2615 driver uses the USB device serial string as the i2c adapter name but does not make sure that the string exists. Verify that the device has a serial number before accessing it to avoid triggering a NULL-pointer dereference (e.g. with malicious devices).", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31433", "url": "https://ubuntu.com/security/CVE-2026-31433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potencial OOB in get_file_all_info() for compound requests When a compound request consists of QUERY_DIRECTORY + QUERY_INFO (FILE_ALL_INFORMATION) and the first command consumes nearly the entire max_trans_size, get_file_all_info() would blindly call smbConvertToUTF16() with PATH_MAX, causing out-of-bounds write beyond the response buffer. In get_file_all_info(), there was a missing validation check for the client-provided OutputBufferLength before copying the filename into FileName field of the smb2_file_all_info structure. If the filename length exceeds the available buffer space, it could lead to potential buffer overflows or memory corruption during smbConvertToUTF16 conversion. This calculating the actual free buffer size using smb2_calc_max_out_buf_len() and returning -EINVAL if the buffer is insufficient and updating smbConvertToUTF16 to use the actual filename length (clamped by PATH_MAX) to ensure a safe copy operation.", "cve_priority": "high", "cve_public_date": "2026-04-22 09:16:00 UTC" }, { "cve": "CVE-2026-31480", "url": "https://ubuntu.com/security/CVE-2026-31480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential deadlock in cpu hotplug with osnoise The following sequence may leads deadlock in cpu hotplug: task1 task2 task3 ----- ----- ----- mutex_lock(&interface_lock) [CPU GOING OFFLINE] cpus_write_lock(); osnoise_cpu_die(); kthread_stop(task3); wait_for_completion(); osnoise_sleep(); mutex_lock(&interface_lock); cpus_read_lock(); [DEAD LOCK] Fix by swap the order of cpus_read_lock() and mutex_lock(&interface_lock).", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31466", "url": "https://ubuntu.com/security/CVE-2026-31466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix folio isn't locked in softleaf_to_folio() On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows: \tCPU0 CPU1 deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags. This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio() because of the race between folio split and zap_nonpresent_ptes() leading to a folio incorrectly undergoing modification without a folio lock being held. This is a BUG_ON() before commit 93976a20345b (\"mm: eliminate further swapops predicates\"), which in merged in v6.19-rc1. To fix it, add missing smp_rmb() if the softleaf entry is migration entry in softleaf_to_folio() and softleaf_to_page(). [tujinjiang@huawei.com: update function name and comments]", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43054", "url": "https://ubuntu.com/security/CVE-2026-43054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Drain commands in target_reset handler tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS without draining any in-flight commands. The SCSI EH documentation (scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver has made lower layers \"forget about timed out scmds\" and is ready for new commands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug, mpi3mr) enforces this by draining or completing outstanding commands before returning SUCCESS. Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight scsi_cmnd structures for recovery commands (e.g. TUR) while the target core still has async completion work queued for the old se_cmd. The memset in queuecommand zeroes se_lun and lun_ref_active, causing transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN reference prevents transport_clear_lun_ref() from completing, hanging configfs LUN unlink forever in D-state: INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transport_clear_lun_ref+0x78/0x90 [target_core_mod] core_tpg_remove_lun+0x28/0xb0 [target_core_mod] target_fabric_port_unlink+0x50/0x60 [target_core_mod] configfs_unlink+0x156/0x1f0 [configfs] vfs_unlink+0x109/0x290 do_unlinkat+0x1d5/0x2d0 Fix this by making tcm_loop_target_reset() actually drain commands: 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that the target core knows about (those not yet CMD_T_COMPLETE). 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and flush_work() on each se_cmd — this drains any deferred completion work for commands that already had CMD_T_COMPLETE set before the TMR (which the TMR skips via __target_check_io_state()). This is the same pattern used by mpi3mr, scsi_debug, and libsas to drain outstanding commands during reset.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-23401", "url": "https://ubuntu.com/security/CVE-2026-23401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE When installing an emulated MMIO SPTE, do so *after* dropping/zapping the existing SPTE (if it's shadow-present). While commit a54aa15c6bda3 was right about it being impossible to convert a shadow-present SPTE to an MMIO SPTE due to a _guest_ write, it failed to account for writes to guest memory that are outside the scope of KVM. E.g. if host userspace modifies a shadowed gPTE to switch from a memslot to emulted MMIO and then the guest hits a relevant page fault, KVM will install the MMIO SPTE without first zapping the shadow-present SPTE. ------------[ cut here ]------------ is_shadow_present_pte(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm] Call Trace: mmu_set_spte+0x237/0x440 [kvm] ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47fa3f ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-04-01 09:16:00 UTC" }, { "cve": "CVE-2026-31454", "url": "https://ubuntu.com/security/CVE-2026-31454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: save ailp before dropping the AIL lock in push callbacks In xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the AIL lock is dropped to perform buffer IO. Once the cluster buffer no longer protects the log item from reclaim, the log item may be freed by background reclaim or the dquot shrinker. The subsequent spin_lock() call dereferences lip->li_ailp, which is a use-after-free. Fix this by saving the ailp pointer in a local variable while the AIL lock is held and the log item is guaranteed to be valid.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31446", "url": "https://ubuntu.com/security/CVE-2026-31446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in update_super_work when racing with umount Commit b98535d09179 (\"ext4: fix bug_on in start_this_handle during umount filesystem\") moved ext4_unregister_sysfs() before flushing s_sb_upd_work to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups reads during unmount. However, this introduced a use-after-free because update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which accesses the kobject's kernfs_node after it has been freed by kobject_del() in ext4_unregister_sysfs(): update_super_work ext4_put_super ----------------- -------------- ext4_unregister_sysfs(sb) kobject_del(&sbi->s_kobj) __kobject_del() sysfs_remove_dir() kobj->sd = NULL sysfs_put(sd) kernfs_put() // RCU free ext4_notify_error_sysfs(sbi) sysfs_notify(&sbi->s_kobj) kn = kobj->sd // stale pointer kernfs_get(kn) // UAF on freed kernfs_node ext4_journal_destroy() flush_work(&sbi->s_sb_upd_work) Instead of reordering the teardown sequence, fix this by making ext4_notify_error_sysfs() detect that sysfs has already been torn down by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call in that case. A dedicated mutex (s_error_notify_mutex) serializes ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs() to prevent TOCTOU races where the kobject could be deleted between the state_in_sysfs check and the sysfs_notify() call.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31450", "url": "https://ubuntu.com/security/CVE-2026-31450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: publish jinode after initialization ext4_inode_attach_jinode() publishes ei->jinode to concurrent users. It used to set ei->jinode before jbd2_journal_init_jbd_inode(), allowing a reader to observe a non-NULL jinode with i_vfs_inode still unset. The fast commit flush path can then pass this jinode to jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and may crash. Below is the crash I observe: ``` BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xas_find_marked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: filemap_get_folios_tag+0x87/0x2a0 __filemap_fdatawait_range+0x5f/0xd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? cap_safe_nice+0x37/0x70 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 filemap_fdatawait_range_keep_errors+0x12/0x40 ext4_fc_commit+0x697/0x8b0 ? ext4_file_write_iter+0x64b/0x950 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? vfs_write+0x356/0x480 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ext4_sync_file+0xf7/0x370 do_fsync+0x3b/0x80 ? syscall_trace_enter+0x108/0x1d0 __x64_sys_fdatasync+0x16/0x20 do_syscall_64+0x62/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... ``` Fix this by initializing the jbd2_inode first. Use smp_wmb() and WRITE_ONCE() to publish ei->jinode after initialization. Readers use READ_ONCE() to fetch the pointer.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31726", "url": "https://ubuntu.com/security/CVE-2026-31726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix NULL pointer dereference during unbind race Commit b81ac4395bbe (\"usb: gadget: uvc: allow for application to cleanly shutdown\") introduced two stages of synchronization waits totaling 1500ms in uvc_function_unbind() to prevent several types of kernel panics. However, this timing-based approach is insufficient during power management (PM) transitions. When the PM subsystem starts freezing user space processes, the wait_event_interruptible_timeout() is aborted early, which allows the unbind thread to proceed and nullify the gadget pointer (cdev->gadget = NULL): [ 814.123447][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind() [ 814.178583][ T3173] PM: suspend entry (deep) [ 814.192487][ T3173] Freezing user space processes [ 814.197668][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind no clean disconnect, wait for release When the PM subsystem resumes or aborts the suspend and tasks are restarted, the V4L2 release path is executed and attempts to access the already nullified gadget pointer, triggering a kernel panic: [ 814.292597][ C0] PM: pm_system_irq_wakeup: 479 triggered dhdpcie_host_wake [ 814.386727][ T3173] Restarting tasks ... [ 814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 814.404021][ T4558] pc : usb_gadget_deactivate+0x14/0xf4 [ 814.404031][ T4558] lr : usb_function_deactivate+0x54/0x94 [ 814.404078][ T4558] Call trace: [ 814.404080][ T4558] usb_gadget_deactivate+0x14/0xf4 [ 814.404083][ T4558] usb_function_deactivate+0x54/0x94 [ 814.404087][ T4558] uvc_function_disconnect+0x1c/0x5c [ 814.404092][ T4558] uvc_v4l2_release+0x44/0xac [ 814.404095][ T4558] v4l2_release+0xcc/0x130 Address the race condition and NULL pointer dereference by: 1. State Synchronization (flag + mutex) Introduce a 'func_unbound' flag in struct uvc_device. This allows uvc_function_disconnect() to safely skip accessing the nullified cdev->gadget pointer. As suggested by Alan Stern, this flag is protected by a new mutex (uvc->lock) to ensure proper memory ordering and prevent instruction reordering or speculative loads. This mutex is also used to protect 'func_connected' for consistent state management. 2. Explicit Synchronization (completion) Use a completion to synchronize uvc_function_unbind() with the uvc_vdev_release() callback. This prevents Use-After-Free (UAF) by ensuring struct uvc_device is freed after all video device resources are released.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31728", "url": "https://ubuntu.com/security/CVE-2026-31728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop A race condition between gether_disconnect() and eth_stop() leads to a NULL pointer dereference. Specifically, if eth_stop() is triggered concurrently while gether_disconnect() is tearing down the endpoints, eth_stop() attempts to access the cleared endpoint descriptor, causing the following NPE: Unable to handle kernel NULL pointer dereference Call trace: __dwc3_gadget_ep_enable+0x60/0x788 dwc3_gadget_ep_enable+0x70/0xe4 usb_ep_enable+0x60/0x15c eth_stop+0xb8/0x108 Because eth_stop() crashes while holding the dev->lock, the thread running gether_disconnect() fails to acquire the same lock and spins forever, resulting in a hardlockup: Core - Debugging Information for Hardlockup core(7) Call trace: queued_spin_lock_slowpath+0x94/0x488 _raw_spin_lock+0x64/0x6c gether_disconnect+0x19c/0x1e8 ncm_set_alt+0x68/0x1a0 composite_setup+0x6a0/0xc50 The root cause is that the clearing of dev->port_usb in gether_disconnect() is delayed until the end of the function. Move the clearing of dev->port_usb to the very beginning of gether_disconnect() while holding dev->lock. This cuts off the link immediately, ensuring eth_stop() will see dev->port_usb as NULL and safely bail out.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31721", "url": "https://ubuntu.com/security/CVE-2026-31721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: move list and spinlock inits from bind to alloc There was an issue when you did the following: - setup and bind an hid gadget - open /dev/hidg0 - use the resulting fd in EPOLL_CTL_ADD - unbind the UDC - bind the UDC - use the fd in EPOLL_CTL_DEL When CONFIG_DEBUG_LIST was enabled, a list_del corruption was reported within remove_wait_queue (via ep_remove_wait_queue). After some debugging I found out that the queues, which f_hid registers via poll_wait were the problem. These were initialized using init_waitqueue_head inside hidg_bind. So effectively, the bind function re-initialized the queues while there were still items in them. The solution is to move the initialization from hidg_bind to hidg_alloc to extend their lifetimes to the lifetime of the function instance. Additionally, I found many other possibly problematic init calls in the bind function, which I moved as well.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31670", "url": "https://ubuntu.com/security/CVE-2026-31670", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rfkill: prevent unlimited numbers of rfkill events from being created Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a \"large\" number (i.e. 1000) to prevent abuses like this.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31634", "url": "https://ubuntu.com/security/CVE-2026-31634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix reference count leak in rxrpc_server_keyring() This patch fixes a reference count leak in rxrpc_server_keyring() by checking if rx->securities is already set.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31651", "url": "https://ubuntu.com/security/CVE-2026-31651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix NULL-deref on disconnect Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31656", "url": "https://ubuntu.com/security/CVE-2026-31656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` <4> [487.221889] Workqueue: i915-unordered engine_retire [i915] <4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] Call Trace: <4> [487.222711] <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ? __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ? __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ? __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] ``` Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it. (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31658", "url": "https://ubuntu.com/security/CVE-2026-31658", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit() When dma_map_single() fails in tse_start_xmit(), the function returns NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure. Add dev_kfree_skb_any() before returning to properly free the skb.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31660", "url": "https://ubuntu.com/security/CVE-2026-31660", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: allocate rx skb before consuming bytes pn532_receive_buf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already hand a complete frame to pn533_recv_frame() before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31661", "url": "https://ubuntu.com/security/CVE-2026-31661", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: Fix dma_free_coherent() size dma_alloc_consistent() may change the size to align it. The new size is saved in alloced. Change the free size to match the allocation size.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31662", "url": "https://ubuntu.com/security/CVE-2026-31662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round. Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31665", "url": "https://ubuntu.com/security/CVE-2026-31665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: fix use-after-free in timeout object destroy nft_ct_timeout_obj_destroy() frees the timeout object with kfree() immediately after nf_ct_untimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcu_dereference() in nf_ct_timeout_data(). Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c. KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2024-56557", "url": "https://ubuntu.com/security/CVE-2024-56557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer The AD7923 was updated to support devices with 8 channels, but the size of tx_buf and ring_xfer was not increased accordingly, leading to a potential buffer overflow in ad7923_update_scan_mode().", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2024-36898", "url": "https://ubuntu.com/security/CVE-2024-36898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: fix uninitialised kfifo If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace. Initialise the kfifo in the case where the software debounce is already active.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2025-40016", "url": "https://ubuntu.com/security/CVE-2025-40016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID. In a previous attempt commit 3dd075fe8ebb (\"media: uvcvideo: Require entities to have a non-zero unique ID\"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2026-31667", "url": "https://ubuntu.com/security/CVE-2026-31667", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: uinput - fix circular locking dependency with ff-core A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller): ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex The cycle is caused by four lock acquisition paths: 1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex. 2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex. 3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex. 4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex. Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes. To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock. Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible. Lock ordering after the fix: ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31671", "url": "https://ubuntu.com/security/CVE-2026-31671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_report() struct xfrm_user_report is a __u8 proto field followed by a struct xfrm_selector which means there is three \"empty\" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31672", "url": "https://ubuntu.com/security/CVE-2026-31672", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00usb: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the USB anchor lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43336", "url": "https://ubuntu.com/security/CVE-2026-43336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: chacha: Zeroize permuted_state before it leaves scope Since the ChaCha permutation is invertible, the local variable 'permuted_state' is sufficient to compute the original 'state', and thus the key, even after the permutation has been done. While the kernel is quite inconsistent about zeroizing secrets on the stack (and some prominent userspace crypto libraries don't bother at all since it's not guaranteed to work anyway), the kernel does try to do it as a best practice, especially in cases involving the RNG. Thus, explicitly zeroize 'permuted_state' before it goes out of scope.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31695", "url": "https://ubuntu.com/security/CVE-2026-31695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free Currently we execute `SET_NETDEV_DEV(dev, &priv->lowerdev->dev)` for the virt_wifi net devices. However, unregistering a virt_wifi device in netdev_run_todo() can happen together with the device referenced by SET_NETDEV_DEV(). It can result in use-after-free during the ethtool operations performed on a virt_wifi device that is currently being unregistered. Such a net device can have the `dev.parent` field pointing to the freed memory, but ethnl_ops_begin() calls `pm_runtime_get_sync(dev->dev.parent)`. Let's remove SET_NETDEV_DEV for virt_wifi to avoid bugs like this: ================================================================== BUG: KASAN: slab-use-after-free in __pm_runtime_resume+0xe2/0xf0 Read of size 2 at addr ffff88810cfc46f8 by task pm/606 Call Trace: dump_stack_lvl+0x4d/0x70 print_report+0x170/0x4f3 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 kasan_report+0xda/0x110 ? __pm_runtime_resume+0xe2/0xf0 ? __pm_runtime_resume+0xe2/0xf0 __pm_runtime_resume+0xe2/0xf0 ethnl_ops_begin+0x49/0x270 ethnl_set_features+0x23c/0xab0 ? __pfx_ethnl_set_features+0x10/0x10 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xf/0xf0 ? local_clock+0x10/0x30 ? kasan_save_track+0x25/0x60 ? __kasan_kmalloc+0x7f/0x90 ? genl_family_rcv_msg_attrs_parse.isra.0+0x150/0x2c0 genl_family_rcv_msg_doit+0x1e7/0x2c0 ? __pfx_genl_family_rcv_msg_doit+0x10/0x10 ? __pfx_cred_has_capability.isra.0+0x10/0x10 ? stack_trace_save+0x8e/0xc0 genl_rcv_msg+0x411/0x660 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_ethnl_set_features+0x10/0x10 netlink_rcv_skb+0x121/0x380 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_down_read+0x10/0x10 genl_rcv+0x23/0x30 netlink_unicast+0x60f/0x830 ? __pfx_netlink_unicast+0x10/0x10 ? __pfx___alloc_skb+0x10/0x10 netlink_sendmsg+0x6ea/0xbc0 ? __pfx_netlink_sendmsg+0x10/0x10 ? __futex_queue+0x10b/0x1f0 ____sys_sendmsg+0x7a2/0x950 ? copy_msghdr_from_user+0x26b/0x430 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ___sys_sendmsg+0xf8/0x180 ? __pfx____sys_sendmsg+0x10/0x10 ? __pfx_futex_wait+0x10/0x10 ? fdget+0x2e4/0x4a0 __sys_sendmsg+0x11f/0x1c0 ? __pfx___sys_sendmsg+0x10/0x10 do_syscall_64+0xe2/0x570 ? exc_page_fault+0x66/0xb0 entry_SYSCALL_64_after_hwframe+0x77/0x7f This fix may be combined with another one in the ethtool subsystem: https://lore.kernel.org/all/20260322075917.254874-1-alex.popov@linux.com/T/#u", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2024-56584", "url": "https://ubuntu.com/security/CVE-2024-56584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/tctx: work around xa_store() allocation error issue syzbot triggered the following WARN_ON: WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51 which is the WARN_ON_ONCE(!xa_empty(&tctx->xa)); sanity check in __io_uring_free() when a io_uring_task is going through its final put. The syzbot test case includes injecting memory allocation failures, and it very much looks like xa_store() can fail one of its memory allocations and end up with ->head being non-NULL even though no entries exist in the xarray. Until this issue gets sorted out, work around it by attempting to iterate entries in our xarray, and WARN_ON_ONCE() if one is found.", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2026-31720", "url": "https://ubuntu.com/security/CVE-2026-31720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: validate control request size f_audio_complete() copies req->length bytes into a 4-byte stack variable: u32 data = 0; memcpy(&data, req->buf, req->length); req->length is derived from the host-controlled USB request path, which can lead to a stack out-of-bounds write. Validate req->actual against the expected payload size for the supported control selectors and decode only the expected amount of data. This avoids copying a host-influenced length into a fixed-size stack object.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43342", "url": "https://ubuntu.com/security/CVE-2026-43342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Protect RNDIS options with mutex The class/subclass/protocol options are suspectible to race conditions as they can be accessed concurrently through configfs. Use existing mutex to protect these options. This issue was identified during code inspection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43343", "url": "https://ubuntu.com/security/CVE-2026-43343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_subset: Fix unbalanced refcnt in geth_free geth_alloc() increments the reference count, but geth_free() fails to decrement it. This prevents the configuration of attributes via configfs after unlinking the function. Decrement the reference count in geth_free() to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-68256", "url": "https://ubuntu.com/security/CVE-2025-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser The Information Element (IE) parser rtw_get_ie() trusted the length byte of each IE without validating that the IE body (len bytes after the 2-byte header) fits inside the remaining frame buffer. A malformed frame can advertise an IE length larger than the available data, causing the parser to increment its pointer beyond the buffer end. This results in out-of-bounds reads or, depending on the pattern, an infinite loop. Fix by validating that (offset + 2 + len) does not exceed the limit before accepting the IE or advancing to the next element. This prevents OOB reads and ensures the parser terminates safely on malformed frames.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40103", "url": "https://ubuntu.com/security/CVE-2025-40103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix refcount leak for cifs_sb_tlink Fix three refcount inconsistency issues related to `cifs_sb_tlink`. Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be called after successful calls to `cifs_sb_tlink()`. Three calls fail to update refcount accordingly, leading to possible resource leaks.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-38006", "url": "https://ubuntu.com/security/CVE-2025-38006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: Don't access ifa_index when missing In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but only when the struct ifaddrmsg is provided. Otherwise it will be comparing to uninitialised memory - reproducible in the syzkaller case from dhcpd, or busybox \"ip addr show\". The kernel MCTP implementation has always filtered by ifa_index, so existing userspace programs expecting to dump MCTP addresses must already be passing a valid ifa_index value (either 0 or a real index). BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40323", "url": "https://ubuntu.com/security/CVE-2025-40323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Set fb_display[i]->mode to NULL when the mode is released Recently, we discovered the following issue through syzkaller: BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0. Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2026-23031", "url": "https://ubuntu.com/security/CVE-2026-23031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak In gs_can_open(), the URBs for USB-in transfers are allocated, added to the parent->rx_submitted anchor and submitted. In the complete callback gs_usb_receive_bulk_callback(), the URB is processed and resubmitted. In gs_can_close() the URBs are freed by calling usb_kill_anchored_urbs(parent->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in gs_can_close(). Fix the memory leak by anchoring the URB in the gs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-43324", "url": "https://ubuntu.com/security/CVE-2026-43324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix interrupt synchronization error This fixes an error in synchronization in the dummy-hcd driver. The error has a somewhat involved history. The synchronization mechanism was introduced by commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), which added an emulated \"interrupts enabled\" flag together with code emulating synchronize_irq() (it waits until all current handler callbacks have returned). But the emulated interrupt-disable occurred too late, after the driver containing the handler callback routines had been told that it was unbound and no more callbacks would occur. Commit 4a5d797a9f9c (\"usb: gadget: dummy_hcd: fix gpf in gadget_setup\") tried to fix this by moving the synchronize_irq() emulation code from dummy_stop() to dummy_pullup(), which runs before the unbind callback. There still were races, though, because the emulated interrupt-disable still occurred too late. It couldn't be moved to dummy_pullup(), because that routine can be called for reasons other than an impending unbind. Therefore commits 7dc0c55e9f30 (\"USB: UDC core: Add udc_async_callbacks gadget op\") and 04145a03db9d (\"USB: UDC: Implement udc_async_callbacks in dummy-hcd\") added an API allowing the UDC core to tell dummy-hcd exactly when emulated interrupts and their callbacks should be disabled. That brings us to the current state of things, which is still wrong because the emulated synchronize_irq() occurs before the emulated interrupt-disable! That's no good, beause it means that more emulated interrupts can occur after the synchronize_irq() emulation has run, leading to the possibility that a callback handler may be running when the gadget driver is unbound. To fix this, we have to move the synchronize_irq() emulation code yet again, to the dummy_udc_async_callbacks() routine, which takes care of enabling and disabling emulated interrupt requests. The synchronization will now run immediately after emulated interrupts are disabled, which is where it belongs.", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43327", "url": "https://ubuntu.com/security/CVE-2026-43327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix locking/synchronization error Syzbot testing was able to provoke an addressing exception and crash in the usb_gadget_udc_reset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second (\"driver\") argument of NULL. The bad caller was set_link_state() in dummy_hcd.c, and the problem arose because of a race between a USB reset and driver unbind. These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first. The error responsible for the syzbot crash occurred because the stop_activity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stop_activity() occurs in set_link_state() when handling an emulated USB reset, after the test of dum->ints_enabled and before the increment of dum->callback_usage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->ints_enabled and dum->driver. Normally this other thread would have to wait for dum->callback_usage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callback_usage had not yet been incremented. The fix is to increment dum->callback_usage _before_ calling stop_activity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usb_gadget_udc_reset() safely returns and dum->callback_usage has been decremented again.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31737", "url": "https://ubuntu.com/security/CVE-2026-31737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ftgmac100: fix ring allocation unwind on open failure ftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, and rx_scratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function. Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31738", "url": "https://ubuntu.com/security/CVE-2026-31738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: validate ND option lengths in vxlan_na_create vxlan_na_create() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31747", "url": "https://ubuntu.com/security/CVE-2026-31747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me4000: Fix potential overrun of firmware buffer `me4000_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`. Note: The firmware loading was totally broken before commit ac584af59945 (\"staging: comedi: me4000: fix firmware downloading\"), but that is the most sensible target for this fix.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31748", "url": "https://ubuntu.com/security/CVE-2026-31748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me_daq: Fix potential overrun of firmware buffer `me2600_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Although it checks that the supplied firmware is at least 16 bytes long, it does not check that it is long enough to contain the data stream. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31749", "url": "https://ubuntu.com/security/CVE-2026-31749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: ni_atmio16d: Fix invalid clean-up after failed attach If the driver's COMEDI \"attach\" handler function (`atmio16d_attach()`) returns an error, the COMEDI core will call the driver's \"detach\" handler function (`atmio16d_detach()`) to clean up. This calls `reset_atmio16d()` unconditionally, but depending on where the error occurred in the attach handler, the device may not have been sufficiently initialized to call `reset_atmio16d()`. It uses `dev->iobase` as the I/O port base address and `dev->private` as the pointer to the COMEDI device's private data structure. `dev->iobase` may still be set to its initial value of 0, which would result in undesired writes to low I/O port addresses. `dev->private` may still be `NULL`, which would result in null pointer dereferences. Fix `atmio16d_detach()` by checking that `dev->private` is valid (non-null) before calling `reset_atmio16d()`. This implies that `dev->iobase` was set correctly since that is set up before `dev->private`.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43340", "url": "https://ubuntu.com/security/CVE-2026-43340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Reinit dev->spinlock between attachments to low-level drivers `struct comedi_device` is the main controlling structure for a COMEDI device created by the COMEDI subsystem. It contains a member `spinlock` containing a spin-lock that is initialized by the COMEDI subsystem, but is reserved for use by a low-level driver attached to the COMEDI device (at least since commit 25436dc9d84f (\"Staging: comedi: remove RT code\")). Some COMEDI devices (those created on initialization of the COMEDI subsystem when the \"comedi.comedi_num_legacy_minors\" parameter is non-zero) can be attached to different low-level drivers over their lifetime using the `COMEDI_DEVCONFIG` ioctl command. This can result in inconsistent lock states being reported when there is a mismatch in the spin-lock locking levels used by each low-level driver to which the COMEDI device has been attached. Fix it by reinitializing `dev->spinlock` before calling the low-level driver's `attach` function pointer if `CONFIG_LOCKDEP` is enabled.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31751", "url": "https://ubuntu.com/security/CVE-2026-31751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: dt2815: add hardware detection to prevent crash The dt2815 driver crashes when attached to I/O ports without actual hardware present. This occurs because syzkaller or users can attach the driver to arbitrary I/O addresses via COMEDI_DEVCONFIG ioctl. When no hardware exists at the specified port, inb() operations return 0xff (floating bus), but outb() operations can trigger page faults due to undefined behavior, especially under race conditions: BUG: unable to handle page fault for address: 000000007fffff90 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:dt2815_attach+0x6e0/0x1110 Add hardware detection by reading the status register before attempting any write operations. If the read returns 0xff, assume no hardware is present and fail the attach with -ENODEV. This prevents crashes from outb() operations on non-existent hardware.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31752", "url": "https://ubuntu.com/security/CVE-2026-31752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: validate ND option lengths br_nd_send() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31754", "url": "https://ubuntu.com/security/CVE-2026-31754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix state inconsistency on gadget init failure When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency. When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error, so cdns_role_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles. This leads to a synchronous external abort in xhci_gen_setup() when setting up the host controller: [ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408 [ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switch Fix by calling cdns_drd_gadget_off() in the error path to properly clean up the DRD gadget state.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31755", "url": "https://ubuntu.com/security/CVE-2026-31755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix NULL pointer dereference in ep_queue When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when __cdns3_gadget_ep_queue() is called, causing a kernel crash. Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints. This prevents potential crashes when ep_queue is called on endpoints that are not ready.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31756", "url": "https://ubuntu.com/security/CVE-2026-31756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop() dwc2_gadget_exit_clock_gating() internally calls call_gadget() macro, which expects hsotg->lock to be held since it does spin_unlock/spin_lock around the gadget driver callback invocation. However, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating() without holding the lock. This leads to: - spin_unlock on a lock that is not held (undefined behavior) - The lock remaining held after dwc2_gadget_exit_clock_gating() returns, causing a deadlock when spin_lock_irqsave() is called later in the same function. Fix this by acquiring hsotg->lock before calling dwc2_gadget_exit_clock_gating() and releasing it afterwards, which satisfies the locking requirement of the call_gadget() macro.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31758", "url": "https://ubuntu.com/security/CVE-2026-31758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbtmc: Flush anchored URBs in usbtmc_release When calling usbtmc_release, pending anchored URBs must be flushed or killed to prevent use-after-free errors (e.g. in the HCD giveback path). Call usbtmc_draw_down() to allow anchored URBs to be completed.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31759", "url": "https://ubuntu.com/security/CVE-2026-31759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: fix double free in ulpi_register_interface() error path When device_register() fails, ulpi_register() calls put_device() on ulpi->dev. The device release callback ulpi_dev_release() drops the OF node reference and frees ulpi, but the current error path in ulpi_register_interface() then calls kfree(ulpi) again, causing a double free. Let put_device() handle the cleanup through ulpi_dev_release() and avoid freeing ulpi again in ulpi_register_interface().", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31761", "url": "https://ubuntu.com/security/CVE-2026-31761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Move iio_device_register() to correct location iio_device_register() should be at the end of the probe function to prevent race conditions. Place iio_device_register() at the end of the probe function and place iio_device_unregister() accordingly.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31762", "url": "https://ubuntu.com/security/CVE-2026-31762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix irq resource leak The interrupt handler is setup but only a few lines down if iio_trigger_register() fails the function returns without properly releasing the handler. Add cleanup goto to resolve resource leak. Detected by Smatch: drivers/iio/gyro/mpu3050-core.c:1128 mpu3050_trigger_probe() warn: 'irq' from request_threaded_irq() not released on lines: 1124.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31763", "url": "https://ubuntu.com/security/CVE-2026-31763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix incorrect free_irq() variable The handler for the IRQ part of this driver is mpu3050->trig but, in the teardown free_irq() is called with handler mpu3050. Use correct IRQ handler when calling free_irq().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31770", "url": "https://ubuntu.com/security/CVE-2026-31770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) Fix division by zero in occ_show_power_1() In occ_show_power_1() case 1, the accumulator is divided by update_tag without checking for zero. If no samples have been collected yet (e.g. during early boot when the sensor block is included but hasn't been updated), update_tag is zero, causing a kernel divide-by-zero crash. The 2019 fix in commit 211186cae14d (\"hwmon: (occ) Fix division by zero issue\") only addressed occ_get_powr_avg() used by occ_show_power_2() and occ_show_power_a0(). This separate code path in occ_show_power_1() was missed. Fix this by reusing the existing occ_get_powr_avg() helper, which already handles the zero-sample case and uses mul_u64_u32_div() to multiply before dividing for better precision. Move the helper above occ_show_power_1() so it is visible at the call site. [groeck: Fix alignment problems reported by checkpatch]", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43334", "url": "https://ubuntu.com/security/CVE-2026-43334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: force responder MITM requirements before building the pairing response smp_cmd_pairing_req() currently builds the pairing response from the initiator auth_req before enforcing the local BT_SECURITY_HIGH requirement. If the initiator omits SMP_AUTH_MITM, the response can also omit it even though the local side still requires MITM. tk_request() then sees an auth value without SMP_AUTH_MITM and may select JUST_CFM, making method selection inconsistent with the pairing policy the responder already enforces. When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMP_AUTH_MITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31773", "url": "https://ubuntu.com/security/CVE-2026-31773", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: derive legacy responder STK authentication from MITM state The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved. For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result. This also keeps the legacy path aligned with the Secure Connections code, which already treats JUST_WORKS/JUST_CFM as unauthenticated.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31776", "url": "https://ubuntu.com/security/CVE-2026-31776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix missing SPDIFI1 index handling SPDIF1 DAIO type isn't properly handled in daio_device_index() for hw20k2, and it returned -EINVAL, which ended up with the out-of-bounds array access. Follow the hw20k1 pattern and return the proper index for this type, too.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31778", "url": "https://ubuntu.com/security/CVE-2026-31778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix stack out-of-bounds read in init_card The loop creates a whitespace-stripped copy of the card shortname where `len < sizeof(card->id)` is used for the bounds check. Since sizeof(card->id) is 16 and the local id buffer is also 16 bytes, writing 16 non-space characters fills the entire buffer, overwriting the terminating nullbyte. When this non-null-terminated string is later passed to snd_card_set_id() -> copy_valid_id_string(), the function scans forward with `while (*nid && ...)` and reads past the end of the stack buffer, reading the contents of the stack. A USB device with a product name containing many non-ASCII, non-space characters (e.g. multibyte UTF-8) will reliably trigger this as follows: BUG: KASAN: stack-out-of-bounds in copy_valid_id_string sound/core/init.c:696 [inline] BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c sound/core/init.c:718 The off-by-one has been present since commit bafeee5b1f8d (\"ALSA: snd_usb_caiaq: give better shortname\") from June 2009 (v2.6.31-rc1), which first introduced this whitespace-stripping loop. The original code never accounted for the null terminator when bounding the copy. Fix this by changing the loop bound to `sizeof(card->id) - 1`, ensuring at least one byte remains as the null terminator.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31780", "url": "https://ubuntu.com/security/CVE-2026-31780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation The variable valuesize is declared as u8 but accumulates the total length of all SSIDs to scan. Each SSID contributes up to 33 bytes (IEEE80211_MAX_SSID_LEN + 1), and with WILC_MAX_NUM_PROBED_SSID (10) SSIDs the total can reach 330, which wraps around to 74 when stored in a u8. This causes kmalloc to allocate only 75 bytes while the subsequent memcpy writes up to 331 bytes into the buffer, resulting in a 256-byte heap buffer overflow. Widen valuesize from u8 to u32 to accommodate the full range.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31781", "url": "https://ubuntu.com/security/CVE-2026-31781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ioc32: stop speculation on the drm_compat_ioctl path The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling array_index_nospec() on the index to the function pointer list.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43333", "url": "https://ubuntu.com/security/CVE-2026-43333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject direct access to nullable PTR_TO_BUF pointers check_mem_access() matches PTR_TO_BUF via base_type() which strips PTR_MAYBE_NULL, allowing direct dereference without a null check. Map iterator ctx->key and ctx->value are PTR_TO_BUF | PTR_MAYBE_NULL. On stop callbacks these are NULL, causing a kernel NULL dereference. Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching the existing PTR_TO_BTF_ID pattern.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31415", "url": "https://ubuntu.com/security/CVE-2026-31415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid overflows in ip6_datagram_send_ctl() Yiming Qian reported : I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via `skb_under_panic()` (local DoS). The core issue is a mismatch between: - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type `__u16`) and - a pointer to the *last* provided destination-options header (`opt->dst1opt`) when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided. - `include/net/ipv6.h`: - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible). (lines 291-307, especially 298) - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`: - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen` without rejecting duplicates. (lines 909-933) - `net/ipv6/ip6_output.c:__ip6_append_data()`: - Uses `opt->opt_flen + opt->opt_nflen` to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - `net/ipv6/ip6_output.c:__ip6_make_skb()`: - Calls `ipv6_push_frag_opts()` if `opt->opt_flen` is non-zero. (lines 1930-1934) - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`: - Push size comes from `ipv6_optlen(opt->dst1opt)` (based on the pointed-to header). (lines 1179-1185 and 1206-1211) 1. `opt_flen` is a 16-bit accumulator: - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`. 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs and increments `opt_flen` each time: - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`: - It computes `len = ((hdr->hdrlen + 1) << 3);` - It checks `CAP_NET_RAW` using `ns_capable(net->user_ns, CAP_NET_RAW)`. (line 922) - Then it does: - `opt->opt_flen += len;` (line 927) - `opt->dst1opt = hdr;` (line 928) There is no duplicate rejection here (unlike the legacy `IPV6_2292DSTOPTS` path which rejects duplicates at `net/ipv6/datagram.c:901-904`). If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps while `dst1opt` still points to a large (2048-byte) destination-options header. In the attached PoC (`poc.c`): - 32 cmsgs with `hdrlen=255` => `len = (255+1)*8 = 2048` - 1 cmsg with `hdrlen=0` => `len = 8` - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8` - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header. 3. The transmit path sizes headers using the wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1463-1465`: - `headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;` With wrapped `opt_flen`, `headersize`/headroom decisions underestimate what will be pushed later. 4. When building the final skb, the actual push length comes from `dst1opt` and is not limited by wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1930-1934`: - `if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);` - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes `dst1opt` via `ipv6_push_exthdr()`. - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does: - `skb_push(skb, ipv6_optlen(opt));` - `memcpy(h, opt, ipv6_optlen(opt));` With insufficient headroom, `skb_push()` underflows and triggers `skb_under_panic()` -> `BUG()`: - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`) - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`) - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target netns user namespace (`ns_capable(net->user_ns, CAP_NET_RAW)`). - Root (or any task with `CAP_NET_RAW`) can trigger this without user namespaces. - An unprivileged `uid=1000` user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced `CAP_NET_RAW` (the attached PoC does this). - Local denial of service: kernel BUG/panic (system crash). - ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31422", "url": "https://ubuntu.com/security/CVE-2026-31422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_flow: fix NULL pointer dereference on shared blocks flow_change() calls tcf_block_q() and dereferences q->handle to derive a default baseclass. Shared blocks leave block->q NULL, causing a NULL deref when a flow filter without a fully qualified baseclass is created on a shared block. Check tcf_block_shared() before accessing block->q and return -EINVAL for shared blocks. This avoids the null-deref shown below: ======================================================================= KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:flow_change (net/sched/cls_flow.c:508) Call Trace: tc_new_tfilter (net/sched/cls_api.c:2432) rtnetlink_rcv_msg (net/core/rtnetlink.c:6980) [...] =======================================================================", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31421", "url": "https://ubuntu.com/security/CVE-2026-31421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL pointer dereference on shared blocks The old-method path in fw_classify() calls tcf_block_q() and dereferences q->handle. Shared blocks leave block->q NULL, causing a NULL deref when an empty cls_fw filter is attached to a shared block and a packet with a nonzero major skb mark is classified. Reject the configuration in fw_change() when the old method (no TCA_OPTIONS) is used on a shared block, since fw_classify()'s old-method path needs block->q which is NULL for shared blocks. The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fw_classify (net/sched/cls_fw.c:81) Call Trace: tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860) tc_run (net/core/dev.c:4401) __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31417", "url": "https://ubuntu.com/security/CVE-2026-31417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix overflow when accumulating packets Add a check to ensure that `x25_sock.fraglen` does not overflow. The `fraglen` also needs to be resetted when purging `fragment_queue` in `x25_clear_queues()`.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43014", "url": "https://ubuntu.com/security/CVE-2026-43014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: properly unregister fixed rate clocks The additional resources allocated with clk_register_fixed_rate() need to be released with clk_unregister_fixed_rate(), otherwise they are lost.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43015", "url": "https://ubuntu.com/security/CVE-2026-43015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix clk handling on PCI glue driver removal platform_device_unregister() may still want to use the registered clks during runtime resume callback. Note that there is a commit d82d5303c4c5 (\"net: macb: fix use after free on rmmod\") that addressed the similar problem of clk vs platform device unregistration but just moved the bug to another place. Save the pointers to clks into local variables for reuse after platform device is unregistered. BUG: KASAN: use-after-free in clk_prepare+0x5a/0x60 Read of size 8 at addr ffff888104f85e00 by task modprobe/597 CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x8d/0xba print_report+0x17f/0x496 kasan_report+0xd9/0x180 clk_prepare+0x5a/0x60 macb_runtime_resume+0x13d/0x410 [macb] pm_generic_runtime_resume+0x97/0xd0 __rpm_callback+0xc8/0x4d0 rpm_callback+0xf6/0x230 rpm_resume+0xeeb/0x1a70 __pm_runtime_resume+0xb4/0x170 bus_remove_device+0x2e3/0x4b0 device_del+0x5b3/0xdc0 platform_device_del+0x4e/0x280 platform_device_unregister+0x11/0x50 pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 519: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x8e/0x90 __clk_register+0x458/0x2890 clk_hw_register+0x1a/0x60 __clk_hw_register_fixed_rate+0x255/0x410 clk_register_fixed_rate+0x3c/0xa0 macb_probe+0x1d8/0x42e [macb_pci] local_pci_probe+0xd7/0x190 pci_device_probe+0x252/0x600 really_probe+0x255/0x7f0 __driver_probe_device+0x1ee/0x330 driver_probe_device+0x4c/0x1f0 __driver_attach+0x1df/0x4e0 bus_for_each_dev+0x15d/0x1f0 bus_add_driver+0x486/0x5e0 driver_register+0x23a/0x3d0 do_one_initcall+0xfd/0x4d0 do_init_module+0x18b/0x5a0 load_module+0x5663/0x7950 __do_sys_finit_module+0x101/0x180 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 597: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x180 __kmem_cache_free+0xbc/0x320 clk_unregister+0x6de/0x8d0 macb_remove+0x73/0xc0 [macb_pci] pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31425", "url": "https://ubuntu.com/security/CVE-2026-31425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: ib: reject FRMR registration before IB connection is established rds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_data and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with i_cm_id = NULL because the connection worker has not yet called rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses the control message before any connection establishment, allowing rds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash the kernel. The existing guard in rds_ib_reg_frmr() only checks for !ic (added in commit 9e630bcb7701), which does not catch this case since ic is allocated early and is always non-NULL once the connection object exists. KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920 Call Trace: rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167) rds_ib_map_frmr (net/rds/ib_frmr.c:252) rds_ib_reg_frmr (net/rds/ib_frmr.c:430) rds_ib_get_mr (net/rds/ib_rdma.c:615) __rds_rdma_map (net/rds/rdma.c:295) rds_cmsg_rdma_map (net/rds/rdma.c:860) rds_sendmsg (net/rds/send.c:1363) ____sys_sendmsg do_syscall_64 Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all non-NULL before proceeding with FRMR registration, mirroring the guard already present in rds_ib_post_inv(). Return -ENODEV when the connection is not ready, which the existing error handling in rds_cmsg_send() converts to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to start the connection worker.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43020", "url": "https://ubuntu.com/security/CVE-2026-43020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate LTK enc_size on load Load Long Term Keys stores the user-provided enc_size and later uses it to size fixed-size stack operations when replying to LE LTK requests. An enc_size larger than the 16-byte key buffer can therefore overflow the reply stack buffer. Reject oversized enc_size values while validating the management LTK record so invalid keys never reach the stored key state.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43024", "url": "https://ubuntu.com/security/CVE-2026-43024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject immediate NF_QUEUE verdict nft_queue is always used from userspace nftables to deliver the NF_QUEUE verdict. Immediately emitting an NF_QUEUE verdict is never used by the userspace nft tools, so reject immediate NF_QUEUE verdicts. The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NF_QUEUE immediate verdicts to address this issue.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31424", "url": "https://ubuntu.com/security/CVE-2026-31424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP Weiming Shi says: xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_* constants. This is only correct for families whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING). ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports: - arpt_CLASSIFY - arpt_mangle - arpt_MARK that provide explicit NFPROTO_ARP match/target declarations.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43026", "url": "https://ubuntu.com/security/CVE-2026-43026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT. The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields. Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled. Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43027", "url": "https://ubuntu.com/security/CVE-2026-43027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_helper: pass helper to expect cleanup nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expect_iter_me() never matches any expectation and all of them survive the cleanup. After unregister returns, nfnl_cthelper_del() frees the helper object immediately. Subsequent expectation dumps or packet-driven init_conntrack() calls then dereference the freed exp->helper, causing a use-after-free. Pass the actual helper pointer so expectations referencing it are properly destroyed before the helper object is freed. BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43028", "url": "https://ubuntu.com/security/CVE-2026-43028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: ensure names are nul-terminated Reject names that lack a \\0 character before feeding them to functions that expect c-strings. Fixes tag is the most recent commit that needs this change.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31416", "url": "https://ubuntu.com/security/CVE-2026-31416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: account for netlink header size This is a followup to an old bug fix: NLMSG_DONE needs to account for the netlink header size, not just the attribute size. This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43329", "url": "https://ubuntu.com/security/CVE-2026-43329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: strictly check for maximum number of actions The maximum number of flowtable hardware offload actions in IPv6 is: * ethernet mangling (4 payload actions, 2 for each ethernet address) * SNAT (4 payload actions) * DNAT (4 payload actions) * Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. * Redirect (1 action) Which makes 17, while the maximum is 16. But act_ct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions. Update flow_action_entry_next() calls to check for the maximum number of supported actions. While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31680", "url": "https://ubuntu.com/security/CVE-2026-31680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: flowlabel: defer exclusive option free until RCU teardown `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file RCU read-side lock and prints `fl->opt->opt_nflen` when an option block is present. Exclusive flowlabels currently free `fl->opt` as soon as `fl->users` drops to zero in `fl_release()`. However, the surrounding `struct ip6_flowlabel` remains visible in the global hash table until later garbage collection removes it and `fl_free_rcu()` finally tears it down. A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that early `kfree()` and dereference freed option state, triggering a crash in `ip6fl_seq_show()`. Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43030", "url": "https://ubuntu.com/security/CVE-2026-43030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix regsafe() for pointers to packet In case rold->reg->range == BEYOND_PKT_END && rcur->reg->range == N regsafe() may return true which may lead to current state with valid packet range not being explored. Fix the bug.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43032", "url": "https://ubuntu.com/security/CVE-2026-43032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: pn533: bound the UART receive buffer pn532_receive_buf() appends every incoming byte to dev->recv_skb and only resets the buffer after pn532_uart_rx_is_frame() recognizes a complete frame. A continuous stream of bytes without a valid PN532 frame header therefore keeps growing the skb until skb_put_u8() hits the tail limit. Drop the accumulated partial frame once the fixed receive buffer is full so malformed UART traffic cannot grow the skb past PN532_UART_SKB_BUFF_LEN.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43035", "url": "https://ubuntu.com/security/CVE-2026-43035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to zero to prevent an info-leak When building netlink messages, tc_chain_fill_node() never initializes the tcm_info field of struct tcmsg. Since the allocation is not zeroed, kernel heap memory is leaked to userspace through this 4-byte field. The fix simply zeroes tcm_info alongside the other fields that are already initialized.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43339", "url": "https://ubuntu.com/security/CVE-2026-43339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible UaF in addrconf_permanent_addr() The mentioned helper try to warn the user about an exceptional condition, but the message is delivered too late, accessing the ipv6 after its possible deletion. Reorder the statement to avoid the possible UaF; while at it, place the warning outside the idev->lock as it needs no protection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31423", "url": "https://ubuntu.com/security/CVE-2026-31423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: fix divide-by-zero in rtsc_min() m2sm() converts a u32 slope to a u64 scaled value. For large inputs (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores the difference of two such u64 values in a u32 variable `dsm` and uses it as a divisor. When the difference is exactly 2^32 the truncation yields zero, causing a divide-by-zero oops in the concave-curve intersection path: Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...] Widen `dsm` to u64 and replace do_div() with div64_u64() so the full difference is preserved.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43040", "url": "https://ubuntu.com/security/CVE-2026-43040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak When processing Router Advertisements with user options the kernel builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data The fix is simple, just zeroes the padding fields.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43041", "url": "https://ubuntu.com/security/CVE-2026-43041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak __radix_tree_create() allocates and links intermediate nodes into the tree one by one. If a subsequent allocation fails, the already-linked nodes remain in the tree with no corresponding leaf entry. These orphaned internal nodes are never reclaimed because radix_tree_for_each_slot() only visits slots containing leaf values. The radix_tree API is deprecated in favor of xarray. As suggested by Matthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray instead of fixing the radix_tree itself [1]. xarray properly handles cleanup of internal nodes — xa_destroy() frees all internal xarray nodes when the qrtr_node is released, preventing the leak. [1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43043", "url": "https://ubuntu.com/security/CVE-2026-43043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af-alg - fix NULL pointer dereference in scatterwalk The AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL) when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL exactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent sendmsg() allocates a new SGL and chains it, but fails to clear the end marker on the previous SGL's last data entry. This causes the crypto scatterwalk to hit a premature end, returning NULL on sg_next() and leading to a kernel panic during dereference. Fix this by explicitly unmarking the end of the previous SGL when performing sg_chain() in af_alg_alloc_tsgl().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43046", "url": "https://ubuntu.com/security/CVE-2026-43046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject root items with drop_progress and zero drop_level [BUG] When recovering relocation at mount time, merge_reloc_root() and btrfs_drop_snapshot() both use BUG_ON(level == 0) to guard against an impossible state: a non-zero drop_progress combined with a zero drop_level in a root_item, which can be triggered: ------------[ cut here ]------------ kernel BUG at fs/btrfs/relocation.c:1545! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2 RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545 Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000 Call Trace: merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861 btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195 btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130 open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640 btrfs_fill_super fs/btrfs/super.c:987 [inline] btrfs_get_tree_super fs/btrfs/super.c:1951 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline] btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ... RIP: 0033:0x7f969c9a8fde Code: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f ---[ end trace 0000000000000000 ]--- The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamic metadata fuzzing tool that corrupts btrfs metadata at runtime. [CAUSE] A non-zero drop_progress.objectid means an interrupted btrfs_drop_snapshot() left a resume point on disk, and in that case drop_level must be greater than 0 because the checkpoint is only saved at internal node levels. Although this invariant is enforced when the kernel writes the root item, it is not validated when the root item is read back from disk. That allows on-disk corruption to provide an invalid state with drop_progress.objectid != 0 and drop_level == 0. When relocation recovery later processes such a root item, merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). The same invalid metadata can also trigger the corresponding BUG_ON() in btrfs_drop_snapshot(). [FIX] Fix this by validating the root_item invariant in tree-checker when reading root items from disk: if drop_progress.objectid is non-zero, drop_level must also be non-zero. Reject such malformed metadata with -EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot() and triggers the BUG_ON. After the fix, the same corruption is correctly rejected by tree-checker and the BUG_ON is no longer triggered.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43047", "url": "https://ubuntu.com/security/CVE-2026-43047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Check to ensure report responses match the request It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes. Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43050", "url": "https://ubuntu.com/security/CVE-2026-43050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix use-after-free in sock_def_readable() A race condition exists between lec_atm_close() setting priv->lecd to NULL and concurrent access to priv->lecd in send_to_lecd(), lec_handle_bridge(), and lec_atm_send(). When the socket is freed via RCU while another thread is still using it, a use-after-free occurs in sock_def_readable() when accessing the socket's wait queue. The root cause is that lec_atm_close() clears priv->lecd without any synchronization, while callers dereference priv->lecd without any protection against concurrent teardown. Fix this by converting priv->lecd to an RCU-protected pointer: - Mark priv->lecd as __rcu in lec.h - Use rcu_assign_pointer() in lec_atm_close() and lecd_attach() for safe pointer assignment - Use rcu_access_pointer() for NULL checks that do not dereference the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and lecd_attach() - Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(), lec_handle_bridge() and lec_atm_send() to safely access lecd - Use rcu_assign_pointer() followed by synchronize_rcu() in lec_atm_close() to ensure all readers have completed before proceeding. This is safe since lec_atm_close() is called from vcc_release() which holds lock_sock(), a sleeping lock. - Remove the manual sk_receive_queue drain from lec_atm_close() since vcc_destroy_socket() already drains it after lec_atm_close() returns. v2: Switch from spinlock + sock_hold/put approach to RCU to properly fix the race. The v1 spinlock approach had two issues pointed out by Eric Dumazet: 1. priv->lecd was still accessed directly after releasing the lock instead of using a local copy. 2. The spinlock did not prevent packets being queued after lec_atm_close() drains sk_receive_queue since timer and workqueue paths bypass netif_stop_queue(). Note: Syzbot patch testing was attempted but the test VM terminated unexpectedly with \"Connection to localhost closed by remote host\", likely due to a QEMU AHCI emulation issue unrelated to this fix. Compile testing with \"make W=1 net/atm/lec.o\" passes cleanly.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43051", "url": "https://ubuntu.com/security/CVE-2026-43051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq The wacom_intuos_bt_irq() function processes Bluetooth HID reports without sufficient bounds checking. A maliciously crafted short report can trigger an out-of-bounds read when copying data into the wacom structure. Specifically, report 0x03 requires at least 22 bytes to safely read the processed data and battery status, while report 0x04 (which falls through to 0x03) requires 32 bytes. Add explicit length checks for these report IDs and log a warning if a short report is received.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31555", "url": "https://ubuntu.com/security/CVE-2026-31555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Clear stale exiting pointer in futex_lock_pi() retry path Fuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524 When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'. After wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0\t\t\t CPU1\t\t CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; \t\t\t futex_lock_pi(uaddr) \t\t\t futex_lock_pi_atomic() \t\t\t\t attach_to_pi_owner() \t\t\t\t // observes EXITING \t\t\t\t *exiting = owner; // takes ref \t\t\t\t return -EBUSY \t\t\t wait_for_owner_exiting(-EBUSY, owner) \t\t\t\t put_task_struct(); // drops ref \t\t\t // exiting still points to owner \t\t\t goto retry; \t\t\t futex_lock_pi_atomic() \t\t\t\t lock_pi_update_atomic() \t\t\t\t cmpxchg(uaddr) \t\t\t\t\t*uaddr ^= WAITERS // whatever \t\t\t\t // value changed \t\t\t\t return -EAGAIN; \t\t\t wait_for_owner_exiting(-EAGAIN, exiting) // stale \t\t\t\t WARN_ON_ONCE(exiting) Fix this by resetting upon retry, essentially aligning it with requeue_pi.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43065", "url": "https://ubuntu.com/security/CVE-2026-43065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: always drain queued discard work in ext4_mb_release() While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]: > If the filesystem is initially mounted with the discard option, > deleting files will populate sbi->s_discard_list and queue > s_discard_work. If it is then remounted with nodiscard, the > EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is > neither cancelled nor flushed. [1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing. In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own. Fix it because it's a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-43066", "url": "https://ubuntu.com/security/CVE-2026-43066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths During code review, Joseph found that ext4_fc_replay_inode() calls ext4_get_fc_inode_loc() to get the inode location, which holds a reference to iloc.bh that must be released via brelse(). However, several error paths jump to the 'out' label without releasing iloc.bh: - ext4_handle_dirty_metadata() failure - sync_dirty_buffer() failure - ext4_mark_inode_used() failure - ext4_iget() failure Fix this by introducing an 'out_brelse' label placed just before the existing 'out' label to ensure iloc.bh is always released. Additionally, make ext4_fc_replay_inode() propagate errors properly instead of always returning 0.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31447", "url": "https://ubuntu.com/security/CVE-2026-31447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: reject mount if bigalloc with s_first_data_block != 0 bigalloc with s_first_data_block != 0 is not supported, reject mounting it.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43068", "url": "https://ubuntu.com/security/CVE-2026-43068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal() There's issue as follows: ... EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): error count since last fsck: 1 EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760 EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760 ... According to the log analysis, blocks are always requested from the corrupted block group. This may happen as follows: ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return error ext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out; After commit 9008a58e5dce (\"ext4: make the bitmap read routines return real error codes\") merged, Commit 163a203ddb36 (\"ext4: mark block group as corrupt on block bitmap error\") is no real solution for allocating blocks from corrupted block groups. This is because if 'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then 'ext4_mb_load_buddy()' may return an error. This means that the block allocation will fail. Therefore, check block group if corrupted when ext4_mb_load_buddy() returns error.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31452", "url": "https://ubuntu.com/security/CVE-2026-31452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: convert inline data to extents when truncate exceeds inline size Add a check in ext4_setattr() to convert files from inline data storage to extent-based storage when truncate() grows the file size beyond the inline capacity. This prevents the filesystem from entering an inconsistent state where the inline data flag is set but the file size exceeds what can be stored inline. Without this fix, the following sequence causes a kernel BUG_ON(): 1. Mount filesystem with inode that has inline flag set and small size 2. truncate(file, 50MB) - grows size but inline flag remains set 3. sendfile() attempts to write data 4. ext4_write_inline_data() hits BUG_ON(write_size > inline_capacity) The crash occurs because ext4_write_inline_data() expects inline storage to accommodate the write, but the actual inline capacity (~60 bytes for i_block + ~96 bytes for xattrs) is far smaller than the file size and write request. The fix checks if the new size from setattr exceeds the inode's actual inline capacity (EXT4_I(inode)->i_inline_size) and converts the file to extent-based storage before proceeding with the size change. This addresses the root cause by ensuring the inline data flag and file size remain consistent during truncate operations.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31455", "url": "https://ubuntu.com/security/CVE-2026-31455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: stop reclaim before pushing AIL during unmount The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while background reclaim and inodegc are still running. This is broken independently of any use-after-free issues - background reclaim and inodegc should not be running while the AIL is being pushed during unmount, as inodegc can dirty and insert inodes into the AIL during the flush, and background reclaim can race to abort and free dirty inodes. Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel background reclaim before pushing the AIL. Stop inodegc before cancelling m_reclaim_work because the inodegc worker can re-queue m_reclaim_work via xfs_inodegc_set_reclaimable.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31464", "url": "https://ubuntu.com/security/CVE-2026-31464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done() A malicious or compromised VIO server can return a num_written value in the discover targets MAD response that exceeds max_targets. This value is stored directly in vhost->num_targets without validation, and is then used as the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], which is only allocated for max_targets entries. Indices at or beyond max_targets access kernel memory outside the DMA-coherent allocation. The out-of-bounds data is subsequently embedded in Implicit Logout and PLOGI MADs that are sent back to the VIO server, leaking kernel memory. Fix by clamping num_written to max_targets before storing it.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31467", "url": "https://ubuntu.com/security/CVE-2026-31467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: add GFP_NOIO in the bio completion if needed The bio completion path in the process context (e.g. dm-verity) will directly call into decompression rather than trigger another workqueue context for minimal scheduling latencies, which can then call vm_map_ram() with GFP_KERNEL. Due to insufficient memory, vm_map_ram() may generate memory swapping I/O, which can cause submit_bio_wait to deadlock in some scenarios. Trimmed down the call stack, as follows: f2fs_submit_read_io submit_bio //bio_list is initialized. mmc_blk_mq_recovery z_erofs_endio vm_map_ram __pte_alloc_kernel __alloc_pages_direct_reclaim shrink_folio_list __swap_writepage submit_bio_wait //bio_list is non-NULL, hang!!! Use memalloc_noio_{save,restore}() to wrap up this path.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31469", "url": "https://ubuntu.com/security/CVE-2026-31469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false A UAF issue occurs when the virtio_net driver is configured with napi_tx=N and the device's IFF_XMIT_DST_RELEASE flag is cleared (e.g., during the configuration of tc route filter rules). When IFF_XMIT_DST_RELEASE is removed from the net_device, the network stack expects the driver to hold the reference to skb->dst until the packet is fully transmitted and freed. In virtio_net with napi_tx=N, skbs may remain in the virtio transmit ring for an extended period. If the network namespace is destroyed while these skbs are still pending, the corresponding dst_ops structure has freed. When a subsequent packet is transmitted, free_old_xmit() is triggered to clean up old skbs. It then calls dst_release() on the skb associated with the stale dst_entry. Since the dst_ops (referenced by the dst_entry) has already been freed, a UAF kernel paging request occurs. fix it by adds skb_dst_drop(skb) in start_xmit to explicitly release the dst reference before the skb is queued in virtio_net. Call Trace: Unable to handle kernel paging request at virtual address ffff80007e150000 CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT ... percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P) dst_release+0xe0/0x110 net/core/dst.c:177 skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177 sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255 dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469 napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527 __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net] free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net] start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net] ... Reproduction Steps: NETDEV=\"enp3s0\" config_qdisc_route_filter() { tc qdisc del dev $NETDEV root tc qdisc add dev $NETDEV root handle 1: prio tc filter add dev $NETDEV parent 1:0 \\ \tprotocol ip prio 100 route to 100 flowid 1:1 ip route add 192.168.1.100/32 dev $NETDEV realm 100 } test_ns() { ip netns add testns ip link set $NETDEV netns testns ip netns exec testns ifconfig $NETDEV 10.0.32.46/24 ip netns exec testns ping -c 1 10.0.32.1 ip netns del testns } config_qdisc_route_filter test_ns sleep 2 test_ns", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31473", "url": "https://ubuntu.com/security/CVE-2026-31473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex MEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0) queue teardown paths. This can race request object cleanup against vb2 queue cancellation and lead to use-after-free reports. We already serialize request queueing against STREAMON/OFF with req_queue_mutex. Extend that serialization to REQBUFS, and also take the same mutex in media_request_ioctl_reinit() so REINIT is in the same exclusion domain. This keeps request cleanup and queue cancellation from running in parallel for request-capable devices.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31570", "url": "https://ubuntu.com/security/CVE-2026-31570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gw: fix OOB heap access in cgw_csum_crc8_rel() cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx(): int from = calc_idx(crc8->from_idx, cf->len); int to = calc_idx(crc8->to_idx, cf->len); int res = calc_idx(crc8->result_idx, cf->len); if (from < 0 || to < 0 || res < 0) return; However, the loop and the result write then use the raw s8 fields directly instead of the computed variables: for (i = crc8->from_idx; ...) /* BUG: raw negative index */ cf->data[crc8->result_idx] = ...; /* BUG: raw negative index */ With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame, calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf->data[-64], and the write goes to cf->data[-64]. This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before the start of the canfd_frame on the heap. The companion function cgw_csum_xor_rel() uses `from`/`to`/`res` correctly throughout; fix cgw_csum_crc8_rel() to match. Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62 To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31483", "url": "https://ubuntu.com/security/CVE-2026-31483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/syscalls: Add spectre boundary for syscall dispatch table The s390 syscall number is directly controlled by userspace, but does not have an array_index_nospec() boundary to prevent access past the syscall function pointer tables.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31485", "url": "https://ubuntu.com/security/CVE-2026-31485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-lpspi: fix teardown order issue (UAF) There is a teardown order issue in the driver. The SPI controller is registered using devm_spi_register_controller(), which delays unregistration of the SPI controller until after the fsl_lpspi_remove() function returns. As the fsl_lpspi_remove() function synchronously tears down the DMA channels, a running SPI transfer triggers the following NULL pointer dereference due to use after free: | fsl_lpspi 42550000.spi: I/O Error in DMA RX | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] | Call trace: | fsl_lpspi_dma_transfer+0x260/0x340 [spi_fsl_lpspi] | fsl_lpspi_transfer_one+0x198/0x448 [spi_fsl_lpspi] | spi_transfer_one_message+0x49c/0x7c8 | __spi_pump_transfer_message+0x120/0x420 | __spi_sync+0x2c4/0x520 | spi_sync+0x34/0x60 | spidev_message+0x20c/0x378 [spidev] | spidev_ioctl+0x398/0x750 [spidev] [...] Switch from devm_spi_register_controller() to spi_register_controller() in fsl_lpspi_probe() and add the corresponding spi_unregister_controller() in fsl_lpspi_remove().", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31565", "url": "https://ubuntu.com/security/CVE-2026-31565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix deadlock during netdev reset with active connections Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering device_delete and subsequent client removal. During client removal, uverbs_client waits for QP reference count to reach zero while cma_client holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31494", "url": "https://ubuntu.com/security/CVE-2026-31494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: use the current queue number for stats There's a potential mismatch between the memory reserved for statistics and the amount of memory written. gem_get_sset_count() correctly computes the number of stats based on the active queues, whereas gem_get_ethtool_stats() indiscriminately copies data using the maximum number of queues, and in the case the number of active queues is less than MACB_MAX_QUEUES, this results in a OOB write as observed in the KASAN splat. ================================================================== BUG: KASAN: vmalloc-out-of-bounds in gem_get_ethtool_stats+0x54/0x78 [macb] Write of size 760 at addr ffff80008080b000 by task ethtool/1027 CPU: [...] Tainted: [E]=UNSIGNED_MODULE Hardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 print_report+0x384/0x5e0 kasan_report+0xa0/0xf0 kasan_check_range+0xe8/0x190 __asan_memcpy+0x54/0x98 gem_get_ethtool_stats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] dev_ethtool+0x1220/0x38c0 dev_ioctl+0x4ac/0xca8 sock_do_ioctl+0x170/0x1d8 sock_ioctl+0x484/0x5d8 __arm64_sys_ioctl+0x12c/0x1b8 invoke_syscall+0xd4/0x258 el0_svc_common.constprop.0+0xb4/0x240 do_el0_svc+0x48/0x68 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 The buggy address belongs to a 1-page vmalloc region starting at 0xffff80008080b000 allocated at dev_ethtool+0x11f0/0x38c0 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff00000a333000 pfn:0xa333 flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff) raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== Fix it by making sure the copied size only considers the active number of queues.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31495", "url": "https://ubuntu.com/security/CVE-2026-31495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: use netlink policy range checks Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors. - CTA_PROTOINFO_TCP_STATE: reject values > TCP_CONNTRACK_SYN_SENT2 at policy level, removing the manual >= TCP_CONNTRACK_MAX check. - CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values > TCP_MAX_WSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count. - CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with CTA_FILTER_F_ALL, removing the manual mask checks. - CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding a new mask define grouping all valid expect flags. Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31427", "url": "https://ubuntu.com/security/CVE-2026-31427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp process_sdp() declares union nf_inet_addr rtp_addr on the stack and passes it to the nf_nat_sip sdp_session hook after walking the SDP media descriptions. However rtp_addr is only initialized inside the media loop when a recognized media type with a non-zero port is found. If the SDP body contains no m= lines, only inactive media sections (m=audio 0 ...) or only unrecognized media types, rtp_addr is never assigned. Despite that, the function still calls hooks->sdp_session() with &rtp_addr, causing nf_nat_sdp_session() to format the stale stack value as an IP address and rewrite the SDP session owner and connection lines with it. With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this results in the session-level o= and c= addresses being rewritten to 0.0.0.0 for inactive SDP sessions. Without stack auto-init the rewritten address is whatever happened to be on the stack. Fix this by pre-initializing rtp_addr from the session-level connection address (caddr) when available, and tracking via a have_rtp_addr flag whether any valid address was established. Skip the sdp_session hook entirely when no valid address exists.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31674", "url": "https://ubuntu.com/security/CVE-2026-31674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check() Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS. rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[]. Validate addrnr during rule installation so malformed rules are rejected before the match logic can use an out-of-range value.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31428", "url": "https://ubuntu.com/security/CVE-2026-31428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD __build_packet_message() manually constructs the NFULA_PAYLOAD netlink attribute using skb_put() and skb_copy_bits(), bypassing the standard nla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes are allocated (including NLA alignment padding), only data_len bytes of actual packet data are copied. The trailing nla_padlen(data_len) bytes (1-3 when data_len is not 4-byte aligned) are never initialized, leaking stale heap contents to userspace via the NFLOG netlink socket. Replace the manual attribute construction with nla_reserve(), which handles the tailroom check, header setup, and padding zeroing via __nla_reserve(). The subsequent skb_copy_bits() fills in the payload data on top of the properly initialized attribute.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31497", "url": "https://ubuntu.com/security/CVE-2026-31497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: clamp SCO altsetting table indices btusb_work() maps the number of active SCO links to USB alternate settings through a three-entry lookup table when CVSD traffic uses transparent voice settings. The lookup currently indexes alts[] with data->sco_num - 1 without first constraining sco_num to the number of available table entries. While the table only defines alternate settings for up to three SCO links, data->sco_num comes from hci_conn_num() and is used directly. Cap the lookup to the last table entry before indexing it so the driver keeps selecting the highest supported alternate setting without reading past alts[].", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31498", "url": "https://ubuntu.com/security/CVE-2026-31498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop l2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTED state to support L2CAP reconfiguration (e.g. MTU changes). However, since both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set from the initial configuration, the reconfiguration path falls through to l2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, and retrans_list without freeing the previous allocations and sets chan->sdu to NULL without freeing the existing skb. This leaks all previously allocated ERTM resources. Additionally, l2cap_parse_conf_req() does not validate the minimum value of remote_mps derived from the RFC max_pdu_size option. A zero value propagates to l2cap_segment_sdu() where pdu_len becomes zero, causing the while loop to never terminate since len is never decremented, exhausting all available memory. Fix the double-init by skipping l2cap_ertm_init() and l2cap_chan_ready() when the channel is already in BT_CONNECTED state, while still allowing the reconfiguration parameters to be updated through l2cap_parse_conf_req(). Also add a pdu_len zero check in l2cap_segment_sdu() as a safeguard.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31507", "url": "https://ubuntu.com/security/CVE-2026-31507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffer smc_rx_splice() allocates one smc_spd_priv per pipe_buffer and stores the pointer in pipe_buffer.private. The pipe_buf_operations for these buffers used .get = generic_pipe_buf_get, which only increments the page reference count when tee(2) duplicates a pipe buffer. The smc_spd_priv pointer itself was not handled, so after tee() both the original and the cloned pipe_buffer share the same smc_spd_priv *. When both pipes are subsequently released, smc_rx_pipe_buf_release() is called twice against the same object: 1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct] 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF] KASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), which then escalates to a NULL-pointer dereference and kernel panic via smc_rx_update_consumer() when it chases the freed priv->smc pointer: BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x650 kasan_report+0xc6/0x100 smc_rx_pipe_buf_release+0x78/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smc_rx_update_consumer+0x8d/0x350 Call Trace: smc_rx_pipe_buf_release+0x121/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception Beyond the memory-safety problem, duplicating an SMC splice buffer is semantically questionable: smc_rx_update_cons() would advance the consumer cursor twice for the same data, corrupting receive-window accounting. A refcount on smc_spd_priv could fix the double-free, but the cursor-accounting issue would still need to be addressed separately. The .get callback is invoked by both tee(2) and splice_pipe_to_pipe() for partial transfers; both will now return -EFAULT. Users who need to duplicate SMC socket data must use a copy-based read path.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31679", "url": "https://ubuntu.com/security/CVE-2026-31679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: validate MPLS set/set_masked payload length validate_set() accepted OVS_KEY_ATTR_MPLS as variable-sized payload for SET/SET_MASKED actions. In action handling, OVS expects fixed-size MPLS key data (struct ovs_key_mpls). Use the already normalized key_len (masked case included) and reject non-matching MPLS action key sizes. Reject invalid MPLS action payload lengths early.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31508", "url": "https://ubuntu.com/security/CVE-2026-31508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Avoid releasing netdev before teardown completes The patch cited in the Fixes tag below changed the teardown code for OVS ports to no longer unconditionally take the RTNL. After this change, the netdev_destroy() callback can proceed immediately to the call_rcu() invocation if the IFF_OVS_DATAPATH flag is already cleared on the netdev. The ovs_netdev_detach_dev() function clears the flag before completing the unregistration, and if it gets preempted after clearing the flag (as can happen on an -rt kernel), netdev_destroy() can complete and the device can be freed before the unregistration completes. This leads to a splat like: [ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025 [ 998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0 [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90 [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246 [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000 [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0 [ 998.393944] PKRU: 55555554 [ 998.393946] Call Trace: [ 998.393949] [ 998.393952] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393961] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393975] ? dp_device_event+0x41/0x80 [openvswitch] [ 998.394009] ? __die_body.cold+0x8/0x12 [ 998.394016] ? die_addr+0x3c/0x60 [ 998.394027] ? exc_general_protection+0x16d/0x390 [ 998.394042] ? asm_exc_general_protection+0x26/0x30 [ 998.394058] ? dev_set_promiscuity+0x8d/0xa0 [ 998.394066] ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch] [ 998.394092] dp_device_event+0x41/0x80 [openvswitch] [ 998.394102] notifier_call_chain+0x5a/0xd0 [ 998.394106] unregister_netdevice_many_notify+0x51b/0xa60 [ 998.394110] rtnl_dellink+0x169/0x3e0 [ 998.394121] ? rt_mutex_slowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlink_rcv_msg+0x142/0x3f0 [ 998.394128] ? avc_has_perm_noaudit+0x69/0xf0 [ 998.394130] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 998.394132] netlink_rcv_skb+0x50/0x100 [ 998.394138] netlink_unicast+0x292/0x3f0 [ 998.394141] netlink_sendmsg+0x21b/0x470 [ 998.394145] ____sys_sendmsg+0x39d/0x3d0 [ 998.394149] ___sys_sendmsg+0x9a/0xe0 [ 998.394156] __sys_sendmsg+0x7a/0xd0 [ 998.394160] do_syscall_64+0x7f/0x170 [ 998.394162] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 998.394165] RIP: 0033:0x7fad61bf4724 [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724 [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003 [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2 ---truncated---", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31509", "url": "https://ubuntu.com/security/CVE-2026-31509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix circular locking dependency in nci_close_device nci_close_device() flushes rx_wq and tx_wq while holding req_lock. This causes a circular locking dependency because nci_rx_work() running on rx_wq can end up taking req_lock too: nci_rx_work -> nci_rx_data_packet -> nci_data_exchange_complete -> __sk_destruct -> rawsock_destruct -> nfc_deactivate_target -> nci_deactivate_target -> nci_request -> mutex_lock(&ndev->req_lock) Move the flush of rx_wq after req_lock has been released. This should safe (I think) because NCI_UP has already been cleared and the transport is closed, so the work will see it and return -ENETDOWN. NIPA has been hitting this running the nci selftest with a debug kernel on roughly 4% of the runs.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31510", "url": "https://ubuntu.com/security/CVE-2026-31510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb Before using sk pointer, check if it is null. Fix the following: KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267] CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025 Workqueue: events l2cap_info_timeout RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce veth0_macvtap: entered promiscuous mode RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: __kasan_check_byte+0x12/0x40 lock_acquire+0x79/0x2e0 lock_sock_nested+0x48/0x100 ? l2cap_sock_ready_cb+0x46/0x160 l2cap_sock_ready_cb+0x46/0x160 l2cap_conn_start+0x779/0xff0 ? __pfx_l2cap_conn_start+0x10/0x10 ? l2cap_info_timeout+0x60/0xa0 ? __pfx___mutex_lock+0x10/0x10 l2cap_info_timeout+0x68/0xa0 ? process_scheduled_works+0xa8d/0x18c0 process_scheduled_works+0xb6e/0x18c0 ? __pfx_process_scheduled_works+0x10/0x10 ? assign_work+0x3d5/0x5e0 worker_thread+0xa53/0xfc0 kthread+0x388/0x470 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x51e/0xb90 ? __pfx_ret_from_fork+0x10/0x10 veth1_macvtap: entered promiscuous mode ? __switch_to+0xc7d/0x1450 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- batman_adv: batadv0: Interface activated: batadv_slave_0 batman_adv: batadv0: Interface activated: batadv_slave_1 netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce ieee80211 phy39: Selected rate control algorithm 'minstrel_ht' RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43069", "url": "https://ubuntu.com/security/CVE-2026-43069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_ll: Fix firmware leak on error path Smatch reports: drivers/bluetooth/hci_ll.c:587 download_firmware() warn: 'fw' from request_firmware() not released on lines: 544. In download_firmware(), if request_firmware() succeeds but the returned firmware content is invalid (no data or zero size), the function returns without releasing the firmware, resulting in a resource leak. Fix this by calling release_firmware() before returning when request_firmware() succeeded but the firmware content is invalid.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31408", "url": "https://ubuntu.com/security/CVE-2026-31408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold sco_recv_frame() reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold a reference under the lock. Fix by using sco_sock_hold() to take a reference before releasing the lock, and adding sock_put() on all exit paths.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-31512", "url": "https://ubuntu.com/security/CVE-2026-31512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv() l2cap_ecred_data_rcv() reads the SDU length field from skb->data using get_unaligned_le16() without first verifying that skb contains at least L2CAP_SDULEN_SIZE (2) bytes. When skb->len is less than 2, this reads past the valid data in the skb. The ERTM reassembly path correctly calls pskb_may_pull() before reading the SDU length (l2cap_reassemble_sdu, L2CAP_SAR_START case). Apply the same validation to the Enhanced Credit Based Flow Control data path.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31515", "url": "https://ubuntu.com/security/CVE-2026-31515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_key: validate families in pfkey_send_migrate() syzbot was able to trigger a crash in skb_put() [1] Issue is that pfkey_send_migrate() does not check old/new families, and that set_ipsecrequest() @family argument was truncated, thus possibly overfilling the skb. Validate families early, do not wait set_ipsecrequest(). [1] skbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev: kernel BUG at net/core/skbuff.c:214 ! Call Trace: skb_over_panic net/core/skbuff.c:219 [inline] skb_put+0x159/0x210 net/core/skbuff.c:2655 skb_put_zero include/linux/skbuff.h:2788 [inline] set_ipsecrequest net/key/af_key.c:3532 [inline] pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636 km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848 xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705 xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31518", "url": "https://ubuntu.com/security/CVE-2026-31518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: esp: fix skb leak with espintcp and async crypto When the TX queue for espintcp is full, esp_output_tail_tcp will return an error and not free the skb, because with synchronous crypto, the common xfrm output code will drop the packet for us. With async crypto (esp_output_done), we need to drop the skb when esp_output_tail_tcp returns an error.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31521", "url": "https://ubuntu.com/security/CVE-2026-31521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: module: Fix kernel panic when a symbol st_shndx is out of bounds The module loader doesn't check for bounds of the ELF section index in simplify_symbols(): for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) { \t\tconst char *name = info->strtab + sym[i].st_name; \t\tswitch (sym[i].st_shndx) { \t\tcase SHN_COMMON: \t\t[...] \t\tdefault: \t\t\t/* Divert to percpu allocation if a percpu var. */ \t\t\tif (sym[i].st_shndx == info->index.pcpu) \t\t\t\tsecbase = (unsigned long)mod_percpu(mod); \t\t\telse /** HERE --> **/\t\tsecbase = info->sechdrs[sym[i].st_shndx].sh_addr; \t\t\tsym[i].st_value += secbase; \t\t\tbreak; \t\t} \t} A symbol with an out-of-bounds st_shndx value, for example 0xffff (known as SHN_XINDEX or SHN_HIRESERVE), may cause a kernel panic: BUG: unable to handle page fault for address: ... RIP: 0010:simplify_symbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exception This can happen when module ELF is legitimately using SHN_XINDEX or when it is corrupted. Add a bounds check in simplify_symbols() to validate that st_shndx is within the valid range before using it. This issue was discovered due to a bug in llvm-objcopy, see relevant discussion for details [1]. [1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31522", "url": "https://ubuntu.com/security/CVE-2026-31522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: avoid memory leak in magicmouse_report_fixup() The magicmouse_report_fixup() function was returning a newly kmemdup()-allocated buffer, but never freeing it. The caller of report_fixup() does not take ownership of the returned pointer, but it *is* permitted to return a sub-portion of the input rdesc, whose lifetime is managed by the caller.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31523", "url": "https://ubuntu.com/security/CVE-2026-31523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-pci: ensure we're polling a polled queue A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31524", "url": "https://ubuntu.com/security/CVE-2026-31524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: asus: avoid memory leak in asus_report_fixup() The asus_report_fixup() function was returning a newly allocated kmemdup()-allocated buffer, but never freeing it. Switch to devm_kzalloc() to ensure the memory is managed and freed automatically when the device is removed. The caller of report_fixup() does not take ownership of the returned pointer, but it is permitted to return a pointer whose lifetime is at least that of the input buffer. Also fix a harmless out-of-bounds read by copying only the original descriptor size.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31788", "url": "https://ubuntu.com/security/CVE-2026-31788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: restrict usage in unprivileged domU The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains. In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature. The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest. Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today. The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot. This is XSA-482 --- V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich)", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31540", "url": "https://ubuntu.com/security/CVE-2026-31540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Check set_default_submission() before deferencing When the i915 driver firmware binaries are not present, the set_default_submission pointer is not set. This pointer is dereferenced during suspend anyways. Add a check to make sure it is set before dereferencing. [ 23.289926] PM: suspend entry (deep) [ 23.293558] Filesystems sync: 0.000 seconds [ 23.298010] Freezing user space processes [ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds) [ 23.309766] OOM killer disabled. [ 23.313027] Freezing remaining freezable tasks [ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 23.342038] serial 00:05: disabled [ 23.345719] serial 00:02: disabled [ 23.349342] serial 00:01: disabled [ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 23.361635] ata1.00: Entering standby power mode [ 23.368863] ata2.00: Entering standby power mode [ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 23.452194] #PF: supervisor instruction fetch in kernel mode [ 23.457896] #PF: error_code(0x0010) - not-present page [ 23.463065] PGD 0 P4D 0 [ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI [ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary) [ 23.482512] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 23.496511] Workqueue: async async_run_entry_fn [ 23.501087] RIP: 0010:0x0 [ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246 [ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f [ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000 [ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff [ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8 [ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68 [ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000 [ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0 [ 23.572539] PKRU: 55555554 [ 23.575281] Call Trace: [ 23.577770] [ 23.579905] intel_engines_reset_default_submission+0x42/0x60 [ 23.585695] __intel_gt_unset_wedged+0x191/0x200 [ 23.590360] intel_gt_unset_wedged+0x20/0x40 [ 23.594675] gt_sanitize+0x15e/0x170 [ 23.598290] i915_gem_suspend_late+0x6b/0x180 [ 23.602692] i915_drm_suspend_late+0x35/0xf0 [ 23.607008] ? __pfx_pci_pm_suspend_late+0x10/0x10 [ 23.611843] dpm_run_callback+0x78/0x1c0 [ 23.615817] device_suspend_late+0xde/0x2e0 [ 23.620037] async_suspend_late+0x18/0x30 [ 23.624082] async_run_entry_fn+0x25/0xa0 [ 23.628129] process_one_work+0x15b/0x380 [ 23.632182] worker_thread+0x2a5/0x3c0 [ 23.635973] ? __pfx_worker_thread+0x10/0x10 [ 23.640279] kthread+0xf6/0x1f0 [ 23.643464] ? __pfx_kthread+0x10/0x10 [ 23.647263] ? __pfx_kthread+0x10/0x10 [ 23.651045] ret_from_fork+0x131/0x190 [ 23.654837] ? __pfx_kthread+0x10/0x10 [ 23.658634] ret_from_fork_asm+0x1a/0x30 [ 23.662597] [ 23.664826] Modules linked in: [ 23.667914] CR2: 0000000000000000 [ 23.671271] ------------[ cut here ]------------ (cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad)", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23434", "url": "https://ubuntu.com/security/CVE-2026-23434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: serialize lock/unlock against other NAND operations nand_lock() and nand_unlock() call into chip->ops.lock_area/unlock_area without holding the NAND device lock. On controllers that implement SET_FEATURES via multiple low-level PIO commands, these can race with concurrent UBI/UBIFS background erase/write operations that hold the device lock, resulting in cmd_pending conflicts on the NAND controller. Add nand_get_device()/nand_release_device() around the lock/unlock operations to serialize them against all other NAND controller access.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23398", "url": "https://ubuntu.com/security/CVE-2026-23398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: fix NULL pointer dereference in icmp_tag_validation() icmp_tag_validation() unconditionally dereferences the result of rcu_dereference(inet_protos[proto]) without checking for NULL. The inet_protos[] array is sparse -- only about 15 of 256 protocol numbers have registered handlers. When ip_no_pmtu_disc is set to 3 (hardened PMTU mode) and the kernel receives an ICMP Fragmentation Needed error with a quoted inner IP header containing an unregistered protocol number, the NULL dereference causes a kernel panic in softirq context. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) Add a NULL check before accessing icmp_strict_tag_validation. If the protocol has no registered handler, return false since it cannot perform strict tag validation.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-23438", "url": "https://ubuntu.com/security/CVE-2026-23438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: guard flow control update with global_tx_fc in buffer switching mvpp2_bm_switch_buffers() unconditionally calls mvpp2_bm_pool_update_priv_fc() when switching between per-cpu and shared buffer pool modes. This function programs CM3 flow control registers via mvpp2_cm3_read()/mvpp2_cm3_write(), which dereference priv->cm3_base without any NULL check. When the CM3 SRAM resource is not present in the device tree (the third reg entry added by commit 60523583b07c (\"dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree\")), priv->cm3_base remains NULL and priv->global_tx_fc is false. Any operation that triggers mvpp2_bm_switch_buffers(), for example an MTU change that crosses the jumbo frame threshold, will crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2_cm3_read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2_bm_pool_update_fc+0x40/0x12c mvpp2_bm_pool_update_priv_fc+0x94/0xd8 mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0 mvpp2_change_mtu+0x140/0x380 __dev_set_mtu+0x1c/0x38 dev_set_mtu_ext+0x78/0x118 dev_set_mtu+0x48/0xa8 dev_ifsioc+0x21c/0x43c dev_ioctl+0x2d8/0x42c sock_ioctl+0x314/0x378 Every other flow control call site in the driver already guards hardware access with either priv->global_tx_fc or port->tx_fc. mvpp2_bm_switch_buffers() is the only place that omits this check. Add the missing priv->global_tx_fc guard to both the disable and re-enable calls in mvpp2_bm_switch_buffers(), consistent with the rest of the driver.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23397", "url": "https://ubuntu.com/security/CVE-2026-23397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfnetlink_osf: validate individual option lengths in fingerprints nfnl_osf_add_callback() validates opt_num bounds and string NUL-termination but does not check individual option length fields. A zero-length option causes nf_osf_match_one() to enter the option matching loop even when foptsize sums to zero, which matches packets with no TCP options where ctx->optp is NULL: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:227) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:293) nf_hook_slow (net/netfilter/core.c:623) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) Additionally, an MSS option (kind=2) with length < 4 causes out-of-bounds reads when nf_osf_match_one() unconditionally accesses optp[2] and optp[3] for MSS value extraction. While RFC 9293 section 3.2 specifies that the MSS option is always exactly 4 bytes (Kind=2, Length=4), the check uses \"< 4\" rather than \"!= 4\" because lengths greater than 4 do not cause memory safety issues -- the buffer is guaranteed to be at least foptsize bytes by the ctx->optsize == foptsize check. Reject fingerprints where any option has zero length, or where an MSS option has length less than 4, at add time rather than trusting these values in the packet matching hot path.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-31546", "url": "https://ubuntu.com/security/CVE-2026-31546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL deref in bond_debug_rlb_hash_show rlb_clear_slave intentionally keeps RLB hash-table entries on the rx_hashtbl_used_head list with slave set to NULL when no replacement slave is available. However, bond_debug_rlb_hash_show visites client_info->slave without checking if it's NULL. Other used-list iterators in bond_alb.c already handle this NULL-slave state safely: - rlb_update_client returns early on !client_info->slave - rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalance compare slave values before visiting - lb_req_update_subnet_clients continues if slave is NULL The following NULL deref crash can be trigger in bond_debug_rlb_hash_show: [ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seq_read_iter (fs/seq_file.c:231) [ 1.296341] seq_read (fs/seq_file.c:164) [ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfs_read (fs/read_write.c:572) [ 1.296981] ksys_read (fs/read_write.c:717) [ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) [ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add a NULL check and print \"(none)\" for entries with no assigned slave.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23439", "url": "https://ubuntu.com/security/CVE-2026-23439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n When CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0 (success) without actually creating a socket. Callers such as fou_create() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference. The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764) [...] Call Trace: genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130) This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23396", "url": "https://ubuntu.com/security/CVE-2026-23396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix NULL deref in mesh_matches_local() mesh_matches_local() unconditionally dereferences ie->mesh_config to compare mesh configuration parameters. When called from mesh_rx_csa_frame(), the parsed action-frame elements may not contain a Mesh Configuration IE, leaving ie->mesh_config NULL and triggering a kernel NULL pointer dereference. The other two callers are already safe: - ieee80211_mesh_rx_bcn_presp() checks !elems->mesh_config before calling mesh_matches_local() - mesh_plink_get_event() is only reached through mesh_process_plink_frame(), which checks !elems->mesh_config, too mesh_rx_csa_frame() is the only caller that passes raw parsed elements to mesh_matches_local() without guarding mesh_config. An adjacent attacker can exploit this by sending a crafted CSA action frame that includes a valid Mesh ID IE but omits the Mesh Configuration IE, crashing the kernel. The captured crash log: Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events_unbound cfg80211_wiphy_work [...] Call Trace: ? __pfx_mesh_matches_local (net/mac80211/mesh.c:65) ieee80211_mesh_rx_queued_mgmt (net/mac80211/mesh.c:1686) [...] ieee80211_iface_work (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802) [...] cfg80211_wiphy_work (net/wireless/core.c:426) process_one_work (net/kernel/workqueue.c:3280) ? assign_work (net/kernel/workqueue.c:1219) worker_thread (net/kernel/workqueue.c:3352) ? __pfx_worker_thread (net/kernel/workqueue.c:3385) kthread (net/kernel/kthread.c:436) [...] ret_from_fork_asm (net/arch/x86/entry/entry_64.S:255) This patch adds a NULL check for ie->mesh_config at the top of mesh_matches_local() to return false early when the Mesh Configuration IE is absent.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-23446", "url": "https://ubuntu.com/security/CVE-2026-23446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: Do not perform PM inside suspend callback syzbot reports \"task hung in rpm_resume\" This is caused by aqc111_suspend calling the PM variant of its write_cmd routine. The simplified call trace looks like this: rpm_suspend() usb_suspend_both() - here udev->dev.power.runtime_status == RPM_SUSPENDING aqc111_suspend() - called for the usb device interface aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() - here we call rpm_resume() on our parent rpm_resume() - Here we wait for a status change that will never happen. At this point we block another task which holds rtnl_lock and locks up the whole networking stack. Fix this by replacing the write_cmd calls with their _nopm variants", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23452", "url": "https://ubuntu.com/security/CVE-2026-23452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM: runtime: Fix a race condition related to device removal The following code in pm_runtime_work() may dereference the dev->parent pointer after the parent device has been freed: \t/* Maybe the parent is now able to suspend. */ \tif (parent && !parent->power.ignore_children) { \t\tspin_unlock(&dev->power.lock); \t\tspin_lock(&parent->power.lock); \t\trpm_idle(parent, RPM_ASYNC); \t\tspin_unlock(&parent->power.lock); \t\tspin_lock(&dev->power.lock); \t} Fix this by inserting a flush_work() call in pm_runtime_remove(). Without this patch blktest block/001 triggers the following complaint sporadically: BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160 Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081 Workqueue: pm pm_runtime_work Call Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0 __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160 _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 Allocated by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50 __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23454", "url": "https://ubuntu.com/security/CVE-2026-23454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: fix use-after-free in mana_hwc_destroy_channel() by reordering teardown A potential race condition exists in mana_hwc_destroy_channel() where hwc->caller_ctx is freed before the HWC's Completion Queue (CQ) and Event Queue (EQ) are destroyed. This allows an in-flight CQ interrupt handler to dereference freed memory, leading to a use-after-free or NULL pointer dereference in mana_hwc_handle_resp(). mana_smc_teardown_hwc() signals the hardware to stop but does not synchronize against IRQ handlers already executing on other CPUs. The IRQ synchronization only happens in mana_hwc_destroy_cq() via mana_gd_destroy_eq() -> mana_gd_deregister_irq(). Since this runs after kfree(hwc->caller_ctx), a concurrent mana_hwc_rx_event_handler() can dereference freed caller_ctx (and rxq->msg_buf) in mana_hwc_handle_resp(). Fix this by reordering teardown to reverse-of-creation order: destroy the TX/RX work queues and CQ/EQ before freeing hwc->caller_ctx. This ensures all in-flight interrupt handlers complete before the memory they access is freed.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23391", "url": "https://ubuntu.com/security/CVE-2026-23391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_CT: drop pending enqueued packets on template removal Templates refer to objects that can go away while packets are sitting in nfqueue refer to: - helper, this can be an issue on module removal. - timeout policy, nfnetlink_cttimeout might remove it. The use of templates with zone and event cache filter are safe, since this just copies values. Flush these enqueued packets in case the template rule gets removed.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43060", "url": "https://ubuntu.com/security/CVE-2026-43060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: drop pending enqueued packets on removal Packets sitting in nfqueue might hold a reference to: - templates that specify the conntrack zone, because a percpu area is used and module removal is possible. - conntrack timeout policies and helper, where object removal leave a stale reference. Since these objects can just go away, drop enqueued packets to avoid stale reference to them. If there is a need for finer grain removal, this logic can be revisited to make selective packet drop upon dependencies.", "cve_priority": "high", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2025-68206", "url": "https://ubuntu.com/security/CVE-2025-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: add seqadj extension for natted connections Sequence adjustment may be required for FTP traffic with PASV/EPSV modes. due to need to re-write packet payload (IP, port) on the ftp control connection. This can require changes to the TCP length and expected seq / ack_seq. The easiest way to reproduce this issue is with PASV mode. Example ruleset: table inet ftp_nat { ct helper ftp_helper { type \"ftp\" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set \"ftp_helper\" } } table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { \t\t\t192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { \t\t\t192.168.13.2 : 192.168.100.1/32 } } } Note that the ftp helper gets assigned *after* the dnat setup. The inverse (nat after helper assign) is handled by an existing check in nf_nat_setup_info() and will not show the problem. Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ ftp nat changes do not work as expected in this case: Connected to 192.168.100.1. [..] ftp> epsv EPSV/EPRT on IPv4 off. ftp> ls 227 Entering passive mode (192,168,100,1,209,129). 421 Service not available, remote server has closed connection. Kernel logs: Missing nfct_seqadj_ext_add() setup call WARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41 [..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 .. Fix this by adding the required extension when a conntrack helper is assigned to a connection that has a nat binding.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-23456", "url": "https://ubuntu.com/security/CVE-2026-23456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case In decode_int(), the CONS case calls get_bits(bs, 2) to read a length value, then calls get_uint(bs, len) without checking that len bytes remain in the buffer. The existing boundary check only validates the 2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint() reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte slab-out-of-bounds read. Add a boundary check for len bytes after get_bits() and before get_uint().", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23457", "url": "https://ubuntu.com/security/CVE-2026-23457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp() sip_help_tcp() parses the SIP Content-Length header with simple_strtoul(), which returns unsigned long, but stores the result in unsigned int clen. On 64-bit systems, values exceeding UINT_MAX are silently truncated before computing the SIP message boundary. For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32, causing the parser to miscalculate where the current message ends. The loop then treats trailing data in the TCP segment as a second SIP message and processes it through the SDP parser. Fix this by changing clen to unsigned long to match the return type of simple_strtoul(), and reject Content-Length values that exceed the remaining TCP payload length.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23458", "url": "https://ubuntu.com/security/CVE-2026-23458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct() ctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for the netlink dump callback ctnetlink_exp_ct_dump_table(), but drops the conntrack reference immediately after netlink_dump_start(). When the dump spans multiple rounds, the second recvmsg() triggers the dump callback which dereferences the now-freed conntrack via nfct_help(ct), leading to a use-after-free on ct->ext. The bug is that the netlink_dump_control has no .start or .done callbacks to manage the conntrack reference across dump rounds. Other dump functions in the same file (e.g. ctnetlink_get_conntrack) properly use .start/.done callbacks for this purpose. Fix this by adding .start and .done callbacks that hold and release the conntrack reference for the duration of the dump, and move the nfct_help() call after the cb->args[0] early-return check in the dump callback to avoid dereferencing ct->ext unnecessarily. BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133 CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 ? aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0 Allocated by task 133: kmem_cache_alloc_noprof+0x134/0x440 __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180 Freed by task 0: slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2025-39764", "url": "https://ubuntu.com/security/CVE-2025-39764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: remove refcounting in expectation dumpers Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption. AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcount_inc_not_zero(&exp->use)) to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2026-23460", "url": "https://ubuntu.com/security/CVE-2026-23460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect syzkaller reported a bug [1], and the reproducer is available at [2]. ROSE sockets use four sk->sk_state values: TCP_CLOSE, TCP_LISTEN, TCP_SYN_SENT, and TCP_ESTABLISHED. rose_connect() already rejects calls for TCP_ESTABLISHED (-EISCONN) and TCP_CLOSE with SS_CONNECTING (-ECONNREFUSED), but lacks a check for TCP_SYN_SENT. When rose_connect() is called a second time while the first connection attempt is still in progress (TCP_SYN_SENT), it overwrites rose->neighbour via rose_get_neigh(). If that returns NULL, the socket is left with rose->state == ROSE_STATE_1 but rose->neighbour == NULL. When the socket is subsequently closed, rose_release() sees ROSE_STATE_1 and calls rose_write_internal() -> rose_transmit_link(skb, NULL), causing a NULL pointer dereference. Per connect(2), a second connect() while a connection is already in progress should return -EALREADY. Add this missing check for TCP_SYN_SENT to complete the state validation in rose_connect(). [1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271 [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23462", "url": "https://ubuntu.com/security/CVE-2026-23462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: Fix possible UAF This fixes the following trace caused by not dropping l2cap_conn reference when user->remove callback is called: [ 97.809249] l2cap_conn_free: freeing conn ffff88810a171c00 [ 97.809907] CPU: 1 UID: 0 PID: 1419 Comm: repro_standalon Not tainted 7.0.0-rc1-dirty #14 PREEMPT(lazy) [ 97.809935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 97.809947] Call Trace: [ 97.809954] [ 97.809961] dump_stack_lvl (lib/dump_stack.c:122) [ 97.809990] l2cap_conn_free (net/bluetooth/l2cap_core.c:1808) [ 97.810017] l2cap_conn_del (./include/linux/kref.h:66 net/bluetooth/l2cap_core.c:1821 net/bluetooth/l2cap_core.c:1798) [ 97.810055] l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7347 (discriminator 1) net/bluetooth/l2cap_core.c:7340 (discriminator 1)) [ 97.810086] ? __pfx_l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7341) [ 97.810117] hci_conn_hash_flush (./include/net/bluetooth/hci_core.h:2152 (discriminator 2) net/bluetooth/hci_conn.c:2644 (discriminator 2)) [ 97.810148] hci_dev_close_sync (net/bluetooth/hci_sync.c:5360) [ 97.810180] ? __pfx_hci_dev_close_sync (net/bluetooth/hci_sync.c:5285) [ 97.810212] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810242] ? up_write (./arch/x86/include/asm/atomic64_64.h:87 (discriminator 5) ./include/linux/atomic/atomic-arch-fallback.h:2852 (discriminator 5) ./include/linux/atomic/atomic-long.h:268 (discriminator 5) ./include/linux/atomic/atomic-instrumented.h:3391 (discriminator 5) kernel/locking/rwsem.c:1385 (discriminator 5) kernel/locking/rwsem.c:1643 (discriminator 5)) [ 97.810267] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810290] ? rcu_is_watching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/context_tracking.h:128 kernel/rcu/tree.c:752) [ 97.810320] hci_unregister_dev (net/bluetooth/hci_core.c:504 net/bluetooth/hci_core.c:2716) [ 97.810346] vhci_release (drivers/bluetooth/hci_vhci.c:691) [ 97.810375] ? __pfx_vhci_release (drivers/bluetooth/hci_vhci.c:678) [ 97.810404] __fput (fs/file_table.c:470) [ 97.810430] task_work_run (kernel/task_work.c:235) [ 97.810451] ? __pfx_task_work_run (kernel/task_work.c:201) [ 97.810472] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810495] ? do_raw_spin_unlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlock_debug.c:142 (discriminator 5)) [ 97.810527] do_exit (kernel/exit.c:972) [ 97.810547] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810574] ? __pfx_do_exit (kernel/exit.c:897) [ 97.810594] ? lock_acquire (kernel/locking/lockdep.c:470 (discriminator 6) kernel/locking/lockdep.c:5870 (discriminator 6) kernel/locking/lockdep.c:5825 (discriminator 6)) [ 97.810616] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810639] ? do_raw_spin_lock (kernel/locking/spinlock_debug.c:95 (discriminator 4) kernel/locking/spinlock_debug.c:118 (discriminator 4)) [ 97.810664] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810688] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1)) [ 97.810721] do_group_exit (kernel/exit.c:1093) [ 97.810745] get_signal (kernel/signal.c:3007 (discriminator 1)) [ 97.810772] ? security_file_permission (./arch/x86/include/asm/jump_label.h:37 security/security.c:2366) [ 97.810803] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810826] ? vfs_read (fs/read_write.c:555) [ 97.810854] ? __pfx_get_signal (kernel/signal.c:2800) [ 97.810880] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810905] ? __pfx_vfs_read (fs/read_write.c:555) [ 97.810932] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810960] arch_do_signal_or_restart (arch/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31551", "url": "https://ubuntu.com/security/CVE-2026-31551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Fix static_branch_dec() underflow for aql_disable. syzbot reported static_branch_dec() underflow in aql_enable_write(). [0] The problem is that aql_enable_write() does not serialise concurrent write()s to the debugfs. aql_enable_write() checks static_key_false(&aql_disable.key) and later calls static_branch_inc() or static_branch_dec(), but the state may change between the two calls. aql_disable does not need to track inc/dec. Let's use static_branch_enable() and static_branch_disable(). [0]: val == 0 WARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288 Modules linked in: CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full) Tainted: [U]=USER, [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311 Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 <0f> 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00 RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4 RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a R13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98 FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0 Call Trace: __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline] __static_key_slow_dec kernel/jump_label.c:321 [inline] static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336 aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343 short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383 vfs_write+0x2aa/0x1070 fs/read_write.c:684 ksys_pwrite64 fs/read_write.c:793 [inline] __do_sys_pwrite64 fs/read_write.c:801 [inline] __se_sys_pwrite64 fs/read_write.c:798 [inline] __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f530cf9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012 RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010 RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000 R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978 ", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23463", "url": "https://ubuntu.com/security/CVE-2026-23463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: fix race condition in qman_destroy_fq When QMAN_FQ_FLAG_DYNAMIC_FQID is set, there's a race condition between fq_table[fq->idx] state and freeing/allocating from the pool and WARN_ON(fq_table[fq->idx]) in qman_create_fq() gets triggered. Indeed, we can have: Thread A Thread B qman_destroy_fq() qman_create_fq() qman_release_fqid() qman_shutdown_fq() gen_pool_free() -- At this point, the fqid is available again -- qman_alloc_fqid() -- so, we can get the just-freed fqid in thread B -- fq->fqid = fqid; fq->idx = fqid * 2; WARN_ON(fq_table[fq->idx]); fq_table[fq->idx] = fq; fq_table[fq->idx] = NULL; And adding some logs between qman_release_fqid() and fq_table[fq->idx] = NULL makes the WARN_ON() trigger a lot more. To prevent that, ensure that fq_table[fq->idx] is set to NULL before gen_pool_free() is called by using smp_wmb().", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31683", "url": "https://ubuntu.com/security/CVE-2026-31683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: avoid OGM aggregation when skb tailroom is insufficient When OGM aggregation state is toggled at runtime, an existing forwarded packet may have been allocated with only packet_len bytes, while a later packet can still be selected for aggregation. Appending in this case can hit skb_put overflow conditions. Reject aggregation when the target skb tailroom cannot accommodate the new packet. The caller then falls back to creating a new forward packet instead of appending.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31550", "url": "https://ubuntu.com/security/CVE-2026-31550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: bcm: bcm2835-power: Increase ASB control timeout The bcm2835_asb_control() function uses a tight polling loop to wait for the ASB bridge to acknowledge a request. During intensive workloads, this handshake intermittently fails for V3D's master ASB on BCM2711, resulting in \"Failed to disable ASB master for v3d\" errors during runtime PM suspend. As a consequence, the failed power-off leaves V3D in a broken state, leading to bus faults or system hangs on later accesses. As the timeout is insufficient in some scenarios, increase the polling timeout from 1us to 5us, which is still negligible in the context of a power domain transition. Also, replace the open-coded ktime_get_ns()/ cpu_relax() polling loop with readl_poll_timeout_atomic().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23368", "url": "https://ubuntu.com/security/CVE-2026-23368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: register phy led_triggers during probe to avoid AB-BA deadlock There is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and LED_TRIGGER_PHY are enabled: [ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc <-- Trying to get lock \"triggers_list_lock\" via down_write(&triggers_list_lock); [ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234 [ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c [ 1362.065489] [<80651fc4>] phylink_fwnode_phy_connect+0x15c/0x23c [ 1362.071480] [<8066ee18>] mtk_open+0x7c/0xba0 [ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0 [ 1362.080384] [<806d7668>] __dev_change_flags+0x244/0x24c [ 1362.085598] [<806d7698>] dev_change_flags+0x28/0x78 [ 1362.090528] [<807150e4>] dev_ioctl+0x4c0/0x654 <-- Hold lock \"rtnl_mutex\" by calling rtnl_lock(); [ 1362.094985] [<80694360>] sock_ioctl+0x2f4/0x4e0 [ 1362.099567] [<802e9c4c>] sys_ioctl+0x32c/0xd8c [ 1362.104022] [<80014504>] syscall_common+0x34/0x58 Here LED_TRIGGER_PHY is registering LED triggers during phy_attach while holding RTNL and then taking triggers_list_lock. [ 1362.191101] [<806c2640>] register_netdevice_notifier+0x60/0x168 <-- Trying to get lock \"rtnl_mutex\" via rtnl_lock(); [ 1362.197073] [<805504ac>] netdev_trig_activate+0x194/0x1e4 [ 1362.202490] [<8054e28c>] led_trigger_set+0x1d4/0x360 <-- Hold lock \"triggers_list_lock\" by down_read(&triggers_list_lock); [ 1362.207511] [<8054eb38>] led_trigger_write+0xd8/0x14c [ 1362.212566] [<80381d98>] sysfs_kf_bin_write+0x80/0xbc [ 1362.217688] [<8037fcd8>] kernfs_fop_write_iter+0x17c/0x28c [ 1362.223174] [<802cbd70>] vfs_write+0x21c/0x3c4 [ 1362.227712] [<802cc0c4>] ksys_write+0x78/0x12c [ 1362.232164] [<80014504>] syscall_common+0x34/0x58 Here LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takes triggers_list_lock and then RTNL. A classical AB-BA deadlock. phy_led_triggers_registers() does not require the RTNL, it does not make any calls into the network stack which require protection. There is also no requirement the PHY has been attached to a MAC, the triggers only make use of phydev state. This allows the call to phy_led_triggers_registers() to be placed elsewhere. PHY probe() and release() don't hold RTNL, so solving the AB-BA deadlock.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23303", "url": "https://ubuntu.com/security/CVE-2026-23303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Don't log plaintext credentials in cifs_set_cifscreds When debug logging is enabled, cifs_set_cifscreds() logs the key payload and exposes the plaintext username and password. Remove the debug log to avoid exposing credentials.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23335", "url": "https://ubuntu.com/security/CVE-2026-23335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah() struct irdma_create_ah_resp { // 8 bytes, no padding __u32 ah_id; // offset 0 - SET (uresp.ah_id = ah->sc_ah.ah_info.ah_idx) __u8 rsvd[4]; // offset 4 - NEVER SET <- LEAK }; rsvd[4]: 4 bytes of stack memory leaked unconditionally. Only ah_id is assigned before ib_respond_udata(). The reserved members of the structure were not zeroed.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23336", "url": "https://ubuntu.com/security/CVE-2026-23336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel rfkill_block work in wiphy_unregister() There is a use-after-free error in cfg80211_shutdown_all_interfaces found by syzkaller: BUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220 Read of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326 CPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events cfg80211_rfkill_block_work Call Trace: dump_stack_lvl+0x116/0x1f0 print_report+0xcd/0x630 kasan_report+0xe0/0x110 cfg80211_shutdown_all_interfaces+0x213/0x220 cfg80211_rfkill_block_work+0x1e/0x30 process_one_work+0x9cf/0x1b70 worker_thread+0x6c8/0xf10 kthread+0x3c5/0x780 ret_from_fork+0x56d/0x700 ret_from_fork_asm+0x1a/0x30 The problem arises due to the rfkill_block work is not cancelled when wiphy is being unregistered. In order to fix the issue cancel the corresponding work in wiphy_unregister(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23281", "url": "https://ubuntu.com/security/CVE-2026-23281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix use-after-free in lbs_free_adapter() The lbs_free_adapter() function uses timer_delete() (non-synchronous) for both command_timer and tx_lockup_timer before the structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If a timer callback is executing when lbs_free_adapter() is called, the callback will access freed memory since lbs_cfg_free() frees the containing structure immediately after lbs_free_adapter() returns. Both timer callbacks (lbs_cmd_timeout_handler and lbs_tx_lockup_handler) access priv->driver_lock, priv->cur_cmd, priv->dev, and other fields, which would all be use-after-free violations. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning. This bug was introduced in commit 8f641d93c38a (\"libertas: detect TX lockups and reset hardware\") where del_timer() was used instead of del_timer_sync() in the cleanup path. The command_timer has had the same issue since the driver was first written.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-38562", "url": "https://ubuntu.com/security/CVE-2025-38562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference error in generate_encryptionkey If client send two session setups with krb5 authenticate to ksmbd, null pointer dereference error in generate_encryptionkey could happen. sess->Preauth_HashValue is set to NULL if session is valid. So this patch skip generate encryption key if session is valid.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2026-45920", "url": "https://ubuntu.com/security/CVE-2026-45920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix dirtyclusters double decrement on fs shutdown fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count: WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4] Tracing the failure shows that the warning fires due to an s_dirtyclusters_counter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4_mb_mark_diskspace_used() and the caller ext4_mb_new_blocks(). First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4_handle_dirty_metadata() call(s) made from ext4_mb_mark_context(). The changed value is non-zero at this point, so ext4_mb_mark_diskspace_used() does not exit after the error bubbles up from ext4_mb_mark_context(). Instead, the former decrements both cluster counters and returns the error up to ext4_mb_new_blocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency. To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4_mb_new_blocks() is responsible for acquiring cluster reservation (via ext4_claim_free_clusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45899", "url": "https://ubuntu.com/security/CVE-2026-45899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop extent cache when splitting extent fails When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45985", "url": "https://ubuntu.com/security/CVE-2026-45985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues. Assume we have an unwritten extent, and then DIO writes the second half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set. Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree. [0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone. Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45924", "url": "https://ubuntu.com/security/CVE-2026-45924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths There are two places where ksmbd_vfs_kern_path_end_removing() needs to be called in order to balance what the corresponding successful call to ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and put the taken references. Otherwise there might be potential deadlocks and unbalanced locks which are caught like: BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work 2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660 CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30 Found by Linux Verification Center (linuxtesting.org).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23227", "url": "https://ubuntu.com/security/CVE-2026-23227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/free Exynos Virtual Display driver performs memory alloc/free operations without lock protection, which easily causes concurrency problem. For example, use-after-free can occur in race scenario like this: ``` \tCPU0\t\t\t\tCPU1\t\t\t\tCPU2 \t----\t\t\t\t----\t\t\t\t---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... \t\t\t\t\t\t\t\tdrm_mode_getconnector() \t\t\t\t\t\t\t\t drm_helper_probe_single_connector_modes() \t\t\t\t\t\t\t\t vidi_get_modes() \t\t\t\t\t\t\t\t if (ctx->raw_edid) // true \t\t\t\t\t\t\t\t drm_edid_dup(ctx->raw_edid); \t\t\t\t\t\t\t\t if (!drm_edid) // false \t\t\t\t\t\t\t\t ... \t\t\t\tvidi_connection_ioctl() \t\t\t\t if (vidi->connection) // false \t\t\t\t drm_edid_free(ctx->raw_edid); // free drm_edid \t\t\t\t ... \t\t\t\t\t\t\t\t drm_edid_alloc(drm_edid->edid) \t\t\t\t\t\t\t\t kmemdup(edid); // UAF!! \t\t\t\t\t\t\t\t ... ``` To prevent these vulns, at least in vidi_context, member variables related to memory alloc/free should be protected with ctx->lock.", "cve_priority": "high", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-45958", "url": "https://ubuntu.com/security/CVE-2026-45958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: fix to avoid directly dereferencing user pointer In vidi_connection_ioctl(), vidi->edid(user pointer) is directly dereferenced in the kernel. This allows arbitrary kernel memory access from the user space, so instead of directly accessing the user pointer in the kernel, we should modify it to copy edid to kernel memory using copy_from_user() and use it.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45956", "url": "https://ubuntu.com/security/CVE-2026-45956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl() vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to obtain a struct vidi_context pointer. However, drm_dev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device. This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more. To resolve this issue, we need to store/delete the vidi device pointer in exynos_drm_private->vidi_dev during bind/unbind, and then read this exynos_drm_private->vidi_dev within ioctl() to obtain the correct struct vidi_context pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23100", "url": "https://ubuntu.com/security/CVE-2026-23100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb_pmd_shared() Patch series \"mm/hugetlb: fixes for PMD table sharing (incl. using mmu_gather)\", v3. One functional fix, one performance regression fix, and two related comment fixes. I cleaned up my prototype I recently shared [1] for the performance fix, deferring most of the cleanups I had in the prototype to a later point. While doing that I identified the other things. The goal of this patch set is to be backported to stable trees \"fairly\" easily. At least patch #1 and #4. Patch #1 fixes hugetlb_pmd_shared() not detecting any sharing Patch #2 + #3 are simple comment fixes that patch #4 interacts with. Patch #4 is a fix for the reported performance regression due to excessive IPI broadcasts during fork()+exit(). The last patch is all about TLB flushes, IPIs and mmu_gather. Read: complicated There are plenty of cleanups in the future to be had + one reasonable optimization on x86. But that's all out of scope for this series. Runtime tested, with a focus on fixing the performance regression using the original reproducer [2] on x86. This patch (of 4): We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->pt_share_count to identify sharing. We didn't convert hugetlb_pmd_shared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table. Page migration, like mbind() or migrate_pages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as \"private\" although they are \"shared\", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the pagemap interface. Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-43061", "url": "https://ubuntu.com/security/CVE-2026-43061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Fix TX deadlock when using DMA `dmaengine_terminate_async` does not guarantee that the `__dma_tx_complete` callback will run. The callback is currently the only place where `dma->tx_running` gets cleared. If the transaction is canceled and the callback never runs, then `dma->tx_running` will never get cleared and we will never schedule new TX DMA transactions again. This change makes it so we clear `dma->tx_running` after we terminate the DMA transaction. This is \"safe\" because `serial8250_tx_dma_flush` is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to `dma->tx_running` is serialized.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-23474", "url": "https://ubuntu.com/security/CVE-2026-23474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: Avoid boot crash in RedBoot partition table parser Given CONFIG_FORTIFY_SOURCE=y and a recent compiler, commit 439a1bcac648 (\"fortify: Use __builtin_dynamic_object_size() when available\") produces the warning below and an oops. Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000 ------------[ cut here ]------------ WARNING: lib/string_helpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1 memcmp: detected buffer overflow: 15 byte read of buffer size 14 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONE As Kees said, \"'names' is pointing to the final 'namelen' many bytes of the allocation ... 'namelen' could be basically any length at all. This fortify warning looks legit to me -- this code used to be reading beyond the end of the allocation.\" Since the size of the dynamic allocation is calculated with strlen() we can use strcmp() instead of memcmp() and remain within bounds.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31393", "url": "https://ubuntu.com/security/CVE-2026-31393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present: - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8). - L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5). A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data. Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43062", "url": "https://ubuntu.com/security/CVE-2026-43062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp() l2cap_ecred_reconf_rsp() casts the incoming data to struct l2cap_ecred_conn_rsp (the ECRED *connection* response, 8 bytes with result at offset 6) instead of struct l2cap_ecred_reconf_rsp (2 bytes with result at offset 0). This causes two problems: - The sizeof(*rsp) length check requires 8 bytes instead of the correct 2, so valid L2CAP_ECRED_RECONF_RSP packets are rejected with -EPROTO. - rsp->result reads from offset 6 instead of offset 0, returning wrong data when the packet is large enough to pass the check. Fix by using the correct type. Also pass the already byte-swapped result variable to BT_DBG instead of the raw __le16 field.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31396", "url": "https://ubuntu.com/security/CVE-2026-31396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix use-after-free access to PTP clock PTP clock is registered on every opening of the interface and destroyed on every closing. However it may be accessed via get_ts_info ethtool call which is possible while the interface is just present in the kernel. BUG: KASAN: use-after-free in ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 Read of size 4 at addr ffff8880194345cc by task syz.0.6/948 CPU: 1 PID: 948 Comm: syz.0.6 Not tainted 6.1.164+ #109 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x17f/0x496 mm/kasan/report.c:420 kasan_report+0xd9/0x180 mm/kasan/report.c:524 ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 gem_get_ts_info+0x138/0x1e0 drivers/net/ethernet/cadence/macb_main.c:3349 macb_get_ts_info+0x68/0xb0 drivers/net/ethernet/cadence/macb_main.c:3371 __ethtool_get_ts_info+0x17c/0x260 net/ethtool/common.c:558 ethtool_get_ts_info net/ethtool/ioctl.c:2367 [inline] __dev_ethtool net/ethtool/ioctl.c:3017 [inline] dev_ethtool+0x2b05/0x6290 net/ethtool/ioctl.c:3095 dev_ioctl+0x637/0x1070 net/core/dev_ioctl.c:510 sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215 sock_ioctl+0x577/0x6d0 net/socket.c:1320 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 457: kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:699 [inline] ptp_clock_register+0x144/0x10e0 drivers/ptp/ptp_clock.c:235 gem_ptp_init+0x46f/0x930 drivers/net/ethernet/cadence/macb_ptp.c:375 macb_open+0x901/0xd10 drivers/net/ethernet/cadence/macb_main.c:2920 __dev_open+0x2ce/0x500 net/core/dev.c:1501 __dev_change_flags+0x56a/0x740 net/core/dev.c:8651 dev_change_flags+0x92/0x170 net/core/dev.c:8722 do_setlink+0xaf8/0x3a80 net/core/rtnetlink.c:2833 __rtnl_newlink+0xbf4/0x1940 net/core/rtnetlink.c:3608 rtnl_newlink+0x63/0xa0 net/core/rtnetlink.c:3655 rtnetlink_rcv_msg+0x3c6/0xed0 net/core/rtnetlink.c:6150 netlink_rcv_skb+0x15d/0x430 net/netlink/af_netlink.c:2511 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x6d7/0xa30 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x97e/0xeb0 net/netlink/af_netlink.c:1872 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x14b/0x180 net/socket.c:730 __sys_sendto+0x320/0x3b0 net/socket.c:2152 __do_sys_sendto net/socket.c:2164 [inline] __se_sys_sendto net/socket.c:2160 [inline] __x64_sys_sendto+0xdc/0x1b0 net/socket.c:2160 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 938: kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1729 [inline] slab_free_freelist_hook mm/slub.c:1755 [inline] slab_free mm/slub.c:3687 [inline] __kmem_cache_free+0xbc/0x320 mm/slub.c:3700 device_release+0xa0/0x240 drivers/base/core.c:2507 kobject_cleanup lib/kobject.c:681 [inline] kobject_release lib/kobject.c:712 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1cd/0x350 lib/kobject.c:729 put_device+0x1b/0x30 drivers/base/core.c:3805 ptp_clock_unregister+0x171/0x270 drivers/ptp/ptp_clock.c:391 gem_ptp_remove+0x4e/0x1f0 drivers/net/ethernet/cadence/macb_ptp.c:404 macb_close+0x1c8/0x270 drivers/net/ethernet/cadence/macb_main.c:2966 __dev_close_many+0x1b9/0x310 net/core/dev.c:1585 __dev_close net/core/dev.c:1597 [inline] __dev_change_flags+0x2bb/0x740 net/core/dev.c:8649 dev_change_fl ---truncated---", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31545", "url": "https://ubuntu.com/security/CVE-2026-31545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: nxp-nci: allow GPIOs to sleep Allow the firmware and enable GPIOs to sleep. This fixes a `WARN_ON' and allows the driver to operate GPIOs which are connected to I2C GPIO expanders. -- >8 -- kernel: WARNING: CPU: 3 PID: 2636 at drivers/gpio/gpiolib.c:3880 gpiod_set_value+0x88/0x98 -- >8 --", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31399", "url": "https://ubuntu.com/security/CVE-2026-31399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/bus: Fix potential use after free in asynchronous initialization Dingisoul with KASAN reports a use after free if device_add() fails in nd_async_device_register(). Commit b6eae0f61db2 (\"libnvdimm: Hold reference on parent while scheduling async init\") correctly added a reference on the parent device to be held until asynchronous initialization was complete. However, if device_add() results in an allocation failure the ref count of the device drops to 0 prior to the parent pointer being accessed. Thus resulting in use after free. The bug bot AI correctly identified the fix. Save a reference to the parent pointer to be used to drop the parent reference regardless of the outcome of device_add().", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31400", "url": "https://ubuntu.com/security/CVE-2026-31400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix cache_request leak in cache_release When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request. In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup. The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up. Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, dequeue and free the cache_request.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2024-46715", "url": "https://ubuntu.com/security/CVE-2024-46715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver: iio: add missing checks on iio_info's callback access Some callbacks from iio_info structure are accessed without any check, so if a driver doesn't implement them trying to access the corresponding sysfs entries produce a kernel oops such as: [ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute [...] [ 2203.783416] Call trace: [ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48 [ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120 [ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4 [ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0 [ 2203.802236] vfs_read from ksys_read+0xa4/0xd4 [ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54 [ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0) [ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000 [ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000 [ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0 [ 2203.830363] Code: bad PC value [ 2203.832695] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-09-18 07:15:00 UTC" }, { "cve": "CVE-2026-23113", "url": "https://ubuntu.com/security/CVE-2026-23113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't support ->read_iter(), loop_rw_iter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path: INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000 Call Trace: context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98 There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2025-39748", "url": "https://ubuntu.com/security/CVE-2025-39748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Forget ranges when refining tnum after JSET Syzbot reported a kernel warning due to a range invariant violation on the following BPF program. 0: call bpf_get_netns_cookie 1: if r0 == 0 goto 2: if r0 & Oxffffffff goto The issue is on the path where we fall through both jumps. That path is unreachable at runtime: after insn 1, we know r0 != 0, but with the sign extension on the jset, we would only fallthrough insn 2 if r0 == 0. Unfortunately, is_branch_taken() isn't currently able to figure this out, so the verifier walks all branches. The verifier then refines the register bounds using the second condition and we end up with inconsistent bounds on this unreachable path: 1: if r0 == 0 goto r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2: if r0 & 0xffffffff goto r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0) r0 after reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0) Improving the range refinement for JSET to cover all cases is tricky. We also don't expect many users to rely on JSET given LLVM doesn't generate those instructions. So instead of improving the range refinement for JSETs, Eduard suggested we forget the ranges whenever we're narrowing tnums after a JSET. This patch implements that approach.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2026-43357", "url": "https://ubuntu.com/security/CVE-2026-43357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050-core: fix pm_runtime error handling The return value of pm_runtime_get_sync() is not checked, allowing the driver to access hardware that may fail to resume. The device usage count is also unconditionally incremented. Use pm_runtime_resume_and_get() which propagates errors and avoids incrementing the usage count on failure. In preenable, add pm_runtime_put_autosuspend() on set_8khz_samplerate() failure since postdisable does not run when preenable fails.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43476", "url": "https://ubuntu.com/security/CVE-2026-43476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas() sizeof(num) evaluates to sizeof(size_t) (8 bytes on 64-bit) instead of the intended __be32 element size (4 bytes). Use sizeof(*meas) to correctly match the buffer element type.", "cve_priority": "medium", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43363", "url": "https://ubuntu.com/security/CVE-2026-43363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/apic: Disable x2apic on resume if the kernel expects so When resuming from s2ram, firmware may re-enable x2apic mode, which may have been disabled by the kernel during boot either because it doesn't support IRQ remapping or for other reasons. This causes the kernel to continue using the xapic interface, while the hardware is in x2apic mode, which causes hangs. This happens on defconfig + bare metal + s2ram. Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be disabled, i.e. when x2apic_mode = 0. The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the pre-sleep configuration or initial boot configuration for each CPU, including MSR state: When executing from the power-on reset vector as a result of waking from an S2 or S3 sleep state, the platform firmware performs only the hardware initialization required to restore the system to either the state the platform was in prior to the initial operating system boot, or to the pre-sleep configuration state. In multiprocessor systems, non-boot processors should be placed in the same state as prior to the initial operating system boot. (further ahead) If this is an S2 or S3 wake, then the platform runtime firmware restores minimum context of the system before jumping to the waking vector. This includes: \tCPU configuration. Platform runtime firmware restores the pre-sleep \tconfiguration or initial boot configuration of each CPU (MSR, MTRR, \tfirmware update, SMBase, and so on). Interrupts must be disabled (for \tIA-32 processors, disabled by CLI instruction). \t(and other things) So at least as per the spec, re-enablement of x2apic by the firmware is allowed if \"x2apic on\" is a part of the initial boot configuration. [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization [ bp: Massage. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43365", "url": "https://ubuntu.com/security/CVE-2026-43365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix undersized l_iclog_roundoff values If the superblock doesn't list a log stripe unit, we set the incore log roundoff value to 512. This leads to corrupt logs and unmountable filesystems in generic/617 on a disk with 4k physical sectors... XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197. XFS (sda1): failed to locate log tail XFS (sda1): log mount/recovery failed: error -74 XFS (sda1): log mount failed XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Ending clean mount ...on the current xfsprogs for-next which has a broken mkfs. xfs_info shows this... meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1 data = bsize=4096 blocks=2579968, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=4096 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=268435456 extents = zoned=0 start=0 reserved=0 ...observe that the log section has sectsz=4096 sunit=0, which means that the roundoff factor is 512, not 4096 as you'd expect. We should fix mkfs not to generate broken filesystems, but anyone can fuzz the ondisk superblock so we should be more cautious. I think the inadequate logic predates commit a6a65fef5ef8d0, but that's clearly going to require a different backport.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43370", "url": "https://ubuntu.com/security/CVE-2026-43370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix use-after-free race in VM acquire Replace non-atomic vm->process_info assignment with cmpxchg() to prevent race when parent/child processes sharing a drm_file both try to acquire the same VM after fork(). (cherry picked from commit c7c573275ec20db05be769288a3e3bb2250ec618)", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43373", "url": "https://ubuntu.com/security/CVE-2026-43373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ncsi: fix skb leak in error paths Early return paths in NCSI RX and AEN handlers fail to release the received skb, resulting in a memory leak. Specifically, ncsi_aen_handler() returns on invalid AEN packets without consuming the skb. Similarly, ncsi_rcv_rsp() exits early when failing to resolve the NCSI device, response handler, or request, leaving the skb unfreed.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43380", "url": "https://ubuntu.com/security/CVE-2026-43380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read The q54sj108a2_debugfs_read function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes 'data' as the destination and 'data_char' as the source. Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since 'data' is only 34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the end of the buffer onto the stack. Additionally, the arguments were swapped: it was reading from the zero-initialized 'data_char' and writing to 'data', resulting in all-zero output regardless of the actual I2C read. Fix this by: 1. Expanding 'data_char' to 66 bytes to safely hold the hex output. 2. Correcting the bin2hex() argument order and using the actual read count. 3. Using a pointer to select the correct output buffer for the final simple_read_from_buffer call.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43381", "url": "https://ubuntu.com/security/CVE-2026-43381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dpcd: return EBUSY for aux xfer if the device is asleep If we have runtime suspended, and userspace wants to use /dev/drm_dp_* then just tell it the device is busy instead of crashing in the GSP code. WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy) Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024 RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them awake while fw updates are happening.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43382", "url": "https://ubuntu.com/security/CVE-2026-43382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid double-rtnl_lock ELP metric worker batadv_v_elp_get_throughput() might be called when the RTNL lock is already held. This could be problematic when the work queue item is cancelled via cancel_delayed_work_sync() in batadv_v_elp_iface_disable(). In this case, an rtnl_lock() would cause a deadlock. To avoid this, rtnl_trylock() was used in this function to skip the retrieval of the ethtool information in case the RTNL lock was already held. But for cfg80211 interfaces, batadv_get_real_netdev() was called - which also uses rtnl_lock(). The approach for __ethtool_get_link_ksettings() must also be used instead and the lockless version __batadv_get_real_netdev() has to be called.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-31405", "url": "https://ubuntu.com/security/CVE-2026-31405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-net: fix OOB access in ULE extension header tables The ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables in handle_one_ule_extension() are declared with 255 elements (valid indices 0-254), but the index htype is derived from network-controlled data as (ule_sndu_type & 0x00FF), giving a range of 0-255. When htype equals 255, an out-of-bounds read occurs on the function pointer table, and the OOB value may be called as a function pointer. Add a bounds check on htype against the array size before either table is accessed. Out-of-range values now cause the SNDU to be discarded.", "cve_priority": "high", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-43387", "url": "https://ubuntu.com/security/CVE-2026-43387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: properly validate the data in rtw_get_ie_ex() Just like in commit 154828bf9559 (\"staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser\"), we don't trust the data in the frame so we should check the length better before acting on it", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43386", "url": "https://ubuntu.com/security/CVE-2026-43386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie The current code checks 'i + 5 < in_len' at the end of the if statement. However, it accesses 'in_ie[i + 5]' before that check, which can lead to an out-of-bounds read. Move the length check to the beginning of the conditional to ensure the index is within bounds before accessing the array.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43420", "url": "https://ubuntu.com/security/CVE-2026-43420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix i_nlink underrun during async unlink During async unlink, we drop the `i_nlink` counter before we receive the completion (that will eventually update the `i_nlink`) because \"we assume that the unlink will succeed\". That is not a bad idea, but it races against deletions by other clients (or against the completion of our own unlink) and can lead to an underrun which emits a WARNING like this one: WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68 Modules linked in: CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drop_nlink+0x50/0x68 lr : ceph_unlink+0x6c4/0x720 sp : ffff80012173bc90 x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680 x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647 x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203 x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365 x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74 x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94 x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002 x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8 Call trace: drop_nlink+0x50/0x68 (P) vfs_unlink+0xb0/0x2e8 do_unlinkat+0x204/0x288 __arm64_sys_unlinkat+0x3c/0x80 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0xa4/0xc8 el0_svc+0x18/0x58 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x154/0x158 In ceph_unlink(), a call to ceph_mdsc_submit_request() submits the CEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion. Meanwhile, between this call and the following drop_nlink() call, a worker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT or just a CEPH_MSG_CLIENT_REPLY (the latter of which could be our own completion). These will lead to a set_nlink() call, updating the `i_nlink` counter to the value received from the MDS. If that new `i_nlink` value happens to be zero, it is illegal to decrement it further. But that is exactly what ceph_unlink() will do then. The WARNING can be reproduced this way: 1. Force async unlink; only the async code path is affected. Having no real clue about Ceph internals, I was unable to find out why the MDS wouldn't give me the \"Fxr\" capabilities, so I patched get_caps_for_async_unlink() to always succeed. (Note that the WARNING dump above was found on an unpatched kernel, without this kludge - this is not a theoretical bug.) 2. Add a sleep call after ceph_mdsc_submit_request() so the unlink completion gets handled by a worker thread before drop_nlink() is called. This guarantees that the `i_nlink` is already zero before drop_nlink() runs. The solution is to skip the counter decrement when it is already zero, but doing so without a lock is still racy (TOCTOU). Since ceph_fill_inode() and handle_cap_grant() both hold the `ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, this seems like the proper lock to protect the `i_nlink` updates. I found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using `afs_vnode.cb_lock`). All three have the zero check as well.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43405", "url": "https://ubuntu.com/security/CVE-2026-43405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Use u32 for non-negative values in ceph_monmap_decode() This patch fixes unnecessary implicit conversions that change signedness of blob_len and num_mon in ceph_monmap_decode(). Currently blob_len and num_mon are (signed) int variables. They are used to hold values that are always non-negative and get assigned in ceph_decode_32_safe(), which is meant to assign u32 values. Both variables are subsequently used as unsigned values, and the value of num_mon is further assigned to monmap->num_mon, which is of type u32. Therefore, both variables should be of type u32. This is especially relevant for num_mon. If the value read from the incoming message is very large, it is interpreted as a negative value, and the check for num_mon > CEPH_MAX_MON does not catch it. This leads to the attempt to allocate a very large chunk of memory for monmap, which will most likely fail. In this case, an unnecessary attempt to allocate memory is performed, and -ENOMEM is returned instead of -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43411", "url": "https://ubuntu.com/security/CVE-2026-43411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix divide-by-zero in tipc_sk_filter_connect() A user can set conn_timeout to any value via setsockopt(TIPC_CONN_TIMEOUT), including values less than 4. When a SYN is rejected with TIPC_ERR_OVERLOAD and the retry path in tipc_sk_filter_connect() executes: delay %= (tsk->conn_timeout / 4); If conn_timeout is in the range [0, 3], the integer division yields 0, and the modulo operation triggers a divide-by-zero exception, causing a kernel oops/panic. Fix this by clamping conn_timeout to a minimum of 4 at the point of use in tipc_sk_filter_connect(). Oops: divide error: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+ RIP: 0010:tipc_sk_filter_rcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362) Call Trace: tipc_sk_backlog_rcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406) __release_sock (include/net/sock.h:1185 net/core/sock.c:3213) release_sock (net/core/sock.c:3797) tipc_connect (net/tipc/socket.c:2570) __sys_connect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098)", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43484", "url": "https://ubuntu.com/security/CVE-2026-43484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: core: Avoid bitfield RMW for claim/retune flags Move claimed and retune control flags out of the bitfield word to avoid unrelated RMW side effects in asynchronous contexts. The host->claimed bit shared a word with retune flags. Writes to claimed in __mmc_claim_host() or retune_now in mmc_mq_queue_rq() can overwrite other bits when concurrent updates happen in other contexts, triggering spurious WARN_ON(!host->claimed). Convert claimed, can_retune, retune_now and retune_paused to bool to remove shared-word coupling.", "cve_priority": "low", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43425", "url": "https://ubuntu.com/security/CVE-2026-43425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: kill download URB on timeout mdc800_device_read() submits download_urb and waits for completion. If the timeout fires and the device has not responded, the function returns without killing the URB, leaving it active. A subsequent read() resubmits the same URB while it is still in-flight, triggering the WARN in usb_submit_urb(): \"URB submitted while active\" Check the return value of wait_event_timeout() and kill the URB if it indicates timeout, ensuring the URB is complete before its status is inspected or the URB is resubmitted. Similar to - commit 372c93131998 (\"USB: yurex: fix control-URB timeout handling\") - commit b98d5000c505 (\"media: rc: iguanair: handle timeouts\")", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43426", "url": "https://ubuntu.com/security/CVE-2026-43426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: fix use-after-free in ISR during device removal In usbhs_remove(), the driver frees resources (including the pipe array) while the interrupt handler (usbhs_interrupt) is still registered. If an interrupt fires after usbhs_pipe_remove() but before the driver is fully unbound, the ISR may access freed memory, causing a use-after-free. Fix this by calling devm_free_irq() before freeing resources. This ensures the interrupt handler is both disabled and synchronized (waits for any running ISR to complete) before usbhs_pipe_remove() is called.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43427", "url": "https://ubuntu.com/security/CVE-2026-43427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: class: cdc-wdm: fix reordering issue in read code path Quoting the bug report: Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdm_read() can see the new length and call copy_to_user() on uninitialized memory. This also violates LKMM data race rules [1]. Fix it by using WRITE_ONCE and memory barriers.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43428", "url": "https://ubuntu.com/security/CVE-2026-43428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: core: Limit the length of unkillable synchronous timeouts The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device. To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector. In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43429", "url": "https://ubuntu.com/security/CVE-2026-43429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: Use usb_bulk_msg_killable() with user-specified timeouts The usbtmc driver accepts timeout values specified by the user in an ioctl command, and uses these timeouts for some usb_bulk_msg() calls. Since the user can specify arbitrarily long timeouts and usb_bulk_msg() uses unkillable waits, call usb_bulk_msg_killable() instead to avoid the possibility of the user hanging a kernel thread indefinitely.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43430", "url": "https://ubuntu.com/security/CVE-2026-43430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: yurex: fix race in probe The bbu member of the descriptor must be set to the value standing for uninitialized values before the URB whose completion handler sets bbu is submitted. Otherwise there is a window during which probing can overwrite already retrieved data.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43432", "url": "https://ubuntu.com/security/CVE-2026-43432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix memory leak in xhci_disable_slot() xhci_alloc_command() allocates a command structure and, when the second argument is true, also allocates a completion structure. Currently, the error handling path in xhci_disable_slot() only frees the command structure using kfree(), causing the completion structure to leak. Use xhci_free_command() instead of kfree(). xhci_free_command() correctly frees both the command structure and the associated completion structure. Since the command structure is allocated with zero-initialization, command->in_ctx is NULL and will not be erroneously freed by xhci_free_command(). This bug was found using an experimental static analysis tool we are developing. The tool is based on the LLVM framework and is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available, but we plan to open-source it after our research is published. The bug was originally detected on v6.13-rc1 using our static analysis tool, and we have verified that the issue persists in the latest mainline kernel. We performed build testing on x86_64 with allyesconfig using GCC=11.4.0. Since triggering these error paths in xhci_disable_slot() requires specific hardware conditions or abnormal state, we were unable to construct a test case to reliably trigger these specific error paths at runtime.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43439", "url": "https://ubuntu.com/security/CVE-2026-43439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup: fix race between task migration and iteration When a task is migrated out of a css_set, cgroup_migrate_add_task() first moves it from cset->tasks to cset->mg_tasks via: list_move_tail(&task->cg_list, &cset->mg_tasks); If a css_task_iter currently has it->task_pos pointing to this task, css_set_move_task() calls css_task_iter_skip() to keep the iterator valid. However, since the task has already been moved to ->mg_tasks, the iterator is advanced relative to the mg_tasks list instead of the original tasks list. As a result, remaining tasks on cset->tasks, as well as tasks queued on cset->mg_tasks, can be skipped by iteration. Fix this by calling css_set_skip_task_iters() before unlinking task->cg_list from cset->tasks. This advances all active iterators to the next task on cset->tasks, so iteration continues correctly even when a task is concurrently being migrated. This race is hard to hit in practice without instrumentation, but it can be reproduced by artificially slowing down cgroup_procs_show(). For example, on an Android device a temporary /sys/kernel/cgroup/cgroup_test knob can be added to inject a delay into cgroup_procs_show(), and then: 1) Spawn three long-running tasks (PIDs 101, 102, 103). 2) Create a test cgroup and move the tasks into it. 3) Enable a large delay via /sys/kernel/cgroup/cgroup_test. 4) In one shell, read cgroup.procs from the test cgroup. 5) Within the delay window, in another shell migrate PID 102 by writing it to a different cgroup.procs file. Under this setup, cgroup.procs can intermittently show only PID 101 while skipping PID 103. Once the migration completes, reading the file again shows all tasks as expected. Note that this change does not allow removing the existing css_set_skip_task_iters() call in css_set_move_task(). The new call in cgroup_migrate_add_task() only handles iterators that are racing with migration while the task is still on cset->tasks. Iterators may also start after the task has been moved to cset->mg_tasks. If we dropped css_set_skip_task_iters() from css_set_move_task(), such iterators could keep task_pos pointing to a migrating task, causing css_task_iter_advance() to malfunction on the destination css_set, up to and including crashes or infinite loops. The race window between migration and iteration is very small, and css_task_iter is not on a hot path. In the worst case, when an iterator is positioned on the first thread of the migrating process, cgroup_migrate_add_task() may have to skip multiple tasks via css_set_skip_task_iters(). However, this only happens when migration and iteration actually race, so the performance impact is negligible compared to the correctness fix provided here.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43480", "url": "https://ubuntu.com/security/CVE-2026-43480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisition The acp3x_5682_init() function did not check the return value of clk_get(), which could lead to dereferencing error pointers in rt5682_clk_enable(). Fix this by: 1. Changing clk_get() to the device-managed devm_clk_get(). 2. Adding proper IS_ERR() checks for both clock acquisitions.", "cve_priority": "low", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43445", "url": "https://ubuntu.com/security/CVE-2026-43445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: e1000/e1000e: Fix leak in 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 after a successful 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 would leak. In these commits, a faulty while condition caused an infinite loop in dma_error: Commit 03b1320dfcee (\"e1000e: remove use of skb_dma_map from e1000e driver\") Commit 602c0554d7b0 (\"e1000: remove use of skb_dma_map from e1000 driver\") Commit c1fa347f20f1 (\"e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()\") fixed the infinite loop, but introduced the off-by-one error. This issue may still exist in the igbvf driver, but I did not address it in this patch.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43449", "url": "https://ubuntu.com/security/CVE-2026-43449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_set dev->online_queues is a count incremented in nvme_init_queue. Thus, valid indices are 0 through dev->online_queues − 1. This patch fixes the loop condition to ensure the index stays within the valid range. Index 0 is excluded because it is the admin queue. KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74 CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: nvme-reset-wq nvme_reset_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xea/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xce/0x5d0 mm/kasan/report.c:482 kasan_report+0xdc/0x110 mm/kasan/report.c:595 __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c:379 nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c:3252 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 34 on cpu 1 at 4.241550s: kasan_save_stack+0x2c/0x60 mm/kasan/common.c:57 kasan_save_track+0x1c/0x70 mm/kasan/common.c:78 kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c:570 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5657 [inline] __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c:5663 kmalloc_array_node_noprof include/linux/slab.h:1075 [inline] nvme_pci_alloc_dev drivers/nvme/host/pci.c:3479 [inline] nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534 local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c:324 pci_call_probe drivers/pci/pci-driver.c:392 [inline] __pci_device_probe drivers/pci/pci-driver.c:417 [inline] pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c:451 call_driver_probe drivers/base/dd.c:583 [inline] really_probe+0x29b/0xb70 drivers/base/dd.c:661 __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c:803 driver_probe_device+0x56/0x1f0 drivers/base/dd.c:833 __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c:1159 async_run_entry_fn+0xa6/0x4b0 kernel/async.c:129 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 The buggy address belongs to the object at ffff88800592a000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 244 bytes to the right of allocated 1152-byte region [ffff88800592a000, ffff88800592a480) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff) page_type: f5(slab) raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000 head: 000fffffc0000040 ffff888001042000 00000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43450", "url": "https://ubuntu.com/security/CVE-2026-43450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table() nfnl_cthelper_dump_table() has a 'goto restart' that jumps to a label inside the for loop body. When the \"last\" helper saved in cb->args[1] is deleted between dump rounds, every entry fails the (cur != last) check, so cb->args[1] is never cleared. The for loop finishes with cb->args[0] == nf_ct_helper_hsize, and the 'goto restart' jumps back into the loop body bypassing the bounds check, causing an 8-byte out-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize]. The 'goto restart' block was meant to re-traverse the current bucket when \"last\" is no longer found, but it was placed after the for loop instead of inside it. Move the block into the for loop body so that the restart only occurs while cb->args[0] is still within bounds. BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131 Call Trace: nfnl_cthelper_dump_table+0x9f/0x1b0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 sock_recvmsg+0xde/0xf0 __sys_recvfrom+0x150/0x200 __x64_sys_recvfrom+0x76/0x90 do_syscall_64+0xc3/0x6e0 Allocated by task 1: __kvmalloc_node_noprof+0x21b/0x700 nf_ct_alloc_hashtable+0x65/0xd0 nf_conntrack_helper_init+0x21/0x60 nf_conntrack_init_start+0x18d/0x300 nf_conntrack_standalone_init+0x12/0xc0", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43451", "url": "https://ubuntu.com/security/CVE-2026-43451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: fix entry leak in bridge verdict error path nfqnl_recv_verdict() calls find_dequeue_entry() to remove the queue entry from the queue data structures, taking ownership of the entry. For PF_BRIDGE packets, it then calls nfqa_parse_bridge() to parse VLAN attributes. If nfqa_parse_bridge() returns an error (e.g. NFQA_VLAN present but NFQA_VLAN_TCI missing), the function returns immediately without freeing the dequeued entry or its sk_buff. This leaks the nf_queue_entry, its associated sk_buff, and all held references (net_device refcounts, struct net refcount). Repeated triggering exhausts kernel memory. Fix this by dropping the entry via nfqnl_reinject() with NF_DROP verdict on the error path, consistent with other error handling in this file.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43452", "url": "https://ubuntu.com/security/CVE-2026-43452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: guard option walkers against 1-byte tail reads When the last byte of options is a non-single-byte option kind, walkers that advance with i += op[i + 1] ? : 1 can read op[i + 1] past the end of the option area. Add an explicit i == optlen - 1 check before dereferencing op[i + 1] in xt_tcpudp and xt_dccp option walkers.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43453", "url": "https://ubuntu.com/security/CVE-2026-43453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop() pipapo_drop() passes rulemap[i + 1].n to pipapo_unmap() as the to_offset argument on every iteration, including the last one where i == m->field_count - 1. This reads one element past the end of the stack-allocated rulemap array (declared as rulemap[NFT_PIPAPO_MAX_FIELDS] with NFT_PIPAPO_MAX_FIELDS == 16). Although pipapo_unmap() returns early when is_last is true without using the to_offset value, the argument is evaluated at the call site before the function body executes, making this a genuine out-of-bounds stack read confirmed by KASAN: BUG: KASAN: stack-out-of-bounds in pipapo_drop+0x50c/0x57c [nf_tables] Read of size 4 at addr ffff8000810e71a4 This frame has 1 object: [32, 160) 'rulemap' The buggy address is at offset 164 -- exactly 4 bytes past the end of the rulemap array. Pass 0 instead of rulemap[i + 1].n on the last iteration to avoid the out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43458", "url": "https://ubuntu.com/security/CVE-2026-43458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: caif: hold tty->link reference in ldisc_open and ser_release A reproducer triggers a KASAN slab-use-after-free in pty_write_room() when caif_serial's TX path calls tty_write_room(). The faulting access is on tty->link->port. Hold an extra kref on tty->link for the lifetime of the caif_serial line discipline: get it in ldisc_open() and drop it in ser_release(), and also drop it on the ldisc_open() error path. With this change applied, the reproducer no longer triggers the UAF in my testing.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43459", "url": "https://ubuntu.com/security/CVE-2026-43459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-core: flush delayed work before removing DAIs and widgets When a sound card is unbound while a PCM stream is open, a use-after-free can occur in snd_soc_dapm_stream_event(), called from the close_delayed_work workqueue handler. During unbind, snd_soc_unbind_card() flushes delayed work and then calls soc_cleanup_card_resources(). Inside cleanup, snd_card_disconnect_sync() releases all PCM file descriptors, and the resulting PCM close path can call snd_soc_dapm_stream_stop() which schedules new delayed work with a pmdown_time timer delay. Since this happens after the flush in snd_soc_unbind_card(), the new work is not caught. soc_remove_link_components() then frees DAPM widgets before this work fires, leading to the use-after-free. The existing flush in soc_free_pcm_runtime() also cannot help as it runs after soc_remove_link_components() has already freed the widgets. Add a flush in soc_cleanup_card_resources() after snd_card_disconnect_sync() (after which no new PCM closes can schedule further delayed work) and before soc_remove_link_dais() and soc_remove_link_components() (which tear down the structures the delayed work accesses).", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-23277", "url": "https://ubuntu.com/security/CVE-2026-23277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit teql_master_xmit() calls netdev_start_xmit(skb, slave) to transmit through slave devices, but does not update skb->dev to the slave device beforehand. When a gretap tunnel is a TEQL slave, the transmit path reaches iptunnel_xmit() which saves dev = skb->dev (still pointing to teql0 master) and later calls iptunnel_xmit_stats(dev, pkt_len). This function does: get_cpu_ptr(dev->tstats) Since teql_master_setup() does not set dev->pcpu_stat_type to NETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstats for teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computes NULL + __per_cpu_offset[cpu], resulting in a page fault. BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206) Fix this by setting skb->dev = slave before calling netdev_start_xmit(), so that tunnel xmit functions see the correct slave device with properly allocated tstats.", "cve_priority": "medium", "cve_public_date": "2026-03-20 09:16:00 UTC" }, { "cve": "CVE-2026-43466", "url": "https://ubuntu.com/security/CVE-2026-43466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery In case of a TX error CQE, a recovery flow is triggered, mlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc, desyncing the DMA FIFO producer and consumer. After recovery, the producer pushes new DMA entries at the old dma_fifo_pc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery. The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dma_fifo_cc is already equal to dma_fifo_pc. There is no need to reset either counter, similar to how skb_fifo pc/cc are untouched. Remove the 'dma_fifo_cc = 0' reset. This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90 Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: ? __warn+0x7d/0x110 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0x16d/0x180 ? handle_bug+0x4f/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 ? iommu_dma_unmap_page+0x2e/0x90 dma_unmap_page_attrs+0x10d/0x1b0 mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core] mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core] mlx5e_napi_poll+0x8b/0xac0 [mlx5_core] __napi_poll+0x24/0x190 net_rx_action+0x32a/0x3b0 ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core] ? notifier_call_chain+0x35/0xa0 handle_softirqs+0xc9/0x270 irq_exit_rcu+0x71/0xd0 common_interrupt+0x7f/0xa0 asm_common_interrupt+0x22/0x40", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43469", "url": "https://ubuntu.com/security/CVE-2026-43469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decrement re_receiving on the early exit paths In the event that rpcrdma_post_recvs() fails to create a work request (due to memory allocation failure, say) or otherwise exits early, we should decrement ep->re_receiving before returning. Otherwise we will hang in rpcrdma_xprt_drain() as re_receiving will never reach zero and the completion will never be triggered. On a system with high memory pressure, this can appear as the following hung task: INFO: task kworker/u385:17:8393 blocked for more than 122 seconds. Tainted: G S E 6.19.0 #3 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u385:17 state:D stack:0 pid:8393 tgid:8393 ppid:2 task_flags:0x4248060 flags:0x00080000 Workqueue: xprtiod xprt_autoclose [sunrpc] Call Trace: __schedule+0x48b/0x18b0 ? ib_post_send_mad+0x247/0xae0 [ib_core] schedule+0x27/0xf0 schedule_timeout+0x104/0x110 __wait_for_common+0x98/0x180 ? __pfx_schedule_timeout+0x10/0x10 wait_for_completion+0x24/0x40 rpcrdma_xprt_disconnect+0x444/0x460 [rpcrdma] xprt_rdma_close+0x12/0x40 [rpcrdma] xprt_autoclose+0x5f/0x120 [sunrpc] process_one_work+0x191/0x3e0 worker_thread+0x2e3/0x420 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x273/0x2b0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2025-54505", "url": "https://ubuntu.com/security/CVE-2025-54505", "cve_description": "A transient execution vulnerability within AMD CPUs may allow a local user-privileged attacker to leak data via the floating point divisor unit, potentially resulting in loss of confidentiality.", "cve_priority": "medium", "cve_public_date": "2026-04-27 16:16:00 UTC" }, { "cve": "CVE-2026-31628", "url": "https://ubuntu.com/security/CVE-2026-31628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU: Fix FPDSS on Zen1 Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43472", "url": "https://ubuntu.com/security/CVE-2026-43472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: unshare: fix unshare_fs() handling There's an unpleasant corner case in unshare(2), when we have a CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that case copy_mnt_ns() gets passed current->fs instead of a private copy, which causes interesting warts in proof of correctness] > I guess if private means fs->users == 1, the condition could still be true. Unfortunately, it's worse than just a convoluted proof of correctness. Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS (and current->fs->users == 1). We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and flips current->fs->{pwd,root} to corresponding locations in the new namespace. Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM). We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's destroyed and its mount tree is dissolved, but... current->fs->root and current->fs->pwd are both left pointing to now detached mounts. They are pinning those, so it's not a UAF, but it leaves the calling process with unshare(2) failing with -ENOMEM _and_ leaving it with pwd and root on detached isolated mounts. The last part is clearly a bug. There is other fun related to that mess (races with pivot_root(), including the one between pivot_root() and fork(), of all things), but this one is easy to isolate and fix - treat CLONE_NEWNS as \"allocate a new fs_struct even if it hadn't been shared in the first place\". Sure, we could go for something like \"if both CLONE_NEWNS *and* one of the things that might end up failing after copy_mnt_ns() call in create_new_namespaces() are set, force allocation of new fs_struct\", but let's keep it simple - the cost of copy_fs_struct() is trivial. Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets a freshly allocated fs_struct, yet to be attached to anything. That seriously simplifies the analysis... FWIW, that bug had been there since the introduction of unshare(2) ;-/", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-43473", "url": "https://ubuntu.com/security/CVE-2026-43473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Add NULL checks when resetting request and reply queues The driver encountered a crash during resource cleanup when the reply and request queues were NULL due to freed memory. This issue occurred when the creation of reply or request queues failed, and the driver freed the memory first, but attempted to mem set the content of the freed memory, leading to a system crash. Add NULL pointer checks for reply and request queues before accessing the reply/request memory during cleanup", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-43475", "url": "https://ubuntu.com/security/CVE-2026-43475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT This resolves the follow splat and lock-up when running with PREEMPT_RT enabled on Hyper-V: [ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002 [ 415.140822] INFO: lockdep is turned off. [ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common [ 415.140846] Preemption disabled at: [ 415.140847] [] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)} [ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024 [ 415.140857] Call Trace: [ 415.140861] [ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140863] dump_stack_lvl+0x91/0xb0 [ 415.140870] __schedule_bug+0x9c/0xc0 [ 415.140875] __schedule+0xdf6/0x1300 [ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980 [ 415.140879] ? rcu_is_watching+0x12/0x60 [ 415.140883] schedule_rtlock+0x21/0x40 [ 415.140885] rtlock_slowlock_locked+0x502/0x1980 [ 415.140891] rt_spin_lock+0x89/0x1e0 [ 415.140893] hv_ringbuffer_write+0x87/0x2a0 [ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0 [ 415.140900] ? rcu_is_watching+0x12/0x60 [ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc] [ 415.140904] ? HARDIRQ_verbose+0x10/0x10 [ 415.140908] ? __rq_qos_issue+0x28/0x40 [ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod] [ 415.140926] __blk_mq_issue_directly+0x4a/0xc0 [ 415.140928] blk_mq_issue_direct+0x87/0x2b0 [ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440 [ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0 [ 415.140935] __blk_flush_plug+0xf4/0x150 [ 415.140940] __submit_bio+0x2b2/0x5c0 [ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360 [ 415.140946] submit_bio_noacct_nocheck+0x272/0x360 [ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4] [ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4] [ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4] [ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4] [ 415.141060] generic_perform_write+0x14e/0x2c0 [ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4] [ 415.141083] vfs_write+0x2ca/0x570 [ 415.141087] ksys_write+0x76/0xf0 [ 415.141089] do_syscall_64+0x99/0x1490 [ 415.141093] ? rcu_is_watching+0x12/0x60 [ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0 [ 415.141097] ? rcu_is_watching+0x12/0x60 [ 415.141098] ? lock_release+0x1f0/0x2a0 [ 415.141100] ? rcu_is_watching+0x12/0x60 [ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0 [ 415.141103] ? rcu_is_watching+0x12/0x60 [ 415.141104] ? __schedule+0xb34/0x1300 [ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170 [ 415.141109] ? do_nanosleep+0x8b/0x160 [ 415.141111] ? hrtimer_nanosleep+0x89/0x100 [ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10 [ 415.141116] ? xfd_validate_state+0x26/0x90 [ 415.141118] ? rcu_is_watching+0x12/0x60 [ 415.141120] ? do_syscall_64+0x1e0/0x1490 [ 415.141121] ? do_syscall_64+0x1e0/0x1490 [ 415.141123] ? rcu_is_watching+0x12/0x60 [ 415.141124] ? do_syscall_64+0x1e0/0x1490 [ 415.141125] ? do_syscall_64+0x1e0/0x1490 [ 415.141127] ? irqentry_exit+0x140/0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-23270", "url": "https://ubuntu.com/security/CVE-2026-23270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocks As Paolo said earlier [1]: \"Since the blamed commit below, classify can return TC_ACT_CONSUMED while the current skb being held by the defragmentation engine. As reported by GangMin Kim, if such packet is that may cause a UaF when the defrag engine later on tries to tuch again such packet.\" act_ct was never meant to be used in the egress path, however some users are attaching it to egress today [2]. Attempting to reach a middle ground, we noticed that, while most qdiscs are not handling TC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, we address the issue by only allowing act_ct to bind to clsact/ingress qdiscs and shared blocks. That way it's still possible to attach act_ct to egress (albeit only with clsact). [1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/ [2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23300", "url": "https://ubuntu.com/security/CVE-2026-23300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop When a standalone IPv6 nexthop object is created with a loopback device (e.g., \"ip -6 nexthop add id 100 dev lo\"), fib6_nh_init() misclassifies it as a reject route. This is because nexthop objects have no destination prefix (fc_dst=::), causing fib6_is_reject() to match any loopback nexthop. The reject path skips fib_nh_common_init(), leaving nhc_pcpu_rth_output unallocated. If an IPv4 route later references this nexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and panics. Simplify the check in fib6_nh_init() to only match explicit reject routes (RTF_REJECT) instead of using fib6_is_reject(). The loopback promotion heuristic in fib6_is_reject() is handled separately by ip6_route_info_create_nh(). After this change, the three cases behave as follows: 1. Explicit reject route (\"ip -6 route add unreachable 2001:db8::/64\"): RTF_REJECT is set, enters reject path, skips fib_nh_common_init(). No behavior change. 2. Implicit loopback reject route (\"ip -6 route add 2001:db8::/32 dev lo\"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. ip6_route_info_create_nh() still promotes it to reject afterward. nhc_pcpu_rth_output is allocated but unused, which is harmless. 3. Standalone nexthop object (\"ip -6 nexthop add id 100 dev lo\"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. nhc_pcpu_rth_output is properly allocated, fixing the crash when IPv4 routes reference this nexthop.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23293", "url": "https://ubuntu.com/security/CVE-2026-23293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. If an IPv6 packet is injected into the interface, route_shortcircuit() is called and a NULL pointer dereference happens on neigh_lookup(). BUG: kernel NULL pointer dereference, address: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neigh_lookup+0x20/0x270 [...] Call Trace: vxlan_xmit+0x638/0x1ef0 [vxlan] dev_hard_start_xmit+0x9e/0x2e0 __dev_queue_xmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x12f/0x1590 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix this by adding an early check on route_shortcircuit() when protocol is ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here because VXLAN can be built-in even when IPv6 is built as a module.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23381", "url": "https://ubuntu.com/security/CVE-2026-23381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. Then, if neigh_suppress is enabled and an ICMPv6 Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() will dereference ipv6_stub->nd_tbl which is NULL, passing it to neigh_lookup(). This causes a kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neigh_lookup+0x16/0xe0 [...] Call Trace: ? neigh_lookup+0x16/0xe0 br_do_suppress_nd+0x160/0x290 [bridge] br_handle_frame_finish+0x500/0x620 [bridge] br_handle_frame+0x353/0x440 [bridge] __netif_receive_skb_core.constprop.0+0x298/0x1110 __netif_receive_skb_one_core+0x3d/0xa0 process_backlog+0xa0/0x140 __napi_poll+0x2c/0x170 net_rx_action+0x2c4/0x3a0 handle_softirqs+0xd0/0x270 do_softirq+0x3f/0x60 Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() in the callers. This is in essence disabling NS/NA suppression when IPv6 is disabled.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23372", "url": "https://ubuntu.com/security/CVE-2026-23372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: rawsock: cancel tx_work before socket teardown In rawsock_release(), cancel any pending tx_work and purge the write queue before orphaning the socket. rawsock_tx_work runs on the system workqueue and calls nfc_data_exchange which dereferences the NCI device. Without synchronization, tx_work can race with socket and device teardown when a process is killed (e.g. by SIGKILL), leading to use-after-free or leaked references. Set SEND_SHUTDOWN first so that if tx_work is already running it will see the flag and skip transmitting, then use cancel_work_sync to wait for any in-progress execution to finish, and finally purge any remaining queued skbs.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23339", "url": "https://ubuntu.com/security/CVE-2026-23339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: free skb on nci_transceive early error paths nci_transceive() takes ownership of the skb passed by the caller, but the -EPROTO, -EINVAL, and -EBUSY error paths return without freeing it. Due to issues clearing NCI_DATA_EXCHANGE fixed by subsequent changes the nci/nci_dev selftest hits the error path occasionally in NIPA, and kmemleak detects leaks: unreferenced object 0xff11000015ce6a40 (size 640): comm \"nci_dev\", pid 3954, jiffies 4295441246 hex dump (first 32 bytes): 6b 6b 6b 6b 00 a4 00 0c 02 e1 03 6b 6b 6b 6b 6b kkkk.......kkkkk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk backtrace (crc 7c40cc2a): kmem_cache_alloc_node_noprof+0x492/0x630 __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xc6/0x8f0 sock_alloc_send_pskb+0x326/0x3f0 nfc_alloc_send_skb+0x94/0x1d0 rawsock_sendmsg+0x162/0x4c0 do_syscall_64+0x117/0xfc0", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23340", "url": "https://ubuntu.com/security/CVE-2026-23340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs When shrinking the number of real tx queues, netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush qdiscs for queues which will no longer be used. qdisc_reset_all_tx_gt() currently serializes qdisc_reset() with qdisc_lock(). However, for lockless qdiscs, the dequeue path is serialized by qdisc_run_begin/end() using qdisc->seqlock instead, so qdisc_reset() can run concurrently with __qdisc_run() and free skbs while they are still being dequeued, leading to UAF. This can easily be reproduced on e.g. virtio-net by imposing heavy traffic while frequently changing the number of queue pairs: iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 done With KASAN enabled, this leads to reports like: BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: ... __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 udp_sendmsg+0x13c9/0x1fc0 ... Allocated by task 1270 on cpu 5 at 44.558414s: ... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg+0x13a6/0x1fc0 ... Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a/0x890 ... Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path by taking qdisc->seqlock for TCQ_F_NOLOCK qdiscs, matching the serialization model already used by dev_reset_queue(). Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state reflects an empty queue, avoiding needless re-scheduling.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23304", "url": "https://ubuntu.com/security/CVE-2026-23304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu() l3mdev_master_dev_rcu() can return NULL when the slave device is being un-slaved from a VRF. All other callers deal with this, but we lost the fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu() with commit 4832c30d5458 (\"net: ipv6: put host and anycast routes on device with address\"). KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418) Call Trace: ip6_pol_route (net/ipv6/route.c:2318) fib6_rule_lookup (net/ipv6/fib6_rules.c:115) ip6_route_output_flags (net/ipv6/route.c:2607) vrf_process_v6_outbound (drivers/net/vrf.c:437) I was tempted to rework the un-slaving code to clear the flag first and insert synchronize_rcu() before we remove the upper. But looks like the explicit fallback to loopback_dev is an established pattern. And I guess avoiding the synchronize_rcu() is nice, too.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23420", "url": "https://ubuntu.com/security/CVE-2026-23420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: Fix a locking bug Make sure that wl->mutex is locked before it is unlocked. This has been detected by the Clang thread-safety analyzer.", "cve_priority": "medium", "cve_public_date": "2026-04-03 14:16:00 UTC" }, { "cve": "CVE-2026-23357", "url": "https://ubuntu.com/security/CVE-2026-23357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix deadlock in error path of mcp251x_open The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish. This issue is similar to the one fixed in commit 7dd9c26bd6cf (\"can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\") but for the error path. To solve this issue move the call to free_irq() after the lock is released. Setting `priv->force_quit = 1` beforehand ensure that the IRQ handler will exit right away once it acquired the lock.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23362", "url": "https://ubuntu.com/security/CVE-2026-23362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix locking for bcm_op runtime updates Commit c2aba69d0c36 (\"can: bcm: add locking for bcm_op runtime updates\") added a locking for some variables that can be modified at runtime when updating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup(). Usually the RX_SETUP only handles and filters incoming traffic with one exception: When the RX_RTR_FRAME flag is set a predefined CAN frame is sent when a specific RTR frame is received. Therefore the rx bcm_op uses bcm_can_tx() which uses the bcm_tx_lock that was only initialized in bcm_tx_setup(). Add the missing spin_lock_init() when allocating the bcm_op in bcm_rx_setup() to handle the RTR case properly.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23286", "url": "https://ubuntu.com/security/CVE-2026-23286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix null-ptr-deref in lec_arp_clear_vccs syzkaller reported a null-ptr-deref in lec_arp_clear_vccs(). This issue can be easily reproduced using the syzkaller reproducer. In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared by multiple lec_arp_table entries (e.g., via entry->vcc or entry->recv_vcc). When the underlying VCC is closed, lec_vcc_close() iterates over all ARP entries and calls lec_arp_clear_vccs() for each matched entry. For example, when lec_vcc_close() iterates through the hlists in priv->lec_arp_empty_ones or other ARP tables: 1. In the first iteration, for the first matched ARP entry sharing the VCC, lec_arp_clear_vccs() frees the associated vpriv (which is vcc->user_back) and sets vcc->user_back to NULL. 2. In the second iteration, for the next matched ARP entry sharing the same VCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv from vcc->user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference it via `vcc->pop = vpriv->old_pop`, leading to a null-ptr-deref crash. Fix this by adding a null check for vpriv before dereferencing it. If vpriv is already NULL, it means the VCC has been cleared by a previous call, so we can safely skip the cleanup and just clear the entry's vcc/recv_vcc pointers. The entire cleanup block (including vcc_release_async()) is placed inside the vpriv guard because a NULL vpriv indicates the VCC has already been fully released by a prior iteration — repeating the teardown would redundantly set flags and trigger callbacks on an already-closing socket. The Fixes tag points to the initial commit because the entry->vcc path has been vulnerable since the original code. The entry->recv_vcc path was later added by commit 8d9f73c0ad2f (\"atm: fix a memory leak of vcc->user_back\") with the same pattern, and both paths are fixed here.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23296", "url": "https://ubuntu.com/security/CVE-2026-23296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix refcount leak for tagset_refcnt This leak will cause a hang when tearing down the SCSI host. For example, iscsid hangs with the following call trace: [130120.652718] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured PID: 2528 TASK: ffff9d0408974e00 CPU: 3 COMMAND: \"iscsid\" #0 [ffffb5b9c134b9e0] __schedule at ffffffff860657d4 #1 [ffffb5b9c134ba28] schedule at ffffffff86065c6f #2 [ffffb5b9c134ba40] schedule_timeout at ffffffff86069fb0 #3 [ffffb5b9c134bab0] __wait_for_common at ffffffff8606674f #4 [ffffb5b9c134bb10] scsi_remove_host at ffffffff85bfe84b #5 [ffffb5b9c134bb30] iscsi_sw_tcp_session_destroy at ffffffffc03031c4 [iscsi_tcp] #6 [ffffb5b9c134bb48] iscsi_if_recv_msg at ffffffffc0292692 [scsi_transport_iscsi] #7 [ffffb5b9c134bb98] iscsi_if_rx at ffffffffc02929c2 [scsi_transport_iscsi] #8 [ffffb5b9c134bbf0] netlink_unicast at ffffffff85e551d6 #9 [ffffb5b9c134bc38] netlink_sendmsg at ffffffff85e554ef", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23356", "url": "https://ubuntu.com/security/CVE-2026-23356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: fix \"LOGIC BUG\" in drbd_al_begin_io_nonblock() Even though we check that we \"should\" be able to do lc_get_cumulative() while holding the device->al_lock spinlock, it may still fail, if some other code path decided to do lc_try_lock() with bad timing. If that happened, we logged \"LOGIC BUG for enr=...\", but still did not return an error. The rest of the code now assumed that this request has references for the relevant activity log extents. The implcations are that during an active resync, mutual exclusivity of resync versus application IO is not guaranteed. And a potential crash at this point may not realizs that these extents could have been target of in-flight IO and would need to be resynced just in case. Also, once the request completes, it will give up activity log references it does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put(). Fix: Do not crash the kernel for a condition that is harmless during normal operation: also catch \"e->refcnt == 0\", not only \"e == NULL\" when being noisy about \"al_complete_io() called on inactive extent %u\\n\". And do not try to be smart and \"guess\" whether something will work, then be surprised when it does not. Deal with the fact that it may or may not work. If it does not, remember a possible \"partially in activity log\" state (only possible for requests that cross extent boundaries), and return an error code from drbd_al_begin_io_nonblock(). A latter call for the same request will then resume from where we left off.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23388", "url": "https://ubuntu.com/security/CVE-2026-23388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check metadata block offset is within range Syzkaller reports a \"general protection fault in squashfs_copy_data\" This is ultimately caused by a corrupted index look-up table, which produces a negative metadata block offset. This is subsequently passed to squashfs_copy_data (via squashfs_read_metadata) where the negative offset causes an out of bounds access. The fix is to check that the offset is within range in squashfs_read_metadata. This will trap this and other cases.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23379", "url": "https://ubuntu.com/security/CVE-2026-23379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: fix divide by zero in the offload path Offloading ETS requires computing each class' WRR weight: this is done by averaging over the sums of quanta as 'q_sum' and 'q_psum'. Using unsigned int, the same integer size as the individual DRR quanta, can overflow and even cause division by zero, like it happened in the following splat: Oops: divide error: 0000 [#1] SMP PTI CPU: 13 UID: 0 PID: 487 Comm: tc Tainted: G E 6.19.0-virtme #45 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Call Trace: ets_qdisc_change+0x870/0xf40 [sch_ets] qdisc_create+0x12b/0x540 tc_modify_qdisc+0x6d7/0xbd0 rtnetlink_rcv_msg+0x168/0x6b0 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x1d6/0x2b0 netlink_sendmsg+0x22e/0x470 ____sys_sendmsg+0x38a/0x3c0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x111/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f440b81c77e Code: 4d 89 d8 e8 d4 bc 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff951e4c10 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000481820 RCX: 00007f440b81c77e RDX: 0000000000000000 RSI: 00007fff951e4cd0 RDI: 0000000000000003 RBP: 00007fff951e4c20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff951f4fa8 R13: 00000000699ddede R14: 00007f440bb01000 R15: 0000000000486980 Modules linked in: sch_ets(E) netdevsim(E) ---[ end trace 0000000000000000 ]--- RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]--- Fix this using 64-bit integers for 'q_sum' and 'q_psum'.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23289", "url": "https://ubuntu.com/security/CVE-2026-23289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq() Fix a user triggerable leak on the system call failure path.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23279", "url": "https://ubuntu.com/security/CVE-2026-23279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix NULL pointer dereference in mesh_rx_csa_frame() In mesh_rx_csa_frame(), elems->mesh_chansw_params_ie is dereferenced at lines 1638 and 1642 without a prior NULL check: ifmsh->chsw_ttl = elems->mesh_chansw_params_ie->mesh_ttl; ... pre_value = le16_to_cpu(elems->mesh_chansw_params_ie->mesh_pre_value); The mesh_matches_local() check above only validates the Mesh ID, Mesh Configuration, and Supported Rates IEs. It does not verify the presence of the Mesh Channel Switch Parameters IE (element ID 118). When a received CSA action frame omits that IE, ieee802_11_parse_elems() leaves elems->mesh_chansw_params_ie as NULL, and the unconditional dereference causes a kernel NULL pointer dereference. A remote mesh peer with an established peer link (PLINK_ESTAB) can trigger this by sending a crafted SPECTRUM_MGMT/CHL_SWITCH action frame that includes a matching Mesh ID and Mesh Configuration IE but omits the Mesh Channel Switch Parameters IE. No authentication beyond the default open mesh peering is required. Crash confirmed on kernel 6.17.0-5-generic via mac80211_hwsim: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:ieee80211_mesh_rx_queued_mgmt+0x143/0x2a0 [mac80211] CR2: 0000000000000000 Fix by adding a NULL check for mesh_chansw_params_ie after mesh_matches_local() returns, consistent with how other optional IEs are guarded throughout the mesh code. The bug has been present since v3.13 (released 2014-01-19).", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23367", "url": "https://ubuntu.com/security/CVE-2026-23367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: radiotap: reject radiotap with unknown bits The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator->_next_ns_data isn't initialized (it's only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value. Fix this by moving the rejection of unknown radiotap fields down to after the in-namespace lookup, so it will really use iterator->_next_ns_data only for vendor namespaces, even in case undefined fields are present.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23318", "url": "https://ubuntu.com/security/CVE-2026-23318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Use correct version for UAC3 header validation The entry of the validators table for UAC3 AC header descriptor is defined with the wrong protocol version UAC_VERSION_2, while it should have been UAC_VERSION_3. This results in the validator never matching for actual UAC3 devices (protocol == UAC_VERSION_3), causing their header descriptors to bypass validation entirely. A malicious USB device presenting a truncated UAC3 header could exploit this to cause out-of-bounds reads when the driver later accesses unvalidated descriptor fields. The bug was introduced in the same commit as the recently fixed UAC3 feature unit sub-type typo, and appears to be from the same copy-paste error when the UAC3 section was created from the UAC2 section.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23370", "url": "https://ubuntu.com/security/CVE-2026-23370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data set_new_password() hex dumps the entire buffer, which contains plaintext password data, including current and new passwords. Remove the hex dump to avoid leaking credentials.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23352", "url": "https://ubuntu.com/security/CVE-2026-23352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/efi: defer freeing of boot services memory efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late(). There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area(). More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete. Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM. If the freed memory resides in the areas that memory map for them is still uninitialized, they won't be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages. Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map. Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that's undesirable late in boot when there is concurrency. More robust approach is to only defer freeing of the EFI boot services memory. Split efi_free_boot_services() in two. First efi_unmap_boot_services() collects ranges that should be freed into an array then efi_free_boot_services() later frees them after deferred init is complete.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23382", "url": "https://ubuntu.com/security/CVE-2026-23382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them In commit 2ff5baa9b527 (\"HID: appleir: Fix potential NULL dereference at raw event handle\"), we handle the fact that raw event callbacks can happen even for a HID device that has not been \"claimed\" causing a crash if a broken device were attempted to be connected to the system. Fix up the remaining in-tree HID drivers that forgot to add this same check to resolve the same issue.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23324", "url": "https://ubuntu.com/security/CVE-2026-23324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: usb: etas_es58x: correctly anchor the urb in the read bulk callback When submitting an urb, that is using the anchor pattern, it needs to be anchored before submitting it otherwise it could be leaked if usb_kill_anchored_urbs() is called. This logic is correctly done elsewhere in the driver, except in the read bulk callback so do that here also.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23298", "url": "https://ubuntu.com/security/CVE-2026-23298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ucan: Fix infinite loop from zero-length messages If a broken ucan device gets a message with the message length field set to 0, then the driver will loop for forever in ucan_read_bulk_callback(), hanging the system. If the length is 0, just skip the message and go on to the next one. This has been fixed in the kvaser_usb driver in the past in commit 0c73772cd2b8 (\"can: kvaser_usb: leaf: Fix potential infinite loop in command parsers\"), so there must be some broken devices out there like this somewhere.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23307", "url": "https://ubuntu.com/security/CVE-2026-23307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a message When looking at the data in a USB urb, the actual_length is the size of the buffer passed to the driver, not the transfer_buffer_length which is set by the driver as the max size of the buffer. When parsing the messages in ems_usb_read_bulk_callback() properly check the size both at the beginning of parsing the message to make sure it is big enough for the expected structure, and at the end of the message to make sure we don't overflow past the end of the buffer for the next message.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23290", "url": "https://ubuntu.com/security/CVE-2026-23290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: validate USB endpoints The pegasus driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23365", "url": "https://ubuntu.com/security/CVE-2026-23365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kalmia: validate USB endpoints The kalmia driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23312", "url": "https://ubuntu.com/security/CVE-2026-23312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: validate USB endpoints The kaweth driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23291", "url": "https://ubuntu.com/security/CVE-2026-23291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: properly drop the usb interface reference on disconnect When the device is disconnected from the driver, there is a \"dangling\" reference count on the usb interface that was grabbed in the probe callback. Fix this up by properly dropping the reference after we are done with it.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23253", "url": "https://ubuntu.com/security/CVE-2026-23253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: fix wrong reinitialization of ringbuffer on reopen dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock.", "cve_priority": "high", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-43123", "url": "https://ubuntu.com/security/CVE-2026-43123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: check return value of con2fb_acquire_newinfo() If fbcon_open() fails when called from con2fb_acquire_newinfo() then info->fbcon_par pointer remains NULL which is later dereferenced. Add check for return value of the function con2fb_acquire_newinfo() to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23220", "url": "https://ubuntu.com/security/CVE-2026-23220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error paths The problem occurs when a signed request fails smb2 signature verification check. In __process_request(), if check_sign_req() returns an error, set_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called. set_smb2_rsp_status() set work->next_smb2_rcv_hdr_off as zero. By resetting next_smb2_rcv_hdr_off to zero, the pointer to the next command in the chain is lost. Consequently, is_chained_smb2_message() continues to point to the same request header instead of advancing. If the header's NextCommand field is non-zero, the function returns true, causing __handle_ksmbd_work() to repeatedly process the same failed request in an infinite loop. This results in the kernel log being flooded with \"bad smb2 signature\" messages and high CPU usage. This patch fixes the issue by changing the return value from SERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures that the processing loop terminates immediately rather than attempting to continue from an invalidated offset.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-45911", "url": "https://ubuntu.com/security/CVE-2026-45911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix role switching during resume If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference. The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped. So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usb_hcd_is_primary_hcd+0x0/0x1c lr : cdns_host_resume+0x24/0x5c ... Call trace: usb_hcd_is_primary_hcd+0x0/0x1c (P) cdns_resume+0x6c/0xbc cdns3_controller_resume.isra.0+0xe8/0x17c cdns3_plat_resume+0x18/0x24 platform_pm_resume+0x2c/0x68 dpm_run_callback+0x90/0x248 device_resume+0x100/0x24c dpm_resume+0x190/0x2ec dpm_resume_end+0x18/0x34 suspend_devices_and_enter+0x2b0/0xa44 pm_suspend+0x16c/0x5fc state_store+0x80/0xec kobj_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x130/0x1dc vfs_write+0x240/0x370 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0x108 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-71287", "url": "https://ubuntu.com/security/CVE-2025-71287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memory: mtk-smi: fix device leak on larb probe Make sure to drop the reference taken when looking up the SMI device during larb probe on late probe failure (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23359", "url": "https://ubuntu.com/security/CVE-2026-23359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stack-out-of-bounds write in devmap get_upper_ifindexes() iterates over all upper devices and writes their indices into an array without checking bounds. Also the callers assume that the max number of upper devices is MAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack, but that assumption is not correct and the number of upper devices could be larger than MAX_NEST_DEV (e.g., many macvlans), causing a stack-out-of-bounds write. Add a max parameter to get_upper_ifindexes() to avoid the issue. When there are too many upper devices, return -EOVERFLOW and abort the redirect. To reproduce, create more than MAX_NEST_DEV(8) macvlans on a device with an XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS. Then send a packet to the device to trigger the XDP redirect path.", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43291", "url": "https://ubuntu.com/security/CVE-2026-43291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: nfc: nci: Fix parameter validation for packet data Since commit 9c328f54741b (\"net: nfc: nci: Add parameter validation for packet data\") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct).", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43283", "url": "https://ubuntu.com/security/CVE-2026-43283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle dma_free_coherent() in error path takes priv->rx_buf.alloc_len as the dma handle. This would lead to improper unmapping of the buffer. Change the dma handle to priv->rx_buf.alloc_phys.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43264", "url": "https://ubuntu.com/security/CVE-2026-43264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: of: display_timing: fix refcount leak in of_get_display_timings() of_parse_phandle() returns a device_node with refcount incremented, which is stored in 'entry' and then copied to 'native_mode'. When the error paths at lines 184 or 192 jump to 'entryfail', native_mode's refcount is not decremented, causing a refcount leak. Fix this by changing the goto target from 'entryfail' to 'timingfail', which properly calls of_node_put(native_mode) before cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43202", "url": "https://ubuntu.com/security/CVE-2026-43202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: vt8500lcdfb: fix missing dma_free_coherent() fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not freed if the error path is reached.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43203", "url": "https://ubuntu.com/security/CVE-2026-43203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: fore200e: fix use-after-free in tasklets during device removal When the PCA-200E or SBA-200E adapter is being detached, the fore200e is deallocated. However, the tx_tasklet or rx_tasklet may still be running or pending, leading to use-after-free bug when the already freed fore200e is accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet(). One of the race conditions can occur as follows: CPU 0 (cleanup) | CPU 1 (tasklet) fore200e_pca_remove_one() | fore200e_interrupt() fore200e_shutdown() | tasklet_schedule() kfree(fore200e) | fore200e_tx_tasklet() | fore200e-> // UAF Fix this by ensuring tx_tasklet or rx_tasklet is properly canceled before the fore200e is released. Add tasklet_kill() in fore200e_shutdown() to synchronize with any pending or running tasklets. Moreover, since fore200e_reset() could prevent further interrupts or data transfers, the tasklet_kill() should be placed after fore200e_reset() to prevent the tasklet from being rescheduled in fore200e_interrupt(). Finally, it only needs to do tasklet_kill() when the fore200e state is greater than or equal to FORE200E_STATE_IRQ, since tasklets are uninitialized in earlier states. In a word, the tasklet_kill() should be placed in the FORE200E_STATE_IRQ branch within the switch...case structure. This bug was identified through static analysis.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43149", "url": "https://ubuntu.com/security/CVE-2026-43149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean() The priv->rx_buffer and priv->tx_buffer are alloc'd together as contiguous buffers in uhdlc_init() but freed as two buffers in uhdlc_memclean(). Change the cleanup to only call dma_free_coherent() once on the whole buffer.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43273", "url": "https://ubuntu.com/security/CVE-2026-43273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: supply snapshot context in ceph_zero_partial_object() The ceph_zero_partial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.conf dd if=/dev/urandom of=/mnt/mycephfs/foo bs=64K count=1 mkdir /mnt/mycephfs/.snap/snap1 md5sum /mnt/mycephfs/.snap/snap1/foo fallocate -p -o 0 -l 4096 /mnt/mycephfs/foo echo 3 > /proc/sys/vm/drop/caches md5sum /mnt/mycephfs/.snap/snap1/foo # get different md5sum!!", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43159", "url": "https://ubuntu.com/security/CVE-2026-43159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix null dereference in find_network The variable pwlan has the possibility of being NULL when passed into rtw_free_network_nolock() which would later dereference the variable.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43211", "url": "https://ubuntu.com/security/CVE-2026-43211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: Fix pci_slot_trylock() error handling Commit a4e772898f8b (\"PCI: Add missing bridge lock to pci_bus_lock()\") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails. Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } } After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug. This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread. Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path. [Same patch later posted by Keith at https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com]", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43206", "url": "https://ubuntu.com/security/CVE-2026-43206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8 bytes via memset without checking the buffer size parameter. This allows unprivileged userspace to trigger an out-of bounds kernel memory write by passing a small buffer, leading to potential privilege escalation.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43275", "url": "https://ubuntu.com/security/CVE-2026-43275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Flush exception handling work when RPM level is zero Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0. When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race condition where the driver could attempt to access the host controller to handle an exception after the system had already entered a deep power-down state, resulting in a system crash. Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete and prevents illegal hardware access during the power-down sequence.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43145", "url": "https://ubuntu.com/security/CVE-2026-43145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_rproc: Fix invalid loaded resource table detection imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded resource table even when the current firmware does not provide one. When the device tree contains a \"rsc-table\" entry, priv->rsc_table is non-NULL and denotes where a resource table would be located if one is present in memory. However, when the current firmware has no resource table, rproc->table_ptr is NULL. The function still returns priv->rsc_table, and the remoteproc core interprets this as a valid loaded resource table. Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when there is no resource table for the current firmware (i.e. when rproc->table_ptr is NULL). This aligns the function's semantics with the remoteproc core: a loaded resource table is only reported when a valid table_ptr exists. With this change, starting firmware without a resource table no longer triggers a crash.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43147", "url": "https://ubuntu.com/security/CVE-2026-43147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV\" This reverts commit 05703271c3cd (\"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV\"), which causes a deadlock by recursively taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of pci_stop_and_remove_bus_device(). For example with the following sequence of commands: $ echo > /sys/bus/pci/devices//sriov_numvfs $ echo 1 > /sys/bus/pci/devices//remove A trimmed trace of the deadlock on a mlx5 device is as below: zsh/5715 is trying to acquire lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140 but task is already holding lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110 [<00000259779c844e>] print_deadlock_bug+0x31e/0x330 [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0 [<00000259779bffac>] lock_acquire+0x14c/0x350 [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520 [<000002597896413c>] mutex_lock_nested+0x3c/0x50 [<00000259784a07e4>] sriov_disable+0x34/0x140 [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core] [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core] [<00000259784857fc>] pci_device_remove+0x3c/0xa0 [<000002597851012e>] device_release_driver_internal+0x18e/0x280 [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0 [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80 [<00000259784972c2>] remove_store+0x72/0x90 [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200 [<0000025977d7241c>] vfs_write+0x24c/0x300 [<0000025977d72696>] ksys_write+0x86/0x110 [<000002597895b61c>] __do_syscall+0x14c/0x400 [<000002597896e0ee>] system_call+0x6e/0x90 This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43289", "url": "https://ubuntu.com/security/CVE-2026-43289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kexec: derive purgatory entry from symbol kexec_load_purgatory() derives image->start by locating e_entry inside an SHF_EXECINSTR section. If the purgatory object contains multiple executable sections with overlapping sh_addr, the entrypoint check can match more than once and trigger a WARN. Derive the entry section from the purgatory_start symbol when present and compute image->start from its final placement. Keep the existing e_entry fallback for purgatories that do not expose the symbol. WARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784 Call Trace: bzImage64_load+0x133/0xa00 __do_sys_kexec_file_load+0x2b3/0x5c0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e [me@linux.beauty: move helper to avoid forward declaration, per Baoquan]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43168", "url": "https://ubuntu.com/security/CVE-2026-43168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix reflink preserve cleanup issue commit c06c303832ec (\"ocfs2: fix xattr array entry __counted_by error\") doesn't handle all cases and the cleanup job for preserved xattr entries still has bug: - the 'last' pointer should be shifted by one unit after cleanup an array entry. - current code logic doesn't cleanup the first entry when xh_count is 1. Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43295", "url": "https://ubuntu.com/security/CVE-2026-43295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net() When idtab allocation fails, net is not registered with rio_add_net() yet, so kfree(net) is sufficient to release the memory. Set mport->net to NULL to avoid dangling pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43148", "url": "https://ubuntu.com/security/CVE-2026-43148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/smp: Add check for kcalloc() failure in parse_thread_groups() As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing it to of_property_read_u32_array().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43163", "url": "https://ubuntu.com/security/CVE-2026-43163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/bitmap: fix GPF in write_page caused by resize race A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod] This is a use-after-free race between bitmap_daemon_work() and __bitmap_resize(). The daemon iterates over `bitmap->storage.filemap` without locking, while the resize path frees that storage via md_bitmap_file_unmap(). `quiesce()` does not stop the md thread, allowing concurrent access to freed pages. Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43200", "url": "https://ubuntu.com/security/CVE-2026-43200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functions struct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target); While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specify the parameters in the correct order, pci_primary_epc_epf_unlink() and pci_secondary_epc_epf_unlink() specify the parameters in the wrong order, leading to the below kernel crash when using the unlink command in configfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0 [mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43158", "url": "https://ubuntu.com/security/CVE-2026-43158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix freemap adjustments when adding xattrs to leaf blocks xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) \t\t\t\t\t+ xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where \"rhs\" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 (\"xfs: fix attr leaf header freemap.size underflow\") and the previous patch that resets zero length freemap entries to have base = 0.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43187", "url": "https://ubuntu.com/security/CVE-2026-43187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: delete attr leaf freemap entries when empty Back in commit 2a2b5932db6758 (\"xfs: fix attr leaf header freemap.size underflow\"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the \"pushed-up\" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43130", "url": "https://ubuntu.com/security/CVE-2026-43130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode Commit 4fc82cd907ac (\"iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected\") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system. For example, if a VM fails to connect to the PCIe device, \"virsh destroy\" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd. Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput Although pci_device_is_present() is slower than pci_dev_is_disconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase. Besides, devtlb_invalidation_with_pasid() is called only in the paths below, which are far less frequent than memory map/unmap. 1. mm-struct release 2. {attach,release}_dev 3. set/remove PASID 4. dirty-tracking setup The gain in system stability far outweighs the negligible cost of using pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43133", "url": "https://ubuntu.com/security/CVE-2026-43133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation Commit cc3ed80ae69f (\"KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state\") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01. As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43196", "url": "https://ubuntu.com/security/CVE-2026-43196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: ti: pruss: Fix double free in pruss_clk_mux_setup() In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectly calls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np) on the error path. However, after the devm_add_action_or_reset() returns, the of_node_put(clk_mux_np) is called again, causing a double free. Fix by returning directly, to avoid the duplicate of_node_put().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43242", "url": "https://ubuntu.com/security/CVE-2026-43242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: ti: k3-socinfo: Fix regmap leak on probe failure The mmio regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43278", "url": "https://ubuntu.com/security/CVE-2026-43278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: clear cloned request bio pointer when last clone bio completes Stale rq->bio values have been observed to cause double-initialization of cloned bios in request-based device-mapper targets, leading to use-after-free and double-free scenarios. One such case occurs when using dm-multipath on top of a PCIe NVMe namespace, where cloned request bios are freed during blk_complete_request(), but rq->bio is left intact. Subsequent clone teardown then attempts to free the same bios again via blk_rq_unprep_clone(). The resulting double-free path looks like: nvme_pci_complete_batch() nvme_complete_batch() blk_mq_end_request_batch() blk_complete_request() // called on a DM clone request bio_endio() // first free of all clone bios ... rq->end_io() // end_clone_request() dm_complete_request(tio->orig) dm_softirq_done() dm_done() dm_end_request() blk_rq_unprep_clone() // second free of clone bios Fix this by clearing the clone request's bio pointer when the last cloned bio completes, ensuring that later teardown paths do not attempt to free already-released bios.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43312", "url": "https://ubuntu.com/security/CVE-2026-43312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov5647: Initialize subdev before controls In ov5647_init_controls() we call v4l2_get_subdevdata, but it is initialized by v4l2_i2c_subdev_init() in the probe, which currently happens after init_controls(). This can result in a segfault if the error condition is hit, and we try to access i2c_client, so fix the order.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43182", "url": "https://ubuntu.com/security/CVE-2026-43182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ccs: Avoid possible division by zero Calculating maximum M for scaler configuration involves dividing by MIN_X_OUTPUT_SIZE limit register's value. Albeit the value is presumably non-zero, the driver was missing the check it in fact was. Fix this.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43246", "url": "https://ubuntu.com/security/CVE-2026-43246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c/tw9906: Fix potential memory leak in tw9906_probe() In one of the error paths in tw9906_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43218", "url": "https://ubuntu.com/security/CVE-2026-43218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c/tw9903: Fix potential memory leak in tw9903_probe() In one of the error paths in tw9903_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43135", "url": "https://ubuntu.com/security/CVE-2026-43135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: Add missing unmap in snd_cx23885_hw_params() In error path, add cx23885_alsa_dma_unmap() to release the resource acquired by cx23885_alsa_dma_map().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43257", "url": "https://ubuntu.com/security/CVE-2026-43257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx88: Add missing unmap in snd_cx88_hw_params() In error path, add cx88_alsa_dma_unmap() to release resource acquired by cx88_alsa_dma_map().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43231", "url": "https://ubuntu.com/security/CVE-2026-43231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-keene: fix memory leak in error path Fix a memory leak in usb_keene_probe(). The v4l2 control handler is initialized and controls are added, but if v4l2_device_register() or video_register_device() fails afterward, the handler was never freed, leaking memory. Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensure the control handler is properly freed for all error paths after it is initialized.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43136", "url": "https://ubuntu.com/security/CVE-2026-43136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Check maxfield in hidpp_get_report_length() Do not crash when a report has no fields. Fake USB gadgets can send their own HID report descriptors and can define report structures without valid fields. This can be used to crash the kernel over USB.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43251", "url": "https://ubuntu.com/security/CVE-2026-43251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: prodikeys: Check presence of pm->input_ep82 Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, pm->input_ep82 stays NULL, which leads to a crash later. This does not happen with the real device, but can be provoked by imposing as one.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43140", "url": "https://ubuntu.com/security/CVE-2026-43140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: Do not crash on missing msc->input Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, msc->input stays NULL, leading to a crash at a later time. Detect this condition in the input_configured() hook and reject the device. This is not supposed to happen with actual magic mouse devices, but can be provoked by imposing as a magic mouse USB device.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43152", "url": "https://ubuntu.com/security/CVE-2026-43152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hid-pl: handle probe errors Errors in init must be reported back or we'll follow a NULL pointer the first time FF is used.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43315", "url": "https://ubuntu.com/security/CVE-2026-43315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeeding Drop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failing as it is trivially easy to trigger from userspace by modifying CPUID after loading CR3. E.g. modifying the state restoration selftest like so: --- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main(int argc, char *argv[]) /* Restore state in a new VM. */ vcpu = vm_recreate_with_one_vcpu(vm); - vcpu_load_state(vcpu, state); + + if (stage == 4) { + state->sregs.cr3 = BIT(44); + vcpu_load_state(vcpu, state); + + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36); + __vcpu_nested_state_set(vcpu, &state->nested); + } else { + vcpu_load_state(vcpu, state); + } /* * Restore XSAVE state in a dummy vCPU, first without doing generates: WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd] Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm] CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd] Call Trace: kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm] kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Simply delete the WARN instead of trying to prevent userspace from shoving \"illegal\" state into CR3. For better or worse, KVM's ABI allows userspace to set CPUID after SREGS, and vice versa, and KVM is very permissive when it comes to guest CPUID. I.e. attempting to enforce the virtual CPU model when setting CPUID could break userspace. Given that the WARN doesn't provide any meaningful protection for KVM or benefit for userspace, simply drop it even though the odds of breaking userspace are minuscule. Opportunistically delete a spurious newline.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43270", "url": "https://ubuntu.com/security/CVE-2026-43270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove() In mtk_mdp_probe(), vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43207", "url": "https://ubuntu.com/security/CVE-2026-43207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix error handling in probe function Add mtk_mdp_unregister_m2m_device() on the error handling path to prevent resource leak. Add check for the return value of vpu_get_plat_device() to prevent null pointer dereference. And vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43132", "url": "https://ubuntu.com/security/CVE-2026-43132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: correctly handle dm_bufio_client_create() failure If either of the calls to dm_bufio_client_create() in verity_fec_ctr() fails, then dm_bufio_client_destroy() is later called with an ERR_PTR() argument. That causes a crash. Fix this.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2025-71274", "url": "https://ubuntu.com/security/CVE-2025-71274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: core: fix race in driver_override_show() and use core helper The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string_attr macro with explicit show and store functions. The new driver_override_store uses the standard driver_set_override helper. Since the introduction of driver_set_override, the comments in include/linux/rpmsg.h have stated that this helper must be used to set or clear driver_override, but the implementation was not updated until now. Because driver_set_override modifies and frees the string while holding the device_lock, the new driver_override_show now correctly holds the device_lock during the read operation to prevent the race. Additionally, since rpmsg_string_attr has only ever been used for driver_override, removing the macro simplifies the code.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43233", "url": "https://ubuntu.com/security/CVE-2026-43233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: fix OOB read in decode_choice() In decode_choice(), the boundary check before get_len() uses the variable `len`, which is still 0 from its initialization at the top of the function: unsigned int type, ext, len = 0; ... if (ext || (son->attr & OPEN)) { BYTE_ALIGN(bs); if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */ return H323_ERROR_BOUND; len = get_len(bs); /* OOB read */ When the bitstream is exactly consumed (bs->cur == bs->end), the check nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent get_len() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well. This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nf_conntrack_h323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer. Fix this by checking for 2 bytes (the maximum that get_len() may read) instead of the uninitialized `len`. This matches the pattern used at every other get_len() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43205", "url": "https://ubuntu.com/security/CVE-2026-43205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: validate num_ifs to prevent out-of-bounds write The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes() but never validates it against DPSW_MAX_IF (64). This value controls iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices into the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reports num_ifs >= 64, the loop can write past the array bounds. Add a bound check for num_ifs in dpaa2_switch_init(). dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all ports match the flood filter, the loop fills all 64 slots and the control interface write overflows by one entry. The check uses >= because num_ifs == DPSW_MAX_IF is also functionally broken. build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ...", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43194", "url": "https://ubuntu.com/security/CVE-2026-43194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: consume xmit errors of GSO frames udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min. These tests use veth to simulate GRO. They attach a trivial (\"return XDP_PASS;\") XDP program to the veth to force TSO off and NAPI on. Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]). In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck. The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok | ok ok ok \\\\ \t\t\t snd_nxt \"x\" means packet lost by veth, and \"ok\" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent. So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above). Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely. We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-\"networks\" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix? Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link).", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43156", "url": "https://ubuntu.com/security/CVE-2026-43156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: enable basic endpoint checking pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors: - usb_rcvbulkpipe(dev, 1) for RX data - usb_sndbulkpipe(dev, 2) for TX data - usb_rcvintpipe(dev, 3) for status interrupts A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes. Add a pegasus_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion. Similar fix to - commit 90b7f2961798 (\"net: usb: rtl8150: enable basic endpoint checking\") - commit 9e7021d2aeae (\"net: usb: catc: enable basic endpoint checking\")", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43232", "url": "https://ubuntu.com/security/CVE-2026-43232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets When the FarSync T-series card is being detached, the fst_card_info is deallocated in fst_remove_one(). However, the fst_tx_task or fst_int_task may still be running or pending, leading to use-after-free bugs when the already freed fst_card_info is accessed in fst_process_tx_work_q() or fst_process_int_work_q(). A typical race condition is depicted below: CPU 0 (cleanup) | CPU 1 (tasklet) | fst_start_xmit() fst_remove_one() | tasklet_schedule() unregister_hdlc_device()| | fst_process_tx_work_q() //handler kfree(card) //free | do_bottom_half_tx() | card-> //use The following KASAN trace was captured: ================================================================== BUG: KASAN: slab-use-after-free in do_bottom_half_tx+0xb88/0xd00 Read of size 4 at addr ffff88800aad101c by task ksoftirqd/3/32 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcb/0x5d0 ? do_bottom_half_tx+0xb88/0xd00 kasan_report+0xb8/0xf0 ? do_bottom_half_tx+0xb88/0xd00 do_bottom_half_tx+0xb88/0xd00 ? _raw_spin_lock_irqsave+0x85/0xe0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx___hrtimer_run_queues+0x10/0x10 fst_process_tx_work_q+0x67/0x90 tasklet_action_common+0x1fa/0x720 ? hrtimer_interrupt+0x31f/0x780 handle_softirqs+0x176/0x530 __irq_exit_rcu+0xab/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 41 on cpu 3 at 72.330843s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 __kasan_kmalloc+0x7f/0x90 fst_add_one+0x1a5/0x1cd0 local_pci_probe+0xdd/0x190 pci_device_probe+0x341/0x480 really_probe+0x1c6/0x6a0 __driver_probe_device+0x248/0x310 driver_probe_device+0x48/0x210 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x101/0x190 __device_attach+0x198/0x3a0 device_initial_probe+0x78/0xa0 pci_bus_add_device+0x81/0xc0 pci_bus_add_devices+0x7e/0x190 enable_slot+0x9b9/0x1130 acpiphp_check_bridge.part.0+0x2e1/0x460 acpiphp_hotplug_notify+0x36c/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... Freed by task 41 on cpu 1 at 75.138639s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x135/0x410 fst_remove_one+0x2ca/0x540 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0x364/0x530 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device+0xd/0x20 disable_slot+0x116/0x260 acpiphp_disable_and_eject_slot+0x4b/0x190 acpiphp_hotplug_notify+0x230/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... The buggy address belongs to the object at ffff88800aad1000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 28 bytes inside of freed 1024-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xaad0 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x100000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000003 ffffea00002ab401 00000000ffffffff 00000000ffffffff head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88800aad0f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800aad0f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800aad1000: fa fb ---truncated---", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43134", "url": "https://ubuntu.com/security/CVE-2026-43134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ This adds a check for encryption key size upon receiving L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAP_CR_LE_BAD_KEY_SIZE.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43180", "url": "https://ubuntu.com/security/CVE-2026-43180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls netif_stop_queue() and netif_wake_queue(). These are TX queue flow control functions unrelated to RX multicast configuration. The premature netif_wake_queue() can re-enable TX while tx_urb is still in-flight, leading to a double usb_submit_urb() on the same URB: kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); } kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done } kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active } This triggers the WARN in usb_submit_urb(): \"URB submitted while active\" This is a similar class of bug fixed in rtl8150 by - commit 958baf5eaee3 (\"net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast\"). Also kaweth_set_rx_mode() is already functionally broken, the real set_rx_mode action is performed by kaweth_async_set_rx_mode(), which in turn is not a no-op only at ndo_open() time.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43139", "url": "https://ubuntu.com/security/CVE-2026-43139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix uninitialized saddr in xfrm6_get_saddr() xfrm6_get_saddr() does not check the return value of ipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6_get_saddr() still returns 0 (success). This causes the caller xfrm_tmpl_resolve_one() to use the uninitialized address in xfrm_state_find(), triggering KMSAN warning: ===================================================== BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940 xfrm_state_find+0x2424/0xa940 xfrm_resolve_and_create_bundle+0x906/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 xfrm_lookup_route+0x63/0x2b0 ip_route_output_flow+0x1ce/0x270 udp_sendmsg+0x2ce1/0x3400 inet_sendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64_sys_sendto+0x130/0x200 x64_sys_call+0x332b/0x3e70 do_syscall_64+0xd3/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable tmp.i.i created at: xfrm_resolve_and_create_bundle+0x3e3/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 ===================================================== Fix by checking the return value of ipv6_dev_get_saddr() and propagating the error.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43141", "url": "https://ubuntu.com/security/CVE-2026-43141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut Number of MW LUTs depends on NTB configuration and can be set to zero, in such scenario rounddown_pow_of_two will cause undefined behaviour and should not be performed. This patch ensures that rounddown_pow_of_two is called on valid value.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43241", "url": "https://ubuntu.com/security/CVE-2026-43241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access Number of MW LUTs depends on NTB configuration and can be set to MAX_MWS, This patch protects against invalid index out of bounds access to mw_sizes When invalid access print message to user that configuration is not valid.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43279", "url": "https://ubuntu.com/security/CVE-2026-43279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Add sanity check for OOB writes at silencing At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2025-71267", "url": "https://ubuntu.com/security/CVE-2025-71267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an ATTR_LIST attribute indicates a zero data size while the driver allocates memory for it. When ntfs_load_attr_list() processes a resident ATTR_LIST with data_size set to zero, it still allocates memory because of al_aligned(0). This creates an inconsistent state where ni->attr_list.size is zero, but ni->attr_list.le is non-null. This causes ni_enum_attr_ex to incorrectly assume that no attribute list exists and enumerates only the primary MFT record. When it finds ATTR_LIST, the code reloads it and restarts the enumeration, repeating indefinitely. The mount operation never completes, hanging the kernel thread. This patch adds validation to ensure that data_size is non-zero before memory allocation. When a zero-sized ATTR_LIST is detected, the function returns -EINVAL, preventing a DoS vulnerability.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2025-71265", "url": "https://ubuntu.com/security/CVE-2025-71265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an attribute header indicates an empty run list, while directory entries reference it as containing actual data. In NTFS, setting evcn=-1 with svcn=0 is a valid way to represent an empty run list, and run_unpack() correctly handles this by checking if evcn + 1 equals svcn and returning early without parsing any run data. However, this creates a problem when there is metadata inconsistency, where the attribute header claims to be empty (evcn=-1) but the caller expects to read actual data. When run_unpack() immediately returns success upon seeing this condition, it leaves the runs_tree uninitialized with run->runs as a NULL. The calling function attr_load_runs_range() assumes that a successful return means that the runs were loaded and sets clen to 0, expecting the next run_lookup_entry() call to succeed. Because runs_tree remains uninitialized, run_lookup_entry() continues to fail, and the loop increments vcn by zero (vcn += 0), leading to an infinite loop. This patch adds a retry counter to detect when run_lookup_entry() fails consecutively after attr_load_runs_vcn(). If the run is still not found on the second attempt, it indicates corrupted metadata and returns -EINVAL, preventing the Denial-of-Service (DoS) vulnerability.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2025-71266", "url": "https://ubuntu.com/security/CVE-2025-71266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: check return value of indx_find to avoid infinite loop We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed dentry in the ntfs3 filesystem can cause the kernel to hang during the lookup operations. By setting the HAS_SUB_NODE flag in an INDEX_ENTRY within a directory's INDEX_ALLOCATION block and manipulating the VCN pointer, an attacker can cause the indx_find() function to repeatedly read the same block, allocating 4 KB of memory each time. The kernel lacks VCN loop detection and depth limits, causing memory exhaustion and an OOM crash. This patch adds a return value check for fnd_push() to prevent a memory exhaustion vulnerability caused by infinite loops. When the index exceeds the size of the fnd->nodes array, fnd_push() returns -EINVAL. The indx_find() function checks this return value and stops processing, preventing further memory allocation.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-43225", "url": "https://ubuntu.com/security/CVE-2026-43225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix memory leak on failure path cfg80211_inform_bss_frame() may return NULL on failure. In that case, the allocated buffer 'buf' is not freed and the function returns early, leading to potential memory leak. Fix this by ensuring that 'buf' is freed on both success and failure paths.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43230", "url": "https://ubuntu.com/security/CVE-2026-43230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: Clear reconnect pending bit When canceling the reconnect worker, care must be taken to reset the reconnect-pending bit. If the reconnect worker has not yet been scheduled before it is canceled, the reconnect-pending bit will stay on forever.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43296", "url": "https://ubuntu.com/security/CVE-2026-43296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Workaround SQM/PSE stalls by disabling sticky NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated. work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21) These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43226", "url": "https://ubuntu.com/security/CVE-2026-43226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: No shortcut out of RDS_CONN_ERROR RDS connections carry a state \"rds_conn_path::cp_state\" and transitions from one state to another and are conditional upon an expected state: \"rds_conn_path_transition.\" There is one exception to this conditionality, which is \"RDS_CONN_ERROR\" that can be enforced by \"rds_conn_path_drop\" regardless of what state the condition is currently in. But as soon as a connection enters state \"RDS_CONN_ERROR\", the connection handling code expects it to go through the shutdown-path. The RDS/TCP multipath changes added a shortcut out of \"RDS_CONN_ERROR\" straight back to \"RDS_CONN_CONNECTING\" via \"rds_tcp_accept_one_path\" (e.g. after \"rds_tcp_state_change\"). A subsequent \"rds_tcp_reset_callbacks\" can then transition the state to \"RDS_CONN_RESETTING\" with a shutdown-worker queued. That'll trip up \"rds_conn_init_shutdown\", which was never adjusted to handle \"RDS_CONN_RESETTING\" and subsequently drops the connection with the dreaded \"DR_INV_CONN_STATE\", which leaves \"RDS_SHUTDOWN_WORK_QUEUED\" on forever. So we do two things here: a) Don't shortcut \"RDS_CONN_ERROR\", but take the longer path through the shutdown code. b) Add \"RDS_CONN_RESETTING\" to the expected states in \"rds_conn_init_shutdown\" so that we won't error out and get stuck, if we ever hit weird state transitions like this again.\"", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43190", "url": "https://ubuntu.com/security/CVE-2026-43190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_tcpmss: check remaining length before reading optlen Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload).", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43255", "url": "https://ubuntu.com/security/CVE-2026-43255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix WARNING in usb_tx_block The function usb_tx_block() submits cardp->tx_urb without ensuring that any previous transmission on this URB has completed. If a second call occurs while the URB is still active (e.g. during rapid firmware loading), usb_submit_urb() detects the active state and triggers a warning: 'URB submitted while active'. Fix this by enforcing serialization: call usb_kill_urb() before submitting the new request. This ensures the URB is idle and safe to reuse.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43314", "url": "https://ubuntu.com/security/CVE-2026-43314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: remove fake timeout to avoid leak request Since commit 15f73f5b3e59 (\"blk-mq: move failure injection out of blk_mq_complete_request\"), drivers are responsible for calling blk_should_fake_timeout() at appropriate code paths and opportunities. However, the dm driver does not implement its own timeout handler and relies on the timeout handling of its slave devices. If an io-timeout-fail error is injected to a dm device, the request will be leaked and never completed, causing tasks to hang indefinitely. Reproduce: 1. prepare dm which has iscsi slave device 2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times 3. read/write dm 4. iscsiadm -m node -u Result: hang task like below [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds. [ 862.244133] Tainted: G E 6.19.0-rc1+ #51 [ 862.244337] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000 [ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi] [ 862.245264] Call Trace: [ 862.245587] [ 862.245814] __schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120 [ 862.247688] elevator_change+0x16d/0x460 [ 862.247893] elevator_set_none+0x87/0xf0 [ 862.248798] blk_unregister_queue+0x12e/0x2a0 [ 862.248995] __del_gendisk+0x231/0x7e0 [ 862.250143] del_gendisk+0x12f/0x1d0 [ 862.250339] sd_remove+0x85/0x130 [sd_mod] [ 862.250650] device_release_driver_internal+0x36d/0x530 [ 862.250849] bus_remove_device+0x1dd/0x3f0 [ 862.251042] device_del+0x38a/0x930 [ 862.252095] __scsi_remove_device+0x293/0x360 [ 862.252291] scsi_remove_target+0x486/0x760 [ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi] [ 862.252886] process_one_work+0x633/0xe50 [ 862.253101] worker_thread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] ret_from_fork+0x2a6/0x470 [ 862.255852] ret_from_fork_asm+0x1a/0x30 [ 862.256037] Remove the blk_should_fake_timeout() check from dm, as dm has no native timeout handling and should not attempt to fake timeouts.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-71292", "url": "https://ubuntu.com/security/CVE-2025-71292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: nlink overflow in jfs_rename If nlink is maximal for a directory (-1) and inside that directory you perform a rename for some child directory (not moving from the parent), then the nlink of the first directory is first incremented and later decremented. Normally this is fine, but when nlink = -1 this causes a wrap around to 0, and then drop_nlink issues a warning. After applying the patch syzbot no longer issues any warnings. I also ran some basic fs tests to look for any regressions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43236", "url": "https://ubuntu.com/security/CVE-2026-43236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying the atmel_hlcdc_plane state structure without properly duplicating the drm_plane_state. In particular, state->commit remained set to the old state commit, which can lead to a use-after-free in the next drm_atomic_commit() call. Fix this by calling __drm_atomic_helper_duplicate_plane_state(), which correctly clones the base drm_plane_state (including the ->commit pointer). It has been seen when closing and re-opening the device node while another DRM client (e.g. fbdev) is still attached: ============================================================================= BUG kmalloc-64 (Not tainted): Poison overwritten ----------------------------------------------------------------------------- 0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0 pid=29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28 Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0 pid=169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0 flags=0x200(workingset|zone=0) Object 0xc611b340 @offset=832 fp=0xc611b7c0", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43269", "url": "https://ubuntu.com/security/CVE-2026-43269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback After several commits, the slab memory increases. Some drm_crtc_commit objects are not freed. The atomic_destroy_state callback only put the framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function to put all the objects that are no longer needed. It has been seen after hours of usage of a graphics application or using kmemleak: unreferenced object 0xc63a6580 (size 64): comm \"egt_basic\", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleak_alloc+0x34/0x3c __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43287", "url": "https://ubuntu.com/security/CVE-2026-43287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Account property blob allocations to memcg DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory. Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM. Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43183", "url": "https://ubuntu.com/security/CVE-2026-43183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx25821: Fix a resource leak in cx25821_dev_setup() Add release_mem_region() if ioremap() fails to release the memory region obtained by cx25821_get_resources().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43316", "url": "https://ubuntu.com/security/CVE-2026-43316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: solo6x10: Check for out of bounds chip_id Clang with CONFIG_UBSAN_SHIFT=y noticed a condition where a signed type (literal \"1\" is an \"int\") could end up being shifted beyond 32 bits, so instrumentation was added (and due to the double is_tw286x() call seen via inlining), Clang decides the second one must now be undefined behavior and elides the rest of the function[1]. This is a known problem with Clang (that is still being worked on), but we can avoid the entire problem by actually checking the existing max chip ID, and now there is no runtime instrumentation added at all since everything is known to be within bounds. Additionally use an unsigned value for the shift to remove the instrumentation even without the explicit bounds checking. [hverkuil: fix checkpatch warning for is_tw286x]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43223", "url": "https://ubuntu.com/security/CVE-2026-43223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix URB leak in pvr2_send_request_ex When pvr2_send_request_ex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2_send_request_ex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usb_submit_urb(). Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43302", "url": "https://ubuntu.com/security/CVE-2026-43302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Set DMA segment size to avoid debug warnings When using V3D rendering with CONFIG_DMA_API_DEBUG enabled, the kernel occasionally reports a segment size mismatch. This is because 'max_seg_size' is not set. The kernel defaults to 64K. setting 'max_seg_size' to the maximum will prevent 'debug_dma_map_sg()' from complaining about the over-mapping of the V3D segment length. DMA-API: v3d 1002000000.v3d: mapping sg segment longer than device claims to support [len=8290304] [max=65536] WARNING: CPU: 0 PID: 493 at kernel/dma/debug.c:1179 debug_dma_map_sg+0x330/0x388 CPU: 0 UID: 0 PID: 493 Comm: Xorg Not tainted 6.12.53-yocto-standard #1 Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_dma_map_sg+0x330/0x388 lr : debug_dma_map_sg+0x330/0x388 sp : ffff8000829a3ac0 x29: ffff8000829a3ac0 x28: 0000000000000001 x27: ffff8000813fe000 x26: ffffc1ffc0000000 x25: ffff00010fdeb760 x24: 0000000000000000 x23: ffff8000816a9bf0 x22: 0000000000000001 x21: 0000000000000002 x20: 0000000000000002 x19: ffff00010185e810 x18: ffffffffffffffff x17: 69766564206e6168 x16: 74207265676e6f6c x15: 20746e656d676573 x14: 20677320676e6970 x13: 5d34303334393134 x12: 0000000000000000 x11: 00000000000000c0 x10: 00000000000009c0 x9 : ffff8000800e0b7c x8 : ffff00010a315ca0 x7 : ffff8000816a5110 x6 : 0000000000000001 x5 : 000000000000002b x4 : 0000000000000002 x3 : 0000000000000008 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00010a315280 Call trace: debug_dma_map_sg+0x330/0x388 __dma_map_sg_attrs+0xc0/0x278 dma_map_sgtable+0x30/0x58 drm_gem_shmem_get_pages_sgt+0xb4/0x140 v3d_bo_create_finish+0x28/0x130 [v3d] v3d_create_bo_ioctl+0x54/0x180 [v3d] drm_ioctl_kernel+0xc8/0x140 drm_ioctl+0x2d4/0x4d8", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43124", "url": "https://ubuntu.com/security/CVE-2026-43124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore: ram_core: fix incorrect success return when vmap() fails In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43227", "url": "https://ubuntu.com/security/CVE-2026-43227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/sh_tmu: Always leave device running after probe The TMU device can be used as both a clocksource and a clockevent provider. The driver tries to be smart and power itself on and off, as well as enabling and disabling its clock when it's not in operation. This behavior is slightly altered if the TMU is used as an early platform device in which case the device is left powered on after probe, but the clock is still enabled and disabled at runtime. This has worked for a long time, but recent improvements in PREEMPT_RT and PROVE_LOCKING have highlighted an issue. As the TMU registers itself as a clockevent provider, clockevents_register_device(), it needs to use raw spinlocks internally as this is the context of which the clockevent framework interacts with the TMU driver. However in the context of holding a raw spinlock the TMU driver can't really manage its power state or clock with calls to pm_runtime_*() and clk_*() as these calls end up in other platform drivers using regular spinlocks to control power and clocks. This mix of spinlock contexts trips a lockdep warning. ============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90 For non-PREEMPT_RT builds this is not really an issue, but for PREEMPT_RT builds where normal spinlocks can sleep this might be an issue. Be cautious and always leave the power and clock running after probe.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43313", "url": "https://ubuntu.com/security/CVE-2026-43313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4() In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDE device and then reassigned an ISA device: dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...); dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...); If the first lookup succeeds but the second fails, dev becomes NULL. This leads to a potential null-pointer dereference when dev_dbg() is called: if (errata.piix4.bmisx) dev_dbg(&dev->dev, ...); To prevent this, use two temporary pointers and retrieve each device independently, avoiding overwriting dev with a possible NULL value. [ rjw: Subject adjustment, added an empty code line ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43266", "url": "https://ubuntu.com/security/CVE-2026-43266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EFI/CPER: don't go past the ARM processor CPER record buffer There's a logic inside GHES/CPER to detect if the section_length is too small, but it doesn't detect if it is too big. Currently, if the firmware receives an ARM processor CPER record stating that a section length is big, kernel will blindly trust section_length, producing a very long dump. For instance, a 67 bytes record with ERR_INFO_NUM set 46198 and section length set to 854918320 would dump a lot of data going a way past the firmware memory-mapped area. Fix it by adding a logic to prevent it to go past the buffer if ERR_INFO_NUM is too big, making it report instead: \t[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 \t[Hardware Error]: event severity: recoverable \t[Hardware Error]: Error 0, type: recoverable \t[Hardware Error]: section_type: ARM processor error \t[Hardware Error]: MIDR: 0xff304b2f8476870a \t[Hardware Error]: section length: 854918320, CPER size: 67 \t[Hardware Error]: section length is too big \t[Hardware Error]: firmware-generated error record is incorrect \t[Hardware Error]: ERR_INFO_NUM is 46198 [ rjw: Subject and changelog tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43277", "url": "https://ubuntu.com/security/CVE-2026-43277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: APEI/GHES: ensure that won't go past CPER allocated record The logic at ghes_new() prevents allocating too large records, by checking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB). Yet, the allocation is done with the actual number of pages from the CPER bios table location, which can be smaller. Yet, a bad firmware could send data with a different size, which might be bigger than the allocated memory, causing an OOPS: Unable to handle kernel paging request at virtual address fff00000f9b40000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000 [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 Workqueue: kacpi_notify acpi_os_execute_deferred pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : hex_dump_to_buffer+0x30c/0x4a0 lr : hex_dump_to_buffer+0x328/0x4a0 sp : ffff800080e13880 x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083 x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004 x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083 x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010 x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008 x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020 x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000 x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008 Call trace: hex_dump_to_buffer+0x30c/0x4a0 (P) print_hex_dump+0xac/0x170 cper_estatus_print_section+0x90c/0x968 cper_estatus_print+0xf0/0x158 __ghes_print_estatus+0xa0/0x148 ghes_proc+0x1bc/0x220 ghes_notify_hed+0x5c/0xb8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x80 acpi_hed_notify+0x28/0x40 acpi_ev_notify_dispatch+0x50/0x80 acpi_os_execute_deferred+0x24/0x48 process_one_work+0x15c/0x3b0 worker_thread+0x2d0/0x400 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44) ---[ end trace 0000000000000000 ]--- Prevent that by taking the actual allocated are into account when checking for CPER length. [ rjw: Subject tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43171", "url": "https://ubuntu.com/security/CVE-2026-43171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EFI/CPER: don't dump the entire memory region The current logic at cper_print_fw_err() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory. The end result can be: - the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region. Fix it by checking if the section length is too small before doing a hex dump. [ rjw: Subject tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43184", "url": "https://ubuntu.com/security/CVE-2026-43184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rnbd-srv: Zero the rsp buffer before using it Before using the data buffer to send back the response message, zero it completely. This prevents any stray bytes to be picked up by the client side when there the message is exchanged between different protocol versions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43261", "url": "https://ubuntu.com/security/CVE-2026-43261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Add support for TSV110 Spectre-BHB mitigation The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43262", "url": "https://ubuntu.com/security/CVE-2026-43262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fiemap page fault fix In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault. Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary. Fixes xfstest generic/742.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43209", "url": "https://ubuntu.com/security/CVE-2026-43209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: minix: Add required sanity checking to minix_check_superblock() The fs/minix implementation of the minix filesystem does not currently support any other value for s_log_zone_size than 0. This is also the only value supported in util-linux; see mkfs.minix.c line 511. In addition, this patch adds some sanity checking for the other minix superblock fields, and moves the minix_blocks_needed() checks for the zmap and imap also to minix_check_super_block(). This also closes a related syzbot bug report.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43268", "url": "https://ubuntu.com/security/CVE-2026-43268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: pretend special inodes as regular files Since commit af153bb63a33 (\"vfs: catch invalid modes in may_open()\") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23241", "url": "https://ubuntu.com/security/CVE-2026-23241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: add missing syscalls to read class The \"at\" variant of getxattr() and listxattr() are missing from the audit read class. Calling getxattrat() or listxattrat() on a file to read its extended attributes will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds missing syscalls to the audit read class.", "cve_priority": "medium", "cve_public_date": "2026-03-17 10:16:00 UTC" }, { "cve": "CVE-2025-71239", "url": "https://ubuntu.com/security/CVE-2025-71239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: add fchmodat2() to change attributes class fchmodat2(), introduced in version 6.6 is currently not in the change attribute class of audit. Calling fchmodat2() to change a file attribute in the same fashion than chmod() or fchmodat() will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds fchmodat2() to the change attributes class.", "cve_priority": "medium", "cve_public_date": "2026-03-17 10:15:00 UTC" }, { "cve": "CVE-2026-45964", "url": "https://ubuntu.com/security/CVE-2026-45964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path Commit 5940d1cf9f42 (\"SUNRPC: Rebalance a kref in auth_gss.c\") added a kref_get(&gss_auth->kref) call to balance the gss_put_auth() done in gss_release_msg(), but forgot to add a corresponding kref_put() on the error path when kstrdup_const() fails. If service_name is non-NULL and kstrdup_const() fails, the function jumps to err_put_pipe_version which calls put_pipe_version() and kfree(gss_msg), but never releases the gss_auth reference. This leads to a kref leak where the gss_auth structure is never freed. Add a forward declaration for gss_free_callback() and call kref_put() in the err_put_pipe_version error path to properly release the reference taken earlier.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45870", "url": "https://ubuntu.com/security/CVE-2026-45870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: auth_gss: fix memory leaks in XDR decoding error paths The gssx_dec_ctx(), gssx_dec_status(), and gssx_dec_name() functions allocate memory via gssx_dec_buffer(), which calls kmemdup(). When a subsequent decode operation fails, these functions return immediately without freeing previously allocated buffers, causing memory leaks. The leak in gssx_dec_ctx() is particularly relevant because the caller (gssp_accept_sec_context_upcall) initializes several buffer length fields to non-zero values, resulting in memory allocation: struct gssx_ctx rctxh = { .exported_context_token.len = GSSX_max_output_handle_sz, .mech.len = GSS_OID_MAX_LEN, .src_name.display_name.len = GSSX_max_princ_sz, .targ_name.display_name.len = GSSX_max_princ_sz }; If, for example, gssx_dec_name() succeeds for src_name but fails for targ_name, the memory allocated for exported_context_token, mech, and src_name.display_name remains unreferenced and cannot be reclaimed. Add error handling with goto-based cleanup to free any previously allocated buffers before returning an error.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45948", "url": "https://ubuntu.com/security/CVE-2026-45948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leak in ext4_ext_shift_extents() In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4_find_extent(), leading to a memory leak. Fix this by jumping to the out label to ensure the path is properly released.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45912", "url": "https://ubuntu.com/security/CVE-2026-45912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't cache extent during splitting extent Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful. Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, when ext4_split_extent_at() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4_find_extent() and ext4_cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting. In adition, if the unwritten extent cache is not shrunk during the splitting, ext4_cache_extents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46250", "url": "https://ubuntu.com/security/CVE-2026-46250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: MIPS: Work around LLVM bug when gp is used as global register variable On MIPS, __current_thread_info is defined as global register variable locating in $gp, and is simply assigned with new address during kernel relocation. This however is broken with LLVM, which always restores $gp if it finds $gp is clobbered in any form, including when intentionally through a global register variable. This is against GCC's documentation[1], which requires a callee-saved register used as global register variable not to be restored if it's clobbered. As a result, $gp will continue to point to the unrelocated kernel after the epilog of relocate_kernel(), leading to an early crash in init_idle, [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY [ 0.000000] Tainted: [W]=WARN [ 0.000000] Hardware name: loongson,loongson64v-4core-virtio [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240 [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001 [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002 [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80 [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80 [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90 [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90 [ 0.000000] Hi : 0000000000000000 [ 0.000000] Lo : 0000000000000000 [ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270 [ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270 [ 0.000000] Status: 540000e2\tKX SX UX KERNEL EXL [ 0.000000] Cause : 00000008 (ExcCode 02) [ 0.000000] BadVA : 0000000000000000 [ 0.000000] PrId : 00006305 (ICT Loongson-3) [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000) [ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528 [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000 [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258 [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98 [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [] init_idle+0x130/0x270 [ 0.000000] [] sched_init+0x5c8/0x6c0 [ 0.000000] [] start_kernel+0x27c/0x7a8 This bug has been reported to LLVM[2] and affects version from (at least) 18 to 21. Let's work around this by using inline assembly to assign $gp before a fix is widely available.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45974", "url": "https://ubuntu.com/security/CVE-2026-45974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not found If btrfs_search_slot_for_read() returns 1, it means we did not find any key greater than or equals to the key we asked for, meaning we have reached the end of the tree and therefore the path is not valid. If this happens we need to break out of the loop and stop, instead of continuing and accessing an invalid path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45965", "url": "https://ubuntu.com/security/CVE-2026-45965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix invalid deref of rawdata when export_binary is unset If the export_binary parameter is disabled on runtime, profiles that were loaded before that will still have their rawdata stored in apparmorfs, with a symbolic link to the rawdata on the policy directory. When one of those profiles are replaced, the rawdata is set to NULL, but when trying to resolve the symbolic links to rawdata for that profile, it will try to dereference profile->rawdata->name when profile->rawdata is now NULL causing an oops. Fix it by checking if rawdata is set. [ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088 [ 168.657420] #PF: supervisor read access in kernel mode [ 168.660619] #PF: error_code(0x0000) - not-present page [ 168.663613] PGD 0 P4D 0 [ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI [ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary) [ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330 [ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8 [ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282 [ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158 [ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80 [ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000 [ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80 [ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0 [ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000 [ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0 [ 168.701696] Call Trace: [ 168.702325] [ 168.702995] rawdata_get_link_data+0x1c/0x30 [ 168.704145] vfs_readlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64_sys_readlink+0x1e/0x30 [ 168.708653] x64_sys_call+0x1d77/0x26b0 [ 168.709525] do_syscall_64+0x81/0x500 [ 168.710348] ? do_statx+0x72/0xb0 [ 168.711109] ? putname+0x3e/0x80 [ 168.711845] ? __x64_sys_statx+0xb7/0x100 [ 168.712711] ? x64_sys_call+0x10fc/0x26b0 [ 168.713577] ? do_syscall_64+0xbf/0x500 [ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0 [ 168.715404] ? irqentry_exit+0xb2/0x740 [ 168.716359] ? exc_page_fault+0x90/0x1b0 [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45848", "url": "https://ubuntu.com/security/CVE-2026-45848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix NULL sock in aa_sock_file_perm Deal with the potential that sock and sock-sk can be NULL during socket setup or teardown. This could lead to an oops. The fix for NULL pointer dereference in __unix_needs_revalidation shows this is at least possible for af_unix sockets. While the fix for af_unix sockets applies for newer mediation this is still the fall back path for older af_unix mediation and other sockets, so ensure it is covered.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45970", "url": "https://ubuntu.com/security/CVE-2026-45970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: alb: fix UAF in rlb_arp_recv during bond up/down The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN. However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag. [ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? __pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry. Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45847", "url": "https://ubuntu.com/security/CVE-2026-45847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: remove WARN_ON_ONCE when accessing forward path array Although unlikely, recent support for IPIP tunnels increases chances of reaching this WARN_ON_ONCE if userspace manages to build a sufficiently long forward path. Remove it.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45890", "url": "https://ubuntu.com/security/CVE-2026-45890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen-netback: reject zero-queue configuration from guest A malicious or buggy Xen guest can write \"0\" to the xenbus key \"multi-queue-num-queues\". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range(). On systems with panic_on_warn=1, this allows a guest-to-host denial of service. The Xen network interface specification requires the queue count to be \"greater than zero\". Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45968", "url": "https://ubuntu.com/security/CVE-2026-45968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuidle: Skip governor when only one idle state is available On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash. [ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668 Fix this by adding a bail-out in cpuidle_select() that returns state 0 directly when state_count <= 1, bypassing the governor and keeping the tick running.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45935", "url": "https://ubuntu.com/security/CVE-2026-45935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot In the 'DeleteIndexEntryRoot' case of the 'do_action' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking. Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize); It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to size_t for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow. This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45864", "url": "https://ubuntu.com/security/CVE-2026-45864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent infinite loops caused by the next valid being the same When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1]. Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this. [1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45868", "url": "https://ubuntu.com/security/CVE-2026-45868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix refcount leak in pcs_add_gpio_func() of_parse_phandle_with_args() returns a device_node pointer with refcount incremented in gpiospec.np. The loop iterates through all phandles but never releases the reference, causing a refcount leak on each iteration. Add of_node_put() calls to release the reference after extracting the needed arguments and on the error path when devm_kzalloc() fails. This bug was detected by our static analysis tool and verified by my code review.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45883", "url": "https://ubuntu.com/security/CVE-2026-45883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: sca3000: Fix a resource leak in sca3000_probe() spi->irq from request_threaded_irq() not released when iio_device_register() fails. Add an return value check and jump to a common error handler when iio_device_register() fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45875", "url": "https://ubuntu.com/security/CVE-2026-45875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: arizona: Fix regulator resource leak on wm5102_clear_write_sequencer() failure The wm5102_clear_write_sequencer() helper may return an error and just return, bypassing the cleanup sequence and causing regulators to remain enabled, leading to a resource leak. Change the direct return to jump to the err_reset label to properly free the resources.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45978", "url": "https://ubuntu.com/security/CVE-2026-45978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: greybus: lights: avoid NULL deref gb_lights_light_config() stores channel_count before allocating the channels array. If kcalloc() fails, gb_lights_release() iterates the non-zero count and dereferences light->channels, which is NULL. Allocate channels first and only then publish channels_count so the cleanup path can't walk a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45954", "url": "https://ubuntu.com/security/CVE-2026-45954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe() In au1200fb_drv_probe(), when platform_get_irq fails(), it directly returns from the function with an error code, which causes a memory leak. Replace it with a goto label to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45857", "url": "https://ubuntu.com/security/CVE-2026-45857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: csiostor: Fix dereference of null pointer rn The error exit path when rn is NULL ends up deferencing the null pointer rn via the use of the macro CSIO_INC_STATS. Fix this by adding a new error return path label after the use of the macro to avoid the deference.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45856", "url": "https://ubuntu.com/security/CVE-2026-45856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45852", "url": "https://ubuntu.com/security/CVE-2026-45852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45869", "url": "https://ubuntu.com/security/CVE-2026-45869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: wm97xx: Fix NULL pointer dereference in power_supply_changed() In `probe()`, `request_irq()` is called before allocating/registering a `power_supply` handle. If an interrupt is fired between the call to `request_irq()` and `power_supply_register()`, the `power_supply` handle will be used uninitialized in `power_supply_changed()` in `wm97xx_bat_update()` (triggered from the interrupt handler). This will lead to a `NULL` pointer dereference since Fix this racy `NULL` pointer dereference by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Since the IRQ is the last thing requests in the `probe()` now, remove the error path for freeing it. Instead add one for unregistering the `power_supply` handle when IRQ request fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45916", "url": "https://ubuntu.com/security/CVE-2026-45916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sbs-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Keep the old behavior of just printing a warning in case of any failures during the IRQ request and finishing the probe successfully.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46270", "url": "https://ubuntu.com/security/CVE-2026-46270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: rt9455: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45936", "url": "https://ubuntu.com/security/CVE-2026-45936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: goldfish: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45885", "url": "https://ubuntu.com/security/CVE-2026-45885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cpcap-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45879", "url": "https://ubuntu.com/security/CVE-2026-45879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq25980: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45902", "url": "https://ubuntu.com/security/CVE-2026-45902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45867", "url": "https://ubuntu.com/security/CVE-2026-45867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: act8945a: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45946", "url": "https://ubuntu.com/security/CVE-2026-45946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Commit 1c1f13a006ed (\"power: supply: ab8500: Move to componentized binding\") introduced this issue during a refactorization. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45866", "url": "https://ubuntu.com/security/CVE-2026-45866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: caif: fix use-after-free in caif_serial ldisc_close() There is a use-after-free bug in caif_serial where handle_tx() may access ser->tty after the tty has been freed. The race condition occurs between ldisc_close() and packet transmission: CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldisc_close() tty_kref_put(ser->tty) [tty may be freed here] <-- race window --> caif_xmit() handle_tx() tty = ser->tty // dangling ptr tty->ops->write() // UAF! schedule_work() ser_release() unregister_netdevice() The root cause is that tty_kref_put() is called in ldisc_close() while the network device is still active and can receive packets. Since ser and tty have a 1:1 binding relationship with consistent lifecycles (ser is allocated in ldisc_open and freed in ser_release via unregister_netdevice, and each ser binds exactly one tty), we can safely defer the tty reference release to ser_release() where the network device is unregistered. Fix this by moving tty_kref_put() from ldisc_close() to ser_release(), after unregister_netdevice(). This ensures the tty reference is held as long as the network device exists, preventing the UAF. Note: We save ser->tty before unregister_netdevice() because ser is embedded in netdev's private data and will be freed along with netdev (needs_free_netdev = true). How to reproduce: Add mdelay(500) at the beginning of ldisc_close() to widen the race window, then run the reproducer program [1]. Note: There is a separate deadloop issue in handle_tx() when using PORT_UNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper serial backend). This deadloop exists even without this patch, and is likely caused by inconsistency between uart_write_room() and uart_write() in serial core. It has been addressed in a separate patch [2]. KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in handle_tx+0x5d1/0x620 Read of size 1 at addr ffff8881131e1490 by task caif_uaf_trigge/9929 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xd0/0x630 kasan_report+0xe4/0x120 handle_tx+0x5d1/0x620 dev_hard_start_xmit+0x9d/0x6c0 __dev_queue_xmit+0x6e2/0x4410 packet_xmit+0x243/0x360 packet_sendmsg+0x26cf/0x5500 __sys_sendto+0x4a3/0x520 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0xc9/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f615df2c0d7 Allocated by task 9930: Freed by task 64: Last potentially related work creation: The buggy address belongs to the object at ffff8881131e1000 which belongs to the cache kmalloc-cg-2k of size 2048 The buggy address is located 1168 bytes inside of freed 2048-byte region [ffff8881131e1000, ffff8881131e1800) The buggy address belongs to the physical page: page_owner tracks the page as allocated page last free pid 9778 tgid 9778 stack trace: Memory state around the buggy address: ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-31411", "url": "https://ubuntu.com/security/CVE-2026-31411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: fix crash due to unvalidated vcc pointer in sigd_send() Reproducer available at [1]. The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values. Fix this by introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found. Since struct atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock_hold/sock_put is sufficient to keep the vcc alive while it is being used. Note that there may be a race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety. [1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3", "cve_priority": "medium", "cve_public_date": "2026-04-08 14:16:00 UTC" }, { "cve": "CVE-2026-46259", "url": "https://ubuntu.com/security/CVE-2026-46259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent.", "cve_priority": "high", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45891", "url": "https://ubuntu.com/security/CVE-2026-45891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix double free issue for tx spare buffer In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory. Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory. The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer. Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new `tx_spare` fails. This ensures the error cleanup path only frees genuinely newly allocated buffers.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45873", "url": "https://ubuntu.com/security/CVE-2026-45873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets Userspace provides an optimized representation in case intervals are adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous set checks on start elements for this reason. However, it is possible to add intervals that overlap to this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end \tA B start end A C Restore the check on overlapping start elements to report an overlap.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46267", "url": "https://ubuntu.com/security/CVE-2026-46267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: hci: shdlc: Stop timers and work before freeing context llc_shdlc_deinit() purges SHDLC skb queues and frees the llc_shdlc structure while its timers and state machine work may still be active. Timer callbacks can schedule sm_work, and sm_work accesses SHDLC state and the skb queues. If teardown happens in parallel with a queued/running work item, it can lead to UAF and other shutdown races. Stop all SHDLC timers and cancel sm_work synchronously before purging the queues and freeing the context. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-46249", "url": "https://ubuntu.com/security/CVE-2026-46249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix PF driver crash with kexec kernel booting During a kexec reboot the hardware is not power-cycled, so AF state from the old kernel can persist into the new kernel. When AF and PF drivers are built as modules, the PF driver may probe before AF reinitializes the hardware. The PF driver treats the RVUM block revision as an indication that AF initialization is complete. If this value is left uncleared at shutdown, PF may incorrectly assume AF is ready and access stale hardware state, leading to a crash. Clear the RVUM block revision during AF shutdown to avoid PF mis-detecting AF readiness after kexec.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45915", "url": "https://ubuntu.com/security/CVE-2026-45915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: avoid parent link count underflow in rmdir Corrupted FAT images can leave a directory inode with an incorrect i_nlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls drop_nlink(dir) and can drive i_nlink to 0, triggering the WARN_ON in drop_nlink(). Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45983", "url": "https://ubuntu.com/security/CVE-2026-45983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: never defer requests during idmap lookup During v4 request compound arg decoding, some ops (e.g. SETATTR) can trigger idmap lookup upcalls. When those upcall responses get delayed beyond the allowed time limit, cache_check() will mark the request for deferral and cause it to be dropped. This prevents nfs4svc_encode_compoundres from being executed, and thus the session slot flag NFSD4_SLOT_INUSE never gets cleared. Subsequent client requests will fail with NFSERR_JUKEBOX, given that the slot will be marked as in-use, making the SEQUENCE op fail. Fix this by making sure that the RQ_USEDEFERRAL flag is always clear during nfs4svc_decode_compoundargs(), since no v4 request should ever be deferred.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45862", "url": "https://ubuntu.com/security/CVE-2026-45862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush cache for PASID table before using it When writing the address of a freshly allocated zero-initialized PASID table to a PASID directory entry, do that after the CPU cache flush for this PASID table, not before it, to avoid the time window when this PASID table may be already used by non-coherent IOMMU hardware while its contents in RAM is still some random old data, not zero-initialized.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45860", "url": "https://ubuntu.com/security/CVE-2026-45860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: increase the connection clean up limit to 64 After the optimization to only perform one GC per jiffy, a new problem was introduced. If more than 8 new connections are tracked per jiffy the list won't be cleaned up fast enough possibly reaching the limit wrongly. In order to prevent this issue, only skip the GC if it was already triggered during the same jiffy and the increment is lower than the clean up limit. In addition, increase the clean up limit to 64 connections to avoid triggering GC too often and do more effective GCs. This has been tested using a HTTP server and several performance tools while having nft_connlimit/xt_connlimit or OVS limit configured. Output of slowhttptest + OVS limit at 52000 connections: slow HTTP test status on 340th second: initializing: 0 pending: 432 connected: 51998 error: 0 closed: 0 service available: YES", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45969", "url": "https://ubuntu.com/security/CVE-2026-45969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: playstation: Add missing check for input_ff_create_memless The ps_gamepad_create() function calls input_ff_create_memless() without verifying its return value, which can lead to incorrect behavior or potential crashes when FF effects are triggered. Add a check for the return value of input_ff_create_memless().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-71304", "url": "https://ubuntu.com/security/CVE-2025-71304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: /smack/doi: accept previously used values Writing to /smack/doi a value that has ever been written there in the past disables networking for non-ambient labels. E.g. # cat /smack/doi 3 # netlabelctl -p cipso list Configured CIPSO mappings (1) DOI value : 3 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (3) domain: \"_\" (IPv4) protocol: UNLABELED domain: DEFAULT (IPv4) protocol: CIPSO, DOI = 3 domain: DEFAULT (IPv6) protocol: UNLABELED # cat /smack/ambient _ # cat /proc/$$/attr/smack/current _ # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.964 ms # echo foo >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.956 ms unknown option 86 # echo 4 >/smack/doi # echo 3 >/smack/doi !> [ 214.050395] smk_cipso_doi:691 cipso add rc = -17 # echo 3 >/smack/doi !> [ 249.402261] smk_cipso_doi:678 remove rc = -2 !> [ 249.402261] smk_cipso_doi:691 cipso add rc = -17 # ping -c1 10.1.95.12 !!> ping: 10.1.95.12: Address family for hostname not supported # echo _ >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.617 ms This happens because Smack keeps decommissioned DOIs, fails to re-add them, and consequently refuses to add the “default” domain map: # netlabelctl -p cipso list Configured CIPSO mappings (2) DOI value : 3 mapping type : PASS_THROUGH DOI value : 4 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (2) domain: \"_\" (IPv4) protocol: UNLABELED !> (no ipv4 map for default domain here) domain: DEFAULT (IPv6) protocol: UNLABELED Fix by clearing decommissioned DOI definitions and serializing concurrent DOI updates with a new lock. Also: - allow /smack/doi to live unconfigured, since adding a map (netlbl_cfg_cipsov4_map_add) may fail. CIPSO_V4_DOI_UNKNOWN(0) indicates the unconfigured DOI - add new DOI before removing the old default map, so the old map remains if the add fails (2008-02-04, Casey Schaufler)", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45904", "url": "https://ubuntu.com/security/CVE-2026-45904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling The recent commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug safe\") restructured the EEH driver to improve synchronization with the PCI hotplug layer. However, it inadvertently moved pci_lock_rescan_remove() outside its intended scope in eeh_handle_normal_event(), leading to broken PCI error reporting and improper EEH event triggering. Specifically, eeh_handle_normal_event() acquired pci_lock_rescan_remove() before calling eeh_pe_bus_get(), but eeh_pe_bus_get() itself attempts to acquire the same lock internally, causing nested locking and disrupting normal EEH event handling paths. This patch adds a boolean parameter do_lock to _eeh_pe_bus_get(), with two public wrappers: eeh_pe_bus_get() with locking enabled. eeh_pe_bus_get_nolock() that skips locking. Callers that already hold pci_lock_rescan_remove() now use eeh_pe_bus_get_nolock() to avoid recursive lock acquisition. Additionally, pci_lock_rescan_remove() calls are restored to the correct position—after eeh_pe_bus_get() and immediately before iterating affected PEs and devices. This ensures EEH-triggered PCI removes occur under proper bus rescan locking without recursive lock contention. The eeh_pe_loc_get() function has been split into two functions: eeh_pe_loc_get(struct eeh_pe *pe) which retrieves the loc for given PE. eeh_pe_loc_get_bus(struct pci_bus *bus) which retrieves the location code for given bus. This resolves lockdep warnings such as: [ 84.964298] [ T928] ============================================ [ 84.964304] [ T928] WARNING: possible recursive locking detected [ 84.964311] [ T928] 6.18.0-rc3 #51 Not tainted [ 84.964315] [ T928] -------------------------------------------- [ 84.964320] [ T928] eehd/928 is trying to acquire lock: [ 84.964324] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964342] [ T928] but task is already holding lock: [ 84.964347] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964357] [ T928] other info that might help us debug this: [ 84.964363] [ T928] Possible unsafe locking scenario: [ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928] lock(pci_rescan_remove_lock); [ 84.964378] [ T928] lock(pci_rescan_remove_lock); [ 84.964383] [ T928] *** DEADLOCK *** [ 84.964388] [ T928] May be due to missing lock nesting notation [ 84.964393] [ T928] 1 lock held by eehd/928: [ 84.964397] [ T928] #0: c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964408] [ T928] stack backtrace: [ 84.964414] [ T928] CPU: 2 UID: 0 PID: 928 Comm: eehd Not tainted 6.18.0-rc3 #51 VOLUNTARY [ 84.964417] [ T928] Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_022) hv:phyp pSeries [ 84.964419] [ T928] Call Trace: [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130 (unreliable) [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [ 84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c00000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46253", "url": "https://ubuntu.com/security/CVE-2026-46253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore/ram: fix buffer overflow in persistent_ram_save_old() persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz->old_log when it is NULL, but it unconditionally updates prz->old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1) 9. ramoops_get_next_prz() → persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45919", "url": "https://ubuntu.com/security/CVE-2026-45919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/rt: Skip currently executing CPU in rto_next_cpu() CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts. The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45871", "url": "https://ubuntu.com/security/CVE-2026-45871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Fix missing cleanup on get_burstcount() error get_burstcount() can return -EBUSY on timeout. When this happens, st33zp24_send() returns directly without releasing the locality acquired earlier. Use goto out_err to ensure proper cleanup when get_burstcount() fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45941", "url": "https://ubuntu.com/security/CVE-2026-45941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_infineon: Fix locality leak on get_burstcount() failure get_burstcount() can return -EBUSY on timeout. When this happens, the function returns directly without releasing the locality that was acquired at the beginning of tpm_tis_i2c_send(). Use goto out_err to ensure proper cleanup when get_burstcount() fails.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45984", "url": "https://ubuntu.com/security/CVE-2026-45984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix use-after-free in iomap inline data write path The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45960", "url": "https://ubuntu.com/security/CVE-2026-45960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: return error when node already exists in hfs_bnode_create When hfs_bnode_create() finds that a node is already hashed (which should not happen in normal operation), it currently returns the existing node without incrementing its reference count. This causes a reference count inconsistency that leads to a kernel panic when the node is later freed in hfs_bnode_put(): kernel BUG at fs/hfsplus/bnode.c:676! BUG_ON(!atomic_read(&node->refcnt)) This scenario can occur when hfs_bmap_alloc() attempts to allocate a node that is already in use (e.g., when node 0's bitmap bit is incorrectly unset), or due to filesystem corruption. Returning an existing node from a create path is not normal operation. Fix this by returning ERR_PTR(-EEXIST) instead of the node when it's already hashed. This properly signals the error condition to callers, which already check for IS_ERR() return values.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23243", "url": "https://ubuntu.com/security/CVE-2026-23243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umad: Reject negative data_len in ib_umad_write ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-23242", "url": "https://ubuntu.com/security/CVE-2026-23242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix potential NULL pointer dereference in header processing If siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(), qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data() dereferences qp->rx_fpdu->more_ddp_segs without checking, which may lead to a NULL pointer deref. Only check more_ddp_segs when rx_fpdu is present. KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-23235", "url": "https://ubuntu.com/security/CVE-2026-23235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix out-of-bounds access in sysfs attribute read/write Some f2fs sysfs attributes suffer from out-of-bounds memory access and incorrect handling of integer values whose size is not 4 bytes. For example: vm:~# echo 65537 > /sys/fs/f2fs/vde/carve_out vm:~# cat /sys/fs/f2fs/vde/carve_out 65537 vm:~# echo 4294967297 > /sys/fs/f2fs/vde/atgc_age_threshold vm:~# cat /sys/fs/f2fs/vde/atgc_age_threshold 1 carve_out maps to {struct f2fs_sb_info}->carve_out, which is a 8-bit integer. However, the sysfs interface allows setting it to a value larger than 255, resulting in an out-of-range update. atgc_age_threshold maps to {struct atgc_management}->age_threshold, which is a 64-bit integer, but its sysfs interface cannot correctly set values larger than UINT_MAX. The root causes are: 1. __sbi_store() treats all default values as unsigned int, which prevents updating integers larger than 4 bytes and causes out-of-bounds writes for integers smaller than 4 bytes. 2. f2fs_sbi_show() also assumes all default values are unsigned int, leading to out-of-bounds reads and incorrect access to integers larger than 4 bytes. This patch introduces {struct f2fs_attr}->size to record the actual size of the integer associated with each sysfs attribute. With this information, sysfs read and write operations can correctly access and update values according to their real data size, avoiding memory corruption and truncation.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23234", "url": "https://ubuntu.com/security/CVE-2026-23234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid UAF in f2fs_write_end_io() As syzbot reported an use-after-free issue in f2fs_write_end_io(). It is caused by below race condition: loop device\t\t\t\tumount - worker_thread - loop_process_work - do_req_filebacked - lo_rw_aio - lo_rw_aio_complete - blk_mq_end_request - blk_update_request - f2fs_write_end_io - dec_page_count - folio_end_writeback \t\t\t\t\t- kill_f2fs_super \t\t\t\t\t - kill_block_super \t\t\t\t\t - f2fs_put_super \t\t\t\t\t : free(sbi) : get_pages(, F2FS_WB_CP_DATA) accessed sbi which is freed In kill_f2fs_super(), we will drop all page caches of f2fs inodes before call free(sbi), it guarantee that all folios should end its writeback, so it should be safe to access sbi before last folio_end_writeback(). Let's relocate ckpt thread wakeup flow before folio_end_writeback() to resolve this issue.", "cve_priority": "low", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23236", "url": "https://ubuntu.com/security/CVE-2026-23236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: smscufx: properly copy ioctl memory to kernelspace The UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data from userspace to kernelspace, and instead directly references the memory, which can cause problems if invalid data is passed from userspace. Fix this all up by correctly copying the memory before accessing it within the kernel.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23266", "url": "https://ubuntu.com/security/CVE-2026-23266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: rivafb: fix divide error in nv3_arb() A userspace program can trigger the RIVA NV3 arbitration code by calling the FBIOPUT_VSCREENINFO ioctl on /dev/fb*. When doing so, the driver recomputes FIFO arbitration parameters in nv3_arb(), using state->mclk_khz (derived from the PRAMDAC MCLK PLL) as a divisor without validating it first. In a normal setup, state->mclk_khz is provided by the real hardware and is non-zero. However, an attacker can construct a malicious or misconfigured device (e.g. a crafted/emulated PCI device) that exposes a bogus PLL configuration, causing state->mclk_khz to become zero. Once nv3_get_param() calls nv3_arb(), the division by state->mclk_khz in the gns calculation causes a divide error and crashes the kernel. Fix this by checking whether state->mclk_khz is zero and bailing out before doing the division. The following log reveals it: rivafb: setting virtual Y resolution to 2184 divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 2187 Comm: syz-executor.0 Not tainted 5.18.0-rc1+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:nv3_arb drivers/video/fbdev/riva/riva_hw.c:439 [inline] RIP: 0010:nv3_get_param+0x3ab/0x13b0 drivers/video/fbdev/riva/riva_hw.c:546 Call Trace: nv3CalcArbitration.constprop.0+0x255/0x460 drivers/video/fbdev/riva/riva_hw.c:603 nv3UpdateArbitrationSettings drivers/video/fbdev/riva/riva_hw.c:637 [inline] CalcStateExt+0x447/0x1b90 drivers/video/fbdev/riva/riva_hw.c:1246 riva_load_video_mode+0x8a9/0xea0 drivers/video/fbdev/riva/fbdev.c:779 rivafb_set_par+0xc0/0x5f0 drivers/video/fbdev/riva/fbdev.c:1196 fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1033 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1109 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1188 __x64_sys_ioctl+0x122/0x190 fs/ioctl.c:856", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2025-71233", "url": "https://ubuntu.com/security/CVE-2025-71233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Avoid creating sub-groups asynchronously The asynchronous creation of sub-groups by a delayed work could lead to a NULL pointer dereference when the driver directory is removed before the work completes. The crash can be easily reproduced with the following commands: # cd /sys/kernel/config/pci_ep/functions/pci_epf_test # for i in {1..20}; do mkdir test && rmdir test; done BUG: kernel NULL pointer dereference, address: 0000000000000088 ... Call Trace: configfs_register_group+0x3d/0x190 pci_epf_cfs_work+0x41/0x110 process_one_work+0x18f/0x350 worker_thread+0x25a/0x3a0 Fix this issue by using configfs_add_default_group() API which does not have the deadlock problem as configfs_register_group() and does not require the delayed work handler. [mani: slightly reworded the description and added stable list]", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71232", "url": "https://ubuntu.com/security/CVE-2025-71232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Free sp in error path to fix system crash System crash seen during load/unload test in a loop, [61110.449331] qla2xxx [0000:27:00.0]-0042:0: Disabled MSI-X. [61110.467494] ============================================================================= [61110.467498] BUG qla2xxx_srbs (Tainted: G OE -------- --- ): Objects remaining in qla2xxx_srbs on __kmem_cache_shutdown() [61110.467501] ----------------------------------------------------------------------------- [61110.467502] Slab 0x000000000ffc8162 objects=51 used=1 fp=0x00000000e25d3d85 flags=0x57ffffc0010200(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [61110.467509] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1 [61110.467513] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023 [61110.467515] Call Trace: [61110.467516] [61110.467519] dump_stack_lvl+0x34/0x48 [61110.467526] slab_err.cold+0x53/0x67 [61110.467534] __kmem_cache_shutdown+0x16e/0x320 [61110.467540] kmem_cache_destroy+0x51/0x160 [61110.467544] qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467607] ? __do_sys_delete_module.constprop.0+0x178/0x280 [61110.467613] ? syscall_trace_enter.constprop.0+0x145/0x1d0 [61110.467616] ? do_syscall_64+0x5c/0x90 [61110.467619] ? exc_page_fault+0x62/0x150 [61110.467622] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [61110.467626] [61110.467627] Disabling lock debugging due to kernel taint [61110.467635] Object 0x0000000026f7e6e6 @offset=16000 [61110.467639] ------------[ cut here ]------------ [61110.467639] kmem_cache_destroy qla2xxx_srbs: Slab cache still has objects when called from qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467659] WARNING: CPU: 53 PID: 455206 at mm/slab_common.c:520 kmem_cache_destroy+0x14d/0x160 [61110.467718] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G B OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1 [61110.467720] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023 [61110.467721] RIP: 0010:kmem_cache_destroy+0x14d/0x160 [61110.467724] Code: 99 7d 07 00 48 89 ef e8 e1 6a 07 00 eb b3 48 8b 55 60 48 8b 4c 24 20 48 c7 c6 70 fc 66 90 48 c7 c7 f8 ef a1 90 e8 e1 ed 7c 00 <0f> 0b eb 93 c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 [61110.467725] RSP: 0018:ffffa304e489fe80 EFLAGS: 00010282 [61110.467727] RAX: 0000000000000000 RBX: ffffffffc0d9a860 RCX: 0000000000000027 [61110.467729] RDX: ffff8fd5ff9598a8 RSI: 0000000000000001 RDI: ffff8fd5ff9598a0 [61110.467730] RBP: ffff8fb6aaf78700 R08: 0000000000000000 R09: 0000000100d863b7 [61110.467731] R10: ffffa304e489fd20 R11: ffffffff913bef48 R12: 0000000040002000 [61110.467731] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [61110.467733] FS: 00007f64c89fb740(0000) GS:ffff8fd5ff940000(0000) knlGS:0000000000000000 [61110.467734] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [61110.467735] CR2: 00007f0f02bfe000 CR3: 00000020ad6dc005 CR4: 0000000000770ee0 [61110.467736] PKRU: 55555554 [61110.467737] Call Trace: [61110.467738] [61110.467739] qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467755] ? __do_sys_delete_module.constprop.0+0x178/0x280 Free sp in the error path to fix the crash.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71238", "url": "https://ubuntu.com/security/CVE-2025-71238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix bsg_done() causing double free Kernel panic observed on system, [5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000 [5353358.825194] #PF: supervisor write access in kernel mode [5353358.825195] #PF: error_code(0x0002) - not-present page [5353358.825196] PGD 100006067 P4D 0 [5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI [5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el9_5.x86_64 #1 [5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025 [5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10 [5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246 [5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000 [5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000 [5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000 [5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090 [5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000 [5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000 [5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0 [5353358.825221] PKRU: 55555554 [5353358.825222] Call Trace: [5353358.825223] [5353358.825224] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825229] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825232] ? sg_copy_buffer+0xc8/0x110 [5353358.825236] ? __die_body.cold+0x8/0xd [5353358.825238] ? page_fault_oops+0x134/0x170 [5353358.825242] ? kernelmode_fixup_or_oops+0x84/0x110 [5353358.825244] ? exc_page_fault+0xa8/0x150 [5353358.825247] ? asm_exc_page_fault+0x22/0x30 [5353358.825252] ? memcpy_erms+0x6/0x10 [5353358.825253] sg_copy_buffer+0xc8/0x110 [5353358.825259] qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx] [5353358.825317] qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx] Most routines in qla_bsg.c call bsg_done() only for success cases. However a few invoke it for failure case as well leading to a double free. Validate before calling bsg_done().", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23221", "url": "https://ubuntu.com/security/CVE-2026-23221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: fix use-after-free in driver_override_show() The driver_override_show() function reads the driver_override string without holding the device_lock. However, driver_override_store() uses driver_set_override(), which modifies and frees the string while holding the device_lock. This can result in a concurrent use-after-free if the string is freed by the store function while being read by the show function. Fix this by holding the device_lock around the read operation.", "cve_priority": "low", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23228", "url": "https://ubuntu.com/security/CVE-2026-23228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection() On kthread_run() failure in ksmbd_tcp_new_connection(), the transport is freed via free_transport(), which does not decrement active_num_conn, leaking this counter. Replace free_transport() with ksmbd_tcp_disconnect().", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23169", "url": "https://ubuntu.com/security/CVE-2026-23169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race in mptcp_pm_nl_flush_addrs_doit() syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id() and/or mptcp_pm_nl_is_backup() Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit() which is not RCU ready. list_splice_init_rcu() can not be called here while holding pernet->lock spinlock. Many thanks to Eulgyu Kim for providing a repro and testing our patches.", "cve_priority": "high", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-37786", "url": "https://ubuntu.com/security/CVE-2025-37786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: free routing table on probe failure If complete = true in dsa_tree_setup(), it means that we are the last switch of the tree which is successfully probing, and we should be setting up all switches from our probe path. After \"complete\" becomes true, dsa_tree_setup_cpu_ports() or any subsequent function may fail. If that happens, the entire tree setup is in limbo: the first N-1 switches have successfully finished probing (doing nothing but having allocated persistent memory in the tree's dst->ports, and maybe dst->rtable), and switch N failed to probe, ending the tree setup process before anything is tangible from the user's PoV. If switch N fails to probe, its memory (ports) will be freed and removed from dst->ports. However, the dst->rtable elements pointing to its ports, as created by dsa_link_touch(), will remain there, and will lead to use-after-free if dereferenced. If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirely possible because that is where ds->ops->setup() is, we get a kasan report like this: ================================================================== BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568 Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42 Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 The simplest way to fix the bug is to delete the routing table in its entirety. dsa_tree_setup_routing_table() has no problem in regenerating it even if we deleted links between ports other than those of switch N, because dsa_link_touch() first checks whether the port pair already exists in dst->rtable, allocating if not. The deletion of the routing table in its entirety already exists in dsa_tree_teardown(), so refactor that into a function that can also be called from the tree setup error path. In my analysis of the commit to blame, it is the one which added dsa_link elements to dst->rtable. Prior to that, each switch had its own ds->rtable which is freed when the switch fails to probe. But the tree is potentially persistent memory.", "cve_priority": "low", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2026-23237", "url": "https://ubuntu.com/security/CVE-2026-23237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: classmate-laptop: Add missing NULL pointer checks In a few places in the Classmate laptop driver, code using the accel object may run before that object's address is stored in the driver data of the input device using it. For example, cmpc_accel_sensitivity_store_v4() is the \"show\" method of cmpc_accel_sensitivity_attr_v4 which is added in cmpc_accel_add_v4(), before calling dev_set_drvdata() for inputdev->dev. If the sysfs attribute is accessed prematurely, the dev_get_drvdata(&inputdev->dev) call in in cmpc_accel_sensitivity_store_v4() returns NULL which leads to a NULL pointer dereference going forward. Moreover, sysfs attributes using the input device are added before initializing that device by cmpc_add_acpi_notify_device() and if one of them is accessed before running that function, a NULL pointer dereference will occur. For example, cmpc_accel_sensitivity_attr_v4 is added before calling cmpc_add_acpi_notify_device() and if it is read prematurely, the dev_get_drvdata(&acpi->dev) call in cmpc_accel_sensitivity_show_v4() returns NULL which leads to a NULL pointer dereference going forward. Fix this by adding NULL pointer checks in all of the relevant places.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23238", "url": "https://ubuntu.com/security/CVE-2026-23238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: romfs: check sb_set_blocksize() return value romfs_fill_super() ignores the return value of sb_set_blocksize(), which can fail if the requested block size is incompatible with the block device's configuration. This can be triggered by setting a loop device's block size larger than PAGE_SIZE using ioctl(LOOP_SET_BLOCK_SIZE, 32768), then mounting a romfs filesystem on that device. When sb_set_blocksize(sb, ROMBSIZE) is called with ROMBSIZE=4096 but the device has logical_block_size=32768, bdev_validate_blocksize() fails because the requested size is smaller than the device's logical block size. sb_set_blocksize() returns 0 (failure), but romfs ignores this and continues mounting. The superblock's block size remains at the device's logical block size (32768). Later, when sb_bread() attempts I/O with this oversized block size, it triggers a kernel BUG in folio_set_bh(): kernel BUG at fs/buffer.c:1582! BUG_ON(size > PAGE_SIZE); Fix by checking the return value of sb_set_blocksize() and failing the mount with -EINVAL if it returns 0.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-31687", "url": "https://ubuntu.com/security/CVE-2026-31687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: omap: do not register driver in probe() Commit 11a78b794496 (\"ARM: OMAP: MPUIO wake updates\") registers the omap_mpuio_driver from omap_mpuio_init(), which is called from omap_gpio_probe(). However, it neither makes sense to register drivers from probe() callbacks of other drivers, nor does the driver core allow registering drivers with a device lock already being held. The latter was revealed by commit dc23806a7c47 (\"driver core: enforce device_lock for driver_match_device()\") leading to a potential deadlock condition described in [1]. Additionally, the omap_mpuio_driver is never unregistered from the driver core, even if the module is unloaded. Hence, register the omap_mpuio_driver from the module initcall and unregister it in module_exit().", "cve_priority": "medium", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2025-71235", "url": "https://ubuntu.com/security/CVE-2025-71235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Delay module unload while fabric scan in progress System crash seen during load/unload test in a loop. [105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086 [105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0 [105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000 [105954.384923] FS: 0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000 [105954.384925] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0 [105954.384928] PKRU: 55555554 [105954.384929] Call Trace: [105954.384931] [105954.384934] qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx] [105954.384962] ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx] [105954.384980] ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx] [105954.384999] ? __wake_up_common+0x80/0x190 [105954.385004] ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx] [105954.385023] ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx] [105954.385040] ? __handle_irq_event_percpu+0x3d/0x190 [105954.385044] ? handle_irq_event+0x58/0xb0 [105954.385046] ? handle_edge_irq+0x93/0x240 [105954.385050] ? __common_interrupt+0x41/0xa0 [105954.385055] ? common_interrupt+0x3e/0xa0 [105954.385060] ? asm_common_interrupt+0x22/0x40 The root cause of this was that there was a free (dma_free_attrs) in the interrupt context. There was a device discovery/fabric scan in progress. A module unload was issued which set the UNLOADING flag. As part of the discovery, after receiving an interrupt a work queue was scheduled (which involved a work to be queued). Since the UNLOADING flag is set, the work item was not allocated and the mapped memory had to be freed. The free occurred in interrupt context leading to system crash. Delay the driver unload until the fabric scan is complete to avoid the crash.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71236", "url": "https://ubuntu.com/security/CVE-2025-71236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Validate sp before freeing associated memory System crash with the following signature [154563.214890] nvme nvme2: NVME-FC{1}: controller connect complete [154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Set ZIO exchange threshold to 3. [154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: SET ZIO Activity exchange threshold to 5. [154565.539974] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 0080 0000. [154565.545744] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 00a0 0000. [154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate). [154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate). [154565.553079] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [154565.553080] #PF: supervisor read access in kernel mode [154565.553082] #PF: error_code(0x0000) - not-present page [154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0 [154565.553089] Oops: 0000 1 PREEMPT SMP PTI [154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: loaded Tainted: G OE ------- --- 5.14.0-503.11.1.el9_5.x86_64 #1 [154565.553096] Hardware name: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 09/30/2024 [154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553141] Code: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 <4c> 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b [154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286 [154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002 [154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47 [154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a [154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0 [154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000 [154565.553152] FS: 0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000 [154565.553154] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0 [154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [154565.553159] PKRU: 55555554 [154565.553160] Call Trace: [154565.553162] [154565.553165] ? show_trace_log_lvl+0x1c4/0x2df [154565.553172] ? show_trace_log_lvl+0x1c4/0x2df [154565.553177] ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553215] ? __die_body.cold+0x8/0xd [154565.553218] ? page_fault_oops+0x134/0x170 [154565.553223] ? snprintf+0x49/0x70 [154565.553229] ? exc_page_fault+0x62/0x150 [154565.553238] ? asm_exc_page_fault+0x22/0x30 Check for sp being non NULL before freeing any associated memory", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71237", "url": "https://ubuntu.com/security/CVE-2025-71237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: Fix potential block overflow that cause system hang When a user executes the FITRIM command, an underflow can occur when calculating nblocks if end_block is too small. Since nblocks is of type sector_t, which is u64, a negative nblocks value will become a very large positive integer. This ultimately leads to the block layer function __blkdev_issue_discard() taking an excessively long time to process the bio chain, and the ns_segctor_sem lock remains held for a long period. This prevents other tasks from acquiring the ns_segctor_sem lock, resulting in the hang reported by syzbot in [1]. If the ending block is too small, typically if it is smaller than 4KiB range, depending on the usage of the segment 0, it may be possible to attempt a discard request beyond the device size causing the hang. Exiting successfully and assign the discarded size (0 in this case) to range->len. Although the start and len values in the user input range are too small, a conservative strategy is adopted here to safely ignore them, which is equivalent to a no-op; it will not perform any trimming and will not throw an error. [1] task:segctord state:D stack:28968 pid:6093 tgid:6093 ppid:2 task_flags:0x200040 flags:0x00080000 Call Trace: rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272 nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline] nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684 [ryusuke: corrected part of the commit message about the consequences]", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23229", "url": "https://ubuntu.com/security/CVE-2026-23229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add spinlock protection with virtqueue notification When VM boots with one virtio-crypto PCI device and builtin backend, run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head! It seems that the data virtqueue need protection when it is handled for virtio done notification. If the spinlock protection is added in virtcrypto_done_task(), openssl benchmark with multiple processes works well.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23222", "url": "https://ubuntu.com/security/CVE-2026-23222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly The existing allocation of scatterlists in omap_crypto_copy_sg_lists() was allocating an array of scatterlist pointers, not scatterlist objects, resulting in a 4x too small allocation. Use sizeof(*new_sg) to get the correct object size.", "cve_priority": "high", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23392", "url": "https://ubuntu.com/security/CVE-2026-23392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-45988", "url": "https://ubuntu.com/security/CVE-2026-45988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix re-decryption of RESPONSE packets If a RESPONSE packet gets a temporary failure during processing, it may end up in a partially decrypted state - and then get requeued for a retry. Fix this by just discarding the packet; we will send another CHALLENGE packet and thereby elicit a further response. Similarly, discard an incoming CHALLENGE packet if we get an error whilst generating a RESPONSE; the server will send another CHALLENGE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46195", "url": "https://ubuntu.com/security/CVE-2026-46195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46135", "url": "https://ubuntu.com/security/CVE-2026-46135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.", "cve_priority": "critical", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31402", "url": "https://ubuntu.com/security/CVE-2026-31402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.", "cve_priority": "critical", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43071", "url": "https://ubuntu.com/security/CVE-2026-43071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dcache: Limit the minimal number of bucket to two There is an OOB read problem on dentry_hashtable when user sets 'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260 There will be only one bucket in dentry_hashtable when dhash_entries is set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then, following process will access more than one buckets(which memory region is not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB! Fix it by limiting the minimal number of dentry_hashtable bucket to two, so that 'd_hash_shift' won't exceeds the bit width of type u32.", "cve_priority": "low", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-46119", "url": "https://ubuntu.com/security/CVE-2026-46119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix slab-out-of-bounds access in auth message processing If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY contains a positive value in its result field, it is treated as an error code by ceph_handle_auth_reply() and returned to handle_auth_reply(). Thereafter, an attempt is made to send the preallocated message of type CEPH_MSG_AUTH, where the returned value is interpreted as the size of the front segment to send. If the result value in the message is greater than the size of the memory buffer allocated for the front segment, an out-of-bounds access occurs, and the content of the memory region beyond this buffer is sent out. This patch fixes the issue by treating only negative values in the result field as errors. Positive values are therefore treated as success in the same way as a zero value. Additionally, a BUG_ON is added to __send_prepared_auth_request() comparing the len parameter to front_alloc_len to prevent sending the message if it exceeds the bounds of the allocation and to make it easier to catch any logic flaws leading to this.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-43501", "url": "https://ubuntu.com/security/CVE-2026-43501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: \tskb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards.", "cve_priority": "critical", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46043", "url": "https://ubuntu.com/security/CVE-2026-46043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43493", "url": "https://ubuntu.com/security/CVE-2026-43493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications.", "cve_priority": "high", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-31637", "url": "https://ubuntu.com/security/CVE-2026-31637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: reject undecryptable rxkad response tickets rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether crypto_skcipher_decrypt() succeeded. A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes. Check the decrypt result and abort the connection with RXKADBADTICKET when ticket decryption fails.", "cve_priority": "critical", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31657", "url": "https://ubuntu.com/security/CVE-2026-31657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: hold claim backbone gateways by reference batadv_bla_add_claim() can replace claim->backbone_gw and drop the old gateway's last reference while readers still follow the pointer. The netlink claim dump path dereferences claim->backbone_gw->orig and takes claim->backbone_gw->crc_lock without pinning the underlying backbone gateway. batadv_bla_check_claim() still has the same naked pointer access pattern. Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate on a stable gateway reference until the read-side work is complete. This keeps the dump and claim-check paths aligned with the lifetime rules introduced for the other BLA claim readers.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31685", "url": "https://ubuntu.com/security/CVE-2026-31685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_eui64: reject invalid MAC header for all packets `eui64_mt6()` derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address. The existing guard only rejects an invalid MAC header when `par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()` can still reach `eth_hdr(skb)` even when the MAC header is not valid. Fix this by removing the `par->fragoff != 0` condition so that packets with an invalid MAC header are rejected before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43117", "url": "https://ubuntu.com/security/CVE-2026-43117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() If overlay is used on top of btrfs, dentry->d_sb translates to overlay's super block and fsid assignment will lead to a crash. Use file_inode(file)->i_sb to always get btrfs_sb.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43114", "url": "https://ubuntu.com/security/CVE-2026-43114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry New test case fails unexpectedly when avx2 matching functions are used. The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo. This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f - This is expected to work, because its the same set after all and it was already loaded once. But with avx2, this fails: nft reports a clashing element. The reported clash is of following form: We successfully re-inserted a . b c . d Then we try to insert a . d avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next. Due to incorrect masking, the skip-step finds the next matching element *only considering the first field*, i.e. we return the already reinserted \"a . b\", even though the last field is different and the entry should not have been matched. No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback. Bisection points to 7711f4bb4b36 (\"netfilter: nft_set_pipapo: fix range overlap detection\") but that fix merely uncovers this bug. Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate. The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31478", "url": "https://ubuntu.com/security/CVE-2026-31478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len() After this commit (e2b76ab8b5c9 \"ksmbd: add support for read compound\"), response buffer management was changed to use dynamic iov array. In the new design, smb2_calc_max_out_buf_len() expects the second argument (hdr2_len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31668", "url": "https://ubuntu.com/security/CVE-2026-31668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: separate dst_cache for input and output paths in seg6 lwtunnel The seg6 lwtunnel uses a single dst_cache per encap route, shared between seg6_input_core() and seg6_output_core(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup. Fix this by splitting the cache into cache_input and cache_output, so each path maintains its own cached dst independently.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31659", "url": "https://ubuntu.com/security/CVE-2026-31659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject oversized global TT response buffers batadv_tt_prepare_tvlv_global_data() builds the allocation length for a global TT response in 16-bit temporaries. When a remote originator advertises a large enough global TT, the TT payload length plus the VLAN header offset can exceed 65535 and wrap before kmalloc(). The full-table response path still uses the original TT payload length when it fills tt_change, so the wrapped allocation is too small and batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object before the later packet-size check runs. Fix this by rejecting TT responses whose TVLV value length cannot fit in the 16-bit TVLV payload length field.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31649", "url": "https://ubuntu.com/security/CVE-2026-31649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix integer underflow in chain mode The jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb->len (total length including page fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc); When a packet has a small linear portion (nopaged_len <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax * i pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware. Fix this by introducing a buf_len local variable clamped to min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmac_xmit() handles page fragments afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31669", "url": "https://ubuntu.com/security/CVE-2026-31669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix slab-use-after-free in __inet_lookup_established The ehash table lookups are lockless and rely on SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability during RCU read-side critical sections. Both tcp_prot and tcpv6_prot have their slab caches created with this flag via proto_register(). However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into tcpv6_prot_override during inet_init() (fs_initcall, level 5), before inet6_init() (module_init/device_initcall, level 6) has called proto_register(&tcpv6_prot). At that point, tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab remains NULL permanently. This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so when these sockets are freed without SOCK_RCU_FREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcu_read_lock can then access freed memory, triggering a slab-use-after-free in __inet_lookup_established. Fix this by splitting the IPv6-specific initialization out of mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called from mptcp_proto_v6_init() before protocol registration. This ensures tcpv6_prot_override.slab correctly inherits the SLAB_TYPESAFE_BY_RCU slab cache.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43011", "url": "https://ubuntu.com/security/CVE-2026-43011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix potential double free of skb When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain: x25_queue_rx_frame returns 1 | v x25_state3_machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25_process_rx_frame returns queued=0 | v x25_backlog_rcv at line 452 sees queued=0 and calls kfree_skb(skb) again This would free the same skb twice. Looking at x25_backlog_rcv: net/x25/x25_in.c:x25_backlog_rcv() { ... queued = x25_process_rx_frame(sk, skb); ... if (!queued) kfree_skb(skb); }", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43037", "url": "https://ubuntu.com/security/CVE-2026-43037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip4ip6_err() Oskar Kjos reported the following problem. ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr value. __ip_options_echo() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->__data, a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE). To fix this we clear skb2->cb[], as suggested by Oskar Kjos. Also add minimal IPv4 header validation (version == 4, ihl >= 5).", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43038", "url": "https://ubuntu.com/security/CVE-2026-43038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31682", "url": "https://ubuntu.com/security/CVE-2026-31682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: linearize skb before parsing ND options br_nd_send() parses neighbour discovery options from ns->opt[] and assumes that these options are in the linear part of request. Its callers only guarantee that the ICMPv6 header and target address are available, so the option area can still be non-linear. Parsing ns->opt[] in that case can access data past the linear buffer. Linearize request before option parsing and derive ns from the linear network header.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-23450", "url": "https://ubuntu.com/security/CVE-2026-23450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1]. smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release(). This leads to two issues: 1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed. The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race): CPU A (softirq) CPU B (process ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* No lock on listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash! Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed. Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight. - Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock(). - Use rcu_read_lock() to protect reading sk_user_data. - Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely. Note: smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected. Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied. [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23428", "url": "https://ubuntu.com/security/CVE-2026-23428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of share_conf in compound request smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without validating tcon->t_state. ksmbd_tree_conn_lookup() checks t_state == TREE_CONNECTED on the initial lookup path, but the compound reuse path bypasses this check entirely. If a prior command in the compound (SMB2_TREE_DISCONNECT) sets t_state to TREE_DISCONNECTED and frees share_conf via ksmbd_share_config_put(), subsequent commands dereference the freed share_conf through work->tcon->share_conf. KASAN report: [ 4.144653] ================================================================== [ 4.145059] BUG: KASAN: slab-use-after-free in smb2_write+0xc74/0xe70 [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44 [ 4.145772] [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY [ 4.145871] 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 [ 4.145875] Workqueue: ksmbd-io handle_ksmbd_work [ 4.145888] Call Trace: [ 4.145892] [ 4.145894] dump_stack_lvl+0x64/0x80 [ 4.145910] print_report+0xce/0x660 [ 4.145919] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 4.145928] ? smb2_write+0xc74/0xe70 [ 4.145931] kasan_report+0xce/0x100 [ 4.145934] ? smb2_write+0xc74/0xe70 [ 4.145937] smb2_write+0xc74/0xe70 [ 4.145939] ? __pfx_smb2_write+0x10/0x10 [ 4.145942] ? _raw_spin_unlock+0xe/0x30 [ 4.145945] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 4.145948] ? smb2_tree_disconnect+0x31c/0x480 [ 4.145951] handle_ksmbd_work+0x40f/0x1080 [ 4.145953] process_one_work+0x5fa/0xef0 [ 4.145962] ? assign_work+0x122/0x3e0 [ 4.145964] worker_thread+0x54b/0xf70 [ 4.145967] ? __pfx_worker_thread+0x10/0x10 [ 4.145970] kthread+0x346/0x470 [ 4.145976] ? recalc_sigpending+0x19b/0x230 [ 4.145980] ? __pfx_kthread+0x10/0x10 [ 4.145984] ret_from_fork+0x4fb/0x6c0 [ 4.145992] ? __pfx_ret_from_fork+0x10/0x10 [ 4.145995] ? __switch_to+0x36c/0xbe0 [ 4.145999] ? __pfx_kthread+0x10/0x10 [ 4.146003] ret_from_fork_asm+0x1a/0x30 [ 4.146013] [ 4.146014] [ 4.149858] Allocated by task 44: [ 4.149953] kasan_save_stack+0x33/0x60 [ 4.150061] kasan_save_track+0x14/0x30 [ 4.150169] __kasan_kmalloc+0x8f/0xa0 [ 4.150274] ksmbd_share_config_get+0x1dd/0xdd0 [ 4.150401] ksmbd_tree_conn_connect+0x7e/0x600 [ 4.150529] smb2_tree_connect+0x2e6/0x1000 [ 4.150645] handle_ksmbd_work+0x40f/0x1080 [ 4.150761] process_one_work+0x5fa/0xef0 [ 4.150873] worker_thread+0x54b/0xf70 [ 4.150978] kthread+0x346/0x470 [ 4.151071] ret_from_fork+0x4fb/0x6c0 [ 4.151176] ret_from_fork_asm+0x1a/0x30 [ 4.151286] [ 4.151332] Freed by task 44: [ 4.151418] kasan_save_stack+0x33/0x60 [ 4.151526] kasan_save_track+0x14/0x30 [ 4.151634] kasan_save_free_info+0x3b/0x60 [ 4.151751] __kasan_slab_free+0x43/0x70 [ 4.151861] kfree+0x1ca/0x430 [ 4.151952] __ksmbd_tree_conn_disconnect+0xc8/0x190 [ 4.152088] smb2_tree_disconnect+0x1cd/0x480 [ 4.152211] handle_ksmbd_work+0x40f/0x1080 [ 4.152326] process_one_work+0x5fa/0xef0 [ 4.152438] worker_thread+0x54b/0xf70 [ 4.152545] kthread+0x346/0x470 [ 4.152638] ret_from_fork+0x4fb/0x6c0 [ 4.152743] ret_from_fork_asm+0x1a/0x30 [ 4.152853] [ 4.152900] The buggy address belongs to the object at ffff88810430c180 [ 4.152900] which belongs to the cache kmalloc-96 of size 96 [ 4.153226] The buggy address is located 20 bytes inside of [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0) [ 4.153549] [ 4.153596] The buggy address belongs to the physical page: [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c [ 4.154000] flags: 0x ---truncated---", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23455", "url": "https://ubuntu.com/security/CVE-2026-23455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read. Add a check to ensure len is positive after the decrement.", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43186", "url": "https://ubuntu.com/security/CVE-2026-43186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43185", "url": "https://ubuntu.com/security/CVE-2026-43185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix signededness bug in smb_direct_prepare_negotiation() smb_direct_prepare_negotiation() casts an unsigned __u32 value from sp->max_recv_size and req->preferred_send_size to a signed int before computing min_t(int, ...). A maliciously provided preferred_send_size of 0x80000000 will return as smaller than max_recv_size, and then be used to set the maximum allowed alowed receive size for the next message. By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow. This fix replaces min_t(int, ...) with min_t(u32)", "cve_priority": "critical", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43341", "url": "https://ubuntu.com/security/CVE-2026-43341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31607", "url": "https://ubuntu.com/security/CVE-2026-31607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: validate number_of_packets in usbip_pack_ret_submit() When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the *original* number_of_packets from the CMD_SUBMIT. A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region. KASAN confirmed this with kernel 7.0.0-rc5: BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69 The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40) The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 (\"usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input\") and b78d830f0049 (\"usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input\"). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets. This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size. Kelvin Mbogo's series (\"usb: usbip: fix integer overflow in usbip_recv_iso()\", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit. Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43383", "url": "https://ubuntu.com/security/CVE-2026-43383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-md5: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2025-68263", "url": "https://ubuntu.com/security/CVE-2025-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: ipc: fix use-after-free in ipc_msg_send_request ipc_msg_send_request() waits for a generic netlink reply using an ipc_msg_table_entry on the stack. The generic netlink handler (handle_generic_event()/handle_response()) fills entry->response under ipc_msg_table_lock, but ipc_msg_send_request() used to validate and free entry->response without holding the same lock. Under high concurrency this allows a race where handle_response() is copying data into entry->response while ipc_msg_send_request() has just freed it, leading to a slab-use-after-free reported by KASAN in handle_generic_event(): BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd] Write of size 12 at addr ffff888198ee6e20 by task pool/109349 ... Freed by task: kvfree ipc_msg_send_request [ksmbd] ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd] Fix by: - Taking ipc_msg_table_lock in ipc_msg_send_request() while validating entry->response, freeing it when invalid, and removing the entry from ipc_msg_table. - Returning the final entry->response pointer to the caller only after the hash entry is removed under the lock. - Returning NULL in the error path, preserving the original API semantics. This makes all accesses to entry->response consistent with handle_response(), which already updates and fills the response buffer under ipc_msg_table_lock, and closes the race that allowed the UAF.", "cve_priority": "critical", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2026-46243", "url": "https://ubuntu.com/security/CVE-2026-46243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key.", "cve_priority": "medium", "cve_public_date": "2026-06-01 17:17:00 UTC" }, { "cve": "CVE-2026-43414", "url": "https://ubuntu.com/security/CVE-2026-43414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Completely fix fcport double free In qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free(). When an error happens, this function is called by qla2x00_sp_release(), when kref_put() releases the first and the last reference. qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport(). Doing it one more time after kref_put() is a bad idea.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43407", "url": "https://ubuntu.com/security/CVE-2026-43407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply() This patch fixes an out-of-bounds access in ceph_handle_auth_reply() that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In ceph_handle_auth_reply(), the value of the payload_len field of such a message is stored in a variable of type int. A value greater than INT_MAX leads to an integer overflow and is interpreted as a negative value. This leads to decrementing the pointer address by this value and subsequently accessing it because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. This patch fixes the issue by changing the data type of payload_len to u32. Additionally, the data type of result_msg_len is changed to u32, as it is also a variable holding a non-negative length. Also, an additional layer of sanity checks is introduced, ensuring that directly after reading it from the message, payload_len and result_msg_len are not greater than the overall segment length. BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph] Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262 CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ceph-msgr ceph_con_workfn [libceph] Call Trace: dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x620 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x72/0x210 kasan_report+0xe7/0x130 ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] __asan_report_load_n_noabort+0xf/0x20 ceph_handle_auth_reply+0x642/0x7a0 [libceph] mon_dispatch+0x973/0x23d0 [libceph] ? apparmor_socket_recvmsg+0x6b/0xa0 ? __pfx_mon_dispatch+0x10/0x10 [libceph] ? __kasan_check_write+0x14/0x30i ? mutex_unlock+0x7f/0xd0 ? __pfx_mutex_unlock+0x10/0x10 ? __pfx_do_recvmsg+0x10/0x10 [libceph] ceph_con_process_message+0x1f1/0x650 [libceph] process_message+0x1e/0x450 [libceph] ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] ? save_fpregs_to_fpstate+0xb0/0x230 ? raw_spin_rq_unlock+0x17/0xa0 ? finish_task_switch.isra.0+0x13b/0x760 ? __switch_to+0x385/0xda0 ? __kasan_check_write+0x14/0x30 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 ceph_con_workfn+0x248/0x10c0 [libceph] process_one_work+0x629/0xf80 ? __kasan_check_write+0x14/0x30 worker_thread+0x87f/0x1570 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_try_to_wake_up+0x10/0x10 ? kasan_print_address_stack_frame+0x1f7/0x280 ? __pfx_worker_thread+0x10/0x10 kthread+0x396/0x830 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? __pfx_kthread+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? recalc_sigpending+0x180/0x210 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3f7/0x610 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x385/0xda0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 [ idryomov: replace if statements with ceph_decode_need() for payload_len and result_msg_len ]", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43406", "url": "https://ubuntu.com/security/CVE-2026-43406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in process_message_header() If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in process_message_header(). Perform an explicit bounds check before decoding the message header.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43304", "url": "https://ubuntu.com/security/CVE-2026-43304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.", "cve_priority": "critical", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-37924", "url": "https://ubuntu.com/security/CVE-2025-37924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in kerberos authentication Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbd_free_user but before sess->user is set to NULL.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37778", "url": "https://ubuntu.com/security/CVE-2025-37778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix dangling pointer in krb_authenticate krb_authenticate frees sess->user and does not set the pointer to NULL. It calls ksmbd_krb5_authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2_sess_setup, which calls krb_authenticate, will be accessing free'd memory when it later uses sess->user.", "cve_priority": "high", "cve_public_date": "2025-05-01 14:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2157390, 1786013, 2157405, 2154194, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156629, 2156629, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198 ], "changes": [ { "cves": [ { "cve": "CVE-2026-46137", "url": "https://ubuntu.com/security/CVE-2026-46137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: fix potential data-race This mptcp_pm_add_timer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bh_lock_sock(). If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46275", "url": "https://ubuntu.com/security/CVE-2026-46275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart. The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the `hu` struct. When the scheduled work executes later, it blindly dereferences the freed `hu` struct. Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently. Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities.", "cve_priority": "high", "cve_public_date": "2026-06-08 16:16:00 UTC" }, { "cve": "CVE-2025-23141", "url": "https://ubuntu.com/security/CVE-2025-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where \"accepting\" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit can access guest memory. The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triple_fault_event_test selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario. ============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted ----------------------------- include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2026-43052", "url": "https://ubuntu.com/security/CVE-2026-43052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check tdls flag in ieee80211_tdls_oper When NL80211_TDLS_ENABLE_LINK is called, the code only checks if the station exists but not whether it is actually a TDLS station. This allows the operation to proceed for non-TDLS stations, causing unintended side effects like modifying channel context and HT protection before failing. Add a check for sta->sta.tdls early in the ENABLE_LINK case, before any side effects occur, to ensure the operation is only allowed for actual TDLS peers.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2025-22107", "url": "https://ubuntu.com/security/CVE-2025-22107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry() There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-21863", "url": "https://ubuntu.com/security/CVE-2025-21863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: prevent opcode speculation sqe->opcode is used for different tables, make sure we santitise it against speculations.", "cve_priority": "low", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2026-46274", "url": "https://ubuntu.com/security/CVE-2026-46274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io-wq: check that the predecessor is hashed in io_wq_remove_pending() io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0]. Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory. Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot.", "cve_priority": "high", "cve_public_date": "2026-06-08 16:16:00 UTC" }, { "cve": "CVE-2026-45846", "url": "https://ubuntu.com/security/CVE-2026-45846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst() bareudp_fill_metadata_dst() passes bareudp->sock to udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check. The socket is only created in bareudp_open() and NULLed in bareudp_stop(), so calling this function while the device is down triggers a NULL dereference via sock->sk. BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160) Call Trace: bareudp_fill_metadata_dst (drivers/net/bareudp.c:532) do_execute_actions (net/openvswitch/actions.c:901) ovs_execute_actions (net/openvswitch/actions.c:1589) ovs_packet_cmd_execute (net/openvswitch/datapath.c:700) genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1209) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths in the same driver.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45844", "url": "https://ubuntu.com/security/CVE-2026-45844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: arp_tables: fix IEEE1394 ARP payload parsing Weiming Shi says: \"arp_packet_match() unconditionally parses the ARP payload assuming two hardware addresses are present (source and target). However, IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address field, and arp_hdr_len() already accounts for this by returning a shorter length for ARPHRD_IEEE1394 devices. As a result, on IEEE1394 interfaces arp_packet_match() advances past a nonexistent target hardware address and reads the wrong bytes for both the target device address comparison and the target IP address. This causes arptables rules to match against garbage data, leading to incorrect filtering decisions: packets that should be accepted may be dropped and vice versa. The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already handles this correctly by skipping the target hardware address for ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match().\" Mangle the original patch to always return 0 (no match) in case user matches on the target hardware address which is never present in IEEE1394. Note that this returns 0 (no match) for either normal and inverse match because matching in the target hardware address in ARPHRD_IEEE1394 has never been supported by arptables. This is intentional, matching on the target hardware address should never evaluate true for ARPHRD_IEEE1394. Moreover, adjust arpt_mangle to drop the packet too as AI suggests: In arpt_mangle, the logic assumes a standard ARP layout. Because IEEE1394 (FireWire) omits the target hardware address, the linear pointer arithmetic miscalculates the offset for the target IP address. This causes mangling operations to write to the wrong location, leading to packet corruption. To ensure safety, this patch drops packets (NF_DROP) when mangling is requested for these fields on IEEE1394 devices, as the current implementation cannot correctly map the FireWire ARP payload. This omits both mangling target hardware and IP address. Even if IP address mangling should be possible in IEEE1394, this would require to adjust arpt_mangle offset calculation, which has never been supported. Based on patch from Weiming Shi .", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45843", "url": "https://ubuntu.com/security/CVE-2026-45843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: bound decode() reads against the compressed packet length slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code. A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets. Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45842", "url": "https://ubuntu.com/security/CVE-2026-45842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: reject VJ receive packets on instances with no rstate array slhc_init() accepts rslots == 0 as a valid configuration, with the documented meaning of 'no receive compression'. In that case the allocation loop in slhc_init() is skipped, so comp->rstate stays NULL and comp->rslot_limit stays 0 (from the kzalloc of struct slcompress). The receive helpers do not defend against that configuration. slhc_uncompress() dereferences comp->rstate[x] when the VJ header carries an explicit connection ID, and slhc_remember() later assigns cs = &comp->rstate[...] after only comparing the packet's slot number to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the range check, and the code dereferences a NULL rstate. The configuration is reachable in-tree through PPP. PPPIOCSMAXCID stores its argument in a signed int, and (val >> 16) uses arithmetic shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1 is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because /dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path is reachable from an unprivileged user namespace. Once the malformed VJ state is installed, any inbound VJ-compressed or VJ-uncompressed frame that selects slot 0 crashes the kernel in softirq context: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519) Call Trace: ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466) ppp_input (drivers/net/ppp/ppp_generic.c:2359) ppp_async_process (drivers/net/ppp/ppp_async.c:492) tasklet_action_common (kernel/softirq.c:926) handle_softirqs (kernel/softirq.c:623) run_ksoftirqd (kernel/softirq.c:1055) smpboot_thread_fn (kernel/smpboot.c:160) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) Reject the receive side on such instances instead of touching rstate. slhc_uncompress() falls through to its existing 'bad' label, which bumps sls_i_error and enters the toss state. slhc_remember() mirrors that with an explicit sls_i_error increment followed by slhc_toss(); the sls_i_runt counter is not used here because a missing rstate is an internal configuration state, not a runt packet. The transmit path is unaffected: the only in-tree caller that picks rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and slip.c always calls slhc_init(16, 16), so comp->tstate remains valid and slhc_compress() continues to work.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45841", "url": "https://ubuntu.com/security/CVE-2026-45841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO nf_osf_match_one() computes ctx->window % f->wss.val in the OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a subsequent matching TCP SYN divides by zero and panics the kernel. Reject the bogus fingerprint in nfnl_osf_add_callback() above the per-option for-loop. f->wss is per-fingerprint, not per-option, so the check must run regardless of f->opt_num (including 0). Also reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that as \"should not happen\". Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:220) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:348) nf_hook_slow (net/netfilter/core.c:622) ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv (include/linux/skbuff.h:1162) __netif_receive_skb_one_core (net/core/dev.c:6181) process_backlog (net/core/dev.c:6642) __napi_poll (net/core/dev.c:7710) net_rx_action (net/core/dev.c:7945) handle_softirqs (kernel/softirq.c:622)", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45840", "url": "https://ubuntu.com/security/CVE-2026-45840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: cap upcall PID array size and pre-size vport replies The vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENL_UNS_ADMIN_PERM. kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Kernel panic - not syncing: Fatal exception Reject attempts to set more PIDs than nr_cpu_ids in ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply size in ovs_vport_cmd_msg_size() based on that bound, similar to the existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the two sides stay consistent.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46319", "url": "https://ubuntu.com/security/CVE-2026-46319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: Only release RCU read lock after ct_ft When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero() is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft object. This vulnerability can lead to privilege escalation. Analysis from zdi-disclosures@trendmicro.com: When initializing act_ct, tcf_ct_init() is called, which internally triggers tcf_ct_flow_table_get(). static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params) { struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ... } static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params) { void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj; } At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft from zones_ht . The lookup is performed within an RCU read critical section through rcu_read_lock() / rcu_read_unlock(), which prevents the object from being freed. However, at the point of function return, rcu_read_unlock() has already been called, and there is nothing preventing ct_ft from being freed before reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomes the race window, during which ct_ft can be freed. Free Process: tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put(). static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft) { if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); } } At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work static void tcf_ct_flow_table_cleanup_work(struct work_struct *work) { struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE); } tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes between [1] and [2], UAF occurs. This race condition has a very short race window, making it generally difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was inserted after[1]", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-45839", "url": "https://ubuntu.com/security/CVE-2026-45839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec() CO-RE accessor strings are colon-separated indices that describe a path from a root BTF type to a target field, e.g. \"0:1:2\" walks through nested struct members. bpf_core_parse_spec() parses each component with sscanf(\"%d\"), so negative values like -1 are silently accepted. The subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the upper bound and always pass for negative values because C integer promotion converts the __u16 btf_vlen result to int, making the comparison (int)(-1) >= (int)(N) false for any positive N. When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff, producing an out-of-bounds read far past the members array. A crafted BPF program with a negative CO-RE accessor on any struct that exists in vmlinux BTF (e.g. task_struct) crashes the kernel deterministically during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y (default on major distributions). The bug is reachable with CAP_BPF: BUG: unable to handle page fault for address: ffffed11818b6626 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full) RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354) RAX: 00000000ffffffff Call Trace: bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321) bpf_core_apply (kernel/bpf/btf.c:9507) check_core_relo (kernel/bpf/verifier.c:19475) bpf_check (kernel/bpf/verifier.c:26031) bpf_prog_load (kernel/bpf/syscall.c:3089) __sys_bpf (kernel/bpf/syscall.c:6228) CO-RE accessor indices are inherently non-negative (struct member index, array element index, or enumerator index), so reject them immediately after parsing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45838", "url": "https://ubuntu.com/security/CVE-2026-45838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix end-of-list detection in cgroup_storage_get_next_key() list_next_entry() never returns NULL -- when the current element is the last entry it wraps to the list head via container_of(). The subsequent NULL check is therefore dead code and get_next_key() never returns -ENOENT for the last element, instead reading storage->key from a bogus pointer that aliases internal map fields and copying the result to userspace. Replace it with list_entry_is_head() so the function correctly returns -ENOENT when there are no more entries.", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46214", "url": "https://ubuntu.com/security/CVE-2026-46214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix accept queue count leak on transport mismatch virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listener to reject all new connections. Fix by moving sk_acceptq_added() to after the transport validation, matching the pattern used by vmci_transport and hyperv_transport.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46234", "url": "https://ubuntu.com/security/CVE-2026-46234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: fix buffer size clamping order In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint. This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size. Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45836", "url": "https://ubuntu.com/security/CVE-2026-45836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46231", "url": "https://ubuntu.com/security/CVE-2026-46231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: put backbone reference on failed claim hash insert When batadv_bla_add_claim() fails to insert a new claim into the hash, it leaked a reference to the backbone_gw for which the claim was intended. Call batadv_backbone_gw_put() on the error path to release the reference and avoid leaking the backbone_gw object.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46233", "url": "https://ubuntu.com/security/CVE-2026-46233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: only purge non-released claims When batadv_bla_purge_claims() goes through the list of claims, it is only traversing the hash list with an rcu_read_lock(). Due to a potential parallel batadv_claim_put(), it can happen that it encounters a claim which was actually in the process of being released+freed by batadv_claim_release(). In this case, backbone_gw is set to NULL before the delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is then no longer allowed because it would cause a NULL-ptr derefence. To avoid this, only claims with a valid reference counter must be purged. All others are already taken care of.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46212", "url": "https://ubuntu.com/security/CVE-2026-46212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: prevent use-after-free when deleting claims When batadv_bla_del_backbone_claims() removes all claims for a backbone, it does this by dropping the link entry in the hash list. This list entry itself was one of the references which need to be dropped at the same time via batadv_claim_put(). But the batadv_claim_put() must not be done before the last access to the claim object in this function. Otherwise the claim might be freed already by the batadv_claim_release() function before the list entry was dropped.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46238", "url": "https://ubuntu.com/security/CVE-2026-46238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop caching unowned originator pointers in BAT IV BAT IV keeps the last-hop neighbor address in each neigh_node, but some paths also cache an originator pointer derived from a temporary lookup. That pointer is not owned by the neigh_node and may no longer refer to a live originator entry after purge handling runs. Stop storing the auxiliary originator pointer in the BAT IV neighbor state. When BAT IV needs the neighbor originator data, resolve it from the stored neighbor address and drop the reference again after use. [sven: avoid bonding logic for outgoing OGM]", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46206", "url": "https://ubuntu.com/security/CVE-2026-46206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject new tp_meter sessions during teardown Prevent tp_meter from starting new sender or receiver sessions after mesh_state has left BATADV_MESH_ACTIVE.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46198", "url": "https://ubuntu.com/security/CVE-2026-46198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix integer overflow on buff_pos Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size check is done using the int type in batadv_iv_ogm_aggr_packet whereas the buff_pos variable uses the s16 type. This could lead to an out-of-bound read.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46227", "url": "https://ubuntu.com/security/CVE-2026-46227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the \"sk != asoc->base.sk\" and \"asoc->base.dead\" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 (\"sctp: walk the list of asoc safely\") was added for.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46220", "url": "https://ubuntu.com/security/CVE-2026-46220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission sdma_v4_0_ring_emit_fence() contains two BUG_ON(addr & 0x3) assertions that verify fence writeback addresses are dword-aligned. These assertions can be reached from unprivileged userspace via crafted DRM_IOCTL_AMDGPU_CS submissions, causing a fatal kernel panic in a scheduler worker thread. Replace both BUG_ON() calls with WARN_ON() to log the condition without crashing the kernel. A misaligned fence address at this point indicates a driver bug, but crashing the kernel is never the correct response when the assertion is reachable from userspace. The CS IOCTL path is the correct place to filter invalid submissions; the ring emission callback is too late to do anything about it. (cherry picked from commit b90250bd933afd1ba94d86d6b13821997b22b18e)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46197", "url": "https://ubuntu.com/security/CVE-2026-46197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: validate SVM ioctl nattr against buffer size Validate nattr field against the buffer size, preventing out-of-bounds buffer access via user-controlled attribute count. (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46209", "url": "https://ubuntu.com/security/CVE-2026-46209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1); However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value. A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46230", "url": "https://ubuntu.com/security/CVE-2026-46230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg Check bounds against the end of the BO whenever we access the msg.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46219", "url": "https://ubuntu.com/security/CVE-2026-46219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix use-after-free on unbind The state machine work is scheduled by the interrupt handler and therefore needs to be cancelled after disabling interrupts to avoid a potential use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46236", "url": "https://ubuntu.com/security/CVE-2026-46236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: xbox_remote: heed DMA restrictions The buffer for IO must not be part of the device structure because that violates the DMA coherency rules.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46205", "url": "https://ubuntu.com/security/CVE-2026-46205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: media: atomisp: Disallow all private IOCTLs Disallow all private IOCTLs. These aren't quite as safe as one could assume of IOCTL handlers; disable them for now. Instead of removing the code, return in the beginning of the function if cmd is non-zero in order to keep static checkers happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46168", "url": "https://ubuntu.com/security/CVE-2026-46168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix scheduling with atomic in timestamp sockopt Using lock_sock_fast() (atomic context) around sock_set_timestamp() and sock_set_timestamping() is unsafe, as both helpers can sleep. Replace lock_sock_fast() with sleepable lock_sock()/release_sock() to avoid scheduling while atomic panic.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46189", "url": "https://ubuntu.com/security/CVE-2026-46189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path Sashiko points out that pvrdma_uar_free() is already called within pvrdma_dealloc_ucontext(), so calling it before triggers a double free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46133", "url": "https://ubuntu.com/security/CVE-2026-46133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject unknown opcodes before ICRC processing Even after applying commit 7244491dab34 (\"RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv\"), a single unauthenticated UDP packet can still trigger panic. That patch handled payload_size() underflow only for valid opcodes with short packets, not for packets carrying an unknown opcode. The unknown-opcode OOB read described below predates that commit and reaches back to the initial Soft RoCE driver. The check added there reads pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The rxe_opcode[] array has 256 entries but is only populated for defined IB opcodes; any other entry (for example opcode 0xff) is zero-initialized, so length == 0 and the check degenerates to pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES which underflows when length == 0 and passes a huge value to rxe_crc32(), causing an out-of-bounds read of the skb payload. Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma link add rxe0 type rxe netdev eth0 A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and QPN=IB_MULTICAST_QPN triggers: BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170 Read of size 1 at addr ... The buggy address is located 0 bytes to the right of allocated 704-byte region Call Trace: crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 Subsequent packets with the same shape fault on unmapped memory and panic the kernel. The trigger requires only module load and \"rdma link add\"; no QP, no connection, and no authentication. Fix this by rejecting packets whose opcode has no rxe_opcode[] entry, detected via the zero mask or zero length, before any length arithmetic runs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46127", "url": "https://ubuntu.com/security/CVE-2026-46127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp() Sashiko points out that pd->uctx isn't initialized until late in the function so all these error flow references are NULL and will crash. Use the uctx that isn't NULL.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46178", "url": "https://ubuntu.com/security/CVE-2026-46178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq() Sashiko points out that mlx4_srq_alloc() was not undone during error unwind, add the missing call to mlx4_srq_free().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46112", "url": "https://ubuntu.com/security/CVE-2026-46112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix unlocked call to hns_roce_qp_remove() Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory. Grab the same locks the other two callers use.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46304", "url": "https://ubuntu.com/security/CVE-2026-46304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the final controller reference through nvmet_cq_put(). If that triggers nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on the same nvmet-wq. Call chain: nvmet_tcp_schedule_release_queue() kref_put(&queue->kref, nvmet_tcp_release_queue) nvmet_tcp_release_queue() queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq process_one_work() nvmet_tcp_release_queue_work() nvmet_cq_put(&queue->nvme_cq) nvmet_cq_destroy() nvmet_ctrl_put(cq->ctrl) nvmet_ctrl_free() flush_work(&ctrl->async_event_work) <--- nvmet_wq Previously Scheduled by :- \t\t nvmet_add_async_event \t\t queue_work(nvmet_wq, &ctrl->async_event_work); This trips lockdep with a possible recursive locking warning. [ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55 [ 5223.061801] loop0: detected capacity change from 0 to 2097152 [ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 [ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420) [ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349. [ 5223.128453] nvme nvme1: new ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349 [ 5233.199447] nvme nvme1: Removing ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\" [ 5233.227718] ============================================ [ 5233.231283] WARNING: possible recursive locking detected [ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N [ 5233.238434] -------------------------------------------- [ 5233.241852] kworker/u192:6/2413 is trying to acquire lock: [ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 [ 5233.251438] but task is already holding lock: [ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.261125] other info that might help us debug this: [ 5233.265333] Possible unsafe locking scenario: [ 5233.269217] CPU0 [ 5233.270795] ---- [ 5233.272436] lock((wq_completion)nvmet-wq); [ 5233.275241] lock((wq_completion)nvmet-wq); [ 5233.278020] *** DEADLOCK *** [ 5233.281793] May be due to missing lock nesting notation [ 5233.286195] 3 locks held by kworker/u192:6/2413: [ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0 [ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 [ 5233.304290] stack backtrace: [ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full) [ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST [ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp] [ 5233.306532] Call Trace: [ 5233.306534] [ 5233.306536] dump_stack_lvl+0x73/0xb0 [ 5233.306552] print_deadlock_bug+0x225/0x2f0 [ 5233.306556] __lock_acquire+0x13f0/0x2290 [ 5233.306563] lock_acquire+0xd0/0x300 [ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306571] ? __flush_work+0x20b/0x530 [ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306577] touch_wq_lockdep_map+0x3b/0x90 [ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90 [ 52 ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46161", "url": "https://ubuntu.com/security/CVE-2026-46161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix divide-by-zero in setup_geo() with zero far_copies setup_geo() extracts near_copies (nc) and far_copies (fc) from the user-provided layout parameter without checking for zero. When fc=0 with the \"improved\" far set layout selected, 'geo->far_set_size = disks / fc' triggers a divide-by-zero. Validate nc and fc immediately after extraction, returning -1 if either is zero.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46124", "url": "https://ubuntu.com/security/CVE-2026-46124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate block number from NFS file handle in isofs_export_iget isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker- controlled block number (ifid->block or ifid->parent_block) from the NFS file handle to isofs_export_iget(), which only rejects block == 0 before calling isofs_iget() and ultimately sb_bread(). A crafted file handle with fh_len sufficient to pass the check added by commit 0405d4b63d08 (\"isofs: Prevent the use of too small fid\") can still drive the server to read any in-range block on the backing device as if it were an iso_directory_record. That earlier fix was assigned CVE-2025-37780. sb_bread() on an out-of-range block returns NULL cleanly via the EIO path, so there is no memory-safety violation. For in-range reads of adjacent-partition data on the same block device, the unrelated bytes end up in iso_inode_info fields that reach the NFS client as dentry metadata. The deployment surface (isofs exported over NFS from loop-mounted images) is narrow and requires an authenticated NFS peer, but the malformed-file-handle class is reportable as hardening next to the existing CVE-2025-37780 fix. Reject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent() call sites with a single line.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46303", "url": "https://ubuntu.com/security/CVE-2026-46303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b (\"[PATCH] rock.c: handle corrupted directories\") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 (\"isofs: Fix infinite looping over CE entries\") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.", "cve_priority": "medium", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46294", "url": "https://ubuntu.com/security/CVE-2026-46294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a buffer overflow in ioctl processing Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the \"outptr\" variable to the next 8-byte boundary: \toutptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The \"for\" loop is iterated again, it executes: \tremaining = len - (outptr - outbuf); 5. If \"outptr\" points past \"outbuf + len\", the arithmetics wraps around and the variable \"remaining\" contains unusually high number 6. With \"remaining\" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, \"outptr = align_ptr(outptr)\" can't overshoot the input buffer and the bug can't happen accidentally", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46107", "url": "https://ubuntu.com/security/CVE-2026-46107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-thin: fix metadata refcount underflow There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count. If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in \"device mapper: space map common: unable to decrement block\" errors. Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46301", "url": "https://ubuntu.com/security/CVE-2026-46301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: topcliff-pch: fix use-after-free on unbind Give the driver a chance to flush its queue before releasing the DMA buffers on driver unbind", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46273", "url": "https://ubuntu.com/security/CVE-2026-46273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmveth: Disable GSO for packets with small MSS Some physical adapters on Power systems do not support segmentation offload when the MSS is less than 224 bytes. Attempting to send such packets causes the adapter to freeze, stopping all traffic until manually reset. Implement ndo_features_check to disable GSO for packets with small MSS values. The network stack will perform software segmentation instead. The 224-byte minimum matches ibmvnic commit (\"ibmvnic: Enforce stronger sanity checks on GSO packets\") which uses the same physical adapters in SEA configurations. The issue occurs specifically when the hardware attempts to perform segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets (gso_segs == 1) do not trigger the problematic LSO code path and are transmitted normally without segmentation. Add an ndo_features_check callback to disable GSO when MSS < 224 bytes. Also call vlan_features_check() to ensure proper handling of VLAN packets, particularly QinQ (802.1ad) configurations where the hardware parser may not support certain offload features. Validated using iptables to force small MSS values. Without the fix, the adapter freezes. With the fix, packets are segmented in software and transmission succeeds. Comprehensive regression testing completedd (MSS tests, performance, stability).", "cve_priority": "high", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-43502", "url": "https://ubuntu.com/security/CVE-2026-43502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: handle zerocopy send cleanup before the message is queued A zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket. The purge path currently infers zerocopy state from rm->m_rs, so an unqueued message can be cleaned up as if it owned normal payload pages. However, zerocopy ownership is really determined by the presence of op_mmp_znotifier, regardless of whether the message has reached the socket queue. Capture op_mmp_znotifier up front in rds_message_purge() and use it as the cleanup discriminator. If the message is already associated with a socket, keep the existing completion path. Otherwise, drop the pinned page accounting directly and release the notifier before putting the payload pages. This keeps early send failure cleanup consistent with the zerocopy lifetime rules without changing the normal queued completion path.", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46120", "url": "https://ubuntu.com/security/CVE-2026-46120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: Use cached t->net in ip6erspan_changelink(). After commit 5e72ce3e3980 (\"net: ipv6: Use link netns in newlink() of rtnl_link_ops\"), ip6erspan_newlink() correctly resolves the per-netns ip6gre hash via link_net. ip6erspan_changelink() was not converted in that series and still uses dev_net(dev), which diverges from the device's creation netns after IFLA_NET_NS_FD migration. This re-inserts the tunnel into the wrong per-netns hash. The original netns keeps a stale entry. When that netns is later destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a slab-use-after-free reported by KASAN, followed by a kernel BUG at net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify(). Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). ip6gre_changelink() earlier in the same file already uses the cached t->net; only ip6erspan_changelink() has the wrong shape.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46184", "url": "https://ubuntu.com/security/CVE-2026-46184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sound: ua101: fix division by zero at probe Add a missing sanity check for bNrChannels in detect_usb_format() to prevent a division by zero in playback_urb_complete() and capture_urb_complete(). USB core does not validate class-specific descriptor fields such as bNrChannels, so drivers must verify them before use. If a device provides bNrChannels = 0, frame_bytes becomes zero and is later used as a divisor in the URB completion handlers, leading to a kernel crash.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46132", "url": "https://ubuntu.com/security/CVE-2026-46132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack without initialisation: \tstruct ifla_vf_broadcast vf_broadcast; The struct contains a single fixed 32-byte field: \t/* include/uapi/linux/if_link.h */ \tstruct ifla_vf_broadcast { \t\t__u8 broadcast[32]; \t}; The function then copies dev->broadcast into it using dev->addr_len as the length: \tmemcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len); On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via: \tnla_put(skb, IFLA_VF_BROADCAST, \t\tsizeof(vf_broadcast), &vf_broadcast) leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK request, repeatable. The other vf_* structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vf_vlan_info, node_guid and port_guid a few lines above. vf_broadcast was simply missed when it was added. Reachability: any unprivileged local process can open AF_NETLINK / NETLINK_ROUTE without capabilities and send RTM_GETLINK with an IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nla_put() when reproduced. Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf_* structs in the same function.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46150", "url": "https://ubuntu.com/security/CVE-2026-46150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fanotify: fix false positive on permission events fsnotify_get_mark_safe() may return false for a mark on an unrelated group, which results in bypassing the permission check. Fix by skipping over detached marks that are not in the current group.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45834", "url": "https://ubuntu.com/security/CVE-2026-45834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-45835", "url": "https://ubuntu.com/security/CVE-2026-45835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46186", "url": "https://ubuntu.com/security/CVE-2026-46186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: validate rx pkt_type header length virtbt_rx_handle() reads the leading pkt_type byte from the RX skb and forwards the remainder to hci_recv_frame() for every event/ACL/SCO/ISO type, without checking that the remaining payload is at least the fixed HCI header for that type. After the preceding patch bounds the backend-supplied used.len to [1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches hci_recv_frame() with skb->len already pulled to 0. If the byte happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification fast-path in hci_dev_classify_pkt_type() dereferences hci_acl_hdr(skb)->handle whenever the HCI device has an active CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of uninitialized RX-buffer data. The same hazard exists for every packet type the driver accepts because none of the switch cases in virtbt_rx_handle() check skb->len against the per-type minimum HCI header size before handing the frame to the core. After stripping pkt_type, require skb->len to cover the fixed header size for the selected type (event 2, ACL 4, SCO 3, ISO 4) before calling hci_recv_frame(); drop ratelimited otherwise. Unknown pkt_type values still take the original kfree_skb() default path. Use bt_dev_err_ratelimited() because both the length and pkt_type values come from an untrusted backend that can otherwise flood the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46123", "url": "https://ubuntu.com/security/CVE-2026-46123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: clamp rx length before skb_put virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one(). Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device. The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory. Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle(). Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log. Same class of bug as commit c04db81cd028 (\"net/9p: Fix buffer overflow in USB transport layer\"), which hardened the USB 9p transport against unchecked device-reported length.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46172", "url": "https://ubuntu.com/security/CVE-2026-46172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: xfrm6: release dst on error in xfrm6_rcv_encap() xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6_route_input_lookup() returns a referenced dst entry even when the lookup resolves to an error route. If dst->error is set, xfrm6_rcv_encap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries. Release the dst before jumping to the drop path.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46146", "url": "https://ubuntu.com/security/CVE-2026-46146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3() The convert_chmap_v3() has a loop with its increment size of cs_desc->wLength, but we forgot to validate cs_desc->wLength itself, which may lead to potential endless loop by a malformed descriptor. Add a proper size check to abort the loop for plugging the hole.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46167", "url": "https://ubuntu.com/security/CVE-2026-46167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. Ideally that short command should be detected and error out, but many printers are known to send \"incorrect\" responses back so we can't just do that. statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl. usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller. Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no \"leak\" of information happening.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46151", "url": "https://ubuntu.com/security/CVE-2026-46151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix heap leak in IEEE 1284 device ID via short response usblp_ctrl_msg() collapses the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GET_DEVICE_ID control transfer short and the driver has no way to know. usblp_cache_device_id_string() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves device_id_string[2..1022] holding stale kmalloc heap. That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf(\"%s\", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device. Fix this up by just zapping the buffer with zeros before each request sent to the device.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46122", "url": "https://ubuntu.com/security/CVE-2026-46122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43: enforce bounds check on firmware key index in b43_rx() The firmware-controlled key index in b43_rx() can exceed the dev->key[] array size (58 entries). The existing B43_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read. Make the B43_WARN_ON check enforcing by dropping the frame when the firmware returns an invalid key index.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46307", "url": "https://ubuntu.com/security/CVE-2026-46307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath5k: do not access array OOB Vincent reports: > The ath5k driver seems to do an array-index-out-of-bounds access as > shown by the UBSAN kernel message: > UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20 > index 4 is out of range for type 'ieee80211_tx_rate [4]' > ... > Call Trace: > > dump_stack_lvl+0x5d/0x80 > ubsan_epilogue+0x5/0x2b > __ubsan_handle_out_of_bounds.cold+0x46/0x4b > ath5k_tasklet_tx+0x4e0/0x560 [ath5k] > tasklet_action_common+0xb5/0x1c0 It is real. 'ts->ts_final_idx' can be 3 on 5212, so: info->status.rates[ts->ts_final_idx + 1].idx = -1; with the array defined as: struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES]; while the size is: #define IEEE80211_TX_MAX_RATES 4 is indeed bogus. Set this 'idx = -1' sentinel only if the array index is less than the array size. As mac80211 will not look at rates beyond the size (IEEE80211_TX_MAX_RATES). Note: The effect of the OOB write is negligible. It just overwrites the next member of info->status, i.e. ack_signal.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46187", "url": "https://ubuntu.com/security/CVE-2026-46187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: fix kthread lifetime race between self-exit and external-stop RSI driver use both self-exit(kthread_complete_and_exit) and external-stop (kthread_stop) when killing a kthread. Generally, kthread_stop() is called first, and in this case, no particular issues occur. However, in rare instances where kthread_complete_and_exit() is called first and then kthread_stop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again. Therefore, to prevent this with minimal modification, you must remove kthread_stop() and change the code to wait until the self-exit operation is completed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46163", "url": "https://ubuntu.com/security/CVE-2026-46163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43legacy: enforce bounds check on firmware key index in RX path Same fix as b43: the firmware-controlled key index in b43legacy_rx() can exceed dev->max_nr_keys. The existing B43legacy_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read of dev->key[]. Make the check enforcing by dropping the frame for invalid indices.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46044", "url": "https://ubuntu.com/security/CVE-2026-46044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:ssif: Clean up kthread on errors If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43496", "url": "https://ubuntu.com/security/CVE-2026-43496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peeked When red qdisc has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] [ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq] [ 78.672148][ T363] ? __pfx__printk+0x10/0x10 [ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0 [ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0 [ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red] [ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf] [ 78.673566][ T363] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead.", "cve_priority": "medium", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2024-56727", "url": "https://ubuntu.com/security/CVE-2024-56727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c Adding error pointer check after calling otx2_mbox_get_rsp().", "cve_priority": "medium", "cve_public_date": "2024-12-29 12:15:00 UTC" }, { "cve": "CVE-2026-31489", "url": "https://ubuntu.com/security/CVE-2026-31489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: meson-spicc: Fix double-put in remove path meson_spicc_probe() registers the controller with devm_spi_register_controller(), so teardown already drops the controller reference via devm cleanup. Calling spi_controller_put() again in meson_spicc_remove() causes a double-put.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31476", "url": "https://ubuntu.com/security/CVE-2026-31476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: do not expire session on binding failure When a multichannel session binding request fails (e.g. wrong password), the error path unconditionally sets sess->state = SMB2_SESSION_EXPIRED. However, during binding, sess points to the target session looked up via ksmbd_session_lookup_slowpath() -- which belongs to another connection's user. This allows a remote attacker to invalidate any active session by simply sending a binding request with a wrong password (DoS). Fix this by skipping session expiration when the failed request was a binding attempt, since the session does not belong to the current connection. The reference taken by ksmbd_session_lookup_slowpath() is still correctly released via ksmbd_user_session_put().", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43497", "url": "https://ubuntu.com/security/CVE-2026-43497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages to userspace but sets no vm_ops on the VMA. This means the kernel cannot track active mmaps. When dlfb_realloc_framebuffer() replaces the backing buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated. On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages while userspace PTEs still reference them, resulting in a use-after-free: the process retains read/write access to freed kernel pages. Add vm_operations_struct with open/close callbacks that maintain an atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(), check mmap_count and return -EBUSY if the buffer is currently mapped, preventing buffer replacement while userspace holds stale PTEs. Tested with PoC using dummy_hcd + raw_gadget USB device emulation.", "cve_priority": "low", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46108", "url": "https://ubuntu.com/security/CVE-2026-46108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:si: Return state to normal if message allocation fails There were places where nothing would get started if a message allocation failed, so the driver needs to return to normal state.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46128", "url": "https://ubuntu.com/security/CVE-2026-46128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Check event message buffer response for bad data The event message buffer response data size got checked later when processing, but check it right after the response comes back. It appears some BMCs may return an empty message instead of an error when fetching events. There are apparently some new BMCs that make this error, so we need to compensate.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46177", "url": "https://ubuntu.com/security/CVE-2026-46177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Add limits to event and receive message requests The driver would just fetch events and receive messages until the BMC said it was done. To avoid issues with BMCs that never say they are done, add a limit of 10 fetches at a time. In addition, an si interface has an attn state it can return from the hardware which is supposed to cause a flag fetch to see if the driver needs to fetch events or message or a few other things. If the attn bit gets stuck, it's a similar problem. So allow messages in between flag fetches so the driver itself doesn't get stuck. This is a more general fix than the previous fix for the specific bad BMC, but should fix the more general issue of a BMC that won't stop saying it has data. This has been there from the beginning of the driver. It's not a bug per-se, but it is accounting for bugs in BMCs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46149", "url": "https://ubuntu.com/security/CVE-2026-46149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show() target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered. Commit 27e06650a5ea (\"scsi: target: target_core_configfs: Add length check to avoid buffer overflow\") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46101", "url": "https://ubuntu.com/security/CVE-2026-46101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: reject zero shift in nft_bitwise Reject zero shift operands for nft_bitwise left and right shift expressions during initialization. The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour. Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46099", "url": "https://ubuntu.com/security/CVE-2026-46099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels seg6_input_core() and rpl_input() call ip6_route_input() which sets a NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking dst_hold() unconditionally. On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpu_rt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence: ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1] rt_genid_bump_ipv6() -> bumps fib6_sernum [fib6_sernum from W to Z] ip6_route_output() -> ip6_pol_route() -> FIB lookup resolves fib6_nh [nhid=N] -> rt6_get_pcpu_route() pcpu_rt->sernum != fib6_sernum [W <> Z, stale] -> prev = xchg(rt6i_pcpu, NULL) -> dst_release(prev) [prev is pcpu_rt, refcount 1->0, dead] dst = skb_dst(skb) [dst is the dead pcpu_rt] dst_cache_set_ip6(dst) -> dst_hold() on dead dst -> WARN / use-after-free For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release the pcpu_rt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6_nh and its rt6i_pcpu entry. Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after ip6_route_input() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6_route_output() already returns a refcounted dst.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46033", "url": "https://ubuntu.com/security/CVE-2026-46033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject short ahash digests during instance creation authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46062", "url": "https://ubuntu.com/security/CVE-2026-46062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix integer overflow in run_unpack() volume boundary check The volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses raw addition which can wrap around for large lcn and len values, bypassing the validation. Use check_add_overflow() as is already done for the adjacent prev_lcn + dlcn and vcn64 + len checks added by commit 3ac37e100385 (\"ntfs3: Fix integer overflow in run_unpack()\"). Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46072", "url": "https://ubuntu.com/security/CVE-2026-46072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: add buffer boundary checks to run_unpack() run_unpack() checks `run_buf < run_last` at the top of the while loop but then reads size_size and offset_size bytes via run_unpack_s64() without verifying they fit within the remaining buffer. A crafted NTFS image with truncated run data in an MFT attribute triggers an OOB heap read of up to 15 bytes when the filesystem is mounted. Add boundary checks before each run_unpack_s64() call to ensure the declared field size does not exceed the remaining buffer. Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46023", "url": "https://ubuntu.com/security/CVE-2026-46023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm mirror: fix integer overflow in create_dirty_log() The argument count calculation in create_dirty_log() performs `*args_used = 2 + param_count` before validating against argc. When a user provides a param_count close to UINT_MAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent `argc < *args_used` check to be bypassed. The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array. Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46077", "url": "https://ubuntu.com/security/CVE-2026-46077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-tdes - fix DMA sync direction Before DMA output is consumed by the CPU, ->dma_addr_out must be synced with dma_sync_single_for_cpu() instead of dma_sync_single_for_device(). Using the wrong direction can return stale cache data on non-coherent platforms.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45986", "url": "https://ubuntu.com/security/CVE-2026-45986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccree - fix a memory leak in cc_mac_digest() Add cc_unmap_result() if cc_map_hash_request_final() fails to prevent potential memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46019", "url": "https://ubuntu.com/security/CVE-2026-46019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the first page using free_page(), leaking the remaining 3 pages. Use free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46015", "url": "https://ubuntu.com/security/CVE-2026-46015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: call sk_data_ready() after listener migration When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46040", "url": "https://ubuntu.com/security/CVE-2026-46040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails When fsnotify_add_inode_mark_locked() fails in inotify_new_watch(), the error path calls inotify_remove_from_idr() but does not call dec_inotify_watches() to undo the preceding inc_inotify_watches(). This leaks a watch count, and repeated failures can exhaust the max_user_watches limit with -ENOSPC even when no watches are active. Prior to commit 1cce1eea0aff (\"inotify: Convert to using per-namespace limits\"), the watch count was incremented after fsnotify_add_mark_locked() succeeded, so this path was not affected. The conversion moved inc_inotify_watches() before the mark insertion without adding the corresponding rollback. Add the missing dec_inotify_watches() call in the error path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46070", "url": "https://ubuntu.com/security/CVE-2026-46070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: validate payload size before accessing journal metadata r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block. A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets. Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46051", "url": "https://ubuntu.com/security/CVE-2026-46051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix soft lockup in retry_aligned_read() When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46046", "url": "https://ubuntu.com/security/CVE-2026-46046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all() The commit c8e008b60492 (\"ext4: ignore xattrs past end\") introduced a refcount leak in when block_csum is false. ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to get iloc.bh, but never releases it with brelse().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46285", "url": "https://ubuntu.com/security/CVE-2026-46285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: docg3: fix use-after-free in docg3_release() In docg3_release(), the docg3 pointer is obtained from cascade->floors[0]->priv before the loop that calls doc_release_device() on each floor. doc_release_device() frees the docg3 struct via kfree(docg3) at line 1881. After the loop, docg3->cascade->bch dereferences the already-freed pointer. Fix this by accessing cascade->bch directly, which is equivalent since docg3->cascade points back to the same cascade struct, and is already available as a local variable. This also removes the now-unused docg3 local variable.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46082", "url": "https://ubuntu.com/security/CVE-2026-46082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. [sean: tag for stable@]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45987", "url": "https://ubuntu.com/security/CVE-2026-45987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2 After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46024", "url": "https://ubuntu.com/security/CVE-2026-46024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply() If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for both protocol and result, this is currently not treated as an error. In case of ac->negotiating == true and ac->protocol > 0, this leads to setting ac->protocol = 0 and ac->ops = NULL. Thereafter, the check for ac->protocol != protocol returns false, and init_protocol() is not called. Subsequently, ac->ops->handle_reply() is called, which leads to a null pointer dereference, because ac->ops is still NULL. This patch changes the check for ac->protocol != protocol to !ac->protocol, as this also includes the case when the protocol was set to zero in the message. This causes the message to be treated as containing a bad auth protocol.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46037", "url": "https://ubuntu.com/security/CVE-2026-46037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: validate reply type before using icmp_pointers Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type. That value is outside the range covered by icmp_pointers[], which only describes the traditional ICMP types up to NR_ICMP_TYPES. Avoid consulting icmp_pointers[] for reply types outside that range, and use array_index_nospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46027", "url": "https://ubuntu.com/security/CVE-2026-46027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid early lgr access in smc_clc_wait_msg A CLC decline can be received while the handshake is still in an early stage, before the connection has been associated with a link group. The decline handling in smc_clc_wait_msg() updates link-group level sync state for first-contact declines, but that state only exists after link group setup has completed. Guard the link-group update accordingly and keep the per-socket peer diagnosis handling unchanged. This preserves the existing sync_err handling for established link-group contexts and avoids touching link-group state before it is available.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46053", "url": "https://ubuntu.com/security/CVE-2026-46053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: fix MR cleanup on copy error __rds_rdma_map() hands sg/pages ownership to the transport after get_mr() succeeds. If copying the generated cookie back to user space fails after that point, the error path must not free those resources again before dropping the MR reference. Remove the duplicate unpin/free from the put_user() failure branch so that MR teardown is handled only through the existing final cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46004", "url": "https://ubuntu.com/security/CVE-2026-46004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Handle probe errors properly The probe procedure of setup_card() in caiaq driver doesn't treat the error cases gracefully, e.g. the error from snd_card_register() calls snd_card_free() but continues. This would lead to a UAF for the further calls like snd_usb_caiaq_control_init(), as Berk suggested in another patch in the link below. However, the problem is not only that; in general, this function drops the all error handlings (as it's a void function) although its caller can propagate an error to snd_probe(), which eventually calls snd_card_free() as a proper error path. That said, we should treat each error case in setup_card(), and just return the error code promptly, which is then handled later as a fatal error in snd_probe(). This patch achieves it by changing the setup_card() to return an error code. Also, the superfluous snd_card_free() call is removed, too. Note that card->private_free can be set still safely at returning an error. All called functions in card_free() have checks of the unassigned resources or NULL checks.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46050", "url": "https://ubuntu.com/security/CVE-2026-46050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix deadlock with check operation and nowait requests When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b (\"raid10: cleanup memleak at raid10_make_request\") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case. This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0. Output of r10conf state of the array when we hit this condition: crash> struct r10conf \tbarrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0, Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier(): md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46049", "url": "https://ubuntu.com/security/CVE-2026-46049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Add fallback to default RSR for S/PDIF spdif_passthru_playback_get_resources() uses atc->pll_rate as the RSR for the MSR calculation loop. However, pll_rate is only updated in atc_pll_init() and not in hw_pll_init(), so it remains 0 after the card init. When spdif_passthru_playback_setup() skips atc_pll_init() for 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin indefinitely. Add fallback to use atc->rsr when atc->pll_rate is 0. This reflects the hardware state, since hw_card_init() already configures the PLL to the default RSR.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46002", "url": "https://ubuntu.com/security/CVE-2026-46002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext2: reject inodes with zero i_nlink and valid mode in ext2_iget() ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is zero or i_dtime is set, treating them as deleted. However, the case of i_nlink == 0 with a non-zero mode and zero dtime slips through. Since ext2 has no orphan list, such a combination can only result from filesystem corruption - a legitimate inode deletion always sets either i_dtime or clears i_mode before freeing the inode. A crafted image can exploit this gap to present such an inode to the VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via ext2_unlink(), ext2_rename() and ext2_rmdir(): WARNING: CPU: 3 PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295 vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477 do_unlinkat+0x53e/0x730 fs/namei.c:4541 __x64_sys_unlink+0xc6/0x110 fs/namei.c:4587 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 646 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rename+0x35e/0x850 fs/ext2/namei.c:374 vfs_rename+0xf2f/0x2060 fs/namei.c:5021 do_renameat2+0xbe2/0xd50 fs/namei.c:5178 __x64_sys_rename+0x7e/0xa0 fs/namei.c:5223 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 634 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311 vfs_rmdir+0x204/0x690 fs/namei.c:4348 do_rmdir+0x372/0x3e0 fs/namei.c:4407 __x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Extend the existing i_nlink == 0 check to also catch this case, reporting the corruption via ext2_error() and returning -EFSCORRUPTED. This rejects the inode at load time and prevents it from reaching any of the namei.c paths. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46047", "url": "https://ubuntu.com/security/CVE-2026-46047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Fix use-after-free in driver remove() In the remove callback, if a packet arrives after destroy_workqueue() is called, but before sock_release(), the qrtr_ns_data_ready() callback will try to queue the work, causing use-after-free issue. Fix this issue by saving the default 'sk_data_ready' callback during qrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback at the start of remove(). This ensures that even if a packet arrives after destroy_workqueue(), the work struct will not be dereferenced. Note that it is also required to ensure that the RX threads are completed before destroying the workqueue, because the threads could be using the qrtr_ns_data_ready() callback.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46009", "url": "https://ubuntu.com/security/CVE-2026-46009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to do later. This leads to an oops when .allow_link fails or when .drop_link is performed. Remove the helper. Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46102", "url": "https://ubuntu.com/security/CVE-2026-46102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: strparser: fix skb_head leak in strp_abort_strp() When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46098", "url": "https://ubuntu.com/security/CVE-2026-46098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: caif: clear client service pointer on teardown `caif_connect()` can tear down an existing client after remote shutdown by calling `caif_disconnect_client()` followed by `caif_free_client()`. `caif_free_client()` releases the service layer referenced by `adap_layer->dn`, but leaves that pointer stale. When the socket is later destroyed, `caif_sock_destructor()` calls `caif_free_client()` again and dereferences the freed service pointer. Clear the client/service links before releasing the service object so repeated teardown becomes harmless.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46088", "url": "https://ubuntu.com/security/CVE-2026-46088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names() snd_ctl_elem_init_enum_names() advances pointer p through the names buffer while decrementing buf_len. If buf_len reaches zero but items remain, the next iteration calls strnlen(p, 0). While strnlen(p, 0) returns 0 and would hit the existing name_len == 0 error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks maxlen against __builtin_dynamic_object_size(). When Clang loses track of p's object size inside the loop, this triggers a BRK exception panic before the return value is examined. Add a buf_len == 0 guard at the loop entry to prevent calling fortified strnlen() on an exhausted buffer. Found by kernel fuzz testing through Xiaomi Smartphone.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46080", "url": "https://ubuntu.com/security/CVE-2026-46080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: split transactions in dio completion to avoid credit exhaustion During ocfs2 dio operations, JBD2 may report warnings via following call trace: ocfs2_dio_end_io_write ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_split_extent ocfs2_try_to_merge_extent ocfs2_extend_rotate_transaction ocfs2_extend_trans jbd2__journal_restart start_this_handle output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449 To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to handle extents in a batch of transaction. Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode should only be removed from the orphan list after the extent tree update is complete. This ensures that if a crash occurs in the middle of extent tree updates, we won't leave stale blocks beyond EOF. This patch also changes the logic for updating the inode size and removing orphan, making it similar to ext4_dio_write_end_io(). Both operations are performed only when everything looks good. Finally, thanks to Jans and Joseph for providing the bug fix prototype and suggestions.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-21739", "url": "https://ubuntu.com/security/CVE-2025-21739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix use-after free in init error and remove paths devm_blk_crypto_profile_init() registers a cleanup handler to run when the associated (platform-) device is being released. For UFS, the crypto private data and pointers are stored as part of the ufs_hba's data structure 'struct ufs_hba::crypto_profile'. This structure is allocated as part of the underlying ufshcd and therefore Scsi_host allocation. During driver release or during error handling in ufshcd_pltfrm_init(), this structure is released as part of ufshcd_dealloc_host() before the (platform-) device associated with the crypto call above is released. Once this device is released, the crypto cleanup code will run, using the just-released 'struct ufs_hba::crypto_profile'. This causes a use-after-free situation: Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0 In other words, the initialisation code flow is: platform-device probe ufshcd_pltfrm_init() ufshcd_alloc_host() scsi_host_alloc() allocation of struct ufs_hba creation of scsi-host devices devm_blk_crypto_profile_init() devm registration of cleanup handler using platform-device and during error handling of ufshcd_pltfrm_init() or during driver removal: ufshcd_dealloc_host() scsi_host_put() put_device(scsi-host) release of struct ufs_hba put_device(platform-device) crypto cleanup handler To fix this use-after free, change ufshcd_alloc_host() to register a devres action to automatically cleanup the underlying SCSI device on ufshcd destruction, without requiring explicit calls to ufshcd_dealloc_host(). This way: * the crypto profile and all other ufs_hba-owned resources are destroyed before SCSI (as they've been registered after) * a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as it's not needed anymore * no future drivers using ufshcd_alloc_host() could ever forget adding the cleanup", "cve_priority": "low", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2026-46064", "url": "https://ubuntu.com/security/CVE-2026-46064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix heap over-read in ibmasm_send_i2o_message() The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO. Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure. Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controller's free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it. Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45994", "url": "https://ubuntu.com/security/CVE-2026-45994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix OOB reads in command_file_write due to missing size checks The command_file_write() handler allocates a kernel buffer of exactly count bytes and copies user data into it, but does not validate the buffer against the dot command protocol before passing it to get_dot_command_size() and get_dot_command_timeout(). Since both the allocation size (count) and the header fields (command_size, data_size) are independently user-controlled, an attacker can cause get_dot_command_size() to return a value exceeding the allocation, triggering OOB reads in get_dot_command_timeout() and an out-of-bounds memcpy_toio() that leaks kernel heap memory to the service processor. Fix with two guards: reject writes smaller than sizeof(struct dot_command_header) before allocation, then after copying user data reject commands where the buffer is smaller than the total size declared by the header (sizeof(header) + command_size + data_size). This ensures all subsequent header and payload field accesses stay within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46022", "url": "https://ubuntu.com/security/CVE-2026-46022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt() ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60). A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started. The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes: queue_begin + reader * sizeof(struct remote_input) with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception. Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46006", "url": "https://ubuntu.com/security/CVE-2026-46006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix u32 overflow in pushbuf reloc bounds check nouveau_gem_pushbuf_reloc_apply() validates each relocation with if (r->reloc_bo_offset + 4 > nvbo->bo.base.size) but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size. Cast to u64 so the addition happens in 64-bit arithmetic. [ Add Fixes: tag. - Danilo ]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46018", "url": "https://ubuntu.com/security/CVE-2026-46018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES parse_uac2_sample_rate_range() caps the number of enumerated rates at MAX_NR_RATES, but it only breaks out of the current rate loop. A malformed UAC2 RANGE response with additional triplets continues parsing the remaining triplets and repeatedly prints \"invalid uac2 rates\" while probe still holds register_mutex. Stop the whole parse once the cap is reached and return the number of rates collected so far.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-31696", "url": "https://ubuntu.com/security/CVE-2026-31696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing validation of ticket length in non-XDR key preparsing In rxrpc_preparse(), there are two paths for parsing key payloads: the XDR path (for large payloads) and the non-XDR path (for payloads <= 28 bytes). While the XDR path (rxrpc_preparse_xdr_rxkad()) correctly validates the ticket length against AFSTOKEN_RK_TIX_MAX, the non-XDR path fails to do so. This allows an unprivileged user to provide a very large ticket length. When this key is later read via rxrpc_read(), the total token size (toksize) calculation results in a value that exceeds AFSTOKEN_LENGTH_MAX, triggering a WARN_ON(). [ 2001.302904] WARNING: CPU: 2 PID: 2108 at net/rxrpc/key.c:778 rxrpc_read+0x109/0x5c0 [rxrpc] Fix this by adding a check in the non-XDR parsing path of rxrpc_preparse() to ensure the ticket length does not exceed AFSTOKEN_RK_TIX_MAX, bringing it into parity with the XDR parsing logic.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31697", "url": "https://ubuntu.com/security/CVE-2026-31697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388 CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31698", "url": "https://ubuntu.com/security/CVE-2026-31698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033 CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31699", "url": "https://ubuntu.com/security/CVE-2026-31699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405 CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31701", "url": "https://ubuntu.com/security/CVE-2026-31701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: take a reference on the USB device in create_card() The caiaq driver stores a pointer to the parent USB device in cdev->chip.dev but never takes a reference on it. The card's private_free callback, snd_usb_caiaq_card_free(), can run asynchronously via snd_card_free_when_closed() after the USB device has already been disconnected and freed, so any access to cdev->chip.dev in that path dereferences a freed usb_device. On top of the refcounting issue, the current card_free implementation calls usb_reset_device(cdev->chip.dev). A reset in a free callback is inappropriate: the device is going away, the call takes the device lock in a teardown context, and the reset races with the disconnect path that the callback is already cleaning up after. Take a reference on the USB device in create_card() with usb_get_dev(), drop it with usb_put_dev() in the free callback, and remove the usb_reset_device() call.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31694", "url": "https://ubuntu.com/security/CVE-2026-31694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject oversized dirents in page cache fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31716", "url": "https://ubuntu.com/security/CVE-2026-31716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate rec->used in journal-replay file record check check_file_record() validates rec->total against the record size but never validates rec->used. The do_action() journal-replay handlers read rec->used from disk and use it to compute memmove lengths: DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next)) When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall. This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay Fix this up by bounding rec->used correctly. This is much like commit b2bc7c44ed17 (\"fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\") which checked different values in this same switch statement.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31676", "url": "https://ubuntu.com/security/CVE-2026-31676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31409", "url": "https://ubuntu.com/security/CVE-2026-31409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: unset conn->binding on failed binding request When a multichannel SMB2_SESSION_SETUP request with SMB2_SESSION_REQ_FLAG_BINDING fails ksmbd sets conn->binding = true but never clears it on the error path. This leaves the connection in a binding state where all subsequent ksmbd_session_lookup_all() calls fall back to the global sessions table. This fix it by clearing conn->binding = false in the error path.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2023-53596", "url": "https://ubuntu.com/security/CVE-2023-53596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: base: Free devm resources when unregistering a device In the current code, devres_release_all() only gets called if the device has a bus and has been probed. This leads to issues when using bus-less or driver-less devices where the device might never get freed if a managed resource holds a reference to the device. This is happening in the DRM framework for example. We should thus call devres_release_all() in the device_del() function to make sure that the device-managed actions are properly executed when the device is unregistered, even if it has neither a bus nor a driver. This is effectively the same change than commit 2f8d16a996da (\"devres: release resources on device_del()\") that got reverted by commit a525a3ddeaca (\"driver core: free devres in device_release\") over memory leaks concerns. This patch effectively combines the two commits mentioned above to release the resources both on device_del() and device_release() and get the best of both worlds.", "cve_priority": "low", "cve_public_date": "2025-10-04 16:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2025-38192", "url": "https://ubuntu.com/security/CVE-2025-38192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: clear the dst when changing skb protocol A not-so-careful NAT46 BPF program can crash the kernel if it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10) The output interface has a 4->6 program attached at ingress. We try to loop the multicast skb back to the sending socket. Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr and changes skb->protocol to v6. We enter ip6_rcv_core which tries to use skb_dst(). But the dst is still an IPv4 one left after IPv4 mcast output. Clear the dst in all BPF helpers which change the protocol. Try to preserve metadata dsts, those may carry non-routing metadata.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-21712", "url": "https://ubuntu.com/security/CVE-2025-21712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime After commit ec6bb299c7c3 (\"md/md-bitmap: add 'sync_size' into struct md_bitmap_stats\"), following panic is reported: Oops: general protection fault, probably for non-canonical address RIP: 0010:bitmap_get_stats+0x2b/0xa0 Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Root cause is that bitmap_get_stats() can be called at anytime if mddev is still there, even if bitmap is destroyed, or not fully initialized. Deferenceing bitmap in this case can crash the kernel. Meanwhile, the above commit start to deferencing bitmap->storage, make the problem easier to trigger. Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2026-43328", "url": "https://ubuntu.com/security/CVE-2026-43328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error path When kobject_init_and_add() fails, cpufreq_dbs_governor_init() calls kobject_put(&dbs_data->attr_set.kobj). The kobject release callback cpufreq_dbs_data_release() calls gov->exit(dbs_data) and kfree(dbs_data), but the current error path then calls gov->exit(dbs_data) and kfree(dbs_data) again, causing a double free. Keep the direct kfree(dbs_data) for the gov->init() failure path, but after kobject_init_and_add() has been called, let kobject_put() handle the cleanup through cpufreq_dbs_data_release().", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-23066", "url": "https://ubuntu.com/security/CVE-2026-23066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recvmsg() unconditional requeue If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at the front of the recvmsg queue already has its mutex locked, it requeues the call - whether or not the call is already queued. The call may be on the queue because MSG_PEEK was also passed and so the call was not dequeued or because the I/O thread requeued it. The unconditional requeue may then corrupt the recvmsg queue, leading to things like UAFs or refcount underruns. Fix this by only requeuing the call if it isn't already on the queue - and moving it to the front if it is already queued. If we don't queue it, we have to put the ref we obtained by dequeuing it. Also, MSG_PEEK doesn't dequeue the call so shouldn't call rxrpc_notify_socket() for the call if we didn't use up all the data on the queue, so fix that also.", "cve_priority": "high", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-27407", "url": "https://ubuntu.com/security/CVE-2024-27407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fixed overflow check in mi_enum_attr()", "cve_priority": "high", "cve_public_date": "2024-05-17 12:15:00 UTC" }, { "cve": "CVE-2023-45896", "url": "https://ubuntu.com/security/CVE-2023-45896", "cve_description": "ntfs3 in the Linux kernel through 6.8.0 allows a physically proximate attacker to read kernel memory by mounting a filesystem (e.g., if a Linux distribution is configured to allow unprivileged mounts of removable media) and then leveraging local access to trigger an out-of-bounds read. A length value can be larger than the amount of memory allocated. NOTE: the supplier's perspective is that there is no vulnerability when an attack requires an attacker-modified filesystem image.", "cve_priority": "medium", "cve_public_date": "2024-08-28 05:15:00 UTC" }, { "cve": "CVE-2023-52737", "url": "https://ubuntu.com/security/CVE-2023-52737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: lock the inode in shared mode before starting fiemap Currently fiemap does not take the inode's lock (VFS lock), it only locks a file range in the inode's io tree. This however can lead to a deadlock if we have a concurrent fsync on the file and fiemap code triggers a fault when accessing the user space buffer with fiemap_fill_next_extent(). The deadlock happens on the inode's i_mmap_lock semaphore, which is taken both by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by syzbot and triggers a trace like the following: task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 wait_on_state fs/btrfs/extent-io-tree.c:707 [inline] wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751 lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742 find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488 writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863 __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174 extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091 extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211 do_writepages+0x3c3/0x680 mm/page-writeback.c:2581 filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388 __filemap_fdatawrite_range mm/filemap.c:421 [inline] filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439 btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline] start_ordered_ops fs/btrfs/file.c:1737 [inline] btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839 generic_write_sync include/linux/fs.h:2885 [inline] btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684 call_write_iter include/linux/fs.h:2189 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9 RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006 RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8 INFO: task syz-executor361:5697 blocked for more than 145 seconds. Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095 __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260 btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526 do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947 wp_page_shared+0x15e/0x380 mm/memory.c:3295 handle_pte_fault mm/memory.c:4949 [inline] __handle_mm_fault mm/memory.c:5073 [inline] handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219 do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428 handle_page_fault arch/x86/mm/fault.c:1519 [inline] exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233 Code: 74 0a 89 (...) RSP: 0018:ffffc9000570f330 EFLAGS: 000502 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-05-21 16:15:00 UTC" }, { "cve": "CVE-2025-38626", "url": "https://ubuntu.com/security/CVE-2025-38626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode w/ \"mode=lfs\" mount option, generic/299 will cause system panic as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2835! Call Trace: f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720 The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may trigger foreground gc only if it allocates any physical block, it will be a little bit later when there is multiple threads writing data w/ aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so f2fs_map_blocks() does block allocations aggressively. In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_blocks().", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2024-46770", "url": "https://ubuntu.com/security/CVE-2024-46770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Add netif_device_attach/detach into PF reset flow Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. getting coalesce settings can result in a NULL pointer dereference seen below. Reproduction steps: Once the driver is fully initialized, trigger reset: \t# echo 1 > /sys/class/net//device/reset when reset is in progress try to get coalesce settings using ethtool: \t# ethtool -c BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7 RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice] RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206 RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000 R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40 FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0 Call Trace: ice_get_coalesce+0x17/0x30 [ice] coalesce_prepare_data+0x61/0x80 ethnl_default_doit+0xde/0x340 genl_family_rcv_msg_doit+0xf2/0x150 genl_rcv_msg+0x1b3/0x2c0 netlink_rcv_skb+0x5b/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x19c/0x290 netlink_sendmsg+0x222/0x490 __sys_sendto+0x1df/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7faee60d8e27 Calling netif_device_detach() before reset makes the net core not call the driver when ethtool command is issued, the attempt to execute an ethtool command during reset will result in the following message: netlink error: No such device instead of NULL pointer dereference. Once reset is done and ice_rebuild() is executing, the netif_device_attach() is called to allow for ethtool operations to occur again in a safe manner.", "cve_priority": "medium", "cve_public_date": "2024-09-18 08:15:00 UTC" }, { "cve": "CVE-2025-38105", "url": "https://ubuntu.com/security/CVE-2025-38105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Kill timer properly at removal The USB-audio MIDI code initializes the timer, but in a rare case, the driver might be freed without the disconnect call. This leaves the timer in an active state while the assigned object is released via snd_usbmidi_free(), which ends up with a kernel warning when the debug configuration is enabled, as spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be killed properly. While we're at it, replace the existing timer_delete_sync() at the disconnect callback with timer_shutdown_sync(), too.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2024-27389", "url": "https://ubuntu.com/security/CVE-2024-27389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore: inode: Only d_invalidate() is needed Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning: WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410 Using the combo of d_drop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use d_invalidate() and update the code to not bother checking for error codes that can never happen. ---", "cve_priority": "medium", "cve_public_date": "2024-05-01 13:15:00 UTC" }, { "cve": "CVE-2023-52682", "url": "https://ubuntu.com/security/CVE-2023-52682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait on block writeback for post_read case If inode is compressed, but not encrypted, it missed to call f2fs_wait_on_block_writeback() to wait for GCed page writeback in IPU write path. Thread A\t\t\t\tGC-Thread \t\t\t\t\t- f2fs_gc \t\t\t\t\t - do_garbage_collect \t\t\t\t\t - gc_data_segment \t\t\t\t\t - move_data_block \t\t\t\t\t - f2fs_submit_page_write \t\t\t\t\t migrate normal cluster's block via \t\t\t\t\t meta_inode's page cache - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_submit_page_bio IRQ - f2fs_read_end_io \t\t\t\t\tIRQ \t\t\t\t\told data overrides new data due to \t\t\t\t\tout-of-order GC and common IO. \t\t\t\t\t- f2fs_read_end_io", "cve_priority": "medium", "cve_public_date": "2024-05-17 15:15:00 UTC" }, { "cve": "CVE-2024-56719", "url": "https://ubuntu.com/security/CVE-2024-56719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix TSO DMA API usage causing oops Commit 66600fac7a98 (\"net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data\") moved the assignment of tx_skbuff_dma[]'s members to be later in stmmac_tso_xmit(). The buf (dma cookie) and len stored in this structure are passed to dma_unmap_single() by stmmac_tx_clean(). The DMA API requires that the dma cookie passed to dma_unmap_single() is the same as the value returned from dma_map_single(). However, by moving the assignment later, this is not the case when priv->dma_cap.addr64 > 32 as \"des\" is offset by proto_hdr_len. This causes problems such as: dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed and with DMA_API_DEBUG enabled: DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes] Fix this by maintaining \"des\" as the original DMA cookie, and use tso_des to pass the offset DMA cookie to stmmac_tso_allocator(). Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/", "cve_priority": "medium", "cve_public_date": "2024-12-29 09:15:00 UTC" }, { "cve": "CVE-2024-41079", "url": "https://ubuntu.com/security/CVE-2024-41079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: always initialize cqe.result The spec doesn't mandate that the first two double words (aka results) for the command queue entry need to be set to 0 when they are not used (not specified). Though, the target implemention returns 0 for TCP and FC but not for RDMA. Let's make RDMA behave the same and thus explicitly initializing the result field. This prevents leaking any data from the stack.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2023-53545", "url": "https://ubuntu.com/security/CVE-2023-53545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: unmap and remove csa_va properly Root PD BO should be reserved before unmap and remove a bo_va from VM otherwise lockdep will complain. v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian) [14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu] [14616.937096] Call Trace: [14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu] [14616.937187] drm_file_free+0x1d6/0x300 [drm] [14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm] [14616.937220] drm_release+0x5e/0x100 [drm] [14616.937234] __fput+0x9f/0x280 [14616.937239] ____fput+0xe/0x20 [14616.937241] task_work_run+0x61/0x90 [14616.937246] exit_to_user_mode_prepare+0x215/0x220 [14616.937251] syscall_exit_to_user_mode+0x2a/0x60 [14616.937254] do_syscall_64+0x48/0x90 [14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd", "cve_priority": "medium", "cve_public_date": "2025-10-04 16:15:00 UTC" }, { "cve": "CVE-2025-68239", "url": "https://ubuntu.com/security/CVE-2025-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: restore write access before closing files opened by open_exec() bm_register_write() opens an executable file using open_exec(), which internally calls do_open_execat() and denies write access on the file to avoid modification while it is being executed. However, when an error occurs, bm_register_write() closes the file using filp_close() directly. This does not restore the write permission, which may cause subsequent write operations on the same file to fail. Fix this by calling exe_file_allow_write_access() before filp_close() to restore the write permission properly.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-38659", "url": "https://ubuntu.com/security/CVE-2025-38659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: No more self recovery When a node withdraws and it turns out that it is the only node that has the filesystem mounted, gfs2 currently tries to replay the local journal to bring the filesystem back into a consistent state. Not only is that a very bad idea, it has also never worked because gfs2_recover_func() will refuse to do anything during a withdraw. However, before even getting to this point, gfs2_recover_func() dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free before commit 04133b607a78 (\"gfs2: Prevent double iput for journal on error\") and is a NULL pointer dereference since then. Simply get rid of self recovery to fix that.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2022-49961", "url": "https://ubuntu.com/security/CVE-2022-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg->precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored state. To show a concrete example of the problem: 0000000000000000 : 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 10: r2 = -1 0000000000000058 : 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit 00000000000000b8 : 23: w0 = 0 24: exit For the first case, the single line execution's exploration will prune the search at insn 14 for the branch insn 9's second leg as it will be verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will always be 0 so at runtime we don't get error for being greater than UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just sees reg->precise as false for both r2 registers in both states, hence considers them equal for purposes of states_equal. If we propagated precise markers using the backtracking support, we would use the precise marking to then ensure that old r2 (UINT_MAX) was within the new r2 (1) and this would never be true, so the verification would rightfully fail. The end result is that the out of bounds access at instruction 19 would be permitted without this fix. Note that reg->precise is always set to true when user does not have CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static or global functions)), hence this is only a problem when precision marks need to be explicitly propagated (i.e. privileged users with CAP_BPF). A simplified test case has been included in the next patch to prevent future regressions.", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2024-47809", "url": "https://ubuntu.com/security/CVE-2024-47809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix possible lkb_resource null dereference This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded. The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference. In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.", "cve_priority": "medium", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2025-38250", "url": "https://ubuntu.com/security/CVE-2025-38250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix use-after-free in vhci_flush() syzbot reported use-after-free in vhci_flush() without repro. [0] From the splat, a thread close()d a vhci file descriptor while its device was being used by iotcl() on another thread. Once the last fd refcnt is released, vhci_release() calls hci_unregister_dev(), hci_free_dev(), and kfree() for struct vhci_data, which is set to hci_dev->dev->driver_data. The problem is that there is no synchronisation after unlinking hdev from hci_dev_list in hci_unregister_dev(). There might be another thread still accessing the hdev which was fetched before the unlink operation. We can use SRCU for such synchronisation. Let's run hci_dev_reset() under SRCU and wait for its completion in hci_unregister_dev(). Another option would be to restore hci_dev->destruct(), which was removed in commit 587ae086f6e4 (\"Bluetooth: Remove unused hci-destruct cb\"). However, this would not be a good solution, as we should not run hci_unregister_dev() while there are in-flight ioctl() requests, which could lead to another data-race KCSAN splat. Note that other drivers seem to have the same problem, for exmaple, virtbt_remove(). [0]: BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718 CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name ---truncated---", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2026-43281", "url": "https://ubuntu.com/security/CVE-2026-43281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate() Although it is guided that `#mbox-cells` must be at least 1, there are many instances of `#mbox-cells = <0>;` in the device tree. If that is the case and the corresponding mailbox controller does not provide `fw_xlate` and of_xlate` function pointers, `fw_mbox_index_xlate()` will be used by default and out-of-bounds accesses could occur due to lack of bounds check in that function.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23157", "url": "https://ubuntu.com/security/CVE-2026-23157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not strictly require dirty metadata threshold for metadata writepages [BUG] There is an internal report that over 1000 processes are waiting at the io_schedule_timeout() of balance_dirty_pages(), causing a system hang and trigger a kernel coredump. The kernel is v6.4 kernel based, but the root problem still applies to any upstream kernel before v6.18. [CAUSE] From Jan Kara for his wisdom on the dirty page balance behavior first. This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB. Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there's dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying. When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit. So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in that cgroup. So that means the only way to reduce the dirty pages of that cgroup is to writeback the dirty pages of btrfs btree inode, and only after that those processes can exit balance_dirty_pages(). Now back to the btrfs part, btree_writepages() is responsible for writing back dirty btree inode pages. The problem here is, there is a btrfs internal threshold that if the btree inode's dirty bytes are below the 32M threshold, it will not do any writeback. This behavior is to batch as much metadata as possible so we won't write back those tree blocks and then later re-COW them again for another modification. This internal 32MiB is higher than the existing dirty page size (28MiB), meaning no writeback will happen, causing a deadlock between btrfs and cgroup: - Btrfs doesn't want to write back btree inode until more dirty pages - Cgroup/MM doesn't want more dirty pages for btrfs btree inode Thus any process touching that btree inode is put into sleep until the number of dirty pages is reduced. Thanks Jan Kara a lot for the analysis of the root cause. [ENHANCEMENT] Since kernel commit b55102826d7d (\"btrfs: set AS_KERNEL_FILE on the btree_inode\"), btrfs btree inode pages will only be charged to the root cgroup which should have a much larger limit than btrfs' 32MiB threshold. So it should not affect newer kernels. But for all current LTS kernels, they are all affected by this problem, and backporting the whole AS_KERNEL_FILE may not be a good idea. Even for newer kernels I still think it's a good idea to get rid of the internal threshold at btree_writepages(), since for most cases cgroup/MM has a better view of full system memory usage than btrfs' fixed threshold. For internal callers using btrfs_btree_balance_dirty() since that function is already doing internal threshold check, we don't need to bother them. But for external callers of btree_writepages(), just respect their requests and write back whatever they want, ignoring the internal btrfs threshold to avoid such deadlock on btree inode dirty page balancing.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23141", "url": "https://ubuntu.com/security/CVE-2026-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: check for inline extents in range_is_hole_in_parent() Before accessing the disk_bytenr field of a file extent item we need to check if we are dealing with an inline extent. This is because for inline extents their data starts at the offset of the disk_bytenr field. So accessing the disk_bytenr means we are accessing inline data or in case the inline data is less than 8 bytes we can actually cause an invalid memory access if this inline extent item is the first item in the leaf or access metadata from other items.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-40005", "url": "https://ubuntu.com/security/CVE-2025-40005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: Implement refcount to handle unbind during busy driver support indirect read and indirect write operation with assumption no force device removal(unbind) operation. However force device removal(removal) is still available to root superuser. Unbinding driver during operation causes kernel crash. This changes ensure driver able to handle such operation for indirect read and indirect write by implementing refcount to track attached devices to the controller and gracefully wait and until attached devices remove operation completed before proceed with removal operation.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2023-53629", "url": "https://ubuntu.com/security/CVE-2023-53629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: dlm: fix use after free in midcomms commit While working on processing dlm message in softirq context I experienced the following KASAN use-after-free warning: [ 151.760477] ================================================================== [ 151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347 [ 151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828 [ 151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014 [ 151.768726] Call Trace: [ 151.769277] [ 151.769748] dump_stack_lvl+0x5b/0x86 [ 151.770556] print_report+0x180/0x4c8 [ 151.771378] ? kasan_complete_mode_report_info+0x7c/0x1e0 [ 151.772241] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.773069] kasan_report+0x93/0x1a0 [ 151.773668] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.774514] __asan_load4+0x7e/0xa0 [ 151.775089] dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.775890] ? create_message.isra.29.constprop.64+0x57/0xc0 [ 151.776770] send_common+0x19f/0x1b0 [ 151.777342] ? remove_from_waiters+0x60/0x60 [ 151.778017] ? lock_downgrade+0x410/0x410 [ 151.778648] ? __this_cpu_preempt_check+0x13/0x20 [ 151.779421] ? rcu_lockdep_current_cpu_online+0x88/0xc0 [ 151.780292] _convert_lock+0x46/0x150 [ 151.780893] convert_lock+0x7b/0xc0 [ 151.781459] dlm_lock+0x3ac/0x580 [ 151.781993] ? 0xffffffffc0540000 [ 151.782522] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.783379] ? dlm_scan_rsbs+0xa70/0xa70 [ 151.784003] ? preempt_count_sub+0xd6/0x130 [ 151.784661] ? is_module_address+0x47/0x70 [ 151.785309] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.786166] ? 0xffffffffc0540000 [ 151.786693] ? lockdep_init_map_type+0xc3/0x360 [ 151.787414] ? 0xffffffffc0540000 [ 151.787947] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.789004] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.789858] ? 0xffffffffc0540000 [ 151.790392] ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture] [ 151.791347] ? delay_tsc+0x94/0xc0 [ 151.791898] torture_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.792735] ? torture_start+0x30/0x30 [dlm_locktorture] [ 151.793606] lock_torture+0x177/0x270 [dlm_locktorture] [ 151.794448] ? torture_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture] [ 151.795539] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.796476] ? do_raw_spin_lock+0x11e/0x1e0 [ 151.797152] ? mark_held_locks+0x34/0xb0 [ 151.797784] ? _raw_spin_unlock_irqrestore+0x30/0x70 [ 151.798581] ? __kthread_parkme+0x79/0x110 [ 151.799246] ? trace_preempt_on+0x2a/0xf0 [ 151.799902] ? __kthread_parkme+0x79/0x110 [ 151.800579] ? preempt_count_sub+0xd6/0x130 [ 151.801271] ? __kasan_check_read+0x11/0x20 [ 151.801963] ? __kthread_parkme+0xec/0x110 [ 151.802630] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.803569] kthread+0x192/0x1d0 [ 151.804104] ? kthread_complete_and_exit+0x30/0x30 [ 151.804881] ret_from_fork+0x1f/0x30 [ 151.805480] [ 151.806111] Allocated by task 1347: [ 151.806681] kasan_save_stack+0x26/0x50 [ 151.807308] kasan_set_track+0x25/0x30 [ 151.807920] kasan_save_alloc_info+0x1e/0x30 [ 151.808609] __kasan_slab_alloc+0x63/0x80 [ 151.809263] kmem_cache_alloc+0x1ad/0x830 [ 151.809916] dlm_allocate_mhandle+0x17/0x20 [ 151.810590] dlm_midcomms_get_mhandle+0x96/0x260 [ 151.811344] _create_message+0x95/0x180 [ 151.811994] create_message.isra.29.constprop.64+0x57/0xc0 [ 151.812880] send_common+0x129/0x1b0 [ 151.813467] _convert_lock+0x46/0x150 [ 151.814074] convert_lock+0x7b/0xc0 [ 151.814648] dlm_lock+0x3ac/0x580 [ 151.815199] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.816258] torture_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.817129] lock_t ---truncated---", "cve_priority": "high", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2025-71221", "url": "https://ubuntu.com/security/CVE-2025-71221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue() Add proper locking in mmp_pdma_residue() to prevent use-after-free when accessing descriptor list and descriptor contents. The race occurs when multiple threads call tx_status() while the tasklet on another CPU is freeing completed descriptors: CPU 0 CPU 1 ----- ----- mmp_pdma_tx_status() mmp_pdma_residue() -> NO LOCK held list_for_each_entry(sw, ..) DMA interrupt dma_do_tasklet() -> spin_lock(&desc_lock) list_move(sw->node, ...) spin_unlock(&desc_lock) | dma_pool_free(sw) <- FREED! -> access sw->desc <- UAF! This issue can be reproduced when running dmatest on the same channel with multiple threads (threads_per_chan > 1). Fix by protecting the chain_running list iteration and descriptor access with the chan->desc_lock spinlock.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23204", "url": "https://ubuntu.com/security/CVE-2026-23204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: use skb_header_pointer_careful() skb_header_pointer() does not fully validate negative @offset values. Use skb_header_pointer_careful() instead. GangMin Kim provided a report and a repro fooling u32_classify(): BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0 net/sched/cls_u32.c:221", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-71161", "url": "https://ubuntu.com/security/CVE-2025-71161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: disable recursive forward error correction There are two problems with the recursive correction: 1. It may cause denial-of-service. In fec_read_bufs, there is a loop that has 253 iterations. For each iteration, we may call verity_hash_for_block recursively. There is a limit of 4 nested recursions - that means that there may be at most 253^4 (4 billion) iterations. Red Hat QE team actually created an image that pushes dm-verity to this limit - and this image just makes the udev-worker process get stuck in the 'D' state. 2. It doesn't work. In fec_read_bufs we store data into the variable \"fio->bufs\", but fio bufs is shared between recursive invocations, if \"verity_hash_for_block\" invoked correction recursively, it would overwrite partially filled fio->bufs.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2022-50552", "url": "https://ubuntu.com/security/CVE-2022-50552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: use quiesced elevator switch when reinitializing queues The hctx's run_work may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally. nvme nvme0: resetting controller nvme nvme0: 32/0/0 default/read/poll queues BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:kyber_has_work+0x29/0x70 ... Call Trace: __blk_mq_do_dispatch_sched+0x83/0x2b0 __blk_mq_sched_dispatch_requests+0x12e/0x170 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x2b/0x50 process_one_work+0x1ef/0x380 worker_thread+0x2d/0x3e0", "cve_priority": "low", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2024-36922", "url": "https://ubuntu.com/security/CVE-2024-36922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: read txq->read_ptr under lock If we read txq->read_ptr without lock, we can read the same value twice, then obtain the lock, and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in the WARN_ONCE() a little later. Fix that by reading txq->read_ptr under lock.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2024-53221", "url": "https://ubuntu.com/security/CVE-2024-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix null-ptr-deref in f2fs_submit_page_bio() There's issue as follows when concurrently installing the f2fs.ko module and mounting the f2fs file system: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs] Call Trace: f2fs_submit_page_bio+0x126/0x8b0 [f2fs] __get_meta_page+0x1d4/0x920 [f2fs] get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs] validate_checkpoint+0xac/0x290 [f2fs] f2fs_get_valid_checkpoint+0x207/0x950 [f2fs] f2fs_fill_super+0x1007/0x39b0 [f2fs] mount_bdev+0x183/0x250 legacy_get_tree+0xf4/0x1e0 vfs_get_tree+0x88/0x340 do_new_mount+0x283/0x5e0 path_mount+0x2b2/0x15b0 __x64_sys_mount+0x1fe/0x270 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Above issue happens as the biset of the f2fs file system is not initialized before register \"f2fs_fs_type\". To address above issue just register \"f2fs_fs_type\" at the last in init_f2fs_fs(). Ensure that all f2fs file system resources are initialized.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-56657", "url": "https://ubuntu.com/security/CVE-2024-56657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Avoid WARN() for symlink errors Using WARN() for showing the error of symlink creations don't give more information than telling that something goes wrong, since the usual code path is a lregister callback from each control element creation. More badly, the use of WARN() rather confuses fuzzer as if it were serious issues. This patch downgrades the warning messages to use the normal dev_err() instead of WARN(). For making it clearer, add the function name to the prefix, too.", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2022-49803", "url": "https://ubuntu.com/security/CVE-2022-49803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Fix memory leak of nsim_dev->fa_cookie kmemleak reports this issue: unreferenced object 0xffff8881bac872d0 (size 8): comm \"sh\", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie .. nsim_drv_remove() The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To fix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove().", "cve_priority": "medium", "cve_public_date": "2025-05-01 15:16:00 UTC" }, { "cve": "CVE-2022-50116", "url": "https://ubuntu.com/security/CVE-2022-50116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix deadlock and link starvation in outgoing data path The current implementation queues up new control and user packets as needed and processes this queue down to the ldisc in the same code path. That means that the upper and the lower layer are hard coupled in the code. Due to this deadlocks can happen as seen below while transmitting data, especially during ldisc congestion. Furthermore, the data channels starve the control channel on high transmission load on the ldisc. Introduce an additional control channel data queue to prevent timeouts and link hangups during ldisc congestion. This is being processed before the user channel data queue in gsm_data_kick(), i.e. with the highest priority. Put the queue to ldisc data path into a workqueue and trigger it whenever new data has been put into the transmission queue. Change gsm_dlci_data_sweep() accordingly to fill up the transmission queue until TX_THRESH_HI. This solves the locking issue, keeps latency low and provides good performance on high data load. Note that now all packets from a DLCI are removed from the internal queue if the associated DLCI was closed. This ensures that no data is sent by the introduced write task to an already closed DLCI. BUG: spinlock recursion on CPU#0, test_v24_loop/124 lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0 CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x34/0x44 do_raw_spin_lock+0x76/0xa0 _raw_spin_lock_irqsave+0x72/0x80 uart_write_room+0x3b/0xc0 gsm_data_kick+0x14b/0x240 [n_gsm] gsmld_write_wakeup+0x35/0x70 [n_gsm] tty_wakeup+0x53/0x60 tty_port_default_wakeup+0x1b/0x30 serial8250_tx_chars+0x12f/0x220 serial8250_handle_irq.part.0+0xfe/0x150 serial8250_default_handle_irq+0x48/0x80 serial8250_interrupt+0x56/0xa0 __handle_irq_event_percpu+0x78/0x1f0 handle_irq_event+0x34/0x70 handle_fasteoi_irq+0x90/0x1e0 __common_interrupt+0x69/0x100 common_interrupt+0x48/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:__do_softirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00 RSP: 0018:ffffc90000003f98 EFLAGS: 00000286 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7 RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? __do_softirq+0x73/0x34e irq_exit_rcu+0xb5/0x100 common_interrupt+0xa4/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50 Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 3d 97 33 ff 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44 RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? _raw_spin_unlock_irqrestore+0x23/0x50 gsmtty_write+0x65/0x80 [n_gsm] n_tty_write+0x33f/0x530 ? swake_up_all+0xe0/0xe0 file_tty_write.constprop.0+0x1b1/0x320 ? n_tty_flush_buffer+0xb0/0xb0 new_sync_write+0x10c/0x190 vfs_write+0x282/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f3e5e35c15c Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2026-31586", "url": "https://ubuntu.com/security/CVE-2026-31586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: blk-cgroup: fix use-after-free in cgwb_release_workfn() cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) ** Stack based on commit 66672af7a095 (\"Add linux-next specific files for 20260410\") I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh (The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.) Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31598", "url": "https://ubuntu.com/security/CVE-2026-31598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible deadlock between unlink and dio_end_io_write ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key. Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir \t ocfs2_expand_inline_dir \t down_write(&oi->ip_alloc_sem) <- Lock B Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode) Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31642", "url": "https://ubuntu.com/security/CVE-2026-31642", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call removal to use RCU safe deletion Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop. This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by: Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that. rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31664", "url": "https://ubuntu.com/security/CVE-2026-31664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear trailing padding in build_polexpire() build_expire() clears the trailing padding bytes of struct xfrm_user_expire after setting the hard field via memset_after(), but the analogous function build_polexpire() does not do this for struct xfrm_user_polexpire. The padding bytes after the __u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners, leaking kernel heap memory contents. Add the missing memset_after() call, matching build_expire().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43075", "url": "https://ubuntu.com/security/CVE-2026-43075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix out-of-bounds write in ocfs2_write_end_inline KASAN reports a use-after-free write of 4086 bytes in ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF. The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk id_count field to determine whether a write fits in inline data. On a corrupted filesystem, id_count can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer. Call trace (crash path): vfs_copy_file_range (fs/read_write.c:1634) do_splice_direct splice_direct_to_actor iter_file_splice_write ocfs2_file_write_iter generic_perform_write ocfs2_write_end ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949) ocfs2_write_end_inline (fs/ocfs2/aops.c:1915) memcpy_from_folio <-- KASAN: write OOB So add id_count upper bound check in ocfs2_validate_inode_block() to alongside the existing i_size check to fix it.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43076", "url": "https://ubuntu.com/security/CVE-2026-43076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate inline data i_size during inode read When reading an inode from disk, ocfs2_validate_inode_block() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's i_size can exceed the actual inline data capacity (id_count). This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory. In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry() Fix by adding a validation check in ocfs2_validate_inode_block() to ensure inodes with inline data have i_size <= id_count. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-23444", "url": "https://ubuntu.com/security/CVE-2026-23444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do. Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free. Document the skb ownership guarantee in the function's kdoc.", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2025-38710", "url": "https://ubuntu.com/security/CVE-2025-38710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Validate i_depth for exhash directories A fuzzer test introduced corruption that ends up with a depth of 0 in dir_e_read(), causing an undefined shift by 32 at: index = hash >> (32 - dip->i_depth); As calculated in an open-coded way in dir_make_exhash(), the minimum depth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 is invalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time. So we can avoid the undefined behaviour by checking for depth values lower than the minimum in gfs2_dinode_in(). Values greater than the maximum are already being checked for there. Also switch the calculation in dir_make_exhash() to use ilog2() to clarify how the depth is calculated. Tested with the syzkaller repro.c and xfstests '-g quick'.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2026-23442", "url": "https://ubuntu.com/security/CVE-2026-23442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: add NULL checks for idev in SRv6 paths __in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER). Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31594", "url": "https://ubuntu.com/security/CVE-2026-31594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to perform later. This leads to an oops when .allow_link fails or when .drop_link is performed. The following is an example oops of the former case: Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pci_epc_remove_epf+0x78/0xe0 (P) pci_primary_epc_epf_link+0x88/0xa8 configfs_symlink+0x1f4/0x5a0 vfs_symlink+0x134/0x1d8 do_symlinkat+0x88/0x138 __arm64_sys_symlinkat+0x74/0xe0 [...] Remove the helper, and drop pci_epc_put(). EPC device refcounting is tied to the configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2022-50073", "url": "https://ubuntu.com/security/CVE-2022-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null Fixes a NULL pointer derefence bug triggered from tap driver. When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null (in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb) virtio_net_hdr_to_skb calls dev_parse_header_protocol which needs skb->dev field to be valid. The line that trigers the bug is in dev_parse_header_protocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->header_ops || !dev->header_ops->parse_protocol) 22e1: mov 0x10(%rbx),%rax 22e5:\t mov 0x230(%rax),%rax Setting skb->dev before the call in tap.c fixes the issue. BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tap_get_user+0x3f1/0x540 [tap] tap_sendmsg+0x56/0x362 [tap] ? get_tx_bufs+0xc2/0x1e0 [vhost_net] handle_tx_copy+0x114/0x670 [vhost_net] handle_tx+0xb0/0xe0 [vhost_net] handle_tx_kick+0x15/0x20 [vhost_net] vhost_worker+0x7b/0xc0 [vhost] ? vhost_vring_call_reset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2026-31576", "url": "https://ubuntu.com/security/CVE-2026-31576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: hackrf: fix to not free memory after the device is registered in hackrf_probe() In hackrf driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open hackrf fd \t\t\t\t\t\t.... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... \t\t\t\t\t\tsys_ioctl(fd, ...); \t\t\t\t\t\t v4l2_ioctl(); \t\t\t\t\t\t video_is_registered() // UAF!! \t\t\t\t\t\t.... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t v4l2_release() // UAF!! \t\t\t\t\t\t hackrf_video_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked. However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver's release() is invoked. Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven't been released yet. And since release() free memory too, race to use-after-free and double-free vuln occur. To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43058", "url": "https://ubuntu.com/security/CVE-2026-43058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix pass-by-value structs causing MSAN warnings vidtv_ts_null_write_into() and vidtv_ts_pcr_write_into() take their argument structs by value, causing MSAN to report uninit-value warnings. While only vidtv_ts_null_write_into() has triggered a report so far, both functions share the same issue. Fix by passing both structs by const pointer instead, avoiding the stack copy of the struct along with its MSAN shadow and origin metadata. The functions do not modify the structs, which is enforced by the const qualifier.", "cve_priority": "medium", "cve_public_date": "2026-05-02 07:16:00 UTC" }, { "cve": "CVE-2026-31577", "url": "https://ubuntu.com/security/CVE-2026-31577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map The DAT inode's btree node cache (i_assoc_inode) is initialized lazily during btree operations. However, nilfs_mdt_save_to_shadow_map() assumes i_assoc_inode is already initialized when copying dirty pages to the shadow map during GC. If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before any btree operation has occurred on the DAT inode, i_assoc_inode is NULL leading to a general protection fault. Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always initialized before any GC operation can use it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31578", "url": "https://ubuntu.com/security/CVE-2026-31578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: as102: fix to not free memory after the device is registered in as102_usb_probe() In as102_usb driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open as102 fd \t\t\t\t\t\t.... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t as102_release() // UAF!! \t\t\t\t\t\t as102_usb_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a USB character device registered with usb_register_dev() is later unregistered (via usb_deregister_dev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked. In as102, as102_usb_probe() calls usb_register_dev() and then, on an error path, does usb_deregister_dev() and frees as102_dev_t right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102_release() --> as102_usb_release() and access or free as102_dev_t again, occur a race to use-after-free and double-free vuln. The fix is to never kfree(as102_dev_t) directly once usb_register_dev() has succeeded. After deregistration, defer freeing memory to .release(). In other words, let release() perform the last kfree when the final open FD is closed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31580", "url": "https://ubuntu.com/security/CVE-2026-31580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bcache: fix cached_dev.sb_bio use-after-free and crash In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention: ``` [6888366.280350] Call Trace: [6888366.280452] blk_update_request+0x14e/0x370 [6888366.280561] blk_mq_end_request+0x1a/0x130 [6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd] [6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd] [6888366.280903] __complete_request+0x22/0x70 [libceph] [6888366.281032] osd_dispatch+0x15e/0xb40 [libceph] [6888366.281164] ? inet_recvmsg+0x5b/0xd0 [6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph] [6888366.281405] ceph_con_process_message+0x79/0x140 [libceph] [6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph] [6888366.281661] ceph_con_workfn+0x329/0x680 [libceph] ``` After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped. Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio. This patch hopes to wait for sb_write to complete in cached_dev_free. It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31581", "url": "https://ubuntu.com/security/CVE-2026-31581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: fix use-after-free on disconnect In usb6fire_chip_abort(), the chip struct is allocated as the card's private data (via snd_card_new with sizeof(struct sfire_chip)). When snd_card_free_when_closed() is called and no file handles are open, the card and embedded chip are freed synchronously. The subsequent chip->card = NULL write then hits freed slab memory. Call trace: usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline] usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953 Fix by moving the card lifecycle out of usb6fire_chip_abort() and into usb6fire_chip_disconnect(). The card pointer is saved in a local before any teardown, snd_card_disconnect() is called first to prevent new opens, URBs are aborted while chip is still valid, and snd_card_free_when_closed() is called last so chip is never accessed after the card may be freed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31583", "url": "https://ubuntu.com/security/CVE-2026-31583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free in em28xx_v4l2_open() em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock, creating a race with em28xx_v4l2_init()'s error path and em28xx_v4l2_fini(), both of which free the em28xx_v4l2 struct and set dev->v4l2 to NULL under dev->lock. This race leads to two issues: - use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler, since the video_device is embedded in the freed em28xx_v4l2 struct. - NULL pointer dereference in em28xx_resolution_set() when accessing v4l2->norm, since dev->v4l2 has been set to NULL. Fix this by moving the mutex_lock() before the dev->v4l2 read and adding a NULL check for dev->v4l2 under the lock.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31585", "url": "https://ubuntu.com/security/CVE-2026-31585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix nfeeds state corruption on start_streaming failure syzbot reported a memory leak in vidtv_psi_service_desc_init [1]. When vidtv_start_streaming() fails inside vidtv_start_feed(), the nfeeds counter is left incremented even though no feed was actually started. This corrupts the driver state: subsequent start_feed calls see nfeeds > 1 and skip starting the mux, while stop_feed calls eventually try to stop a non-existent stream. This state corruption can also lead to memory leaks, since the mux and channel resources may be partially allocated during a failed start_streaming but never cleaned up, as the stop path finds dvb->streaming == false and returns early. Fix by decrementing nfeeds back when start_streaming fails, keeping the counter in sync with the actual number of active feeds. [1] BUG: memory leak unreferenced object 0xffff888145b50820 (size 32): comm \"syz.0.17\", pid 6068, jiffies 4294944486 backtrace (crc 90a0c7d4): vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31686", "url": "https://ubuntu.com/security/CVE-2026-31686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/kasan: fix double free for kasan pXds kasan_free_pxd() assumes the page table is always struct page aligned. But that's not always the case for all architectures. E.g. In case of powerpc with 64K pagesize, PUD table (of size 4096) comes from slab cache named pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's just directly pass the start of the pxd table which is passed as the 1st argument. This fixes the below double free kasan issue seen with PMEM: radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages ================================================================== BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20 Free of addr c0000003c38e0000 by task ndctl/2164 CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeries Call Trace: dump_stack_lvl+0x88/0xc4 (unreliable) print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140 kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec ---- interrupt: 3000 at 0x7fff93b3d3f4 NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000 REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392) MSR: 800000000280f033 CR: 48888208 XER: 00000000 <...> NIP [00007fff93b3d3f4] 0x7fff93b3d3f4 LR [00007fff93b3d3f4] 0x7fff93b3d3f4 ---- interrupt: 3000 The buggy address belongs to the object at c0000003c38e0000 which belongs to the cache pgtable-2^9 of size 4096 The buggy address is located 0 bytes inside of 4096-byte region [c0000003c38e0000, c0000003c38e1000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:c0000003bfd63e01 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) page_type: f5(slab) raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected [ 138.953636] [ T2164] Memory state around the buggy address: [ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953669] [ T2164] ^ [ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953692] [ T2164] ================================================================== [ 138.953701] [ T2164] Disabling lock debugging due to kernel taint", "cve_priority": "low", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2026-31588", "url": "https://ubuntu.com/security/CVE-2026-31588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use scratch field in MMIO fragment to hold small write values When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value. This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, *and* both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable. The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by overwrite the data value with garbage. Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *al ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31630", "url": "https://ubuntu.com/security/CVE-2026-31630", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: proc: size address buffers for %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with \"%pISpc\". That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23399", "url": "https://ubuntu.com/security/CVE-2026-23399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nf_tables: nft_dynset: fix possible stateful expression memleak in error path If cloning the second stateful expression in the element via GFP_ATOMIC fails, then the first stateful expression remains in place without being released.   unreferenced object (percpu) 0x607b97e9cab8 (size 16):     comm \"softirq\", pid 0, jiffies 4294931867     hex dump (first 16 bytes on cpu 3):       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     backtrace (crc 0):       pcpu_alloc_noprof+0x453/0xd80       nft_counter_clone+0x9c/0x190 [nf_tables]       nft_expr_clone+0x8f/0x1b0 [nf_tables]       nft_dynset_new+0x2cb/0x5f0 [nf_tables]       nft_rhash_update+0x236/0x11c0 [nf_tables]       nft_dynset_eval+0x11f/0x670 [nf_tables]       nft_do_chain+0x253/0x1700 [nf_tables]       nft_do_chain_ipv4+0x18d/0x270 [nf_tables]       nf_hook_slow+0xaa/0x1e0       ip_local_deliver+0x209/0x330", "cve_priority": "medium", "cve_public_date": "2026-03-28 08:15:00 UTC" }, { "cve": "CVE-2024-35865", "url": "https://ubuntu.com/security/CVE-2024-35865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.", "cve_priority": "medium", "cve_public_date": "2024-05-19 09:15:00 UTC" }, { "cve": "CVE-2026-31590", "url": "https://ubuntu.com/security/CVE-2026-31590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION Drop the WARN in sev_pin_memory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing: struct kvm_enc_region range = { .addr = 0, .size = -1ul, }; __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range); Note, the checks in sev_mem_enc_register_region() that presumably exist to verify the incoming address+size are completely worthless, as both \"addr\" and \"size\" are u64s and SEV is 64-bit only, i.e. they _can't_ be greater than ULONG_MAX. That wart will be cleaned up in the near future. \tif (range->addr > ULONG_MAX || range->size > ULONG_MAX) \t\treturn -EINVAL; Opportunistically add a comment to explain why the code calculates the number of pages the \"hard\" way, e.g. instead of just shifting @ulen.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31596", "url": "https://ubuntu.com/security/CVE-2026-31596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle invalid dinode in ocfs2_group_extend [BUG] kernel BUG at fs/ocfs2/resize.c:308! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308 Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe Call Trace: ... ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... [CAUSE] ocfs2_group_extend() assumes that the global bitmap inode block returned from ocfs2_inode_lock() has already been validated and BUG_ONs when the signature is not a dinode. That assumption is too strong for crafted filesystems because the JBD2-managed buffer path can bypass structural validation and return an invalid dinode to the resize ioctl. [FIX] Validate the dinode explicitly in ocfs2_group_extend(). If the global bitmap buffer does not contain a valid dinode, report filesystem corruption with ocfs2_error() and fail the resize operation instead of crashing the kernel.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31597", "url": "https://ubuntu.com/security/CVE-2026-31597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY, as documented in mm/filemap.c: \"If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap().\" When this happens, a concurrent munmap() can call remove_vma() and free the vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call dereferences it -- a use-after-free. Fix this by saving ip_blkno as a plain integer before calling filemap_fault(), and removing vma from the trace event. Since ip_blkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31599", "url": "https://ubuntu.com/security/CVE-2026-31599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections syzbot reported a general protection fault in vidtv_psi_desc_assign [1]. vidtv_psi_pmt_stream_init() can return NULL on memory allocation failure, but vidtv_channel_pmt_match_sections() does not check for this. When tail is NULL, the subsequent call to vidtv_psi_desc_assign(&tail->descriptor, desc) dereferences a NULL pointer offset, causing a general protection fault. Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean up the already-allocated stream chain and return. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629 Call Trace: vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline] vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479 vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31602", "url": "https://ubuntu.com/security/CVE-2026-31602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Limit PTP to a single page Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic. ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ct_vm_map() tries to access beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count remain unchanged.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31603", "url": "https://ubuntu.com/security/CVE-2026-31603", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: sm750fb: fix division by zero in ps_to_hz() ps_to_hz() is called from hw_sm750_crtc_set_mode() without validating that pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO causes a division by zero. Fix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent with other framebuffer drivers.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31605", "url": "https://ubuntu.com/security/CVE-2026-31605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31615", "url": "https://ubuntu.com/security/CVE-2026-31615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: renesas_usb3: validate endpoint index in standard request handlers The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math. This is just like what was done in commit ee0d382feb44 (\"usb: gadget: aspeed_udc: validate endpoint index for ast udc\") for the aspeed driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31616", "url": "https://ubuntu.com/security/CVE-2026-31616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete() A broken/bored/mean USB host can overflow the skb_shared_info->frags[] array on a Linux gadget exposing a Phonet function by sending an unbounded sequence of full-page OUT transfers. pn_rx_complete() finalizes the skb only when req->actual < req->length, where req->length is set to PAGE_SIZE by the gadget. If the host always sends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never be reset and each completion will add another fragment via skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17), subsequent frag stores overwrite memory adjacent to the shinfo on the heap. Drop the skb and account a length error when the frag limit is reached, matching the fix applied in t7xx by commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\").", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31617", "url": "https://ubuntu.com/security/CVE-2026-31617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb() The block_len read from the host-supplied NTB header is checked against ntb_max but has no lower bound. When block_len is smaller than opts->ndp_size, the bounds check of: \tndp_index > (block_len - opts->ndp_size) will underflow producing a huge unsigned value that ndp_index can never exceed, defeating the check entirely. The same underflow occurs in the datagram index checks against block_len - opts->dpe_size. With those checks neutered, a malicious USB host can choose ndp_index and datagram offsets that point past the actual transfer, and the skb_put_data() copies adjacent kernel memory into the network skb. Fix this by rejecting block lengths that cannot hold at least the NTB header plus one NDP. This will make block_len - opts->ndp_size and block_len - opts->dpe_size both well-defined. Commit 8d2b1a1ec9f5 (\"CDC-NCM: avoid overflow in sanity checking\") fixed a related class of issues on the host side of NCM.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31618", "url": "https://ubuntu.com/security/CVE-2026-31618", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31619", "url": "https://ubuntu.com/security/CVE-2026-31619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: fireworks: bound device-supplied status before string array lookup The status field in an EFW response is a 32-bit value supplied by the firewire device. efr_status_names[] has 17 entries so a status value outside that range goes off into the weeds when looking at the %s value. Even worse, the status could return EFR_STATUS_INCOMPLETE which is 0x80000000, and is obviously not in that array of potential strings. Fix this up by properly bounding the index against the array size and printing \"unknown\" if it's not recognized.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31622", "url": "https://ubuntu.com/security/CVE-2026-31622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: digital: Bounds check NFC-A cascade depth in SDD response handler The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3 or 4 bytes to target->nfcid1 on each round, but the number of cascade rounds is controlled entirely by the peer device. The peer sets the cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the cascade-incomplete bit in the SEL_RES (deciding whether another round follows). ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver actually enforces this. This means a malicious peer can keep the cascade running, writing past the heap-allocated nfc_target with each round. Fix this by rejecting the response when the accumulated UID would exceed the buffer. Commit e329e71013c9 (\"NFC: nci: Bounds check struct nfc_target arrays\") fixed similar missing checks against the same field on the NCI path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31623", "url": "https://ubuntu.com/security/CVE-2026-31623", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete() A malicious USB device claiming to be a CDC Phonet modem can overflow the skb_shared_info->frags[] array by sending an unbounded sequence of full-page bulk transfers. Drop the skb and increment the length error when the frag limit is reached. This matches the same fix that commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\") did for the t7xx driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31624", "url": "https://ubuntu.com/security/CVE-2026-31624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: clamp report_size in s32ton() to avoid undefined shift s32ton() shifts by n-1 where n is the field's report_size, a value that comes directly from a HID device. The HID parser bounds report_size only to <= 256, so a broken HID device can supply a report descriptor with a wide field that triggers shift exponents up to 256 on a 32-bit type when an output report is built via hid_output_field() or hid_set_field(). Commit ec61b41918587 (\"HID: core: fix shift-out-of-bounds in hid_report_raw_event\") added the same n > 32 clamp to the function snto32(), but s32ton() was never given the same fix as I guess syzbot hadn't figured out how to fuzz a device the same way. Fix this up by just clamping the max value of n, just like snto32() does.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31625", "url": "https://ubuntu.com/security/CVE-2026-31625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: alps: fix NULL pointer dereference in alps_raw_event() Commit ecfa6f34492c (\"HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them\") attempted to fix up the HID drivers that had missed the previous fix that was done in 2ff5baa9b527 (\"HID: appleir: Fix potential NULL dereference at raw event handle\"), but the alps driver was missed. Fix this up by properly checking in the hid-alps driver that it had been claimed correctly before attempting to process the raw event.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31626", "url": "https://ubuntu.com/security/CVE-2026-31626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify() Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using uninitialized data. Smatch warns that only 6 bytes are copied to this 8-byte (u64) variable, leaving the last two bytes uninitialized: drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify() warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes) Initializing the variable at the start of the function fixes this warning and ensures predictable behavior.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31627", "url": "https://ubuntu.com/security/CVE-2026-31627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: s3c24xx: check the size of the SMBUS message before using it The first byte of an i2c SMBUS message is the size, and it should be verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX before processing it. This is the same logic that was added in commit a6e04f05ce0b (\"i2c: tegra: check msg length in SMBUS block read\") to the i2c tegra driver.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31532", "url": "https://ubuntu.com/security/CVE-2026-31532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: fix ro->uniq use-after-free in raw_rcv() raw_release() unregisters raw CAN receive filters via can_rx_unregister(), but receiver deletion is deferred with call_rcu(). This leaves a window where raw_rcv() may still be running in an RCU read-side critical section after raw_release() frees ro->uniq, leading to a use-after-free of the percpu uniq storage. Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific socket destructor. can_rx_unregister() takes an extra reference to the socket and only drops it from the RCU callback, so freeing uniq from sk_destruct ensures the percpu area is not released until the relevant callbacks have drained. [mkl: applied manually]", "cve_priority": "high", "cve_public_date": "2026-04-23 12:17:00 UTC" }, { "cve": "CVE-2026-31629", "url": "https://ubuntu.com/security/CVE-2026-31629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: add missing return after LLCP_CLOSED checks In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket state is LLCP_CLOSED, the code correctly calls release_sock() and nfc_llcp_sock_put() but fails to return. Execution falls through to the remainder of the function, which calls release_sock() and nfc_llcp_sock_put() again. This results in a double release_sock() and a refcount underflow via double nfc_llcp_sock_put(), leading to a use-after-free. Add the missing return statements after the LLCP_CLOSED branches in both functions to prevent the fall-through.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31407", "url": "https://ubuntu.com/security/CVE-2026-31407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: add missing netlink policy validations Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink. These attributes are used by the kernel without any validation. Extend the netlink policies accordingly. Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-43079", "url": "https://ubuntu.com/security/CVE-2026-43079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Skip discovery table for offline dies This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0. WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore] Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at \"pmu->boxes[die] = box\" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43080", "url": "https://ubuntu.com/security/CVE-2026-43080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: Drop large packets with UDP encap syzbot reported a WARN on my patch series [1]. The actual issue is an overflow of 16-bit UDP length field, and it exists in the upstream code. My series added a debug WARN with an overflow check that exposed the issue, that's why syzbot tripped on my patches, rather than on upstream code. syzbot's repro: r0 = socket$pppl2tp(0x18, 0x1, 0x1) r1 = socket$inet6_udp(0xa, 0x2, 0x0) connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c) connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\\x00', '\\xff\\xff', @empty}}}}, 0x32) writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)=\"ee\", 0x34000}], 0x1) It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP encapsulation, and l2tp_xmit_core doesn't check for overflows when it assigns the UDP length field. The value gets trimmed to 16 bites. Add an overflow check that drops oversized packets and avoids sending packets with trimmed UDP length to the wire. syzbot's stack trace (with my patch applied): len >= 65536u WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957 Modules linked in: CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline] RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline] RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327 Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f RSP: 0018:ffffc90003d67878 EFLAGS: 00010293 RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000 RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004 R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900 R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000 FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0 Call Trace: pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x503/0x550 net/socket.c:1195 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1 vfs_writev+0x33c/0x990 fs/read_write.c:1059 do_writev+0x154/0x2e0 fs/read_write.c:1105 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f636479c629 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629 RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31673", "url": "https://ubuntu.com/security/CVE-2026-31673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: read UNIX_DIAG_VFS data under unix_state_lock Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unix_release_sock() clears u->path under unix_state_lock() and drops the path reference after unlocking. Read the inode and device numbers for UNIX_DIAG_VFS while holding unix_state_lock(), then emit the netlink attribute after dropping the lock. This keeps the VFS data stable while the reply is being built.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31681", "url": "https://ubuntu.com/security/CVE-2026-31681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_multiport: validate range encoding in checkentry ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end. The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule. Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43085", "url": "https://ubuntu.com/security/CVE-2026-43085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator When batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send() appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSG_DONE message body. Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes the nfgenmsg payload via nfnl_fill_hdr(), consistent with how __build_packet_message() already constructs NFULNL_MSG_PACKET headers.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43089", "url": "https://ubuntu.com/security/CVE-2026-43089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_mapping() struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43093", "url": "https://ubuntu.com/security/CVE-2026-43093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: tighten UMEM headroom validation to account for tailroom and min frame The current headroom validation in xdp_umem_reg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skb_shared_info stored at the end of XSK frame would be corrupted. HW typically works with 128-aligned sizes so let us provide this value as bare minimum. Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43098", "url": "https://ubuntu.com/security/CVE-2026-43098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: s3fwrn5: allocate rx skb before consuming bytes s3fwrn82_uart_read() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already deliver a complete frame before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43099", "url": "https://ubuntu.com/security/CVE-2026-43099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: fix null-ptr-deref in icmp_build_probe() ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing this error pointer to dev_hold() will cause a kernel crash with null-ptr-deref. Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting \"No Such Interface\".", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43103", "url": "https://ubuntu.com/security/CVE-2026-43103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lapbether: handle NETDEV_PRE_TYPE_CHANGE lapbeth_data_transmit() expects the underlying device type to be ARPHRD_ETHER. Returning NOTIFY_BAD from lapbeth_device_event() makes sure bonding driver can not break this expectation.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31684", "url": "https://ubuntu.com/security/CVE-2026-31684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_csum: validate nested VLAN headers tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43074", "url": "https://ubuntu.com/security/CVE-2026-43074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: defer struct eventpoll free to RCU grace period In certain situations, ep_free() in eventpoll.c will kfree the epi->ep eventpoll struct while it still being used by another concurrent thread. Defer the kfree() to an RCU callback to prevent UAF.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43104", "url": "https://ubuntu.com/security/CVE-2026-43104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix a memory leak in hang state error path When vc4_save_hang_state() encounters an early return condition, it returns without freeing the previously allocated `kernel_state`, leaking memory. Add the missing kfree() calls by consolidating the early return paths into a single place.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43105", "url": "https://ubuntu.com/security/CVE-2026-43105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix memory leak of BO array in hang state The hang state's BO array is allocated separately with kzalloc() in vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the missing kfree() for the BO array before freeing the hang state struct.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43110", "url": "https://ubuntu.com/security/CVE-2026-43110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: validate bsscfg indices in IF events brcmf_fweh_handle_if_event() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check. Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array. [add missing wifi prefix]", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43111", "url": "https://ubuntu.com/security/CVE-2026-43111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: fix use-after-free in roccat_report_event roccat_report_event() iterates over the device->readers list without holding the readers_lock. This allows a concurrent roccat_release() to remove and free a reader while it's still being accessed, leading to a use-after-free. Protect the readers list traversal with the readers_lock mutex.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43112", "url": "https://ubuntu.com/security/CVE-2026-43112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath When cifs_sanitize_prepath is called with an empty string or a string containing only delimiters (e.g., \"/\"), the current logic attempts to check *(cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read. This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL. The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.", "cve_priority": "low", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43113", "url": "https://ubuntu.com/security/CVE-2026-43113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wl1251: validate packet IDs before indexing tx_frames wl1251_tx_packet_cb() uses the firmware completion ID directly to index the fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it. Reject completion IDs that fall outside wl->tx_frames[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2025-54518", "url": "https://ubuntu.com/security/CVE-2025-54518", "cve_description": "Improper isolation of shared resources within the CPU operation cache on Zen 2-based products could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation.", "cve_priority": "high", "cve_public_date": "2026-05-15 05:16:00 UTC" }, { "cve": "CVE-2026-46174", "url": "https://ubuntu.com/security/CVE-2026-46174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2025-71150", "url": "https://ubuntu.com/security/CVE-2025-71150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix refcount leak when invalid session is found on session lookup When a session is found but its state is not SMB2_SESSION_VALID, It indicates that no valid session was found, but it is missing to decrement the reference count acquired by the session lookup, which results in a reference count leak. This patch fixes the issue by explicitly calling ksmbd_user_session_put to release the reference to the session.", "cve_priority": "medium", "cve_public_date": "2026-01-23 15:16:00 UTC" }, { "cve": "CVE-2026-23395", "url": "https://ubuntu.com/security/CVE-2026-23395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ Currently the code attempts to accept requests regardless of the command identifier which may cause multiple requests to be marked as pending (FLAG_DEFER_SETUP) which can cause more than L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer causing an overflow. The spec is quite clear that the same identifier shall not be used on subsequent requests: 'Within each signaling channel a different Identifier shall be used for each successive request or indication.' https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d So this attempts to check if there are any channels pending with the same identifier and rejects if any are found.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31549", "url": "https://ubuntu.com/security/CVE-2026-31549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: cp2615: fix serial string NULL-deref at probe The cp2615 driver uses the USB device serial string as the i2c adapter name but does not make sure that the string exists. Verify that the device has a serial number before accessing it to avoid triggering a NULL-pointer dereference (e.g. with malicious devices).", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31433", "url": "https://ubuntu.com/security/CVE-2026-31433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potencial OOB in get_file_all_info() for compound requests When a compound request consists of QUERY_DIRECTORY + QUERY_INFO (FILE_ALL_INFORMATION) and the first command consumes nearly the entire max_trans_size, get_file_all_info() would blindly call smbConvertToUTF16() with PATH_MAX, causing out-of-bounds write beyond the response buffer. In get_file_all_info(), there was a missing validation check for the client-provided OutputBufferLength before copying the filename into FileName field of the smb2_file_all_info structure. If the filename length exceeds the available buffer space, it could lead to potential buffer overflows or memory corruption during smbConvertToUTF16 conversion. This calculating the actual free buffer size using smb2_calc_max_out_buf_len() and returning -EINVAL if the buffer is insufficient and updating smbConvertToUTF16 to use the actual filename length (clamped by PATH_MAX) to ensure a safe copy operation.", "cve_priority": "high", "cve_public_date": "2026-04-22 09:16:00 UTC" }, { "cve": "CVE-2026-31480", "url": "https://ubuntu.com/security/CVE-2026-31480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential deadlock in cpu hotplug with osnoise The following sequence may leads deadlock in cpu hotplug: task1 task2 task3 ----- ----- ----- mutex_lock(&interface_lock) [CPU GOING OFFLINE] cpus_write_lock(); osnoise_cpu_die(); kthread_stop(task3); wait_for_completion(); osnoise_sleep(); mutex_lock(&interface_lock); cpus_read_lock(); [DEAD LOCK] Fix by swap the order of cpus_read_lock() and mutex_lock(&interface_lock).", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31466", "url": "https://ubuntu.com/security/CVE-2026-31466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix folio isn't locked in softleaf_to_folio() On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows: \tCPU0 CPU1 deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags. This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio() because of the race between folio split and zap_nonpresent_ptes() leading to a folio incorrectly undergoing modification without a folio lock being held. This is a BUG_ON() before commit 93976a20345b (\"mm: eliminate further swapops predicates\"), which in merged in v6.19-rc1. To fix it, add missing smp_rmb() if the softleaf entry is migration entry in softleaf_to_folio() and softleaf_to_page(). [tujinjiang@huawei.com: update function name and comments]", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43054", "url": "https://ubuntu.com/security/CVE-2026-43054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Drain commands in target_reset handler tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS without draining any in-flight commands. The SCSI EH documentation (scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver has made lower layers \"forget about timed out scmds\" and is ready for new commands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug, mpi3mr) enforces this by draining or completing outstanding commands before returning SUCCESS. Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight scsi_cmnd structures for recovery commands (e.g. TUR) while the target core still has async completion work queued for the old se_cmd. The memset in queuecommand zeroes se_lun and lun_ref_active, causing transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN reference prevents transport_clear_lun_ref() from completing, hanging configfs LUN unlink forever in D-state: INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transport_clear_lun_ref+0x78/0x90 [target_core_mod] core_tpg_remove_lun+0x28/0xb0 [target_core_mod] target_fabric_port_unlink+0x50/0x60 [target_core_mod] configfs_unlink+0x156/0x1f0 [configfs] vfs_unlink+0x109/0x290 do_unlinkat+0x1d5/0x2d0 Fix this by making tcm_loop_target_reset() actually drain commands: 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that the target core knows about (those not yet CMD_T_COMPLETE). 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and flush_work() on each se_cmd — this drains any deferred completion work for commands that already had CMD_T_COMPLETE set before the TMR (which the TMR skips via __target_check_io_state()). This is the same pattern used by mpi3mr, scsi_debug, and libsas to drain outstanding commands during reset.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-23401", "url": "https://ubuntu.com/security/CVE-2026-23401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE When installing an emulated MMIO SPTE, do so *after* dropping/zapping the existing SPTE (if it's shadow-present). While commit a54aa15c6bda3 was right about it being impossible to convert a shadow-present SPTE to an MMIO SPTE due to a _guest_ write, it failed to account for writes to guest memory that are outside the scope of KVM. E.g. if host userspace modifies a shadowed gPTE to switch from a memslot to emulted MMIO and then the guest hits a relevant page fault, KVM will install the MMIO SPTE without first zapping the shadow-present SPTE. ------------[ cut here ]------------ is_shadow_present_pte(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm] Call Trace: mmu_set_spte+0x237/0x440 [kvm] ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47fa3f ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-04-01 09:16:00 UTC" }, { "cve": "CVE-2026-31454", "url": "https://ubuntu.com/security/CVE-2026-31454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: save ailp before dropping the AIL lock in push callbacks In xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the AIL lock is dropped to perform buffer IO. Once the cluster buffer no longer protects the log item from reclaim, the log item may be freed by background reclaim or the dquot shrinker. The subsequent spin_lock() call dereferences lip->li_ailp, which is a use-after-free. Fix this by saving the ailp pointer in a local variable while the AIL lock is held and the log item is guaranteed to be valid.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31446", "url": "https://ubuntu.com/security/CVE-2026-31446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in update_super_work when racing with umount Commit b98535d09179 (\"ext4: fix bug_on in start_this_handle during umount filesystem\") moved ext4_unregister_sysfs() before flushing s_sb_upd_work to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups reads during unmount. However, this introduced a use-after-free because update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which accesses the kobject's kernfs_node after it has been freed by kobject_del() in ext4_unregister_sysfs(): update_super_work ext4_put_super ----------------- -------------- ext4_unregister_sysfs(sb) kobject_del(&sbi->s_kobj) __kobject_del() sysfs_remove_dir() kobj->sd = NULL sysfs_put(sd) kernfs_put() // RCU free ext4_notify_error_sysfs(sbi) sysfs_notify(&sbi->s_kobj) kn = kobj->sd // stale pointer kernfs_get(kn) // UAF on freed kernfs_node ext4_journal_destroy() flush_work(&sbi->s_sb_upd_work) Instead of reordering the teardown sequence, fix this by making ext4_notify_error_sysfs() detect that sysfs has already been torn down by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call in that case. A dedicated mutex (s_error_notify_mutex) serializes ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs() to prevent TOCTOU races where the kobject could be deleted between the state_in_sysfs check and the sysfs_notify() call.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31450", "url": "https://ubuntu.com/security/CVE-2026-31450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: publish jinode after initialization ext4_inode_attach_jinode() publishes ei->jinode to concurrent users. It used to set ei->jinode before jbd2_journal_init_jbd_inode(), allowing a reader to observe a non-NULL jinode with i_vfs_inode still unset. The fast commit flush path can then pass this jinode to jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and may crash. Below is the crash I observe: ``` BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xas_find_marked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: filemap_get_folios_tag+0x87/0x2a0 __filemap_fdatawait_range+0x5f/0xd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? cap_safe_nice+0x37/0x70 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 filemap_fdatawait_range_keep_errors+0x12/0x40 ext4_fc_commit+0x697/0x8b0 ? ext4_file_write_iter+0x64b/0x950 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? vfs_write+0x356/0x480 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ext4_sync_file+0xf7/0x370 do_fsync+0x3b/0x80 ? syscall_trace_enter+0x108/0x1d0 __x64_sys_fdatasync+0x16/0x20 do_syscall_64+0x62/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... ``` Fix this by initializing the jbd2_inode first. Use smp_wmb() and WRITE_ONCE() to publish ei->jinode after initialization. Readers use READ_ONCE() to fetch the pointer.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31726", "url": "https://ubuntu.com/security/CVE-2026-31726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix NULL pointer dereference during unbind race Commit b81ac4395bbe (\"usb: gadget: uvc: allow for application to cleanly shutdown\") introduced two stages of synchronization waits totaling 1500ms in uvc_function_unbind() to prevent several types of kernel panics. However, this timing-based approach is insufficient during power management (PM) transitions. When the PM subsystem starts freezing user space processes, the wait_event_interruptible_timeout() is aborted early, which allows the unbind thread to proceed and nullify the gadget pointer (cdev->gadget = NULL): [ 814.123447][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind() [ 814.178583][ T3173] PM: suspend entry (deep) [ 814.192487][ T3173] Freezing user space processes [ 814.197668][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind no clean disconnect, wait for release When the PM subsystem resumes or aborts the suspend and tasks are restarted, the V4L2 release path is executed and attempts to access the already nullified gadget pointer, triggering a kernel panic: [ 814.292597][ C0] PM: pm_system_irq_wakeup: 479 triggered dhdpcie_host_wake [ 814.386727][ T3173] Restarting tasks ... [ 814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 814.404021][ T4558] pc : usb_gadget_deactivate+0x14/0xf4 [ 814.404031][ T4558] lr : usb_function_deactivate+0x54/0x94 [ 814.404078][ T4558] Call trace: [ 814.404080][ T4558] usb_gadget_deactivate+0x14/0xf4 [ 814.404083][ T4558] usb_function_deactivate+0x54/0x94 [ 814.404087][ T4558] uvc_function_disconnect+0x1c/0x5c [ 814.404092][ T4558] uvc_v4l2_release+0x44/0xac [ 814.404095][ T4558] v4l2_release+0xcc/0x130 Address the race condition and NULL pointer dereference by: 1. State Synchronization (flag + mutex) Introduce a 'func_unbound' flag in struct uvc_device. This allows uvc_function_disconnect() to safely skip accessing the nullified cdev->gadget pointer. As suggested by Alan Stern, this flag is protected by a new mutex (uvc->lock) to ensure proper memory ordering and prevent instruction reordering or speculative loads. This mutex is also used to protect 'func_connected' for consistent state management. 2. Explicit Synchronization (completion) Use a completion to synchronize uvc_function_unbind() with the uvc_vdev_release() callback. This prevents Use-After-Free (UAF) by ensuring struct uvc_device is freed after all video device resources are released.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31728", "url": "https://ubuntu.com/security/CVE-2026-31728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop A race condition between gether_disconnect() and eth_stop() leads to a NULL pointer dereference. Specifically, if eth_stop() is triggered concurrently while gether_disconnect() is tearing down the endpoints, eth_stop() attempts to access the cleared endpoint descriptor, causing the following NPE: Unable to handle kernel NULL pointer dereference Call trace: __dwc3_gadget_ep_enable+0x60/0x788 dwc3_gadget_ep_enable+0x70/0xe4 usb_ep_enable+0x60/0x15c eth_stop+0xb8/0x108 Because eth_stop() crashes while holding the dev->lock, the thread running gether_disconnect() fails to acquire the same lock and spins forever, resulting in a hardlockup: Core - Debugging Information for Hardlockup core(7) Call trace: queued_spin_lock_slowpath+0x94/0x488 _raw_spin_lock+0x64/0x6c gether_disconnect+0x19c/0x1e8 ncm_set_alt+0x68/0x1a0 composite_setup+0x6a0/0xc50 The root cause is that the clearing of dev->port_usb in gether_disconnect() is delayed until the end of the function. Move the clearing of dev->port_usb to the very beginning of gether_disconnect() while holding dev->lock. This cuts off the link immediately, ensuring eth_stop() will see dev->port_usb as NULL and safely bail out.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31721", "url": "https://ubuntu.com/security/CVE-2026-31721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: move list and spinlock inits from bind to alloc There was an issue when you did the following: - setup and bind an hid gadget - open /dev/hidg0 - use the resulting fd in EPOLL_CTL_ADD - unbind the UDC - bind the UDC - use the fd in EPOLL_CTL_DEL When CONFIG_DEBUG_LIST was enabled, a list_del corruption was reported within remove_wait_queue (via ep_remove_wait_queue). After some debugging I found out that the queues, which f_hid registers via poll_wait were the problem. These were initialized using init_waitqueue_head inside hidg_bind. So effectively, the bind function re-initialized the queues while there were still items in them. The solution is to move the initialization from hidg_bind to hidg_alloc to extend their lifetimes to the lifetime of the function instance. Additionally, I found many other possibly problematic init calls in the bind function, which I moved as well.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31670", "url": "https://ubuntu.com/security/CVE-2026-31670", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rfkill: prevent unlimited numbers of rfkill events from being created Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a \"large\" number (i.e. 1000) to prevent abuses like this.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31634", "url": "https://ubuntu.com/security/CVE-2026-31634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix reference count leak in rxrpc_server_keyring() This patch fixes a reference count leak in rxrpc_server_keyring() by checking if rx->securities is already set.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31651", "url": "https://ubuntu.com/security/CVE-2026-31651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix NULL-deref on disconnect Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31656", "url": "https://ubuntu.com/security/CVE-2026-31656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` <4> [487.221889] Workqueue: i915-unordered engine_retire [i915] <4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] Call Trace: <4> [487.222711] <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ? __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ? __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ? __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] ``` Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it. (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31658", "url": "https://ubuntu.com/security/CVE-2026-31658", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit() When dma_map_single() fails in tse_start_xmit(), the function returns NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure. Add dev_kfree_skb_any() before returning to properly free the skb.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31660", "url": "https://ubuntu.com/security/CVE-2026-31660", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: allocate rx skb before consuming bytes pn532_receive_buf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already hand a complete frame to pn533_recv_frame() before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31661", "url": "https://ubuntu.com/security/CVE-2026-31661", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: Fix dma_free_coherent() size dma_alloc_consistent() may change the size to align it. The new size is saved in alloced. Change the free size to match the allocation size.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31662", "url": "https://ubuntu.com/security/CVE-2026-31662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round. Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31665", "url": "https://ubuntu.com/security/CVE-2026-31665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: fix use-after-free in timeout object destroy nft_ct_timeout_obj_destroy() frees the timeout object with kfree() immediately after nf_ct_untimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcu_dereference() in nf_ct_timeout_data(). Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c. KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2024-56557", "url": "https://ubuntu.com/security/CVE-2024-56557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer The AD7923 was updated to support devices with 8 channels, but the size of tx_buf and ring_xfer was not increased accordingly, leading to a potential buffer overflow in ad7923_update_scan_mode().", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2024-36898", "url": "https://ubuntu.com/security/CVE-2024-36898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: fix uninitialised kfifo If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace. Initialise the kfifo in the case where the software debounce is already active.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2025-40016", "url": "https://ubuntu.com/security/CVE-2025-40016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID. In a previous attempt commit 3dd075fe8ebb (\"media: uvcvideo: Require entities to have a non-zero unique ID\"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2026-31667", "url": "https://ubuntu.com/security/CVE-2026-31667", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: uinput - fix circular locking dependency with ff-core A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller): ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex The cycle is caused by four lock acquisition paths: 1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex. 2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex. 3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex. 4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex. Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes. To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock. Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible. Lock ordering after the fix: ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31671", "url": "https://ubuntu.com/security/CVE-2026-31671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_report() struct xfrm_user_report is a __u8 proto field followed by a struct xfrm_selector which means there is three \"empty\" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31672", "url": "https://ubuntu.com/security/CVE-2026-31672", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00usb: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the USB anchor lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43336", "url": "https://ubuntu.com/security/CVE-2026-43336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: chacha: Zeroize permuted_state before it leaves scope Since the ChaCha permutation is invertible, the local variable 'permuted_state' is sufficient to compute the original 'state', and thus the key, even after the permutation has been done. While the kernel is quite inconsistent about zeroizing secrets on the stack (and some prominent userspace crypto libraries don't bother at all since it's not guaranteed to work anyway), the kernel does try to do it as a best practice, especially in cases involving the RNG. Thus, explicitly zeroize 'permuted_state' before it goes out of scope.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31695", "url": "https://ubuntu.com/security/CVE-2026-31695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free Currently we execute `SET_NETDEV_DEV(dev, &priv->lowerdev->dev)` for the virt_wifi net devices. However, unregistering a virt_wifi device in netdev_run_todo() can happen together with the device referenced by SET_NETDEV_DEV(). It can result in use-after-free during the ethtool operations performed on a virt_wifi device that is currently being unregistered. Such a net device can have the `dev.parent` field pointing to the freed memory, but ethnl_ops_begin() calls `pm_runtime_get_sync(dev->dev.parent)`. Let's remove SET_NETDEV_DEV for virt_wifi to avoid bugs like this: ================================================================== BUG: KASAN: slab-use-after-free in __pm_runtime_resume+0xe2/0xf0 Read of size 2 at addr ffff88810cfc46f8 by task pm/606 Call Trace: dump_stack_lvl+0x4d/0x70 print_report+0x170/0x4f3 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 kasan_report+0xda/0x110 ? __pm_runtime_resume+0xe2/0xf0 ? __pm_runtime_resume+0xe2/0xf0 __pm_runtime_resume+0xe2/0xf0 ethnl_ops_begin+0x49/0x270 ethnl_set_features+0x23c/0xab0 ? __pfx_ethnl_set_features+0x10/0x10 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xf/0xf0 ? local_clock+0x10/0x30 ? kasan_save_track+0x25/0x60 ? __kasan_kmalloc+0x7f/0x90 ? genl_family_rcv_msg_attrs_parse.isra.0+0x150/0x2c0 genl_family_rcv_msg_doit+0x1e7/0x2c0 ? __pfx_genl_family_rcv_msg_doit+0x10/0x10 ? __pfx_cred_has_capability.isra.0+0x10/0x10 ? stack_trace_save+0x8e/0xc0 genl_rcv_msg+0x411/0x660 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_ethnl_set_features+0x10/0x10 netlink_rcv_skb+0x121/0x380 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_down_read+0x10/0x10 genl_rcv+0x23/0x30 netlink_unicast+0x60f/0x830 ? __pfx_netlink_unicast+0x10/0x10 ? __pfx___alloc_skb+0x10/0x10 netlink_sendmsg+0x6ea/0xbc0 ? __pfx_netlink_sendmsg+0x10/0x10 ? __futex_queue+0x10b/0x1f0 ____sys_sendmsg+0x7a2/0x950 ? copy_msghdr_from_user+0x26b/0x430 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ___sys_sendmsg+0xf8/0x180 ? __pfx____sys_sendmsg+0x10/0x10 ? __pfx_futex_wait+0x10/0x10 ? fdget+0x2e4/0x4a0 __sys_sendmsg+0x11f/0x1c0 ? __pfx___sys_sendmsg+0x10/0x10 do_syscall_64+0xe2/0x570 ? exc_page_fault+0x66/0xb0 entry_SYSCALL_64_after_hwframe+0x77/0x7f This fix may be combined with another one in the ethtool subsystem: https://lore.kernel.org/all/20260322075917.254874-1-alex.popov@linux.com/T/#u", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2024-56584", "url": "https://ubuntu.com/security/CVE-2024-56584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/tctx: work around xa_store() allocation error issue syzbot triggered the following WARN_ON: WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51 which is the WARN_ON_ONCE(!xa_empty(&tctx->xa)); sanity check in __io_uring_free() when a io_uring_task is going through its final put. The syzbot test case includes injecting memory allocation failures, and it very much looks like xa_store() can fail one of its memory allocations and end up with ->head being non-NULL even though no entries exist in the xarray. Until this issue gets sorted out, work around it by attempting to iterate entries in our xarray, and WARN_ON_ONCE() if one is found.", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2026-31720", "url": "https://ubuntu.com/security/CVE-2026-31720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: validate control request size f_audio_complete() copies req->length bytes into a 4-byte stack variable: u32 data = 0; memcpy(&data, req->buf, req->length); req->length is derived from the host-controlled USB request path, which can lead to a stack out-of-bounds write. Validate req->actual against the expected payload size for the supported control selectors and decode only the expected amount of data. This avoids copying a host-influenced length into a fixed-size stack object.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43342", "url": "https://ubuntu.com/security/CVE-2026-43342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Protect RNDIS options with mutex The class/subclass/protocol options are suspectible to race conditions as they can be accessed concurrently through configfs. Use existing mutex to protect these options. This issue was identified during code inspection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43343", "url": "https://ubuntu.com/security/CVE-2026-43343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_subset: Fix unbalanced refcnt in geth_free geth_alloc() increments the reference count, but geth_free() fails to decrement it. This prevents the configuration of attributes via configfs after unlinking the function. Decrement the reference count in geth_free() to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-68256", "url": "https://ubuntu.com/security/CVE-2025-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser The Information Element (IE) parser rtw_get_ie() trusted the length byte of each IE without validating that the IE body (len bytes after the 2-byte header) fits inside the remaining frame buffer. A malformed frame can advertise an IE length larger than the available data, causing the parser to increment its pointer beyond the buffer end. This results in out-of-bounds reads or, depending on the pattern, an infinite loop. Fix by validating that (offset + 2 + len) does not exceed the limit before accepting the IE or advancing to the next element. This prevents OOB reads and ensures the parser terminates safely on malformed frames.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40103", "url": "https://ubuntu.com/security/CVE-2025-40103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix refcount leak for cifs_sb_tlink Fix three refcount inconsistency issues related to `cifs_sb_tlink`. Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be called after successful calls to `cifs_sb_tlink()`. Three calls fail to update refcount accordingly, leading to possible resource leaks.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-38006", "url": "https://ubuntu.com/security/CVE-2025-38006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: Don't access ifa_index when missing In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but only when the struct ifaddrmsg is provided. Otherwise it will be comparing to uninitialised memory - reproducible in the syzkaller case from dhcpd, or busybox \"ip addr show\". The kernel MCTP implementation has always filtered by ifa_index, so existing userspace programs expecting to dump MCTP addresses must already be passing a valid ifa_index value (either 0 or a real index). BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40323", "url": "https://ubuntu.com/security/CVE-2025-40323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Set fb_display[i]->mode to NULL when the mode is released Recently, we discovered the following issue through syzkaller: BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0. Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2026-23031", "url": "https://ubuntu.com/security/CVE-2026-23031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak In gs_can_open(), the URBs for USB-in transfers are allocated, added to the parent->rx_submitted anchor and submitted. In the complete callback gs_usb_receive_bulk_callback(), the URB is processed and resubmitted. In gs_can_close() the URBs are freed by calling usb_kill_anchored_urbs(parent->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in gs_can_close(). Fix the memory leak by anchoring the URB in the gs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-43324", "url": "https://ubuntu.com/security/CVE-2026-43324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix interrupt synchronization error This fixes an error in synchronization in the dummy-hcd driver. The error has a somewhat involved history. The synchronization mechanism was introduced by commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), which added an emulated \"interrupts enabled\" flag together with code emulating synchronize_irq() (it waits until all current handler callbacks have returned). But the emulated interrupt-disable occurred too late, after the driver containing the handler callback routines had been told that it was unbound and no more callbacks would occur. Commit 4a5d797a9f9c (\"usb: gadget: dummy_hcd: fix gpf in gadget_setup\") tried to fix this by moving the synchronize_irq() emulation code from dummy_stop() to dummy_pullup(), which runs before the unbind callback. There still were races, though, because the emulated interrupt-disable still occurred too late. It couldn't be moved to dummy_pullup(), because that routine can be called for reasons other than an impending unbind. Therefore commits 7dc0c55e9f30 (\"USB: UDC core: Add udc_async_callbacks gadget op\") and 04145a03db9d (\"USB: UDC: Implement udc_async_callbacks in dummy-hcd\") added an API allowing the UDC core to tell dummy-hcd exactly when emulated interrupts and their callbacks should be disabled. That brings us to the current state of things, which is still wrong because the emulated synchronize_irq() occurs before the emulated interrupt-disable! That's no good, beause it means that more emulated interrupts can occur after the synchronize_irq() emulation has run, leading to the possibility that a callback handler may be running when the gadget driver is unbound. To fix this, we have to move the synchronize_irq() emulation code yet again, to the dummy_udc_async_callbacks() routine, which takes care of enabling and disabling emulated interrupt requests. The synchronization will now run immediately after emulated interrupts are disabled, which is where it belongs.", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43327", "url": "https://ubuntu.com/security/CVE-2026-43327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix locking/synchronization error Syzbot testing was able to provoke an addressing exception and crash in the usb_gadget_udc_reset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second (\"driver\") argument of NULL. The bad caller was set_link_state() in dummy_hcd.c, and the problem arose because of a race between a USB reset and driver unbind. These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first. The error responsible for the syzbot crash occurred because the stop_activity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stop_activity() occurs in set_link_state() when handling an emulated USB reset, after the test of dum->ints_enabled and before the increment of dum->callback_usage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->ints_enabled and dum->driver. Normally this other thread would have to wait for dum->callback_usage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callback_usage had not yet been incremented. The fix is to increment dum->callback_usage _before_ calling stop_activity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usb_gadget_udc_reset() safely returns and dum->callback_usage has been decremented again.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31737", "url": "https://ubuntu.com/security/CVE-2026-31737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ftgmac100: fix ring allocation unwind on open failure ftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, and rx_scratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function. Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31738", "url": "https://ubuntu.com/security/CVE-2026-31738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: validate ND option lengths in vxlan_na_create vxlan_na_create() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31747", "url": "https://ubuntu.com/security/CVE-2026-31747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me4000: Fix potential overrun of firmware buffer `me4000_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`. Note: The firmware loading was totally broken before commit ac584af59945 (\"staging: comedi: me4000: fix firmware downloading\"), but that is the most sensible target for this fix.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31748", "url": "https://ubuntu.com/security/CVE-2026-31748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me_daq: Fix potential overrun of firmware buffer `me2600_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Although it checks that the supplied firmware is at least 16 bytes long, it does not check that it is long enough to contain the data stream. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31749", "url": "https://ubuntu.com/security/CVE-2026-31749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: ni_atmio16d: Fix invalid clean-up after failed attach If the driver's COMEDI \"attach\" handler function (`atmio16d_attach()`) returns an error, the COMEDI core will call the driver's \"detach\" handler function (`atmio16d_detach()`) to clean up. This calls `reset_atmio16d()` unconditionally, but depending on where the error occurred in the attach handler, the device may not have been sufficiently initialized to call `reset_atmio16d()`. It uses `dev->iobase` as the I/O port base address and `dev->private` as the pointer to the COMEDI device's private data structure. `dev->iobase` may still be set to its initial value of 0, which would result in undesired writes to low I/O port addresses. `dev->private` may still be `NULL`, which would result in null pointer dereferences. Fix `atmio16d_detach()` by checking that `dev->private` is valid (non-null) before calling `reset_atmio16d()`. This implies that `dev->iobase` was set correctly since that is set up before `dev->private`.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43340", "url": "https://ubuntu.com/security/CVE-2026-43340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Reinit dev->spinlock between attachments to low-level drivers `struct comedi_device` is the main controlling structure for a COMEDI device created by the COMEDI subsystem. It contains a member `spinlock` containing a spin-lock that is initialized by the COMEDI subsystem, but is reserved for use by a low-level driver attached to the COMEDI device (at least since commit 25436dc9d84f (\"Staging: comedi: remove RT code\")). Some COMEDI devices (those created on initialization of the COMEDI subsystem when the \"comedi.comedi_num_legacy_minors\" parameter is non-zero) can be attached to different low-level drivers over their lifetime using the `COMEDI_DEVCONFIG` ioctl command. This can result in inconsistent lock states being reported when there is a mismatch in the spin-lock locking levels used by each low-level driver to which the COMEDI device has been attached. Fix it by reinitializing `dev->spinlock` before calling the low-level driver's `attach` function pointer if `CONFIG_LOCKDEP` is enabled.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31751", "url": "https://ubuntu.com/security/CVE-2026-31751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: dt2815: add hardware detection to prevent crash The dt2815 driver crashes when attached to I/O ports without actual hardware present. This occurs because syzkaller or users can attach the driver to arbitrary I/O addresses via COMEDI_DEVCONFIG ioctl. When no hardware exists at the specified port, inb() operations return 0xff (floating bus), but outb() operations can trigger page faults due to undefined behavior, especially under race conditions: BUG: unable to handle page fault for address: 000000007fffff90 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:dt2815_attach+0x6e0/0x1110 Add hardware detection by reading the status register before attempting any write operations. If the read returns 0xff, assume no hardware is present and fail the attach with -ENODEV. This prevents crashes from outb() operations on non-existent hardware.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31752", "url": "https://ubuntu.com/security/CVE-2026-31752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: validate ND option lengths br_nd_send() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31754", "url": "https://ubuntu.com/security/CVE-2026-31754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix state inconsistency on gadget init failure When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency. When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error, so cdns_role_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles. This leads to a synchronous external abort in xhci_gen_setup() when setting up the host controller: [ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408 [ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switch Fix by calling cdns_drd_gadget_off() in the error path to properly clean up the DRD gadget state.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31755", "url": "https://ubuntu.com/security/CVE-2026-31755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix NULL pointer dereference in ep_queue When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when __cdns3_gadget_ep_queue() is called, causing a kernel crash. Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints. This prevents potential crashes when ep_queue is called on endpoints that are not ready.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31756", "url": "https://ubuntu.com/security/CVE-2026-31756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop() dwc2_gadget_exit_clock_gating() internally calls call_gadget() macro, which expects hsotg->lock to be held since it does spin_unlock/spin_lock around the gadget driver callback invocation. However, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating() without holding the lock. This leads to: - spin_unlock on a lock that is not held (undefined behavior) - The lock remaining held after dwc2_gadget_exit_clock_gating() returns, causing a deadlock when spin_lock_irqsave() is called later in the same function. Fix this by acquiring hsotg->lock before calling dwc2_gadget_exit_clock_gating() and releasing it afterwards, which satisfies the locking requirement of the call_gadget() macro.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31758", "url": "https://ubuntu.com/security/CVE-2026-31758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbtmc: Flush anchored URBs in usbtmc_release When calling usbtmc_release, pending anchored URBs must be flushed or killed to prevent use-after-free errors (e.g. in the HCD giveback path). Call usbtmc_draw_down() to allow anchored URBs to be completed.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31759", "url": "https://ubuntu.com/security/CVE-2026-31759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: fix double free in ulpi_register_interface() error path When device_register() fails, ulpi_register() calls put_device() on ulpi->dev. The device release callback ulpi_dev_release() drops the OF node reference and frees ulpi, but the current error path in ulpi_register_interface() then calls kfree(ulpi) again, causing a double free. Let put_device() handle the cleanup through ulpi_dev_release() and avoid freeing ulpi again in ulpi_register_interface().", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31761", "url": "https://ubuntu.com/security/CVE-2026-31761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Move iio_device_register() to correct location iio_device_register() should be at the end of the probe function to prevent race conditions. Place iio_device_register() at the end of the probe function and place iio_device_unregister() accordingly.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31762", "url": "https://ubuntu.com/security/CVE-2026-31762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix irq resource leak The interrupt handler is setup but only a few lines down if iio_trigger_register() fails the function returns without properly releasing the handler. Add cleanup goto to resolve resource leak. Detected by Smatch: drivers/iio/gyro/mpu3050-core.c:1128 mpu3050_trigger_probe() warn: 'irq' from request_threaded_irq() not released on lines: 1124.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31763", "url": "https://ubuntu.com/security/CVE-2026-31763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix incorrect free_irq() variable The handler for the IRQ part of this driver is mpu3050->trig but, in the teardown free_irq() is called with handler mpu3050. Use correct IRQ handler when calling free_irq().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31770", "url": "https://ubuntu.com/security/CVE-2026-31770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) Fix division by zero in occ_show_power_1() In occ_show_power_1() case 1, the accumulator is divided by update_tag without checking for zero. If no samples have been collected yet (e.g. during early boot when the sensor block is included but hasn't been updated), update_tag is zero, causing a kernel divide-by-zero crash. The 2019 fix in commit 211186cae14d (\"hwmon: (occ) Fix division by zero issue\") only addressed occ_get_powr_avg() used by occ_show_power_2() and occ_show_power_a0(). This separate code path in occ_show_power_1() was missed. Fix this by reusing the existing occ_get_powr_avg() helper, which already handles the zero-sample case and uses mul_u64_u32_div() to multiply before dividing for better precision. Move the helper above occ_show_power_1() so it is visible at the call site. [groeck: Fix alignment problems reported by checkpatch]", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43334", "url": "https://ubuntu.com/security/CVE-2026-43334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: force responder MITM requirements before building the pairing response smp_cmd_pairing_req() currently builds the pairing response from the initiator auth_req before enforcing the local BT_SECURITY_HIGH requirement. If the initiator omits SMP_AUTH_MITM, the response can also omit it even though the local side still requires MITM. tk_request() then sees an auth value without SMP_AUTH_MITM and may select JUST_CFM, making method selection inconsistent with the pairing policy the responder already enforces. When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMP_AUTH_MITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31773", "url": "https://ubuntu.com/security/CVE-2026-31773", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: derive legacy responder STK authentication from MITM state The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved. For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result. This also keeps the legacy path aligned with the Secure Connections code, which already treats JUST_WORKS/JUST_CFM as unauthenticated.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31776", "url": "https://ubuntu.com/security/CVE-2026-31776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix missing SPDIFI1 index handling SPDIF1 DAIO type isn't properly handled in daio_device_index() for hw20k2, and it returned -EINVAL, which ended up with the out-of-bounds array access. Follow the hw20k1 pattern and return the proper index for this type, too.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31778", "url": "https://ubuntu.com/security/CVE-2026-31778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix stack out-of-bounds read in init_card The loop creates a whitespace-stripped copy of the card shortname where `len < sizeof(card->id)` is used for the bounds check. Since sizeof(card->id) is 16 and the local id buffer is also 16 bytes, writing 16 non-space characters fills the entire buffer, overwriting the terminating nullbyte. When this non-null-terminated string is later passed to snd_card_set_id() -> copy_valid_id_string(), the function scans forward with `while (*nid && ...)` and reads past the end of the stack buffer, reading the contents of the stack. A USB device with a product name containing many non-ASCII, non-space characters (e.g. multibyte UTF-8) will reliably trigger this as follows: BUG: KASAN: stack-out-of-bounds in copy_valid_id_string sound/core/init.c:696 [inline] BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c sound/core/init.c:718 The off-by-one has been present since commit bafeee5b1f8d (\"ALSA: snd_usb_caiaq: give better shortname\") from June 2009 (v2.6.31-rc1), which first introduced this whitespace-stripping loop. The original code never accounted for the null terminator when bounding the copy. Fix this by changing the loop bound to `sizeof(card->id) - 1`, ensuring at least one byte remains as the null terminator.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31780", "url": "https://ubuntu.com/security/CVE-2026-31780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation The variable valuesize is declared as u8 but accumulates the total length of all SSIDs to scan. Each SSID contributes up to 33 bytes (IEEE80211_MAX_SSID_LEN + 1), and with WILC_MAX_NUM_PROBED_SSID (10) SSIDs the total can reach 330, which wraps around to 74 when stored in a u8. This causes kmalloc to allocate only 75 bytes while the subsequent memcpy writes up to 331 bytes into the buffer, resulting in a 256-byte heap buffer overflow. Widen valuesize from u8 to u32 to accommodate the full range.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31781", "url": "https://ubuntu.com/security/CVE-2026-31781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ioc32: stop speculation on the drm_compat_ioctl path The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling array_index_nospec() on the index to the function pointer list.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43333", "url": "https://ubuntu.com/security/CVE-2026-43333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject direct access to nullable PTR_TO_BUF pointers check_mem_access() matches PTR_TO_BUF via base_type() which strips PTR_MAYBE_NULL, allowing direct dereference without a null check. Map iterator ctx->key and ctx->value are PTR_TO_BUF | PTR_MAYBE_NULL. On stop callbacks these are NULL, causing a kernel NULL dereference. Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching the existing PTR_TO_BTF_ID pattern.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31415", "url": "https://ubuntu.com/security/CVE-2026-31415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid overflows in ip6_datagram_send_ctl() Yiming Qian reported : I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via `skb_under_panic()` (local DoS). The core issue is a mismatch between: - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type `__u16`) and - a pointer to the *last* provided destination-options header (`opt->dst1opt`) when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided. - `include/net/ipv6.h`: - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible). (lines 291-307, especially 298) - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`: - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen` without rejecting duplicates. (lines 909-933) - `net/ipv6/ip6_output.c:__ip6_append_data()`: - Uses `opt->opt_flen + opt->opt_nflen` to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - `net/ipv6/ip6_output.c:__ip6_make_skb()`: - Calls `ipv6_push_frag_opts()` if `opt->opt_flen` is non-zero. (lines 1930-1934) - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`: - Push size comes from `ipv6_optlen(opt->dst1opt)` (based on the pointed-to header). (lines 1179-1185 and 1206-1211) 1. `opt_flen` is a 16-bit accumulator: - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`. 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs and increments `opt_flen` each time: - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`: - It computes `len = ((hdr->hdrlen + 1) << 3);` - It checks `CAP_NET_RAW` using `ns_capable(net->user_ns, CAP_NET_RAW)`. (line 922) - Then it does: - `opt->opt_flen += len;` (line 927) - `opt->dst1opt = hdr;` (line 928) There is no duplicate rejection here (unlike the legacy `IPV6_2292DSTOPTS` path which rejects duplicates at `net/ipv6/datagram.c:901-904`). If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps while `dst1opt` still points to a large (2048-byte) destination-options header. In the attached PoC (`poc.c`): - 32 cmsgs with `hdrlen=255` => `len = (255+1)*8 = 2048` - 1 cmsg with `hdrlen=0` => `len = 8` - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8` - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header. 3. The transmit path sizes headers using the wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1463-1465`: - `headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;` With wrapped `opt_flen`, `headersize`/headroom decisions underestimate what will be pushed later. 4. When building the final skb, the actual push length comes from `dst1opt` and is not limited by wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1930-1934`: - `if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);` - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes `dst1opt` via `ipv6_push_exthdr()`. - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does: - `skb_push(skb, ipv6_optlen(opt));` - `memcpy(h, opt, ipv6_optlen(opt));` With insufficient headroom, `skb_push()` underflows and triggers `skb_under_panic()` -> `BUG()`: - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`) - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`) - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target netns user namespace (`ns_capable(net->user_ns, CAP_NET_RAW)`). - Root (or any task with `CAP_NET_RAW`) can trigger this without user namespaces. - An unprivileged `uid=1000` user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced `CAP_NET_RAW` (the attached PoC does this). - Local denial of service: kernel BUG/panic (system crash). - ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31422", "url": "https://ubuntu.com/security/CVE-2026-31422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_flow: fix NULL pointer dereference on shared blocks flow_change() calls tcf_block_q() and dereferences q->handle to derive a default baseclass. Shared blocks leave block->q NULL, causing a NULL deref when a flow filter without a fully qualified baseclass is created on a shared block. Check tcf_block_shared() before accessing block->q and return -EINVAL for shared blocks. This avoids the null-deref shown below: ======================================================================= KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:flow_change (net/sched/cls_flow.c:508) Call Trace: tc_new_tfilter (net/sched/cls_api.c:2432) rtnetlink_rcv_msg (net/core/rtnetlink.c:6980) [...] =======================================================================", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31421", "url": "https://ubuntu.com/security/CVE-2026-31421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL pointer dereference on shared blocks The old-method path in fw_classify() calls tcf_block_q() and dereferences q->handle. Shared blocks leave block->q NULL, causing a NULL deref when an empty cls_fw filter is attached to a shared block and a packet with a nonzero major skb mark is classified. Reject the configuration in fw_change() when the old method (no TCA_OPTIONS) is used on a shared block, since fw_classify()'s old-method path needs block->q which is NULL for shared blocks. The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fw_classify (net/sched/cls_fw.c:81) Call Trace: tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860) tc_run (net/core/dev.c:4401) __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31417", "url": "https://ubuntu.com/security/CVE-2026-31417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix overflow when accumulating packets Add a check to ensure that `x25_sock.fraglen` does not overflow. The `fraglen` also needs to be resetted when purging `fragment_queue` in `x25_clear_queues()`.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43014", "url": "https://ubuntu.com/security/CVE-2026-43014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: properly unregister fixed rate clocks The additional resources allocated with clk_register_fixed_rate() need to be released with clk_unregister_fixed_rate(), otherwise they are lost.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43015", "url": "https://ubuntu.com/security/CVE-2026-43015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix clk handling on PCI glue driver removal platform_device_unregister() may still want to use the registered clks during runtime resume callback. Note that there is a commit d82d5303c4c5 (\"net: macb: fix use after free on rmmod\") that addressed the similar problem of clk vs platform device unregistration but just moved the bug to another place. Save the pointers to clks into local variables for reuse after platform device is unregistered. BUG: KASAN: use-after-free in clk_prepare+0x5a/0x60 Read of size 8 at addr ffff888104f85e00 by task modprobe/597 CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x8d/0xba print_report+0x17f/0x496 kasan_report+0xd9/0x180 clk_prepare+0x5a/0x60 macb_runtime_resume+0x13d/0x410 [macb] pm_generic_runtime_resume+0x97/0xd0 __rpm_callback+0xc8/0x4d0 rpm_callback+0xf6/0x230 rpm_resume+0xeeb/0x1a70 __pm_runtime_resume+0xb4/0x170 bus_remove_device+0x2e3/0x4b0 device_del+0x5b3/0xdc0 platform_device_del+0x4e/0x280 platform_device_unregister+0x11/0x50 pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 519: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x8e/0x90 __clk_register+0x458/0x2890 clk_hw_register+0x1a/0x60 __clk_hw_register_fixed_rate+0x255/0x410 clk_register_fixed_rate+0x3c/0xa0 macb_probe+0x1d8/0x42e [macb_pci] local_pci_probe+0xd7/0x190 pci_device_probe+0x252/0x600 really_probe+0x255/0x7f0 __driver_probe_device+0x1ee/0x330 driver_probe_device+0x4c/0x1f0 __driver_attach+0x1df/0x4e0 bus_for_each_dev+0x15d/0x1f0 bus_add_driver+0x486/0x5e0 driver_register+0x23a/0x3d0 do_one_initcall+0xfd/0x4d0 do_init_module+0x18b/0x5a0 load_module+0x5663/0x7950 __do_sys_finit_module+0x101/0x180 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 597: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x180 __kmem_cache_free+0xbc/0x320 clk_unregister+0x6de/0x8d0 macb_remove+0x73/0xc0 [macb_pci] pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31425", "url": "https://ubuntu.com/security/CVE-2026-31425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: ib: reject FRMR registration before IB connection is established rds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_data and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with i_cm_id = NULL because the connection worker has not yet called rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses the control message before any connection establishment, allowing rds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash the kernel. The existing guard in rds_ib_reg_frmr() only checks for !ic (added in commit 9e630bcb7701), which does not catch this case since ic is allocated early and is always non-NULL once the connection object exists. KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920 Call Trace: rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167) rds_ib_map_frmr (net/rds/ib_frmr.c:252) rds_ib_reg_frmr (net/rds/ib_frmr.c:430) rds_ib_get_mr (net/rds/ib_rdma.c:615) __rds_rdma_map (net/rds/rdma.c:295) rds_cmsg_rdma_map (net/rds/rdma.c:860) rds_sendmsg (net/rds/send.c:1363) ____sys_sendmsg do_syscall_64 Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all non-NULL before proceeding with FRMR registration, mirroring the guard already present in rds_ib_post_inv(). Return -ENODEV when the connection is not ready, which the existing error handling in rds_cmsg_send() converts to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to start the connection worker.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43020", "url": "https://ubuntu.com/security/CVE-2026-43020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate LTK enc_size on load Load Long Term Keys stores the user-provided enc_size and later uses it to size fixed-size stack operations when replying to LE LTK requests. An enc_size larger than the 16-byte key buffer can therefore overflow the reply stack buffer. Reject oversized enc_size values while validating the management LTK record so invalid keys never reach the stored key state.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43024", "url": "https://ubuntu.com/security/CVE-2026-43024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject immediate NF_QUEUE verdict nft_queue is always used from userspace nftables to deliver the NF_QUEUE verdict. Immediately emitting an NF_QUEUE verdict is never used by the userspace nft tools, so reject immediate NF_QUEUE verdicts. The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NF_QUEUE immediate verdicts to address this issue.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31424", "url": "https://ubuntu.com/security/CVE-2026-31424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP Weiming Shi says: xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_* constants. This is only correct for families whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING). ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports: - arpt_CLASSIFY - arpt_mangle - arpt_MARK that provide explicit NFPROTO_ARP match/target declarations.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43026", "url": "https://ubuntu.com/security/CVE-2026-43026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT. The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields. Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled. Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43027", "url": "https://ubuntu.com/security/CVE-2026-43027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_helper: pass helper to expect cleanup nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expect_iter_me() never matches any expectation and all of them survive the cleanup. After unregister returns, nfnl_cthelper_del() frees the helper object immediately. Subsequent expectation dumps or packet-driven init_conntrack() calls then dereference the freed exp->helper, causing a use-after-free. Pass the actual helper pointer so expectations referencing it are properly destroyed before the helper object is freed. BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43028", "url": "https://ubuntu.com/security/CVE-2026-43028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: ensure names are nul-terminated Reject names that lack a \\0 character before feeding them to functions that expect c-strings. Fixes tag is the most recent commit that needs this change.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31416", "url": "https://ubuntu.com/security/CVE-2026-31416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: account for netlink header size This is a followup to an old bug fix: NLMSG_DONE needs to account for the netlink header size, not just the attribute size. This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43329", "url": "https://ubuntu.com/security/CVE-2026-43329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: strictly check for maximum number of actions The maximum number of flowtable hardware offload actions in IPv6 is: * ethernet mangling (4 payload actions, 2 for each ethernet address) * SNAT (4 payload actions) * DNAT (4 payload actions) * Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. * Redirect (1 action) Which makes 17, while the maximum is 16. But act_ct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions. Update flow_action_entry_next() calls to check for the maximum number of supported actions. While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31680", "url": "https://ubuntu.com/security/CVE-2026-31680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: flowlabel: defer exclusive option free until RCU teardown `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file RCU read-side lock and prints `fl->opt->opt_nflen` when an option block is present. Exclusive flowlabels currently free `fl->opt` as soon as `fl->users` drops to zero in `fl_release()`. However, the surrounding `struct ip6_flowlabel` remains visible in the global hash table until later garbage collection removes it and `fl_free_rcu()` finally tears it down. A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that early `kfree()` and dereference freed option state, triggering a crash in `ip6fl_seq_show()`. Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43030", "url": "https://ubuntu.com/security/CVE-2026-43030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix regsafe() for pointers to packet In case rold->reg->range == BEYOND_PKT_END && rcur->reg->range == N regsafe() may return true which may lead to current state with valid packet range not being explored. Fix the bug.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43032", "url": "https://ubuntu.com/security/CVE-2026-43032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: pn533: bound the UART receive buffer pn532_receive_buf() appends every incoming byte to dev->recv_skb and only resets the buffer after pn532_uart_rx_is_frame() recognizes a complete frame. A continuous stream of bytes without a valid PN532 frame header therefore keeps growing the skb until skb_put_u8() hits the tail limit. Drop the accumulated partial frame once the fixed receive buffer is full so malformed UART traffic cannot grow the skb past PN532_UART_SKB_BUFF_LEN.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43035", "url": "https://ubuntu.com/security/CVE-2026-43035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to zero to prevent an info-leak When building netlink messages, tc_chain_fill_node() never initializes the tcm_info field of struct tcmsg. Since the allocation is not zeroed, kernel heap memory is leaked to userspace through this 4-byte field. The fix simply zeroes tcm_info alongside the other fields that are already initialized.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43339", "url": "https://ubuntu.com/security/CVE-2026-43339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible UaF in addrconf_permanent_addr() The mentioned helper try to warn the user about an exceptional condition, but the message is delivered too late, accessing the ipv6 after its possible deletion. Reorder the statement to avoid the possible UaF; while at it, place the warning outside the idev->lock as it needs no protection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31423", "url": "https://ubuntu.com/security/CVE-2026-31423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: fix divide-by-zero in rtsc_min() m2sm() converts a u32 slope to a u64 scaled value. For large inputs (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores the difference of two such u64 values in a u32 variable `dsm` and uses it as a divisor. When the difference is exactly 2^32 the truncation yields zero, causing a divide-by-zero oops in the concave-curve intersection path: Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...] Widen `dsm` to u64 and replace do_div() with div64_u64() so the full difference is preserved.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43040", "url": "https://ubuntu.com/security/CVE-2026-43040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak When processing Router Advertisements with user options the kernel builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data The fix is simple, just zeroes the padding fields.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43041", "url": "https://ubuntu.com/security/CVE-2026-43041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak __radix_tree_create() allocates and links intermediate nodes into the tree one by one. If a subsequent allocation fails, the already-linked nodes remain in the tree with no corresponding leaf entry. These orphaned internal nodes are never reclaimed because radix_tree_for_each_slot() only visits slots containing leaf values. The radix_tree API is deprecated in favor of xarray. As suggested by Matthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray instead of fixing the radix_tree itself [1]. xarray properly handles cleanup of internal nodes — xa_destroy() frees all internal xarray nodes when the qrtr_node is released, preventing the leak. [1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43043", "url": "https://ubuntu.com/security/CVE-2026-43043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af-alg - fix NULL pointer dereference in scatterwalk The AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL) when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL exactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent sendmsg() allocates a new SGL and chains it, but fails to clear the end marker on the previous SGL's last data entry. This causes the crypto scatterwalk to hit a premature end, returning NULL on sg_next() and leading to a kernel panic during dereference. Fix this by explicitly unmarking the end of the previous SGL when performing sg_chain() in af_alg_alloc_tsgl().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43046", "url": "https://ubuntu.com/security/CVE-2026-43046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject root items with drop_progress and zero drop_level [BUG] When recovering relocation at mount time, merge_reloc_root() and btrfs_drop_snapshot() both use BUG_ON(level == 0) to guard against an impossible state: a non-zero drop_progress combined with a zero drop_level in a root_item, which can be triggered: ------------[ cut here ]------------ kernel BUG at fs/btrfs/relocation.c:1545! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2 RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545 Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000 Call Trace: merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861 btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195 btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130 open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640 btrfs_fill_super fs/btrfs/super.c:987 [inline] btrfs_get_tree_super fs/btrfs/super.c:1951 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline] btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ... RIP: 0033:0x7f969c9a8fde Code: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f ---[ end trace 0000000000000000 ]--- The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamic metadata fuzzing tool that corrupts btrfs metadata at runtime. [CAUSE] A non-zero drop_progress.objectid means an interrupted btrfs_drop_snapshot() left a resume point on disk, and in that case drop_level must be greater than 0 because the checkpoint is only saved at internal node levels. Although this invariant is enforced when the kernel writes the root item, it is not validated when the root item is read back from disk. That allows on-disk corruption to provide an invalid state with drop_progress.objectid != 0 and drop_level == 0. When relocation recovery later processes such a root item, merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). The same invalid metadata can also trigger the corresponding BUG_ON() in btrfs_drop_snapshot(). [FIX] Fix this by validating the root_item invariant in tree-checker when reading root items from disk: if drop_progress.objectid is non-zero, drop_level must also be non-zero. Reject such malformed metadata with -EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot() and triggers the BUG_ON. After the fix, the same corruption is correctly rejected by tree-checker and the BUG_ON is no longer triggered.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43047", "url": "https://ubuntu.com/security/CVE-2026-43047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Check to ensure report responses match the request It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes. Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43050", "url": "https://ubuntu.com/security/CVE-2026-43050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix use-after-free in sock_def_readable() A race condition exists between lec_atm_close() setting priv->lecd to NULL and concurrent access to priv->lecd in send_to_lecd(), lec_handle_bridge(), and lec_atm_send(). When the socket is freed via RCU while another thread is still using it, a use-after-free occurs in sock_def_readable() when accessing the socket's wait queue. The root cause is that lec_atm_close() clears priv->lecd without any synchronization, while callers dereference priv->lecd without any protection against concurrent teardown. Fix this by converting priv->lecd to an RCU-protected pointer: - Mark priv->lecd as __rcu in lec.h - Use rcu_assign_pointer() in lec_atm_close() and lecd_attach() for safe pointer assignment - Use rcu_access_pointer() for NULL checks that do not dereference the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and lecd_attach() - Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(), lec_handle_bridge() and lec_atm_send() to safely access lecd - Use rcu_assign_pointer() followed by synchronize_rcu() in lec_atm_close() to ensure all readers have completed before proceeding. This is safe since lec_atm_close() is called from vcc_release() which holds lock_sock(), a sleeping lock. - Remove the manual sk_receive_queue drain from lec_atm_close() since vcc_destroy_socket() already drains it after lec_atm_close() returns. v2: Switch from spinlock + sock_hold/put approach to RCU to properly fix the race. The v1 spinlock approach had two issues pointed out by Eric Dumazet: 1. priv->lecd was still accessed directly after releasing the lock instead of using a local copy. 2. The spinlock did not prevent packets being queued after lec_atm_close() drains sk_receive_queue since timer and workqueue paths bypass netif_stop_queue(). Note: Syzbot patch testing was attempted but the test VM terminated unexpectedly with \"Connection to localhost closed by remote host\", likely due to a QEMU AHCI emulation issue unrelated to this fix. Compile testing with \"make W=1 net/atm/lec.o\" passes cleanly.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43051", "url": "https://ubuntu.com/security/CVE-2026-43051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq The wacom_intuos_bt_irq() function processes Bluetooth HID reports without sufficient bounds checking. A maliciously crafted short report can trigger an out-of-bounds read when copying data into the wacom structure. Specifically, report 0x03 requires at least 22 bytes to safely read the processed data and battery status, while report 0x04 (which falls through to 0x03) requires 32 bytes. Add explicit length checks for these report IDs and log a warning if a short report is received.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31555", "url": "https://ubuntu.com/security/CVE-2026-31555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Clear stale exiting pointer in futex_lock_pi() retry path Fuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524 When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'. After wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0\t\t\t CPU1\t\t CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; \t\t\t futex_lock_pi(uaddr) \t\t\t futex_lock_pi_atomic() \t\t\t\t attach_to_pi_owner() \t\t\t\t // observes EXITING \t\t\t\t *exiting = owner; // takes ref \t\t\t\t return -EBUSY \t\t\t wait_for_owner_exiting(-EBUSY, owner) \t\t\t\t put_task_struct(); // drops ref \t\t\t // exiting still points to owner \t\t\t goto retry; \t\t\t futex_lock_pi_atomic() \t\t\t\t lock_pi_update_atomic() \t\t\t\t cmpxchg(uaddr) \t\t\t\t\t*uaddr ^= WAITERS // whatever \t\t\t\t // value changed \t\t\t\t return -EAGAIN; \t\t\t wait_for_owner_exiting(-EAGAIN, exiting) // stale \t\t\t\t WARN_ON_ONCE(exiting) Fix this by resetting upon retry, essentially aligning it with requeue_pi.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43065", "url": "https://ubuntu.com/security/CVE-2026-43065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: always drain queued discard work in ext4_mb_release() While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]: > If the filesystem is initially mounted with the discard option, > deleting files will populate sbi->s_discard_list and queue > s_discard_work. If it is then remounted with nodiscard, the > EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is > neither cancelled nor flushed. [1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing. In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own. Fix it because it's a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-43066", "url": "https://ubuntu.com/security/CVE-2026-43066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths During code review, Joseph found that ext4_fc_replay_inode() calls ext4_get_fc_inode_loc() to get the inode location, which holds a reference to iloc.bh that must be released via brelse(). However, several error paths jump to the 'out' label without releasing iloc.bh: - ext4_handle_dirty_metadata() failure - sync_dirty_buffer() failure - ext4_mark_inode_used() failure - ext4_iget() failure Fix this by introducing an 'out_brelse' label placed just before the existing 'out' label to ensure iloc.bh is always released. Additionally, make ext4_fc_replay_inode() propagate errors properly instead of always returning 0.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31447", "url": "https://ubuntu.com/security/CVE-2026-31447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: reject mount if bigalloc with s_first_data_block != 0 bigalloc with s_first_data_block != 0 is not supported, reject mounting it.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43068", "url": "https://ubuntu.com/security/CVE-2026-43068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal() There's issue as follows: ... EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): error count since last fsck: 1 EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760 EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760 ... According to the log analysis, blocks are always requested from the corrupted block group. This may happen as follows: ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return error ext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out; After commit 9008a58e5dce (\"ext4: make the bitmap read routines return real error codes\") merged, Commit 163a203ddb36 (\"ext4: mark block group as corrupt on block bitmap error\") is no real solution for allocating blocks from corrupted block groups. This is because if 'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then 'ext4_mb_load_buddy()' may return an error. This means that the block allocation will fail. Therefore, check block group if corrupted when ext4_mb_load_buddy() returns error.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31452", "url": "https://ubuntu.com/security/CVE-2026-31452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: convert inline data to extents when truncate exceeds inline size Add a check in ext4_setattr() to convert files from inline data storage to extent-based storage when truncate() grows the file size beyond the inline capacity. This prevents the filesystem from entering an inconsistent state where the inline data flag is set but the file size exceeds what can be stored inline. Without this fix, the following sequence causes a kernel BUG_ON(): 1. Mount filesystem with inode that has inline flag set and small size 2. truncate(file, 50MB) - grows size but inline flag remains set 3. sendfile() attempts to write data 4. ext4_write_inline_data() hits BUG_ON(write_size > inline_capacity) The crash occurs because ext4_write_inline_data() expects inline storage to accommodate the write, but the actual inline capacity (~60 bytes for i_block + ~96 bytes for xattrs) is far smaller than the file size and write request. The fix checks if the new size from setattr exceeds the inode's actual inline capacity (EXT4_I(inode)->i_inline_size) and converts the file to extent-based storage before proceeding with the size change. This addresses the root cause by ensuring the inline data flag and file size remain consistent during truncate operations.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31455", "url": "https://ubuntu.com/security/CVE-2026-31455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: stop reclaim before pushing AIL during unmount The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while background reclaim and inodegc are still running. This is broken independently of any use-after-free issues - background reclaim and inodegc should not be running while the AIL is being pushed during unmount, as inodegc can dirty and insert inodes into the AIL during the flush, and background reclaim can race to abort and free dirty inodes. Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel background reclaim before pushing the AIL. Stop inodegc before cancelling m_reclaim_work because the inodegc worker can re-queue m_reclaim_work via xfs_inodegc_set_reclaimable.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31464", "url": "https://ubuntu.com/security/CVE-2026-31464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done() A malicious or compromised VIO server can return a num_written value in the discover targets MAD response that exceeds max_targets. This value is stored directly in vhost->num_targets without validation, and is then used as the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], which is only allocated for max_targets entries. Indices at or beyond max_targets access kernel memory outside the DMA-coherent allocation. The out-of-bounds data is subsequently embedded in Implicit Logout and PLOGI MADs that are sent back to the VIO server, leaking kernel memory. Fix by clamping num_written to max_targets before storing it.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31467", "url": "https://ubuntu.com/security/CVE-2026-31467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: add GFP_NOIO in the bio completion if needed The bio completion path in the process context (e.g. dm-verity) will directly call into decompression rather than trigger another workqueue context for minimal scheduling latencies, which can then call vm_map_ram() with GFP_KERNEL. Due to insufficient memory, vm_map_ram() may generate memory swapping I/O, which can cause submit_bio_wait to deadlock in some scenarios. Trimmed down the call stack, as follows: f2fs_submit_read_io submit_bio //bio_list is initialized. mmc_blk_mq_recovery z_erofs_endio vm_map_ram __pte_alloc_kernel __alloc_pages_direct_reclaim shrink_folio_list __swap_writepage submit_bio_wait //bio_list is non-NULL, hang!!! Use memalloc_noio_{save,restore}() to wrap up this path.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31469", "url": "https://ubuntu.com/security/CVE-2026-31469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false A UAF issue occurs when the virtio_net driver is configured with napi_tx=N and the device's IFF_XMIT_DST_RELEASE flag is cleared (e.g., during the configuration of tc route filter rules). When IFF_XMIT_DST_RELEASE is removed from the net_device, the network stack expects the driver to hold the reference to skb->dst until the packet is fully transmitted and freed. In virtio_net with napi_tx=N, skbs may remain in the virtio transmit ring for an extended period. If the network namespace is destroyed while these skbs are still pending, the corresponding dst_ops structure has freed. When a subsequent packet is transmitted, free_old_xmit() is triggered to clean up old skbs. It then calls dst_release() on the skb associated with the stale dst_entry. Since the dst_ops (referenced by the dst_entry) has already been freed, a UAF kernel paging request occurs. fix it by adds skb_dst_drop(skb) in start_xmit to explicitly release the dst reference before the skb is queued in virtio_net. Call Trace: Unable to handle kernel paging request at virtual address ffff80007e150000 CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT ... percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P) dst_release+0xe0/0x110 net/core/dst.c:177 skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177 sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255 dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469 napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527 __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net] free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net] start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net] ... Reproduction Steps: NETDEV=\"enp3s0\" config_qdisc_route_filter() { tc qdisc del dev $NETDEV root tc qdisc add dev $NETDEV root handle 1: prio tc filter add dev $NETDEV parent 1:0 \\ \tprotocol ip prio 100 route to 100 flowid 1:1 ip route add 192.168.1.100/32 dev $NETDEV realm 100 } test_ns() { ip netns add testns ip link set $NETDEV netns testns ip netns exec testns ifconfig $NETDEV 10.0.32.46/24 ip netns exec testns ping -c 1 10.0.32.1 ip netns del testns } config_qdisc_route_filter test_ns sleep 2 test_ns", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31473", "url": "https://ubuntu.com/security/CVE-2026-31473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex MEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0) queue teardown paths. This can race request object cleanup against vb2 queue cancellation and lead to use-after-free reports. We already serialize request queueing against STREAMON/OFF with req_queue_mutex. Extend that serialization to REQBUFS, and also take the same mutex in media_request_ioctl_reinit() so REINIT is in the same exclusion domain. This keeps request cleanup and queue cancellation from running in parallel for request-capable devices.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31570", "url": "https://ubuntu.com/security/CVE-2026-31570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gw: fix OOB heap access in cgw_csum_crc8_rel() cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx(): int from = calc_idx(crc8->from_idx, cf->len); int to = calc_idx(crc8->to_idx, cf->len); int res = calc_idx(crc8->result_idx, cf->len); if (from < 0 || to < 0 || res < 0) return; However, the loop and the result write then use the raw s8 fields directly instead of the computed variables: for (i = crc8->from_idx; ...) /* BUG: raw negative index */ cf->data[crc8->result_idx] = ...; /* BUG: raw negative index */ With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame, calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf->data[-64], and the write goes to cf->data[-64]. This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before the start of the canfd_frame on the heap. The companion function cgw_csum_xor_rel() uses `from`/`to`/`res` correctly throughout; fix cgw_csum_crc8_rel() to match. Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62 To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31483", "url": "https://ubuntu.com/security/CVE-2026-31483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/syscalls: Add spectre boundary for syscall dispatch table The s390 syscall number is directly controlled by userspace, but does not have an array_index_nospec() boundary to prevent access past the syscall function pointer tables.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31485", "url": "https://ubuntu.com/security/CVE-2026-31485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-lpspi: fix teardown order issue (UAF) There is a teardown order issue in the driver. The SPI controller is registered using devm_spi_register_controller(), which delays unregistration of the SPI controller until after the fsl_lpspi_remove() function returns. As the fsl_lpspi_remove() function synchronously tears down the DMA channels, a running SPI transfer triggers the following NULL pointer dereference due to use after free: | fsl_lpspi 42550000.spi: I/O Error in DMA RX | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] | Call trace: | fsl_lpspi_dma_transfer+0x260/0x340 [spi_fsl_lpspi] | fsl_lpspi_transfer_one+0x198/0x448 [spi_fsl_lpspi] | spi_transfer_one_message+0x49c/0x7c8 | __spi_pump_transfer_message+0x120/0x420 | __spi_sync+0x2c4/0x520 | spi_sync+0x34/0x60 | spidev_message+0x20c/0x378 [spidev] | spidev_ioctl+0x398/0x750 [spidev] [...] Switch from devm_spi_register_controller() to spi_register_controller() in fsl_lpspi_probe() and add the corresponding spi_unregister_controller() in fsl_lpspi_remove().", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31565", "url": "https://ubuntu.com/security/CVE-2026-31565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix deadlock during netdev reset with active connections Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering device_delete and subsequent client removal. During client removal, uverbs_client waits for QP reference count to reach zero while cma_client holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31494", "url": "https://ubuntu.com/security/CVE-2026-31494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: use the current queue number for stats There's a potential mismatch between the memory reserved for statistics and the amount of memory written. gem_get_sset_count() correctly computes the number of stats based on the active queues, whereas gem_get_ethtool_stats() indiscriminately copies data using the maximum number of queues, and in the case the number of active queues is less than MACB_MAX_QUEUES, this results in a OOB write as observed in the KASAN splat. ================================================================== BUG: KASAN: vmalloc-out-of-bounds in gem_get_ethtool_stats+0x54/0x78 [macb] Write of size 760 at addr ffff80008080b000 by task ethtool/1027 CPU: [...] Tainted: [E]=UNSIGNED_MODULE Hardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 print_report+0x384/0x5e0 kasan_report+0xa0/0xf0 kasan_check_range+0xe8/0x190 __asan_memcpy+0x54/0x98 gem_get_ethtool_stats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] dev_ethtool+0x1220/0x38c0 dev_ioctl+0x4ac/0xca8 sock_do_ioctl+0x170/0x1d8 sock_ioctl+0x484/0x5d8 __arm64_sys_ioctl+0x12c/0x1b8 invoke_syscall+0xd4/0x258 el0_svc_common.constprop.0+0xb4/0x240 do_el0_svc+0x48/0x68 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 The buggy address belongs to a 1-page vmalloc region starting at 0xffff80008080b000 allocated at dev_ethtool+0x11f0/0x38c0 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff00000a333000 pfn:0xa333 flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff) raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== Fix it by making sure the copied size only considers the active number of queues.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31495", "url": "https://ubuntu.com/security/CVE-2026-31495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: use netlink policy range checks Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors. - CTA_PROTOINFO_TCP_STATE: reject values > TCP_CONNTRACK_SYN_SENT2 at policy level, removing the manual >= TCP_CONNTRACK_MAX check. - CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values > TCP_MAX_WSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count. - CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with CTA_FILTER_F_ALL, removing the manual mask checks. - CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding a new mask define grouping all valid expect flags. Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31427", "url": "https://ubuntu.com/security/CVE-2026-31427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp process_sdp() declares union nf_inet_addr rtp_addr on the stack and passes it to the nf_nat_sip sdp_session hook after walking the SDP media descriptions. However rtp_addr is only initialized inside the media loop when a recognized media type with a non-zero port is found. If the SDP body contains no m= lines, only inactive media sections (m=audio 0 ...) or only unrecognized media types, rtp_addr is never assigned. Despite that, the function still calls hooks->sdp_session() with &rtp_addr, causing nf_nat_sdp_session() to format the stale stack value as an IP address and rewrite the SDP session owner and connection lines with it. With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this results in the session-level o= and c= addresses being rewritten to 0.0.0.0 for inactive SDP sessions. Without stack auto-init the rewritten address is whatever happened to be on the stack. Fix this by pre-initializing rtp_addr from the session-level connection address (caddr) when available, and tracking via a have_rtp_addr flag whether any valid address was established. Skip the sdp_session hook entirely when no valid address exists.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31674", "url": "https://ubuntu.com/security/CVE-2026-31674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check() Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS. rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[]. Validate addrnr during rule installation so malformed rules are rejected before the match logic can use an out-of-range value.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31428", "url": "https://ubuntu.com/security/CVE-2026-31428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD __build_packet_message() manually constructs the NFULA_PAYLOAD netlink attribute using skb_put() and skb_copy_bits(), bypassing the standard nla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes are allocated (including NLA alignment padding), only data_len bytes of actual packet data are copied. The trailing nla_padlen(data_len) bytes (1-3 when data_len is not 4-byte aligned) are never initialized, leaking stale heap contents to userspace via the NFLOG netlink socket. Replace the manual attribute construction with nla_reserve(), which handles the tailroom check, header setup, and padding zeroing via __nla_reserve(). The subsequent skb_copy_bits() fills in the payload data on top of the properly initialized attribute.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31497", "url": "https://ubuntu.com/security/CVE-2026-31497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: clamp SCO altsetting table indices btusb_work() maps the number of active SCO links to USB alternate settings through a three-entry lookup table when CVSD traffic uses transparent voice settings. The lookup currently indexes alts[] with data->sco_num - 1 without first constraining sco_num to the number of available table entries. While the table only defines alternate settings for up to three SCO links, data->sco_num comes from hci_conn_num() and is used directly. Cap the lookup to the last table entry before indexing it so the driver keeps selecting the highest supported alternate setting without reading past alts[].", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31498", "url": "https://ubuntu.com/security/CVE-2026-31498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop l2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTED state to support L2CAP reconfiguration (e.g. MTU changes). However, since both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set from the initial configuration, the reconfiguration path falls through to l2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, and retrans_list without freeing the previous allocations and sets chan->sdu to NULL without freeing the existing skb. This leaks all previously allocated ERTM resources. Additionally, l2cap_parse_conf_req() does not validate the minimum value of remote_mps derived from the RFC max_pdu_size option. A zero value propagates to l2cap_segment_sdu() where pdu_len becomes zero, causing the while loop to never terminate since len is never decremented, exhausting all available memory. Fix the double-init by skipping l2cap_ertm_init() and l2cap_chan_ready() when the channel is already in BT_CONNECTED state, while still allowing the reconfiguration parameters to be updated through l2cap_parse_conf_req(). Also add a pdu_len zero check in l2cap_segment_sdu() as a safeguard.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31507", "url": "https://ubuntu.com/security/CVE-2026-31507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffer smc_rx_splice() allocates one smc_spd_priv per pipe_buffer and stores the pointer in pipe_buffer.private. The pipe_buf_operations for these buffers used .get = generic_pipe_buf_get, which only increments the page reference count when tee(2) duplicates a pipe buffer. The smc_spd_priv pointer itself was not handled, so after tee() both the original and the cloned pipe_buffer share the same smc_spd_priv *. When both pipes are subsequently released, smc_rx_pipe_buf_release() is called twice against the same object: 1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct] 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF] KASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), which then escalates to a NULL-pointer dereference and kernel panic via smc_rx_update_consumer() when it chases the freed priv->smc pointer: BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x650 kasan_report+0xc6/0x100 smc_rx_pipe_buf_release+0x78/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smc_rx_update_consumer+0x8d/0x350 Call Trace: smc_rx_pipe_buf_release+0x121/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception Beyond the memory-safety problem, duplicating an SMC splice buffer is semantically questionable: smc_rx_update_cons() would advance the consumer cursor twice for the same data, corrupting receive-window accounting. A refcount on smc_spd_priv could fix the double-free, but the cursor-accounting issue would still need to be addressed separately. The .get callback is invoked by both tee(2) and splice_pipe_to_pipe() for partial transfers; both will now return -EFAULT. Users who need to duplicate SMC socket data must use a copy-based read path.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31679", "url": "https://ubuntu.com/security/CVE-2026-31679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: validate MPLS set/set_masked payload length validate_set() accepted OVS_KEY_ATTR_MPLS as variable-sized payload for SET/SET_MASKED actions. In action handling, OVS expects fixed-size MPLS key data (struct ovs_key_mpls). Use the already normalized key_len (masked case included) and reject non-matching MPLS action key sizes. Reject invalid MPLS action payload lengths early.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31508", "url": "https://ubuntu.com/security/CVE-2026-31508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Avoid releasing netdev before teardown completes The patch cited in the Fixes tag below changed the teardown code for OVS ports to no longer unconditionally take the RTNL. After this change, the netdev_destroy() callback can proceed immediately to the call_rcu() invocation if the IFF_OVS_DATAPATH flag is already cleared on the netdev. The ovs_netdev_detach_dev() function clears the flag before completing the unregistration, and if it gets preempted after clearing the flag (as can happen on an -rt kernel), netdev_destroy() can complete and the device can be freed before the unregistration completes. This leads to a splat like: [ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025 [ 998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0 [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90 [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246 [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000 [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0 [ 998.393944] PKRU: 55555554 [ 998.393946] Call Trace: [ 998.393949] [ 998.393952] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393961] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393975] ? dp_device_event+0x41/0x80 [openvswitch] [ 998.394009] ? __die_body.cold+0x8/0x12 [ 998.394016] ? die_addr+0x3c/0x60 [ 998.394027] ? exc_general_protection+0x16d/0x390 [ 998.394042] ? asm_exc_general_protection+0x26/0x30 [ 998.394058] ? dev_set_promiscuity+0x8d/0xa0 [ 998.394066] ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch] [ 998.394092] dp_device_event+0x41/0x80 [openvswitch] [ 998.394102] notifier_call_chain+0x5a/0xd0 [ 998.394106] unregister_netdevice_many_notify+0x51b/0xa60 [ 998.394110] rtnl_dellink+0x169/0x3e0 [ 998.394121] ? rt_mutex_slowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlink_rcv_msg+0x142/0x3f0 [ 998.394128] ? avc_has_perm_noaudit+0x69/0xf0 [ 998.394130] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 998.394132] netlink_rcv_skb+0x50/0x100 [ 998.394138] netlink_unicast+0x292/0x3f0 [ 998.394141] netlink_sendmsg+0x21b/0x470 [ 998.394145] ____sys_sendmsg+0x39d/0x3d0 [ 998.394149] ___sys_sendmsg+0x9a/0xe0 [ 998.394156] __sys_sendmsg+0x7a/0xd0 [ 998.394160] do_syscall_64+0x7f/0x170 [ 998.394162] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 998.394165] RIP: 0033:0x7fad61bf4724 [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724 [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003 [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2 ---truncated---", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31509", "url": "https://ubuntu.com/security/CVE-2026-31509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix circular locking dependency in nci_close_device nci_close_device() flushes rx_wq and tx_wq while holding req_lock. This causes a circular locking dependency because nci_rx_work() running on rx_wq can end up taking req_lock too: nci_rx_work -> nci_rx_data_packet -> nci_data_exchange_complete -> __sk_destruct -> rawsock_destruct -> nfc_deactivate_target -> nci_deactivate_target -> nci_request -> mutex_lock(&ndev->req_lock) Move the flush of rx_wq after req_lock has been released. This should safe (I think) because NCI_UP has already been cleared and the transport is closed, so the work will see it and return -ENETDOWN. NIPA has been hitting this running the nci selftest with a debug kernel on roughly 4% of the runs.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31510", "url": "https://ubuntu.com/security/CVE-2026-31510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb Before using sk pointer, check if it is null. Fix the following: KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267] CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025 Workqueue: events l2cap_info_timeout RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce veth0_macvtap: entered promiscuous mode RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: __kasan_check_byte+0x12/0x40 lock_acquire+0x79/0x2e0 lock_sock_nested+0x48/0x100 ? l2cap_sock_ready_cb+0x46/0x160 l2cap_sock_ready_cb+0x46/0x160 l2cap_conn_start+0x779/0xff0 ? __pfx_l2cap_conn_start+0x10/0x10 ? l2cap_info_timeout+0x60/0xa0 ? __pfx___mutex_lock+0x10/0x10 l2cap_info_timeout+0x68/0xa0 ? process_scheduled_works+0xa8d/0x18c0 process_scheduled_works+0xb6e/0x18c0 ? __pfx_process_scheduled_works+0x10/0x10 ? assign_work+0x3d5/0x5e0 worker_thread+0xa53/0xfc0 kthread+0x388/0x470 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x51e/0xb90 ? __pfx_ret_from_fork+0x10/0x10 veth1_macvtap: entered promiscuous mode ? __switch_to+0xc7d/0x1450 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- batman_adv: batadv0: Interface activated: batadv_slave_0 batman_adv: batadv0: Interface activated: batadv_slave_1 netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce ieee80211 phy39: Selected rate control algorithm 'minstrel_ht' RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43069", "url": "https://ubuntu.com/security/CVE-2026-43069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_ll: Fix firmware leak on error path Smatch reports: drivers/bluetooth/hci_ll.c:587 download_firmware() warn: 'fw' from request_firmware() not released on lines: 544. In download_firmware(), if request_firmware() succeeds but the returned firmware content is invalid (no data or zero size), the function returns without releasing the firmware, resulting in a resource leak. Fix this by calling release_firmware() before returning when request_firmware() succeeded but the firmware content is invalid.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31408", "url": "https://ubuntu.com/security/CVE-2026-31408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold sco_recv_frame() reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold a reference under the lock. Fix by using sco_sock_hold() to take a reference before releasing the lock, and adding sock_put() on all exit paths.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-31512", "url": "https://ubuntu.com/security/CVE-2026-31512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv() l2cap_ecred_data_rcv() reads the SDU length field from skb->data using get_unaligned_le16() without first verifying that skb contains at least L2CAP_SDULEN_SIZE (2) bytes. When skb->len is less than 2, this reads past the valid data in the skb. The ERTM reassembly path correctly calls pskb_may_pull() before reading the SDU length (l2cap_reassemble_sdu, L2CAP_SAR_START case). Apply the same validation to the Enhanced Credit Based Flow Control data path.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31515", "url": "https://ubuntu.com/security/CVE-2026-31515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_key: validate families in pfkey_send_migrate() syzbot was able to trigger a crash in skb_put() [1] Issue is that pfkey_send_migrate() does not check old/new families, and that set_ipsecrequest() @family argument was truncated, thus possibly overfilling the skb. Validate families early, do not wait set_ipsecrequest(). [1] skbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev: kernel BUG at net/core/skbuff.c:214 ! Call Trace: skb_over_panic net/core/skbuff.c:219 [inline] skb_put+0x159/0x210 net/core/skbuff.c:2655 skb_put_zero include/linux/skbuff.h:2788 [inline] set_ipsecrequest net/key/af_key.c:3532 [inline] pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636 km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848 xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705 xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31518", "url": "https://ubuntu.com/security/CVE-2026-31518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: esp: fix skb leak with espintcp and async crypto When the TX queue for espintcp is full, esp_output_tail_tcp will return an error and not free the skb, because with synchronous crypto, the common xfrm output code will drop the packet for us. With async crypto (esp_output_done), we need to drop the skb when esp_output_tail_tcp returns an error.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31521", "url": "https://ubuntu.com/security/CVE-2026-31521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: module: Fix kernel panic when a symbol st_shndx is out of bounds The module loader doesn't check for bounds of the ELF section index in simplify_symbols(): for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) { \t\tconst char *name = info->strtab + sym[i].st_name; \t\tswitch (sym[i].st_shndx) { \t\tcase SHN_COMMON: \t\t[...] \t\tdefault: \t\t\t/* Divert to percpu allocation if a percpu var. */ \t\t\tif (sym[i].st_shndx == info->index.pcpu) \t\t\t\tsecbase = (unsigned long)mod_percpu(mod); \t\t\telse /** HERE --> **/\t\tsecbase = info->sechdrs[sym[i].st_shndx].sh_addr; \t\t\tsym[i].st_value += secbase; \t\t\tbreak; \t\t} \t} A symbol with an out-of-bounds st_shndx value, for example 0xffff (known as SHN_XINDEX or SHN_HIRESERVE), may cause a kernel panic: BUG: unable to handle page fault for address: ... RIP: 0010:simplify_symbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exception This can happen when module ELF is legitimately using SHN_XINDEX or when it is corrupted. Add a bounds check in simplify_symbols() to validate that st_shndx is within the valid range before using it. This issue was discovered due to a bug in llvm-objcopy, see relevant discussion for details [1]. [1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31522", "url": "https://ubuntu.com/security/CVE-2026-31522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: avoid memory leak in magicmouse_report_fixup() The magicmouse_report_fixup() function was returning a newly kmemdup()-allocated buffer, but never freeing it. The caller of report_fixup() does not take ownership of the returned pointer, but it *is* permitted to return a sub-portion of the input rdesc, whose lifetime is managed by the caller.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31523", "url": "https://ubuntu.com/security/CVE-2026-31523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-pci: ensure we're polling a polled queue A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31524", "url": "https://ubuntu.com/security/CVE-2026-31524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: asus: avoid memory leak in asus_report_fixup() The asus_report_fixup() function was returning a newly allocated kmemdup()-allocated buffer, but never freeing it. Switch to devm_kzalloc() to ensure the memory is managed and freed automatically when the device is removed. The caller of report_fixup() does not take ownership of the returned pointer, but it is permitted to return a pointer whose lifetime is at least that of the input buffer. Also fix a harmless out-of-bounds read by copying only the original descriptor size.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31788", "url": "https://ubuntu.com/security/CVE-2026-31788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: restrict usage in unprivileged domU The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains. In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature. The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest. Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today. The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot. This is XSA-482 --- V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich)", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31540", "url": "https://ubuntu.com/security/CVE-2026-31540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Check set_default_submission() before deferencing When the i915 driver firmware binaries are not present, the set_default_submission pointer is not set. This pointer is dereferenced during suspend anyways. Add a check to make sure it is set before dereferencing. [ 23.289926] PM: suspend entry (deep) [ 23.293558] Filesystems sync: 0.000 seconds [ 23.298010] Freezing user space processes [ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds) [ 23.309766] OOM killer disabled. [ 23.313027] Freezing remaining freezable tasks [ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 23.342038] serial 00:05: disabled [ 23.345719] serial 00:02: disabled [ 23.349342] serial 00:01: disabled [ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 23.361635] ata1.00: Entering standby power mode [ 23.368863] ata2.00: Entering standby power mode [ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 23.452194] #PF: supervisor instruction fetch in kernel mode [ 23.457896] #PF: error_code(0x0010) - not-present page [ 23.463065] PGD 0 P4D 0 [ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI [ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary) [ 23.482512] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 23.496511] Workqueue: async async_run_entry_fn [ 23.501087] RIP: 0010:0x0 [ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246 [ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f [ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000 [ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff [ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8 [ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68 [ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000 [ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0 [ 23.572539] PKRU: 55555554 [ 23.575281] Call Trace: [ 23.577770] [ 23.579905] intel_engines_reset_default_submission+0x42/0x60 [ 23.585695] __intel_gt_unset_wedged+0x191/0x200 [ 23.590360] intel_gt_unset_wedged+0x20/0x40 [ 23.594675] gt_sanitize+0x15e/0x170 [ 23.598290] i915_gem_suspend_late+0x6b/0x180 [ 23.602692] i915_drm_suspend_late+0x35/0xf0 [ 23.607008] ? __pfx_pci_pm_suspend_late+0x10/0x10 [ 23.611843] dpm_run_callback+0x78/0x1c0 [ 23.615817] device_suspend_late+0xde/0x2e0 [ 23.620037] async_suspend_late+0x18/0x30 [ 23.624082] async_run_entry_fn+0x25/0xa0 [ 23.628129] process_one_work+0x15b/0x380 [ 23.632182] worker_thread+0x2a5/0x3c0 [ 23.635973] ? __pfx_worker_thread+0x10/0x10 [ 23.640279] kthread+0xf6/0x1f0 [ 23.643464] ? __pfx_kthread+0x10/0x10 [ 23.647263] ? __pfx_kthread+0x10/0x10 [ 23.651045] ret_from_fork+0x131/0x190 [ 23.654837] ? __pfx_kthread+0x10/0x10 [ 23.658634] ret_from_fork_asm+0x1a/0x30 [ 23.662597] [ 23.664826] Modules linked in: [ 23.667914] CR2: 0000000000000000 [ 23.671271] ------------[ cut here ]------------ (cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad)", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23434", "url": "https://ubuntu.com/security/CVE-2026-23434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: serialize lock/unlock against other NAND operations nand_lock() and nand_unlock() call into chip->ops.lock_area/unlock_area without holding the NAND device lock. On controllers that implement SET_FEATURES via multiple low-level PIO commands, these can race with concurrent UBI/UBIFS background erase/write operations that hold the device lock, resulting in cmd_pending conflicts on the NAND controller. Add nand_get_device()/nand_release_device() around the lock/unlock operations to serialize them against all other NAND controller access.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23398", "url": "https://ubuntu.com/security/CVE-2026-23398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: fix NULL pointer dereference in icmp_tag_validation() icmp_tag_validation() unconditionally dereferences the result of rcu_dereference(inet_protos[proto]) without checking for NULL. The inet_protos[] array is sparse -- only about 15 of 256 protocol numbers have registered handlers. When ip_no_pmtu_disc is set to 3 (hardened PMTU mode) and the kernel receives an ICMP Fragmentation Needed error with a quoted inner IP header containing an unregistered protocol number, the NULL dereference causes a kernel panic in softirq context. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) Add a NULL check before accessing icmp_strict_tag_validation. If the protocol has no registered handler, return false since it cannot perform strict tag validation.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-23438", "url": "https://ubuntu.com/security/CVE-2026-23438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: guard flow control update with global_tx_fc in buffer switching mvpp2_bm_switch_buffers() unconditionally calls mvpp2_bm_pool_update_priv_fc() when switching between per-cpu and shared buffer pool modes. This function programs CM3 flow control registers via mvpp2_cm3_read()/mvpp2_cm3_write(), which dereference priv->cm3_base without any NULL check. When the CM3 SRAM resource is not present in the device tree (the third reg entry added by commit 60523583b07c (\"dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree\")), priv->cm3_base remains NULL and priv->global_tx_fc is false. Any operation that triggers mvpp2_bm_switch_buffers(), for example an MTU change that crosses the jumbo frame threshold, will crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2_cm3_read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2_bm_pool_update_fc+0x40/0x12c mvpp2_bm_pool_update_priv_fc+0x94/0xd8 mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0 mvpp2_change_mtu+0x140/0x380 __dev_set_mtu+0x1c/0x38 dev_set_mtu_ext+0x78/0x118 dev_set_mtu+0x48/0xa8 dev_ifsioc+0x21c/0x43c dev_ioctl+0x2d8/0x42c sock_ioctl+0x314/0x378 Every other flow control call site in the driver already guards hardware access with either priv->global_tx_fc or port->tx_fc. mvpp2_bm_switch_buffers() is the only place that omits this check. Add the missing priv->global_tx_fc guard to both the disable and re-enable calls in mvpp2_bm_switch_buffers(), consistent with the rest of the driver.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23397", "url": "https://ubuntu.com/security/CVE-2026-23397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfnetlink_osf: validate individual option lengths in fingerprints nfnl_osf_add_callback() validates opt_num bounds and string NUL-termination but does not check individual option length fields. A zero-length option causes nf_osf_match_one() to enter the option matching loop even when foptsize sums to zero, which matches packets with no TCP options where ctx->optp is NULL: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:227) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:293) nf_hook_slow (net/netfilter/core.c:623) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) Additionally, an MSS option (kind=2) with length < 4 causes out-of-bounds reads when nf_osf_match_one() unconditionally accesses optp[2] and optp[3] for MSS value extraction. While RFC 9293 section 3.2 specifies that the MSS option is always exactly 4 bytes (Kind=2, Length=4), the check uses \"< 4\" rather than \"!= 4\" because lengths greater than 4 do not cause memory safety issues -- the buffer is guaranteed to be at least foptsize bytes by the ctx->optsize == foptsize check. Reject fingerprints where any option has zero length, or where an MSS option has length less than 4, at add time rather than trusting these values in the packet matching hot path.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-31546", "url": "https://ubuntu.com/security/CVE-2026-31546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL deref in bond_debug_rlb_hash_show rlb_clear_slave intentionally keeps RLB hash-table entries on the rx_hashtbl_used_head list with slave set to NULL when no replacement slave is available. However, bond_debug_rlb_hash_show visites client_info->slave without checking if it's NULL. Other used-list iterators in bond_alb.c already handle this NULL-slave state safely: - rlb_update_client returns early on !client_info->slave - rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalance compare slave values before visiting - lb_req_update_subnet_clients continues if slave is NULL The following NULL deref crash can be trigger in bond_debug_rlb_hash_show: [ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seq_read_iter (fs/seq_file.c:231) [ 1.296341] seq_read (fs/seq_file.c:164) [ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfs_read (fs/read_write.c:572) [ 1.296981] ksys_read (fs/read_write.c:717) [ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) [ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add a NULL check and print \"(none)\" for entries with no assigned slave.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23439", "url": "https://ubuntu.com/security/CVE-2026-23439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n When CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0 (success) without actually creating a socket. Callers such as fou_create() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference. The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764) [...] Call Trace: genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130) This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23396", "url": "https://ubuntu.com/security/CVE-2026-23396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix NULL deref in mesh_matches_local() mesh_matches_local() unconditionally dereferences ie->mesh_config to compare mesh configuration parameters. When called from mesh_rx_csa_frame(), the parsed action-frame elements may not contain a Mesh Configuration IE, leaving ie->mesh_config NULL and triggering a kernel NULL pointer dereference. The other two callers are already safe: - ieee80211_mesh_rx_bcn_presp() checks !elems->mesh_config before calling mesh_matches_local() - mesh_plink_get_event() is only reached through mesh_process_plink_frame(), which checks !elems->mesh_config, too mesh_rx_csa_frame() is the only caller that passes raw parsed elements to mesh_matches_local() without guarding mesh_config. An adjacent attacker can exploit this by sending a crafted CSA action frame that includes a valid Mesh ID IE but omits the Mesh Configuration IE, crashing the kernel. The captured crash log: Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events_unbound cfg80211_wiphy_work [...] Call Trace: ? __pfx_mesh_matches_local (net/mac80211/mesh.c:65) ieee80211_mesh_rx_queued_mgmt (net/mac80211/mesh.c:1686) [...] ieee80211_iface_work (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802) [...] cfg80211_wiphy_work (net/wireless/core.c:426) process_one_work (net/kernel/workqueue.c:3280) ? assign_work (net/kernel/workqueue.c:1219) worker_thread (net/kernel/workqueue.c:3352) ? __pfx_worker_thread (net/kernel/workqueue.c:3385) kthread (net/kernel/kthread.c:436) [...] ret_from_fork_asm (net/arch/x86/entry/entry_64.S:255) This patch adds a NULL check for ie->mesh_config at the top of mesh_matches_local() to return false early when the Mesh Configuration IE is absent.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-23446", "url": "https://ubuntu.com/security/CVE-2026-23446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: Do not perform PM inside suspend callback syzbot reports \"task hung in rpm_resume\" This is caused by aqc111_suspend calling the PM variant of its write_cmd routine. The simplified call trace looks like this: rpm_suspend() usb_suspend_both() - here udev->dev.power.runtime_status == RPM_SUSPENDING aqc111_suspend() - called for the usb device interface aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() - here we call rpm_resume() on our parent rpm_resume() - Here we wait for a status change that will never happen. At this point we block another task which holds rtnl_lock and locks up the whole networking stack. Fix this by replacing the write_cmd calls with their _nopm variants", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23452", "url": "https://ubuntu.com/security/CVE-2026-23452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM: runtime: Fix a race condition related to device removal The following code in pm_runtime_work() may dereference the dev->parent pointer after the parent device has been freed: \t/* Maybe the parent is now able to suspend. */ \tif (parent && !parent->power.ignore_children) { \t\tspin_unlock(&dev->power.lock); \t\tspin_lock(&parent->power.lock); \t\trpm_idle(parent, RPM_ASYNC); \t\tspin_unlock(&parent->power.lock); \t\tspin_lock(&dev->power.lock); \t} Fix this by inserting a flush_work() call in pm_runtime_remove(). Without this patch blktest block/001 triggers the following complaint sporadically: BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160 Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081 Workqueue: pm pm_runtime_work Call Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0 __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160 _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 Allocated by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50 __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23454", "url": "https://ubuntu.com/security/CVE-2026-23454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: fix use-after-free in mana_hwc_destroy_channel() by reordering teardown A potential race condition exists in mana_hwc_destroy_channel() where hwc->caller_ctx is freed before the HWC's Completion Queue (CQ) and Event Queue (EQ) are destroyed. This allows an in-flight CQ interrupt handler to dereference freed memory, leading to a use-after-free or NULL pointer dereference in mana_hwc_handle_resp(). mana_smc_teardown_hwc() signals the hardware to stop but does not synchronize against IRQ handlers already executing on other CPUs. The IRQ synchronization only happens in mana_hwc_destroy_cq() via mana_gd_destroy_eq() -> mana_gd_deregister_irq(). Since this runs after kfree(hwc->caller_ctx), a concurrent mana_hwc_rx_event_handler() can dereference freed caller_ctx (and rxq->msg_buf) in mana_hwc_handle_resp(). Fix this by reordering teardown to reverse-of-creation order: destroy the TX/RX work queues and CQ/EQ before freeing hwc->caller_ctx. This ensures all in-flight interrupt handlers complete before the memory they access is freed.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23391", "url": "https://ubuntu.com/security/CVE-2026-23391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_CT: drop pending enqueued packets on template removal Templates refer to objects that can go away while packets are sitting in nfqueue refer to: - helper, this can be an issue on module removal. - timeout policy, nfnetlink_cttimeout might remove it. The use of templates with zone and event cache filter are safe, since this just copies values. Flush these enqueued packets in case the template rule gets removed.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43060", "url": "https://ubuntu.com/security/CVE-2026-43060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: drop pending enqueued packets on removal Packets sitting in nfqueue might hold a reference to: - templates that specify the conntrack zone, because a percpu area is used and module removal is possible. - conntrack timeout policies and helper, where object removal leave a stale reference. Since these objects can just go away, drop enqueued packets to avoid stale reference to them. If there is a need for finer grain removal, this logic can be revisited to make selective packet drop upon dependencies.", "cve_priority": "high", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2025-68206", "url": "https://ubuntu.com/security/CVE-2025-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: add seqadj extension for natted connections Sequence adjustment may be required for FTP traffic with PASV/EPSV modes. due to need to re-write packet payload (IP, port) on the ftp control connection. This can require changes to the TCP length and expected seq / ack_seq. The easiest way to reproduce this issue is with PASV mode. Example ruleset: table inet ftp_nat { ct helper ftp_helper { type \"ftp\" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set \"ftp_helper\" } } table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { \t\t\t192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { \t\t\t192.168.13.2 : 192.168.100.1/32 } } } Note that the ftp helper gets assigned *after* the dnat setup. The inverse (nat after helper assign) is handled by an existing check in nf_nat_setup_info() and will not show the problem. Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ ftp nat changes do not work as expected in this case: Connected to 192.168.100.1. [..] ftp> epsv EPSV/EPRT on IPv4 off. ftp> ls 227 Entering passive mode (192,168,100,1,209,129). 421 Service not available, remote server has closed connection. Kernel logs: Missing nfct_seqadj_ext_add() setup call WARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41 [..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 .. Fix this by adding the required extension when a conntrack helper is assigned to a connection that has a nat binding.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-23456", "url": "https://ubuntu.com/security/CVE-2026-23456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case In decode_int(), the CONS case calls get_bits(bs, 2) to read a length value, then calls get_uint(bs, len) without checking that len bytes remain in the buffer. The existing boundary check only validates the 2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint() reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte slab-out-of-bounds read. Add a boundary check for len bytes after get_bits() and before get_uint().", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23457", "url": "https://ubuntu.com/security/CVE-2026-23457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp() sip_help_tcp() parses the SIP Content-Length header with simple_strtoul(), which returns unsigned long, but stores the result in unsigned int clen. On 64-bit systems, values exceeding UINT_MAX are silently truncated before computing the SIP message boundary. For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32, causing the parser to miscalculate where the current message ends. The loop then treats trailing data in the TCP segment as a second SIP message and processes it through the SDP parser. Fix this by changing clen to unsigned long to match the return type of simple_strtoul(), and reject Content-Length values that exceed the remaining TCP payload length.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23458", "url": "https://ubuntu.com/security/CVE-2026-23458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct() ctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for the netlink dump callback ctnetlink_exp_ct_dump_table(), but drops the conntrack reference immediately after netlink_dump_start(). When the dump spans multiple rounds, the second recvmsg() triggers the dump callback which dereferences the now-freed conntrack via nfct_help(ct), leading to a use-after-free on ct->ext. The bug is that the netlink_dump_control has no .start or .done callbacks to manage the conntrack reference across dump rounds. Other dump functions in the same file (e.g. ctnetlink_get_conntrack) properly use .start/.done callbacks for this purpose. Fix this by adding .start and .done callbacks that hold and release the conntrack reference for the duration of the dump, and move the nfct_help() call after the cb->args[0] early-return check in the dump callback to avoid dereferencing ct->ext unnecessarily. BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133 CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 ? aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0 Allocated by task 133: kmem_cache_alloc_noprof+0x134/0x440 __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180 Freed by task 0: slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2025-39764", "url": "https://ubuntu.com/security/CVE-2025-39764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: remove refcounting in expectation dumpers Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption. AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcount_inc_not_zero(&exp->use)) to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2026-23460", "url": "https://ubuntu.com/security/CVE-2026-23460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect syzkaller reported a bug [1], and the reproducer is available at [2]. ROSE sockets use four sk->sk_state values: TCP_CLOSE, TCP_LISTEN, TCP_SYN_SENT, and TCP_ESTABLISHED. rose_connect() already rejects calls for TCP_ESTABLISHED (-EISCONN) and TCP_CLOSE with SS_CONNECTING (-ECONNREFUSED), but lacks a check for TCP_SYN_SENT. When rose_connect() is called a second time while the first connection attempt is still in progress (TCP_SYN_SENT), it overwrites rose->neighbour via rose_get_neigh(). If that returns NULL, the socket is left with rose->state == ROSE_STATE_1 but rose->neighbour == NULL. When the socket is subsequently closed, rose_release() sees ROSE_STATE_1 and calls rose_write_internal() -> rose_transmit_link(skb, NULL), causing a NULL pointer dereference. Per connect(2), a second connect() while a connection is already in progress should return -EALREADY. Add this missing check for TCP_SYN_SENT to complete the state validation in rose_connect(). [1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271 [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23462", "url": "https://ubuntu.com/security/CVE-2026-23462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: Fix possible UAF This fixes the following trace caused by not dropping l2cap_conn reference when user->remove callback is called: [ 97.809249] l2cap_conn_free: freeing conn ffff88810a171c00 [ 97.809907] CPU: 1 UID: 0 PID: 1419 Comm: repro_standalon Not tainted 7.0.0-rc1-dirty #14 PREEMPT(lazy) [ 97.809935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 97.809947] Call Trace: [ 97.809954] [ 97.809961] dump_stack_lvl (lib/dump_stack.c:122) [ 97.809990] l2cap_conn_free (net/bluetooth/l2cap_core.c:1808) [ 97.810017] l2cap_conn_del (./include/linux/kref.h:66 net/bluetooth/l2cap_core.c:1821 net/bluetooth/l2cap_core.c:1798) [ 97.810055] l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7347 (discriminator 1) net/bluetooth/l2cap_core.c:7340 (discriminator 1)) [ 97.810086] ? __pfx_l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7341) [ 97.810117] hci_conn_hash_flush (./include/net/bluetooth/hci_core.h:2152 (discriminator 2) net/bluetooth/hci_conn.c:2644 (discriminator 2)) [ 97.810148] hci_dev_close_sync (net/bluetooth/hci_sync.c:5360) [ 97.810180] ? __pfx_hci_dev_close_sync (net/bluetooth/hci_sync.c:5285) [ 97.810212] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810242] ? up_write (./arch/x86/include/asm/atomic64_64.h:87 (discriminator 5) ./include/linux/atomic/atomic-arch-fallback.h:2852 (discriminator 5) ./include/linux/atomic/atomic-long.h:268 (discriminator 5) ./include/linux/atomic/atomic-instrumented.h:3391 (discriminator 5) kernel/locking/rwsem.c:1385 (discriminator 5) kernel/locking/rwsem.c:1643 (discriminator 5)) [ 97.810267] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810290] ? rcu_is_watching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/context_tracking.h:128 kernel/rcu/tree.c:752) [ 97.810320] hci_unregister_dev (net/bluetooth/hci_core.c:504 net/bluetooth/hci_core.c:2716) [ 97.810346] vhci_release (drivers/bluetooth/hci_vhci.c:691) [ 97.810375] ? __pfx_vhci_release (drivers/bluetooth/hci_vhci.c:678) [ 97.810404] __fput (fs/file_table.c:470) [ 97.810430] task_work_run (kernel/task_work.c:235) [ 97.810451] ? __pfx_task_work_run (kernel/task_work.c:201) [ 97.810472] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810495] ? do_raw_spin_unlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlock_debug.c:142 (discriminator 5)) [ 97.810527] do_exit (kernel/exit.c:972) [ 97.810547] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810574] ? __pfx_do_exit (kernel/exit.c:897) [ 97.810594] ? lock_acquire (kernel/locking/lockdep.c:470 (discriminator 6) kernel/locking/lockdep.c:5870 (discriminator 6) kernel/locking/lockdep.c:5825 (discriminator 6)) [ 97.810616] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810639] ? do_raw_spin_lock (kernel/locking/spinlock_debug.c:95 (discriminator 4) kernel/locking/spinlock_debug.c:118 (discriminator 4)) [ 97.810664] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810688] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1)) [ 97.810721] do_group_exit (kernel/exit.c:1093) [ 97.810745] get_signal (kernel/signal.c:3007 (discriminator 1)) [ 97.810772] ? security_file_permission (./arch/x86/include/asm/jump_label.h:37 security/security.c:2366) [ 97.810803] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810826] ? vfs_read (fs/read_write.c:555) [ 97.810854] ? __pfx_get_signal (kernel/signal.c:2800) [ 97.810880] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810905] ? __pfx_vfs_read (fs/read_write.c:555) [ 97.810932] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810960] arch_do_signal_or_restart (arch/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31551", "url": "https://ubuntu.com/security/CVE-2026-31551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Fix static_branch_dec() underflow for aql_disable. syzbot reported static_branch_dec() underflow in aql_enable_write(). [0] The problem is that aql_enable_write() does not serialise concurrent write()s to the debugfs. aql_enable_write() checks static_key_false(&aql_disable.key) and later calls static_branch_inc() or static_branch_dec(), but the state may change between the two calls. aql_disable does not need to track inc/dec. Let's use static_branch_enable() and static_branch_disable(). [0]: val == 0 WARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288 Modules linked in: CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full) Tainted: [U]=USER, [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311 Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 <0f> 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00 RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4 RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a R13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98 FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0 Call Trace: __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline] __static_key_slow_dec kernel/jump_label.c:321 [inline] static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336 aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343 short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383 vfs_write+0x2aa/0x1070 fs/read_write.c:684 ksys_pwrite64 fs/read_write.c:793 [inline] __do_sys_pwrite64 fs/read_write.c:801 [inline] __se_sys_pwrite64 fs/read_write.c:798 [inline] __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f530cf9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012 RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010 RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000 R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978 ", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23463", "url": "https://ubuntu.com/security/CVE-2026-23463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: fix race condition in qman_destroy_fq When QMAN_FQ_FLAG_DYNAMIC_FQID is set, there's a race condition between fq_table[fq->idx] state and freeing/allocating from the pool and WARN_ON(fq_table[fq->idx]) in qman_create_fq() gets triggered. Indeed, we can have: Thread A Thread B qman_destroy_fq() qman_create_fq() qman_release_fqid() qman_shutdown_fq() gen_pool_free() -- At this point, the fqid is available again -- qman_alloc_fqid() -- so, we can get the just-freed fqid in thread B -- fq->fqid = fqid; fq->idx = fqid * 2; WARN_ON(fq_table[fq->idx]); fq_table[fq->idx] = fq; fq_table[fq->idx] = NULL; And adding some logs between qman_release_fqid() and fq_table[fq->idx] = NULL makes the WARN_ON() trigger a lot more. To prevent that, ensure that fq_table[fq->idx] is set to NULL before gen_pool_free() is called by using smp_wmb().", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31683", "url": "https://ubuntu.com/security/CVE-2026-31683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: avoid OGM aggregation when skb tailroom is insufficient When OGM aggregation state is toggled at runtime, an existing forwarded packet may have been allocated with only packet_len bytes, while a later packet can still be selected for aggregation. Appending in this case can hit skb_put overflow conditions. Reject aggregation when the target skb tailroom cannot accommodate the new packet. The caller then falls back to creating a new forward packet instead of appending.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31550", "url": "https://ubuntu.com/security/CVE-2026-31550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: bcm: bcm2835-power: Increase ASB control timeout The bcm2835_asb_control() function uses a tight polling loop to wait for the ASB bridge to acknowledge a request. During intensive workloads, this handshake intermittently fails for V3D's master ASB on BCM2711, resulting in \"Failed to disable ASB master for v3d\" errors during runtime PM suspend. As a consequence, the failed power-off leaves V3D in a broken state, leading to bus faults or system hangs on later accesses. As the timeout is insufficient in some scenarios, increase the polling timeout from 1us to 5us, which is still negligible in the context of a power domain transition. Also, replace the open-coded ktime_get_ns()/ cpu_relax() polling loop with readl_poll_timeout_atomic().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23368", "url": "https://ubuntu.com/security/CVE-2026-23368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: register phy led_triggers during probe to avoid AB-BA deadlock There is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and LED_TRIGGER_PHY are enabled: [ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc <-- Trying to get lock \"triggers_list_lock\" via down_write(&triggers_list_lock); [ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234 [ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c [ 1362.065489] [<80651fc4>] phylink_fwnode_phy_connect+0x15c/0x23c [ 1362.071480] [<8066ee18>] mtk_open+0x7c/0xba0 [ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0 [ 1362.080384] [<806d7668>] __dev_change_flags+0x244/0x24c [ 1362.085598] [<806d7698>] dev_change_flags+0x28/0x78 [ 1362.090528] [<807150e4>] dev_ioctl+0x4c0/0x654 <-- Hold lock \"rtnl_mutex\" by calling rtnl_lock(); [ 1362.094985] [<80694360>] sock_ioctl+0x2f4/0x4e0 [ 1362.099567] [<802e9c4c>] sys_ioctl+0x32c/0xd8c [ 1362.104022] [<80014504>] syscall_common+0x34/0x58 Here LED_TRIGGER_PHY is registering LED triggers during phy_attach while holding RTNL and then taking triggers_list_lock. [ 1362.191101] [<806c2640>] register_netdevice_notifier+0x60/0x168 <-- Trying to get lock \"rtnl_mutex\" via rtnl_lock(); [ 1362.197073] [<805504ac>] netdev_trig_activate+0x194/0x1e4 [ 1362.202490] [<8054e28c>] led_trigger_set+0x1d4/0x360 <-- Hold lock \"triggers_list_lock\" by down_read(&triggers_list_lock); [ 1362.207511] [<8054eb38>] led_trigger_write+0xd8/0x14c [ 1362.212566] [<80381d98>] sysfs_kf_bin_write+0x80/0xbc [ 1362.217688] [<8037fcd8>] kernfs_fop_write_iter+0x17c/0x28c [ 1362.223174] [<802cbd70>] vfs_write+0x21c/0x3c4 [ 1362.227712] [<802cc0c4>] ksys_write+0x78/0x12c [ 1362.232164] [<80014504>] syscall_common+0x34/0x58 Here LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takes triggers_list_lock and then RTNL. A classical AB-BA deadlock. phy_led_triggers_registers() does not require the RTNL, it does not make any calls into the network stack which require protection. There is also no requirement the PHY has been attached to a MAC, the triggers only make use of phydev state. This allows the call to phy_led_triggers_registers() to be placed elsewhere. PHY probe() and release() don't hold RTNL, so solving the AB-BA deadlock.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23303", "url": "https://ubuntu.com/security/CVE-2026-23303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Don't log plaintext credentials in cifs_set_cifscreds When debug logging is enabled, cifs_set_cifscreds() logs the key payload and exposes the plaintext username and password. Remove the debug log to avoid exposing credentials.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23335", "url": "https://ubuntu.com/security/CVE-2026-23335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah() struct irdma_create_ah_resp { // 8 bytes, no padding __u32 ah_id; // offset 0 - SET (uresp.ah_id = ah->sc_ah.ah_info.ah_idx) __u8 rsvd[4]; // offset 4 - NEVER SET <- LEAK }; rsvd[4]: 4 bytes of stack memory leaked unconditionally. Only ah_id is assigned before ib_respond_udata(). The reserved members of the structure were not zeroed.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23336", "url": "https://ubuntu.com/security/CVE-2026-23336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel rfkill_block work in wiphy_unregister() There is a use-after-free error in cfg80211_shutdown_all_interfaces found by syzkaller: BUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220 Read of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326 CPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events cfg80211_rfkill_block_work Call Trace: dump_stack_lvl+0x116/0x1f0 print_report+0xcd/0x630 kasan_report+0xe0/0x110 cfg80211_shutdown_all_interfaces+0x213/0x220 cfg80211_rfkill_block_work+0x1e/0x30 process_one_work+0x9cf/0x1b70 worker_thread+0x6c8/0xf10 kthread+0x3c5/0x780 ret_from_fork+0x56d/0x700 ret_from_fork_asm+0x1a/0x30 The problem arises due to the rfkill_block work is not cancelled when wiphy is being unregistered. In order to fix the issue cancel the corresponding work in wiphy_unregister(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23281", "url": "https://ubuntu.com/security/CVE-2026-23281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix use-after-free in lbs_free_adapter() The lbs_free_adapter() function uses timer_delete() (non-synchronous) for both command_timer and tx_lockup_timer before the structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If a timer callback is executing when lbs_free_adapter() is called, the callback will access freed memory since lbs_cfg_free() frees the containing structure immediately after lbs_free_adapter() returns. Both timer callbacks (lbs_cmd_timeout_handler and lbs_tx_lockup_handler) access priv->driver_lock, priv->cur_cmd, priv->dev, and other fields, which would all be use-after-free violations. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning. This bug was introduced in commit 8f641d93c38a (\"libertas: detect TX lockups and reset hardware\") where del_timer() was used instead of del_timer_sync() in the cleanup path. The command_timer has had the same issue since the driver was first written.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-38562", "url": "https://ubuntu.com/security/CVE-2025-38562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference error in generate_encryptionkey If client send two session setups with krb5 authenticate to ksmbd, null pointer dereference error in generate_encryptionkey could happen. sess->Preauth_HashValue is set to NULL if session is valid. So this patch skip generate encryption key if session is valid.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2026-45920", "url": "https://ubuntu.com/security/CVE-2026-45920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix dirtyclusters double decrement on fs shutdown fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count: WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4] Tracing the failure shows that the warning fires due to an s_dirtyclusters_counter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4_mb_mark_diskspace_used() and the caller ext4_mb_new_blocks(). First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4_handle_dirty_metadata() call(s) made from ext4_mb_mark_context(). The changed value is non-zero at this point, so ext4_mb_mark_diskspace_used() does not exit after the error bubbles up from ext4_mb_mark_context(). Instead, the former decrements both cluster counters and returns the error up to ext4_mb_new_blocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency. To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4_mb_new_blocks() is responsible for acquiring cluster reservation (via ext4_claim_free_clusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45899", "url": "https://ubuntu.com/security/CVE-2026-45899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop extent cache when splitting extent fails When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45985", "url": "https://ubuntu.com/security/CVE-2026-45985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues. Assume we have an unwritten extent, and then DIO writes the second half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set. Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree. [0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone. Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45924", "url": "https://ubuntu.com/security/CVE-2026-45924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths There are two places where ksmbd_vfs_kern_path_end_removing() needs to be called in order to balance what the corresponding successful call to ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and put the taken references. Otherwise there might be potential deadlocks and unbalanced locks which are caught like: BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work 2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660 CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30 Found by Linux Verification Center (linuxtesting.org).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23227", "url": "https://ubuntu.com/security/CVE-2026-23227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/free Exynos Virtual Display driver performs memory alloc/free operations without lock protection, which easily causes concurrency problem. For example, use-after-free can occur in race scenario like this: ``` \tCPU0\t\t\t\tCPU1\t\t\t\tCPU2 \t----\t\t\t\t----\t\t\t\t---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... \t\t\t\t\t\t\t\tdrm_mode_getconnector() \t\t\t\t\t\t\t\t drm_helper_probe_single_connector_modes() \t\t\t\t\t\t\t\t vidi_get_modes() \t\t\t\t\t\t\t\t if (ctx->raw_edid) // true \t\t\t\t\t\t\t\t drm_edid_dup(ctx->raw_edid); \t\t\t\t\t\t\t\t if (!drm_edid) // false \t\t\t\t\t\t\t\t ... \t\t\t\tvidi_connection_ioctl() \t\t\t\t if (vidi->connection) // false \t\t\t\t drm_edid_free(ctx->raw_edid); // free drm_edid \t\t\t\t ... \t\t\t\t\t\t\t\t drm_edid_alloc(drm_edid->edid) \t\t\t\t\t\t\t\t kmemdup(edid); // UAF!! \t\t\t\t\t\t\t\t ... ``` To prevent these vulns, at least in vidi_context, member variables related to memory alloc/free should be protected with ctx->lock.", "cve_priority": "high", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-45958", "url": "https://ubuntu.com/security/CVE-2026-45958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: fix to avoid directly dereferencing user pointer In vidi_connection_ioctl(), vidi->edid(user pointer) is directly dereferenced in the kernel. This allows arbitrary kernel memory access from the user space, so instead of directly accessing the user pointer in the kernel, we should modify it to copy edid to kernel memory using copy_from_user() and use it.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45956", "url": "https://ubuntu.com/security/CVE-2026-45956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl() vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to obtain a struct vidi_context pointer. However, drm_dev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device. This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more. To resolve this issue, we need to store/delete the vidi device pointer in exynos_drm_private->vidi_dev during bind/unbind, and then read this exynos_drm_private->vidi_dev within ioctl() to obtain the correct struct vidi_context pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23100", "url": "https://ubuntu.com/security/CVE-2026-23100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb_pmd_shared() Patch series \"mm/hugetlb: fixes for PMD table sharing (incl. using mmu_gather)\", v3. One functional fix, one performance regression fix, and two related comment fixes. I cleaned up my prototype I recently shared [1] for the performance fix, deferring most of the cleanups I had in the prototype to a later point. While doing that I identified the other things. The goal of this patch set is to be backported to stable trees \"fairly\" easily. At least patch #1 and #4. Patch #1 fixes hugetlb_pmd_shared() not detecting any sharing Patch #2 + #3 are simple comment fixes that patch #4 interacts with. Patch #4 is a fix for the reported performance regression due to excessive IPI broadcasts during fork()+exit(). The last patch is all about TLB flushes, IPIs and mmu_gather. Read: complicated There are plenty of cleanups in the future to be had + one reasonable optimization on x86. But that's all out of scope for this series. Runtime tested, with a focus on fixing the performance regression using the original reproducer [2] on x86. This patch (of 4): We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->pt_share_count to identify sharing. We didn't convert hugetlb_pmd_shared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table. Page migration, like mbind() or migrate_pages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as \"private\" although they are \"shared\", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the pagemap interface. Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-43061", "url": "https://ubuntu.com/security/CVE-2026-43061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Fix TX deadlock when using DMA `dmaengine_terminate_async` does not guarantee that the `__dma_tx_complete` callback will run. The callback is currently the only place where `dma->tx_running` gets cleared. If the transaction is canceled and the callback never runs, then `dma->tx_running` will never get cleared and we will never schedule new TX DMA transactions again. This change makes it so we clear `dma->tx_running` after we terminate the DMA transaction. This is \"safe\" because `serial8250_tx_dma_flush` is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to `dma->tx_running` is serialized.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-23474", "url": "https://ubuntu.com/security/CVE-2026-23474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: Avoid boot crash in RedBoot partition table parser Given CONFIG_FORTIFY_SOURCE=y and a recent compiler, commit 439a1bcac648 (\"fortify: Use __builtin_dynamic_object_size() when available\") produces the warning below and an oops. Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000 ------------[ cut here ]------------ WARNING: lib/string_helpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1 memcmp: detected buffer overflow: 15 byte read of buffer size 14 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONE As Kees said, \"'names' is pointing to the final 'namelen' many bytes of the allocation ... 'namelen' could be basically any length at all. This fortify warning looks legit to me -- this code used to be reading beyond the end of the allocation.\" Since the size of the dynamic allocation is calculated with strlen() we can use strcmp() instead of memcmp() and remain within bounds.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31393", "url": "https://ubuntu.com/security/CVE-2026-31393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present: - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8). - L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5). A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data. Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43062", "url": "https://ubuntu.com/security/CVE-2026-43062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp() l2cap_ecred_reconf_rsp() casts the incoming data to struct l2cap_ecred_conn_rsp (the ECRED *connection* response, 8 bytes with result at offset 6) instead of struct l2cap_ecred_reconf_rsp (2 bytes with result at offset 0). This causes two problems: - The sizeof(*rsp) length check requires 8 bytes instead of the correct 2, so valid L2CAP_ECRED_RECONF_RSP packets are rejected with -EPROTO. - rsp->result reads from offset 6 instead of offset 0, returning wrong data when the packet is large enough to pass the check. Fix by using the correct type. Also pass the already byte-swapped result variable to BT_DBG instead of the raw __le16 field.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31396", "url": "https://ubuntu.com/security/CVE-2026-31396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix use-after-free access to PTP clock PTP clock is registered on every opening of the interface and destroyed on every closing. However it may be accessed via get_ts_info ethtool call which is possible while the interface is just present in the kernel. BUG: KASAN: use-after-free in ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 Read of size 4 at addr ffff8880194345cc by task syz.0.6/948 CPU: 1 PID: 948 Comm: syz.0.6 Not tainted 6.1.164+ #109 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x17f/0x496 mm/kasan/report.c:420 kasan_report+0xd9/0x180 mm/kasan/report.c:524 ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 gem_get_ts_info+0x138/0x1e0 drivers/net/ethernet/cadence/macb_main.c:3349 macb_get_ts_info+0x68/0xb0 drivers/net/ethernet/cadence/macb_main.c:3371 __ethtool_get_ts_info+0x17c/0x260 net/ethtool/common.c:558 ethtool_get_ts_info net/ethtool/ioctl.c:2367 [inline] __dev_ethtool net/ethtool/ioctl.c:3017 [inline] dev_ethtool+0x2b05/0x6290 net/ethtool/ioctl.c:3095 dev_ioctl+0x637/0x1070 net/core/dev_ioctl.c:510 sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215 sock_ioctl+0x577/0x6d0 net/socket.c:1320 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 457: kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:699 [inline] ptp_clock_register+0x144/0x10e0 drivers/ptp/ptp_clock.c:235 gem_ptp_init+0x46f/0x930 drivers/net/ethernet/cadence/macb_ptp.c:375 macb_open+0x901/0xd10 drivers/net/ethernet/cadence/macb_main.c:2920 __dev_open+0x2ce/0x500 net/core/dev.c:1501 __dev_change_flags+0x56a/0x740 net/core/dev.c:8651 dev_change_flags+0x92/0x170 net/core/dev.c:8722 do_setlink+0xaf8/0x3a80 net/core/rtnetlink.c:2833 __rtnl_newlink+0xbf4/0x1940 net/core/rtnetlink.c:3608 rtnl_newlink+0x63/0xa0 net/core/rtnetlink.c:3655 rtnetlink_rcv_msg+0x3c6/0xed0 net/core/rtnetlink.c:6150 netlink_rcv_skb+0x15d/0x430 net/netlink/af_netlink.c:2511 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x6d7/0xa30 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x97e/0xeb0 net/netlink/af_netlink.c:1872 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x14b/0x180 net/socket.c:730 __sys_sendto+0x320/0x3b0 net/socket.c:2152 __do_sys_sendto net/socket.c:2164 [inline] __se_sys_sendto net/socket.c:2160 [inline] __x64_sys_sendto+0xdc/0x1b0 net/socket.c:2160 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 938: kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1729 [inline] slab_free_freelist_hook mm/slub.c:1755 [inline] slab_free mm/slub.c:3687 [inline] __kmem_cache_free+0xbc/0x320 mm/slub.c:3700 device_release+0xa0/0x240 drivers/base/core.c:2507 kobject_cleanup lib/kobject.c:681 [inline] kobject_release lib/kobject.c:712 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1cd/0x350 lib/kobject.c:729 put_device+0x1b/0x30 drivers/base/core.c:3805 ptp_clock_unregister+0x171/0x270 drivers/ptp/ptp_clock.c:391 gem_ptp_remove+0x4e/0x1f0 drivers/net/ethernet/cadence/macb_ptp.c:404 macb_close+0x1c8/0x270 drivers/net/ethernet/cadence/macb_main.c:2966 __dev_close_many+0x1b9/0x310 net/core/dev.c:1585 __dev_close net/core/dev.c:1597 [inline] __dev_change_flags+0x2bb/0x740 net/core/dev.c:8649 dev_change_fl ---truncated---", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31545", "url": "https://ubuntu.com/security/CVE-2026-31545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: nxp-nci: allow GPIOs to sleep Allow the firmware and enable GPIOs to sleep. This fixes a `WARN_ON' and allows the driver to operate GPIOs which are connected to I2C GPIO expanders. -- >8 -- kernel: WARNING: CPU: 3 PID: 2636 at drivers/gpio/gpiolib.c:3880 gpiod_set_value+0x88/0x98 -- >8 --", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31399", "url": "https://ubuntu.com/security/CVE-2026-31399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/bus: Fix potential use after free in asynchronous initialization Dingisoul with KASAN reports a use after free if device_add() fails in nd_async_device_register(). Commit b6eae0f61db2 (\"libnvdimm: Hold reference on parent while scheduling async init\") correctly added a reference on the parent device to be held until asynchronous initialization was complete. However, if device_add() results in an allocation failure the ref count of the device drops to 0 prior to the parent pointer being accessed. Thus resulting in use after free. The bug bot AI correctly identified the fix. Save a reference to the parent pointer to be used to drop the parent reference regardless of the outcome of device_add().", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31400", "url": "https://ubuntu.com/security/CVE-2026-31400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix cache_request leak in cache_release When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request. In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup. The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up. Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, dequeue and free the cache_request.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2024-46715", "url": "https://ubuntu.com/security/CVE-2024-46715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver: iio: add missing checks on iio_info's callback access Some callbacks from iio_info structure are accessed without any check, so if a driver doesn't implement them trying to access the corresponding sysfs entries produce a kernel oops such as: [ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute [...] [ 2203.783416] Call trace: [ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48 [ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120 [ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4 [ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0 [ 2203.802236] vfs_read from ksys_read+0xa4/0xd4 [ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54 [ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0) [ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000 [ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000 [ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0 [ 2203.830363] Code: bad PC value [ 2203.832695] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-09-18 07:15:00 UTC" }, { "cve": "CVE-2026-23113", "url": "https://ubuntu.com/security/CVE-2026-23113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't support ->read_iter(), loop_rw_iter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path: INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000 Call Trace: context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98 There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2025-39748", "url": "https://ubuntu.com/security/CVE-2025-39748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Forget ranges when refining tnum after JSET Syzbot reported a kernel warning due to a range invariant violation on the following BPF program. 0: call bpf_get_netns_cookie 1: if r0 == 0 goto 2: if r0 & Oxffffffff goto The issue is on the path where we fall through both jumps. That path is unreachable at runtime: after insn 1, we know r0 != 0, but with the sign extension on the jset, we would only fallthrough insn 2 if r0 == 0. Unfortunately, is_branch_taken() isn't currently able to figure this out, so the verifier walks all branches. The verifier then refines the register bounds using the second condition and we end up with inconsistent bounds on this unreachable path: 1: if r0 == 0 goto r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2: if r0 & 0xffffffff goto r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0) r0 after reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0) Improving the range refinement for JSET to cover all cases is tricky. We also don't expect many users to rely on JSET given LLVM doesn't generate those instructions. So instead of improving the range refinement for JSETs, Eduard suggested we forget the ranges whenever we're narrowing tnums after a JSET. This patch implements that approach.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2026-43357", "url": "https://ubuntu.com/security/CVE-2026-43357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050-core: fix pm_runtime error handling The return value of pm_runtime_get_sync() is not checked, allowing the driver to access hardware that may fail to resume. The device usage count is also unconditionally incremented. Use pm_runtime_resume_and_get() which propagates errors and avoids incrementing the usage count on failure. In preenable, add pm_runtime_put_autosuspend() on set_8khz_samplerate() failure since postdisable does not run when preenable fails.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43476", "url": "https://ubuntu.com/security/CVE-2026-43476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas() sizeof(num) evaluates to sizeof(size_t) (8 bytes on 64-bit) instead of the intended __be32 element size (4 bytes). Use sizeof(*meas) to correctly match the buffer element type.", "cve_priority": "medium", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43363", "url": "https://ubuntu.com/security/CVE-2026-43363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/apic: Disable x2apic on resume if the kernel expects so When resuming from s2ram, firmware may re-enable x2apic mode, which may have been disabled by the kernel during boot either because it doesn't support IRQ remapping or for other reasons. This causes the kernel to continue using the xapic interface, while the hardware is in x2apic mode, which causes hangs. This happens on defconfig + bare metal + s2ram. Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be disabled, i.e. when x2apic_mode = 0. The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the pre-sleep configuration or initial boot configuration for each CPU, including MSR state: When executing from the power-on reset vector as a result of waking from an S2 or S3 sleep state, the platform firmware performs only the hardware initialization required to restore the system to either the state the platform was in prior to the initial operating system boot, or to the pre-sleep configuration state. In multiprocessor systems, non-boot processors should be placed in the same state as prior to the initial operating system boot. (further ahead) If this is an S2 or S3 wake, then the platform runtime firmware restores minimum context of the system before jumping to the waking vector. This includes: \tCPU configuration. Platform runtime firmware restores the pre-sleep \tconfiguration or initial boot configuration of each CPU (MSR, MTRR, \tfirmware update, SMBase, and so on). Interrupts must be disabled (for \tIA-32 processors, disabled by CLI instruction). \t(and other things) So at least as per the spec, re-enablement of x2apic by the firmware is allowed if \"x2apic on\" is a part of the initial boot configuration. [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization [ bp: Massage. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43365", "url": "https://ubuntu.com/security/CVE-2026-43365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix undersized l_iclog_roundoff values If the superblock doesn't list a log stripe unit, we set the incore log roundoff value to 512. This leads to corrupt logs and unmountable filesystems in generic/617 on a disk with 4k physical sectors... XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197. XFS (sda1): failed to locate log tail XFS (sda1): log mount/recovery failed: error -74 XFS (sda1): log mount failed XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Ending clean mount ...on the current xfsprogs for-next which has a broken mkfs. xfs_info shows this... meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1 data = bsize=4096 blocks=2579968, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=4096 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=268435456 extents = zoned=0 start=0 reserved=0 ...observe that the log section has sectsz=4096 sunit=0, which means that the roundoff factor is 512, not 4096 as you'd expect. We should fix mkfs not to generate broken filesystems, but anyone can fuzz the ondisk superblock so we should be more cautious. I think the inadequate logic predates commit a6a65fef5ef8d0, but that's clearly going to require a different backport.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43370", "url": "https://ubuntu.com/security/CVE-2026-43370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix use-after-free race in VM acquire Replace non-atomic vm->process_info assignment with cmpxchg() to prevent race when parent/child processes sharing a drm_file both try to acquire the same VM after fork(). (cherry picked from commit c7c573275ec20db05be769288a3e3bb2250ec618)", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43373", "url": "https://ubuntu.com/security/CVE-2026-43373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ncsi: fix skb leak in error paths Early return paths in NCSI RX and AEN handlers fail to release the received skb, resulting in a memory leak. Specifically, ncsi_aen_handler() returns on invalid AEN packets without consuming the skb. Similarly, ncsi_rcv_rsp() exits early when failing to resolve the NCSI device, response handler, or request, leaving the skb unfreed.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43380", "url": "https://ubuntu.com/security/CVE-2026-43380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read The q54sj108a2_debugfs_read function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes 'data' as the destination and 'data_char' as the source. Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since 'data' is only 34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the end of the buffer onto the stack. Additionally, the arguments were swapped: it was reading from the zero-initialized 'data_char' and writing to 'data', resulting in all-zero output regardless of the actual I2C read. Fix this by: 1. Expanding 'data_char' to 66 bytes to safely hold the hex output. 2. Correcting the bin2hex() argument order and using the actual read count. 3. Using a pointer to select the correct output buffer for the final simple_read_from_buffer call.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43381", "url": "https://ubuntu.com/security/CVE-2026-43381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dpcd: return EBUSY for aux xfer if the device is asleep If we have runtime suspended, and userspace wants to use /dev/drm_dp_* then just tell it the device is busy instead of crashing in the GSP code. WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy) Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024 RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them awake while fw updates are happening.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43382", "url": "https://ubuntu.com/security/CVE-2026-43382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid double-rtnl_lock ELP metric worker batadv_v_elp_get_throughput() might be called when the RTNL lock is already held. This could be problematic when the work queue item is cancelled via cancel_delayed_work_sync() in batadv_v_elp_iface_disable(). In this case, an rtnl_lock() would cause a deadlock. To avoid this, rtnl_trylock() was used in this function to skip the retrieval of the ethtool information in case the RTNL lock was already held. But for cfg80211 interfaces, batadv_get_real_netdev() was called - which also uses rtnl_lock(). The approach for __ethtool_get_link_ksettings() must also be used instead and the lockless version __batadv_get_real_netdev() has to be called.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-31405", "url": "https://ubuntu.com/security/CVE-2026-31405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-net: fix OOB access in ULE extension header tables The ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables in handle_one_ule_extension() are declared with 255 elements (valid indices 0-254), but the index htype is derived from network-controlled data as (ule_sndu_type & 0x00FF), giving a range of 0-255. When htype equals 255, an out-of-bounds read occurs on the function pointer table, and the OOB value may be called as a function pointer. Add a bounds check on htype against the array size before either table is accessed. Out-of-range values now cause the SNDU to be discarded.", "cve_priority": "high", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-43387", "url": "https://ubuntu.com/security/CVE-2026-43387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: properly validate the data in rtw_get_ie_ex() Just like in commit 154828bf9559 (\"staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser\"), we don't trust the data in the frame so we should check the length better before acting on it", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43386", "url": "https://ubuntu.com/security/CVE-2026-43386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie The current code checks 'i + 5 < in_len' at the end of the if statement. However, it accesses 'in_ie[i + 5]' before that check, which can lead to an out-of-bounds read. Move the length check to the beginning of the conditional to ensure the index is within bounds before accessing the array.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43420", "url": "https://ubuntu.com/security/CVE-2026-43420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix i_nlink underrun during async unlink During async unlink, we drop the `i_nlink` counter before we receive the completion (that will eventually update the `i_nlink`) because \"we assume that the unlink will succeed\". That is not a bad idea, but it races against deletions by other clients (or against the completion of our own unlink) and can lead to an underrun which emits a WARNING like this one: WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68 Modules linked in: CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drop_nlink+0x50/0x68 lr : ceph_unlink+0x6c4/0x720 sp : ffff80012173bc90 x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680 x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647 x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203 x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365 x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74 x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94 x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002 x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8 Call trace: drop_nlink+0x50/0x68 (P) vfs_unlink+0xb0/0x2e8 do_unlinkat+0x204/0x288 __arm64_sys_unlinkat+0x3c/0x80 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0xa4/0xc8 el0_svc+0x18/0x58 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x154/0x158 In ceph_unlink(), a call to ceph_mdsc_submit_request() submits the CEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion. Meanwhile, between this call and the following drop_nlink() call, a worker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT or just a CEPH_MSG_CLIENT_REPLY (the latter of which could be our own completion). These will lead to a set_nlink() call, updating the `i_nlink` counter to the value received from the MDS. If that new `i_nlink` value happens to be zero, it is illegal to decrement it further. But that is exactly what ceph_unlink() will do then. The WARNING can be reproduced this way: 1. Force async unlink; only the async code path is affected. Having no real clue about Ceph internals, I was unable to find out why the MDS wouldn't give me the \"Fxr\" capabilities, so I patched get_caps_for_async_unlink() to always succeed. (Note that the WARNING dump above was found on an unpatched kernel, without this kludge - this is not a theoretical bug.) 2. Add a sleep call after ceph_mdsc_submit_request() so the unlink completion gets handled by a worker thread before drop_nlink() is called. This guarantees that the `i_nlink` is already zero before drop_nlink() runs. The solution is to skip the counter decrement when it is already zero, but doing so without a lock is still racy (TOCTOU). Since ceph_fill_inode() and handle_cap_grant() both hold the `ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, this seems like the proper lock to protect the `i_nlink` updates. I found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using `afs_vnode.cb_lock`). All three have the zero check as well.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43405", "url": "https://ubuntu.com/security/CVE-2026-43405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Use u32 for non-negative values in ceph_monmap_decode() This patch fixes unnecessary implicit conversions that change signedness of blob_len and num_mon in ceph_monmap_decode(). Currently blob_len and num_mon are (signed) int variables. They are used to hold values that are always non-negative and get assigned in ceph_decode_32_safe(), which is meant to assign u32 values. Both variables are subsequently used as unsigned values, and the value of num_mon is further assigned to monmap->num_mon, which is of type u32. Therefore, both variables should be of type u32. This is especially relevant for num_mon. If the value read from the incoming message is very large, it is interpreted as a negative value, and the check for num_mon > CEPH_MAX_MON does not catch it. This leads to the attempt to allocate a very large chunk of memory for monmap, which will most likely fail. In this case, an unnecessary attempt to allocate memory is performed, and -ENOMEM is returned instead of -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43411", "url": "https://ubuntu.com/security/CVE-2026-43411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix divide-by-zero in tipc_sk_filter_connect() A user can set conn_timeout to any value via setsockopt(TIPC_CONN_TIMEOUT), including values less than 4. When a SYN is rejected with TIPC_ERR_OVERLOAD and the retry path in tipc_sk_filter_connect() executes: delay %= (tsk->conn_timeout / 4); If conn_timeout is in the range [0, 3], the integer division yields 0, and the modulo operation triggers a divide-by-zero exception, causing a kernel oops/panic. Fix this by clamping conn_timeout to a minimum of 4 at the point of use in tipc_sk_filter_connect(). Oops: divide error: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+ RIP: 0010:tipc_sk_filter_rcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362) Call Trace: tipc_sk_backlog_rcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406) __release_sock (include/net/sock.h:1185 net/core/sock.c:3213) release_sock (net/core/sock.c:3797) tipc_connect (net/tipc/socket.c:2570) __sys_connect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098)", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43484", "url": "https://ubuntu.com/security/CVE-2026-43484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: core: Avoid bitfield RMW for claim/retune flags Move claimed and retune control flags out of the bitfield word to avoid unrelated RMW side effects in asynchronous contexts. The host->claimed bit shared a word with retune flags. Writes to claimed in __mmc_claim_host() or retune_now in mmc_mq_queue_rq() can overwrite other bits when concurrent updates happen in other contexts, triggering spurious WARN_ON(!host->claimed). Convert claimed, can_retune, retune_now and retune_paused to bool to remove shared-word coupling.", "cve_priority": "low", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43425", "url": "https://ubuntu.com/security/CVE-2026-43425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: kill download URB on timeout mdc800_device_read() submits download_urb and waits for completion. If the timeout fires and the device has not responded, the function returns without killing the URB, leaving it active. A subsequent read() resubmits the same URB while it is still in-flight, triggering the WARN in usb_submit_urb(): \"URB submitted while active\" Check the return value of wait_event_timeout() and kill the URB if it indicates timeout, ensuring the URB is complete before its status is inspected or the URB is resubmitted. Similar to - commit 372c93131998 (\"USB: yurex: fix control-URB timeout handling\") - commit b98d5000c505 (\"media: rc: iguanair: handle timeouts\")", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43426", "url": "https://ubuntu.com/security/CVE-2026-43426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: fix use-after-free in ISR during device removal In usbhs_remove(), the driver frees resources (including the pipe array) while the interrupt handler (usbhs_interrupt) is still registered. If an interrupt fires after usbhs_pipe_remove() but before the driver is fully unbound, the ISR may access freed memory, causing a use-after-free. Fix this by calling devm_free_irq() before freeing resources. This ensures the interrupt handler is both disabled and synchronized (waits for any running ISR to complete) before usbhs_pipe_remove() is called.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43427", "url": "https://ubuntu.com/security/CVE-2026-43427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: class: cdc-wdm: fix reordering issue in read code path Quoting the bug report: Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdm_read() can see the new length and call copy_to_user() on uninitialized memory. This also violates LKMM data race rules [1]. Fix it by using WRITE_ONCE and memory barriers.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43428", "url": "https://ubuntu.com/security/CVE-2026-43428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: core: Limit the length of unkillable synchronous timeouts The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device. To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector. In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43429", "url": "https://ubuntu.com/security/CVE-2026-43429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: Use usb_bulk_msg_killable() with user-specified timeouts The usbtmc driver accepts timeout values specified by the user in an ioctl command, and uses these timeouts for some usb_bulk_msg() calls. Since the user can specify arbitrarily long timeouts and usb_bulk_msg() uses unkillable waits, call usb_bulk_msg_killable() instead to avoid the possibility of the user hanging a kernel thread indefinitely.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43430", "url": "https://ubuntu.com/security/CVE-2026-43430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: yurex: fix race in probe The bbu member of the descriptor must be set to the value standing for uninitialized values before the URB whose completion handler sets bbu is submitted. Otherwise there is a window during which probing can overwrite already retrieved data.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43432", "url": "https://ubuntu.com/security/CVE-2026-43432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix memory leak in xhci_disable_slot() xhci_alloc_command() allocates a command structure and, when the second argument is true, also allocates a completion structure. Currently, the error handling path in xhci_disable_slot() only frees the command structure using kfree(), causing the completion structure to leak. Use xhci_free_command() instead of kfree(). xhci_free_command() correctly frees both the command structure and the associated completion structure. Since the command structure is allocated with zero-initialization, command->in_ctx is NULL and will not be erroneously freed by xhci_free_command(). This bug was found using an experimental static analysis tool we are developing. The tool is based on the LLVM framework and is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available, but we plan to open-source it after our research is published. The bug was originally detected on v6.13-rc1 using our static analysis tool, and we have verified that the issue persists in the latest mainline kernel. We performed build testing on x86_64 with allyesconfig using GCC=11.4.0. Since triggering these error paths in xhci_disable_slot() requires specific hardware conditions or abnormal state, we were unable to construct a test case to reliably trigger these specific error paths at runtime.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43439", "url": "https://ubuntu.com/security/CVE-2026-43439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup: fix race between task migration and iteration When a task is migrated out of a css_set, cgroup_migrate_add_task() first moves it from cset->tasks to cset->mg_tasks via: list_move_tail(&task->cg_list, &cset->mg_tasks); If a css_task_iter currently has it->task_pos pointing to this task, css_set_move_task() calls css_task_iter_skip() to keep the iterator valid. However, since the task has already been moved to ->mg_tasks, the iterator is advanced relative to the mg_tasks list instead of the original tasks list. As a result, remaining tasks on cset->tasks, as well as tasks queued on cset->mg_tasks, can be skipped by iteration. Fix this by calling css_set_skip_task_iters() before unlinking task->cg_list from cset->tasks. This advances all active iterators to the next task on cset->tasks, so iteration continues correctly even when a task is concurrently being migrated. This race is hard to hit in practice without instrumentation, but it can be reproduced by artificially slowing down cgroup_procs_show(). For example, on an Android device a temporary /sys/kernel/cgroup/cgroup_test knob can be added to inject a delay into cgroup_procs_show(), and then: 1) Spawn three long-running tasks (PIDs 101, 102, 103). 2) Create a test cgroup and move the tasks into it. 3) Enable a large delay via /sys/kernel/cgroup/cgroup_test. 4) In one shell, read cgroup.procs from the test cgroup. 5) Within the delay window, in another shell migrate PID 102 by writing it to a different cgroup.procs file. Under this setup, cgroup.procs can intermittently show only PID 101 while skipping PID 103. Once the migration completes, reading the file again shows all tasks as expected. Note that this change does not allow removing the existing css_set_skip_task_iters() call in css_set_move_task(). The new call in cgroup_migrate_add_task() only handles iterators that are racing with migration while the task is still on cset->tasks. Iterators may also start after the task has been moved to cset->mg_tasks. If we dropped css_set_skip_task_iters() from css_set_move_task(), such iterators could keep task_pos pointing to a migrating task, causing css_task_iter_advance() to malfunction on the destination css_set, up to and including crashes or infinite loops. The race window between migration and iteration is very small, and css_task_iter is not on a hot path. In the worst case, when an iterator is positioned on the first thread of the migrating process, cgroup_migrate_add_task() may have to skip multiple tasks via css_set_skip_task_iters(). However, this only happens when migration and iteration actually race, so the performance impact is negligible compared to the correctness fix provided here.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43480", "url": "https://ubuntu.com/security/CVE-2026-43480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisition The acp3x_5682_init() function did not check the return value of clk_get(), which could lead to dereferencing error pointers in rt5682_clk_enable(). Fix this by: 1. Changing clk_get() to the device-managed devm_clk_get(). 2. Adding proper IS_ERR() checks for both clock acquisitions.", "cve_priority": "low", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43445", "url": "https://ubuntu.com/security/CVE-2026-43445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: e1000/e1000e: Fix leak in 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 after a successful 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 would leak. In these commits, a faulty while condition caused an infinite loop in dma_error: Commit 03b1320dfcee (\"e1000e: remove use of skb_dma_map from e1000e driver\") Commit 602c0554d7b0 (\"e1000: remove use of skb_dma_map from e1000 driver\") Commit c1fa347f20f1 (\"e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()\") fixed the infinite loop, but introduced the off-by-one error. This issue may still exist in the igbvf driver, but I did not address it in this patch.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43449", "url": "https://ubuntu.com/security/CVE-2026-43449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_set dev->online_queues is a count incremented in nvme_init_queue. Thus, valid indices are 0 through dev->online_queues − 1. This patch fixes the loop condition to ensure the index stays within the valid range. Index 0 is excluded because it is the admin queue. KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74 CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: nvme-reset-wq nvme_reset_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xea/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xce/0x5d0 mm/kasan/report.c:482 kasan_report+0xdc/0x110 mm/kasan/report.c:595 __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c:379 nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c:3252 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 34 on cpu 1 at 4.241550s: kasan_save_stack+0x2c/0x60 mm/kasan/common.c:57 kasan_save_track+0x1c/0x70 mm/kasan/common.c:78 kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c:570 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5657 [inline] __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c:5663 kmalloc_array_node_noprof include/linux/slab.h:1075 [inline] nvme_pci_alloc_dev drivers/nvme/host/pci.c:3479 [inline] nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534 local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c:324 pci_call_probe drivers/pci/pci-driver.c:392 [inline] __pci_device_probe drivers/pci/pci-driver.c:417 [inline] pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c:451 call_driver_probe drivers/base/dd.c:583 [inline] really_probe+0x29b/0xb70 drivers/base/dd.c:661 __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c:803 driver_probe_device+0x56/0x1f0 drivers/base/dd.c:833 __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c:1159 async_run_entry_fn+0xa6/0x4b0 kernel/async.c:129 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 The buggy address belongs to the object at ffff88800592a000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 244 bytes to the right of allocated 1152-byte region [ffff88800592a000, ffff88800592a480) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff) page_type: f5(slab) raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000 head: 000fffffc0000040 ffff888001042000 00000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43450", "url": "https://ubuntu.com/security/CVE-2026-43450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table() nfnl_cthelper_dump_table() has a 'goto restart' that jumps to a label inside the for loop body. When the \"last\" helper saved in cb->args[1] is deleted between dump rounds, every entry fails the (cur != last) check, so cb->args[1] is never cleared. The for loop finishes with cb->args[0] == nf_ct_helper_hsize, and the 'goto restart' jumps back into the loop body bypassing the bounds check, causing an 8-byte out-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize]. The 'goto restart' block was meant to re-traverse the current bucket when \"last\" is no longer found, but it was placed after the for loop instead of inside it. Move the block into the for loop body so that the restart only occurs while cb->args[0] is still within bounds. BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131 Call Trace: nfnl_cthelper_dump_table+0x9f/0x1b0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 sock_recvmsg+0xde/0xf0 __sys_recvfrom+0x150/0x200 __x64_sys_recvfrom+0x76/0x90 do_syscall_64+0xc3/0x6e0 Allocated by task 1: __kvmalloc_node_noprof+0x21b/0x700 nf_ct_alloc_hashtable+0x65/0xd0 nf_conntrack_helper_init+0x21/0x60 nf_conntrack_init_start+0x18d/0x300 nf_conntrack_standalone_init+0x12/0xc0", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43451", "url": "https://ubuntu.com/security/CVE-2026-43451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: fix entry leak in bridge verdict error path nfqnl_recv_verdict() calls find_dequeue_entry() to remove the queue entry from the queue data structures, taking ownership of the entry. For PF_BRIDGE packets, it then calls nfqa_parse_bridge() to parse VLAN attributes. If nfqa_parse_bridge() returns an error (e.g. NFQA_VLAN present but NFQA_VLAN_TCI missing), the function returns immediately without freeing the dequeued entry or its sk_buff. This leaks the nf_queue_entry, its associated sk_buff, and all held references (net_device refcounts, struct net refcount). Repeated triggering exhausts kernel memory. Fix this by dropping the entry via nfqnl_reinject() with NF_DROP verdict on the error path, consistent with other error handling in this file.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43452", "url": "https://ubuntu.com/security/CVE-2026-43452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: guard option walkers against 1-byte tail reads When the last byte of options is a non-single-byte option kind, walkers that advance with i += op[i + 1] ? : 1 can read op[i + 1] past the end of the option area. Add an explicit i == optlen - 1 check before dereferencing op[i + 1] in xt_tcpudp and xt_dccp option walkers.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43453", "url": "https://ubuntu.com/security/CVE-2026-43453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop() pipapo_drop() passes rulemap[i + 1].n to pipapo_unmap() as the to_offset argument on every iteration, including the last one where i == m->field_count - 1. This reads one element past the end of the stack-allocated rulemap array (declared as rulemap[NFT_PIPAPO_MAX_FIELDS] with NFT_PIPAPO_MAX_FIELDS == 16). Although pipapo_unmap() returns early when is_last is true without using the to_offset value, the argument is evaluated at the call site before the function body executes, making this a genuine out-of-bounds stack read confirmed by KASAN: BUG: KASAN: stack-out-of-bounds in pipapo_drop+0x50c/0x57c [nf_tables] Read of size 4 at addr ffff8000810e71a4 This frame has 1 object: [32, 160) 'rulemap' The buggy address is at offset 164 -- exactly 4 bytes past the end of the rulemap array. Pass 0 instead of rulemap[i + 1].n on the last iteration to avoid the out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43458", "url": "https://ubuntu.com/security/CVE-2026-43458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: caif: hold tty->link reference in ldisc_open and ser_release A reproducer triggers a KASAN slab-use-after-free in pty_write_room() when caif_serial's TX path calls tty_write_room(). The faulting access is on tty->link->port. Hold an extra kref on tty->link for the lifetime of the caif_serial line discipline: get it in ldisc_open() and drop it in ser_release(), and also drop it on the ldisc_open() error path. With this change applied, the reproducer no longer triggers the UAF in my testing.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43459", "url": "https://ubuntu.com/security/CVE-2026-43459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-core: flush delayed work before removing DAIs and widgets When a sound card is unbound while a PCM stream is open, a use-after-free can occur in snd_soc_dapm_stream_event(), called from the close_delayed_work workqueue handler. During unbind, snd_soc_unbind_card() flushes delayed work and then calls soc_cleanup_card_resources(). Inside cleanup, snd_card_disconnect_sync() releases all PCM file descriptors, and the resulting PCM close path can call snd_soc_dapm_stream_stop() which schedules new delayed work with a pmdown_time timer delay. Since this happens after the flush in snd_soc_unbind_card(), the new work is not caught. soc_remove_link_components() then frees DAPM widgets before this work fires, leading to the use-after-free. The existing flush in soc_free_pcm_runtime() also cannot help as it runs after soc_remove_link_components() has already freed the widgets. Add a flush in soc_cleanup_card_resources() after snd_card_disconnect_sync() (after which no new PCM closes can schedule further delayed work) and before soc_remove_link_dais() and soc_remove_link_components() (which tear down the structures the delayed work accesses).", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-23277", "url": "https://ubuntu.com/security/CVE-2026-23277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit teql_master_xmit() calls netdev_start_xmit(skb, slave) to transmit through slave devices, but does not update skb->dev to the slave device beforehand. When a gretap tunnel is a TEQL slave, the transmit path reaches iptunnel_xmit() which saves dev = skb->dev (still pointing to teql0 master) and later calls iptunnel_xmit_stats(dev, pkt_len). This function does: get_cpu_ptr(dev->tstats) Since teql_master_setup() does not set dev->pcpu_stat_type to NETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstats for teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computes NULL + __per_cpu_offset[cpu], resulting in a page fault. BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206) Fix this by setting skb->dev = slave before calling netdev_start_xmit(), so that tunnel xmit functions see the correct slave device with properly allocated tstats.", "cve_priority": "medium", "cve_public_date": "2026-03-20 09:16:00 UTC" }, { "cve": "CVE-2026-43466", "url": "https://ubuntu.com/security/CVE-2026-43466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery In case of a TX error CQE, a recovery flow is triggered, mlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc, desyncing the DMA FIFO producer and consumer. After recovery, the producer pushes new DMA entries at the old dma_fifo_pc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery. The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dma_fifo_cc is already equal to dma_fifo_pc. There is no need to reset either counter, similar to how skb_fifo pc/cc are untouched. Remove the 'dma_fifo_cc = 0' reset. This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90 Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: ? __warn+0x7d/0x110 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0x16d/0x180 ? handle_bug+0x4f/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 ? iommu_dma_unmap_page+0x2e/0x90 dma_unmap_page_attrs+0x10d/0x1b0 mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core] mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core] mlx5e_napi_poll+0x8b/0xac0 [mlx5_core] __napi_poll+0x24/0x190 net_rx_action+0x32a/0x3b0 ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core] ? notifier_call_chain+0x35/0xa0 handle_softirqs+0xc9/0x270 irq_exit_rcu+0x71/0xd0 common_interrupt+0x7f/0xa0 asm_common_interrupt+0x22/0x40", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43469", "url": "https://ubuntu.com/security/CVE-2026-43469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decrement re_receiving on the early exit paths In the event that rpcrdma_post_recvs() fails to create a work request (due to memory allocation failure, say) or otherwise exits early, we should decrement ep->re_receiving before returning. Otherwise we will hang in rpcrdma_xprt_drain() as re_receiving will never reach zero and the completion will never be triggered. On a system with high memory pressure, this can appear as the following hung task: INFO: task kworker/u385:17:8393 blocked for more than 122 seconds. Tainted: G S E 6.19.0 #3 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u385:17 state:D stack:0 pid:8393 tgid:8393 ppid:2 task_flags:0x4248060 flags:0x00080000 Workqueue: xprtiod xprt_autoclose [sunrpc] Call Trace: __schedule+0x48b/0x18b0 ? ib_post_send_mad+0x247/0xae0 [ib_core] schedule+0x27/0xf0 schedule_timeout+0x104/0x110 __wait_for_common+0x98/0x180 ? __pfx_schedule_timeout+0x10/0x10 wait_for_completion+0x24/0x40 rpcrdma_xprt_disconnect+0x444/0x460 [rpcrdma] xprt_rdma_close+0x12/0x40 [rpcrdma] xprt_autoclose+0x5f/0x120 [sunrpc] process_one_work+0x191/0x3e0 worker_thread+0x2e3/0x420 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x273/0x2b0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2025-54505", "url": "https://ubuntu.com/security/CVE-2025-54505", "cve_description": "A transient execution vulnerability within AMD CPUs may allow a local user-privileged attacker to leak data via the floating point divisor unit, potentially resulting in loss of confidentiality.", "cve_priority": "medium", "cve_public_date": "2026-04-27 16:16:00 UTC" }, { "cve": "CVE-2026-31628", "url": "https://ubuntu.com/security/CVE-2026-31628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU: Fix FPDSS on Zen1 Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43472", "url": "https://ubuntu.com/security/CVE-2026-43472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: unshare: fix unshare_fs() handling There's an unpleasant corner case in unshare(2), when we have a CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that case copy_mnt_ns() gets passed current->fs instead of a private copy, which causes interesting warts in proof of correctness] > I guess if private means fs->users == 1, the condition could still be true. Unfortunately, it's worse than just a convoluted proof of correctness. Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS (and current->fs->users == 1). We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and flips current->fs->{pwd,root} to corresponding locations in the new namespace. Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM). We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's destroyed and its mount tree is dissolved, but... current->fs->root and current->fs->pwd are both left pointing to now detached mounts. They are pinning those, so it's not a UAF, but it leaves the calling process with unshare(2) failing with -ENOMEM _and_ leaving it with pwd and root on detached isolated mounts. The last part is clearly a bug. There is other fun related to that mess (races with pivot_root(), including the one between pivot_root() and fork(), of all things), but this one is easy to isolate and fix - treat CLONE_NEWNS as \"allocate a new fs_struct even if it hadn't been shared in the first place\". Sure, we could go for something like \"if both CLONE_NEWNS *and* one of the things that might end up failing after copy_mnt_ns() call in create_new_namespaces() are set, force allocation of new fs_struct\", but let's keep it simple - the cost of copy_fs_struct() is trivial. Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets a freshly allocated fs_struct, yet to be attached to anything. That seriously simplifies the analysis... FWIW, that bug had been there since the introduction of unshare(2) ;-/", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-43473", "url": "https://ubuntu.com/security/CVE-2026-43473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Add NULL checks when resetting request and reply queues The driver encountered a crash during resource cleanup when the reply and request queues were NULL due to freed memory. This issue occurred when the creation of reply or request queues failed, and the driver freed the memory first, but attempted to mem set the content of the freed memory, leading to a system crash. Add NULL pointer checks for reply and request queues before accessing the reply/request memory during cleanup", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-43475", "url": "https://ubuntu.com/security/CVE-2026-43475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT This resolves the follow splat and lock-up when running with PREEMPT_RT enabled on Hyper-V: [ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002 [ 415.140822] INFO: lockdep is turned off. [ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common [ 415.140846] Preemption disabled at: [ 415.140847] [] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)} [ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024 [ 415.140857] Call Trace: [ 415.140861] [ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140863] dump_stack_lvl+0x91/0xb0 [ 415.140870] __schedule_bug+0x9c/0xc0 [ 415.140875] __schedule+0xdf6/0x1300 [ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980 [ 415.140879] ? rcu_is_watching+0x12/0x60 [ 415.140883] schedule_rtlock+0x21/0x40 [ 415.140885] rtlock_slowlock_locked+0x502/0x1980 [ 415.140891] rt_spin_lock+0x89/0x1e0 [ 415.140893] hv_ringbuffer_write+0x87/0x2a0 [ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0 [ 415.140900] ? rcu_is_watching+0x12/0x60 [ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc] [ 415.140904] ? HARDIRQ_verbose+0x10/0x10 [ 415.140908] ? __rq_qos_issue+0x28/0x40 [ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod] [ 415.140926] __blk_mq_issue_directly+0x4a/0xc0 [ 415.140928] blk_mq_issue_direct+0x87/0x2b0 [ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440 [ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0 [ 415.140935] __blk_flush_plug+0xf4/0x150 [ 415.140940] __submit_bio+0x2b2/0x5c0 [ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360 [ 415.140946] submit_bio_noacct_nocheck+0x272/0x360 [ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4] [ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4] [ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4] [ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4] [ 415.141060] generic_perform_write+0x14e/0x2c0 [ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4] [ 415.141083] vfs_write+0x2ca/0x570 [ 415.141087] ksys_write+0x76/0xf0 [ 415.141089] do_syscall_64+0x99/0x1490 [ 415.141093] ? rcu_is_watching+0x12/0x60 [ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0 [ 415.141097] ? rcu_is_watching+0x12/0x60 [ 415.141098] ? lock_release+0x1f0/0x2a0 [ 415.141100] ? rcu_is_watching+0x12/0x60 [ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0 [ 415.141103] ? rcu_is_watching+0x12/0x60 [ 415.141104] ? __schedule+0xb34/0x1300 [ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170 [ 415.141109] ? do_nanosleep+0x8b/0x160 [ 415.141111] ? hrtimer_nanosleep+0x89/0x100 [ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10 [ 415.141116] ? xfd_validate_state+0x26/0x90 [ 415.141118] ? rcu_is_watching+0x12/0x60 [ 415.141120] ? do_syscall_64+0x1e0/0x1490 [ 415.141121] ? do_syscall_64+0x1e0/0x1490 [ 415.141123] ? rcu_is_watching+0x12/0x60 [ 415.141124] ? do_syscall_64+0x1e0/0x1490 [ 415.141125] ? do_syscall_64+0x1e0/0x1490 [ 415.141127] ? irqentry_exit+0x140/0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-23270", "url": "https://ubuntu.com/security/CVE-2026-23270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocks As Paolo said earlier [1]: \"Since the blamed commit below, classify can return TC_ACT_CONSUMED while the current skb being held by the defragmentation engine. As reported by GangMin Kim, if such packet is that may cause a UaF when the defrag engine later on tries to tuch again such packet.\" act_ct was never meant to be used in the egress path, however some users are attaching it to egress today [2]. Attempting to reach a middle ground, we noticed that, while most qdiscs are not handling TC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, we address the issue by only allowing act_ct to bind to clsact/ingress qdiscs and shared blocks. That way it's still possible to attach act_ct to egress (albeit only with clsact). [1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/ [2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23300", "url": "https://ubuntu.com/security/CVE-2026-23300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop When a standalone IPv6 nexthop object is created with a loopback device (e.g., \"ip -6 nexthop add id 100 dev lo\"), fib6_nh_init() misclassifies it as a reject route. This is because nexthop objects have no destination prefix (fc_dst=::), causing fib6_is_reject() to match any loopback nexthop. The reject path skips fib_nh_common_init(), leaving nhc_pcpu_rth_output unallocated. If an IPv4 route later references this nexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and panics. Simplify the check in fib6_nh_init() to only match explicit reject routes (RTF_REJECT) instead of using fib6_is_reject(). The loopback promotion heuristic in fib6_is_reject() is handled separately by ip6_route_info_create_nh(). After this change, the three cases behave as follows: 1. Explicit reject route (\"ip -6 route add unreachable 2001:db8::/64\"): RTF_REJECT is set, enters reject path, skips fib_nh_common_init(). No behavior change. 2. Implicit loopback reject route (\"ip -6 route add 2001:db8::/32 dev lo\"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. ip6_route_info_create_nh() still promotes it to reject afterward. nhc_pcpu_rth_output is allocated but unused, which is harmless. 3. Standalone nexthop object (\"ip -6 nexthop add id 100 dev lo\"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. nhc_pcpu_rth_output is properly allocated, fixing the crash when IPv4 routes reference this nexthop.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23293", "url": "https://ubuntu.com/security/CVE-2026-23293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. If an IPv6 packet is injected into the interface, route_shortcircuit() is called and a NULL pointer dereference happens on neigh_lookup(). BUG: kernel NULL pointer dereference, address: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neigh_lookup+0x20/0x270 [...] Call Trace: vxlan_xmit+0x638/0x1ef0 [vxlan] dev_hard_start_xmit+0x9e/0x2e0 __dev_queue_xmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x12f/0x1590 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix this by adding an early check on route_shortcircuit() when protocol is ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here because VXLAN can be built-in even when IPv6 is built as a module.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23381", "url": "https://ubuntu.com/security/CVE-2026-23381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. Then, if neigh_suppress is enabled and an ICMPv6 Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() will dereference ipv6_stub->nd_tbl which is NULL, passing it to neigh_lookup(). This causes a kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neigh_lookup+0x16/0xe0 [...] Call Trace: ? neigh_lookup+0x16/0xe0 br_do_suppress_nd+0x160/0x290 [bridge] br_handle_frame_finish+0x500/0x620 [bridge] br_handle_frame+0x353/0x440 [bridge] __netif_receive_skb_core.constprop.0+0x298/0x1110 __netif_receive_skb_one_core+0x3d/0xa0 process_backlog+0xa0/0x140 __napi_poll+0x2c/0x170 net_rx_action+0x2c4/0x3a0 handle_softirqs+0xd0/0x270 do_softirq+0x3f/0x60 Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() in the callers. This is in essence disabling NS/NA suppression when IPv6 is disabled.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23372", "url": "https://ubuntu.com/security/CVE-2026-23372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: rawsock: cancel tx_work before socket teardown In rawsock_release(), cancel any pending tx_work and purge the write queue before orphaning the socket. rawsock_tx_work runs on the system workqueue and calls nfc_data_exchange which dereferences the NCI device. Without synchronization, tx_work can race with socket and device teardown when a process is killed (e.g. by SIGKILL), leading to use-after-free or leaked references. Set SEND_SHUTDOWN first so that if tx_work is already running it will see the flag and skip transmitting, then use cancel_work_sync to wait for any in-progress execution to finish, and finally purge any remaining queued skbs.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23339", "url": "https://ubuntu.com/security/CVE-2026-23339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: free skb on nci_transceive early error paths nci_transceive() takes ownership of the skb passed by the caller, but the -EPROTO, -EINVAL, and -EBUSY error paths return without freeing it. Due to issues clearing NCI_DATA_EXCHANGE fixed by subsequent changes the nci/nci_dev selftest hits the error path occasionally in NIPA, and kmemleak detects leaks: unreferenced object 0xff11000015ce6a40 (size 640): comm \"nci_dev\", pid 3954, jiffies 4295441246 hex dump (first 32 bytes): 6b 6b 6b 6b 00 a4 00 0c 02 e1 03 6b 6b 6b 6b 6b kkkk.......kkkkk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk backtrace (crc 7c40cc2a): kmem_cache_alloc_node_noprof+0x492/0x630 __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xc6/0x8f0 sock_alloc_send_pskb+0x326/0x3f0 nfc_alloc_send_skb+0x94/0x1d0 rawsock_sendmsg+0x162/0x4c0 do_syscall_64+0x117/0xfc0", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23340", "url": "https://ubuntu.com/security/CVE-2026-23340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs When shrinking the number of real tx queues, netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush qdiscs for queues which will no longer be used. qdisc_reset_all_tx_gt() currently serializes qdisc_reset() with qdisc_lock(). However, for lockless qdiscs, the dequeue path is serialized by qdisc_run_begin/end() using qdisc->seqlock instead, so qdisc_reset() can run concurrently with __qdisc_run() and free skbs while they are still being dequeued, leading to UAF. This can easily be reproduced on e.g. virtio-net by imposing heavy traffic while frequently changing the number of queue pairs: iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 done With KASAN enabled, this leads to reports like: BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: ... __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 udp_sendmsg+0x13c9/0x1fc0 ... Allocated by task 1270 on cpu 5 at 44.558414s: ... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg+0x13a6/0x1fc0 ... Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a/0x890 ... Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path by taking qdisc->seqlock for TCQ_F_NOLOCK qdiscs, matching the serialization model already used by dev_reset_queue(). Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state reflects an empty queue, avoiding needless re-scheduling.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23304", "url": "https://ubuntu.com/security/CVE-2026-23304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu() l3mdev_master_dev_rcu() can return NULL when the slave device is being un-slaved from a VRF. All other callers deal with this, but we lost the fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu() with commit 4832c30d5458 (\"net: ipv6: put host and anycast routes on device with address\"). KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418) Call Trace: ip6_pol_route (net/ipv6/route.c:2318) fib6_rule_lookup (net/ipv6/fib6_rules.c:115) ip6_route_output_flags (net/ipv6/route.c:2607) vrf_process_v6_outbound (drivers/net/vrf.c:437) I was tempted to rework the un-slaving code to clear the flag first and insert synchronize_rcu() before we remove the upper. But looks like the explicit fallback to loopback_dev is an established pattern. And I guess avoiding the synchronize_rcu() is nice, too.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23420", "url": "https://ubuntu.com/security/CVE-2026-23420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: Fix a locking bug Make sure that wl->mutex is locked before it is unlocked. This has been detected by the Clang thread-safety analyzer.", "cve_priority": "medium", "cve_public_date": "2026-04-03 14:16:00 UTC" }, { "cve": "CVE-2026-23357", "url": "https://ubuntu.com/security/CVE-2026-23357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix deadlock in error path of mcp251x_open The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish. This issue is similar to the one fixed in commit 7dd9c26bd6cf (\"can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\") but for the error path. To solve this issue move the call to free_irq() after the lock is released. Setting `priv->force_quit = 1` beforehand ensure that the IRQ handler will exit right away once it acquired the lock.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23362", "url": "https://ubuntu.com/security/CVE-2026-23362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix locking for bcm_op runtime updates Commit c2aba69d0c36 (\"can: bcm: add locking for bcm_op runtime updates\") added a locking for some variables that can be modified at runtime when updating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup(). Usually the RX_SETUP only handles and filters incoming traffic with one exception: When the RX_RTR_FRAME flag is set a predefined CAN frame is sent when a specific RTR frame is received. Therefore the rx bcm_op uses bcm_can_tx() which uses the bcm_tx_lock that was only initialized in bcm_tx_setup(). Add the missing spin_lock_init() when allocating the bcm_op in bcm_rx_setup() to handle the RTR case properly.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23286", "url": "https://ubuntu.com/security/CVE-2026-23286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix null-ptr-deref in lec_arp_clear_vccs syzkaller reported a null-ptr-deref in lec_arp_clear_vccs(). This issue can be easily reproduced using the syzkaller reproducer. In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared by multiple lec_arp_table entries (e.g., via entry->vcc or entry->recv_vcc). When the underlying VCC is closed, lec_vcc_close() iterates over all ARP entries and calls lec_arp_clear_vccs() for each matched entry. For example, when lec_vcc_close() iterates through the hlists in priv->lec_arp_empty_ones or other ARP tables: 1. In the first iteration, for the first matched ARP entry sharing the VCC, lec_arp_clear_vccs() frees the associated vpriv (which is vcc->user_back) and sets vcc->user_back to NULL. 2. In the second iteration, for the next matched ARP entry sharing the same VCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv from vcc->user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference it via `vcc->pop = vpriv->old_pop`, leading to a null-ptr-deref crash. Fix this by adding a null check for vpriv before dereferencing it. If vpriv is already NULL, it means the VCC has been cleared by a previous call, so we can safely skip the cleanup and just clear the entry's vcc/recv_vcc pointers. The entire cleanup block (including vcc_release_async()) is placed inside the vpriv guard because a NULL vpriv indicates the VCC has already been fully released by a prior iteration — repeating the teardown would redundantly set flags and trigger callbacks on an already-closing socket. The Fixes tag points to the initial commit because the entry->vcc path has been vulnerable since the original code. The entry->recv_vcc path was later added by commit 8d9f73c0ad2f (\"atm: fix a memory leak of vcc->user_back\") with the same pattern, and both paths are fixed here.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23296", "url": "https://ubuntu.com/security/CVE-2026-23296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix refcount leak for tagset_refcnt This leak will cause a hang when tearing down the SCSI host. For example, iscsid hangs with the following call trace: [130120.652718] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured PID: 2528 TASK: ffff9d0408974e00 CPU: 3 COMMAND: \"iscsid\" #0 [ffffb5b9c134b9e0] __schedule at ffffffff860657d4 #1 [ffffb5b9c134ba28] schedule at ffffffff86065c6f #2 [ffffb5b9c134ba40] schedule_timeout at ffffffff86069fb0 #3 [ffffb5b9c134bab0] __wait_for_common at ffffffff8606674f #4 [ffffb5b9c134bb10] scsi_remove_host at ffffffff85bfe84b #5 [ffffb5b9c134bb30] iscsi_sw_tcp_session_destroy at ffffffffc03031c4 [iscsi_tcp] #6 [ffffb5b9c134bb48] iscsi_if_recv_msg at ffffffffc0292692 [scsi_transport_iscsi] #7 [ffffb5b9c134bb98] iscsi_if_rx at ffffffffc02929c2 [scsi_transport_iscsi] #8 [ffffb5b9c134bbf0] netlink_unicast at ffffffff85e551d6 #9 [ffffb5b9c134bc38] netlink_sendmsg at ffffffff85e554ef", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23356", "url": "https://ubuntu.com/security/CVE-2026-23356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: fix \"LOGIC BUG\" in drbd_al_begin_io_nonblock() Even though we check that we \"should\" be able to do lc_get_cumulative() while holding the device->al_lock spinlock, it may still fail, if some other code path decided to do lc_try_lock() with bad timing. If that happened, we logged \"LOGIC BUG for enr=...\", but still did not return an error. The rest of the code now assumed that this request has references for the relevant activity log extents. The implcations are that during an active resync, mutual exclusivity of resync versus application IO is not guaranteed. And a potential crash at this point may not realizs that these extents could have been target of in-flight IO and would need to be resynced just in case. Also, once the request completes, it will give up activity log references it does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put(). Fix: Do not crash the kernel for a condition that is harmless during normal operation: also catch \"e->refcnt == 0\", not only \"e == NULL\" when being noisy about \"al_complete_io() called on inactive extent %u\\n\". And do not try to be smart and \"guess\" whether something will work, then be surprised when it does not. Deal with the fact that it may or may not work. If it does not, remember a possible \"partially in activity log\" state (only possible for requests that cross extent boundaries), and return an error code from drbd_al_begin_io_nonblock(). A latter call for the same request will then resume from where we left off.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23388", "url": "https://ubuntu.com/security/CVE-2026-23388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check metadata block offset is within range Syzkaller reports a \"general protection fault in squashfs_copy_data\" This is ultimately caused by a corrupted index look-up table, which produces a negative metadata block offset. This is subsequently passed to squashfs_copy_data (via squashfs_read_metadata) where the negative offset causes an out of bounds access. The fix is to check that the offset is within range in squashfs_read_metadata. This will trap this and other cases.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23379", "url": "https://ubuntu.com/security/CVE-2026-23379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: fix divide by zero in the offload path Offloading ETS requires computing each class' WRR weight: this is done by averaging over the sums of quanta as 'q_sum' and 'q_psum'. Using unsigned int, the same integer size as the individual DRR quanta, can overflow and even cause division by zero, like it happened in the following splat: Oops: divide error: 0000 [#1] SMP PTI CPU: 13 UID: 0 PID: 487 Comm: tc Tainted: G E 6.19.0-virtme #45 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Call Trace: ets_qdisc_change+0x870/0xf40 [sch_ets] qdisc_create+0x12b/0x540 tc_modify_qdisc+0x6d7/0xbd0 rtnetlink_rcv_msg+0x168/0x6b0 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x1d6/0x2b0 netlink_sendmsg+0x22e/0x470 ____sys_sendmsg+0x38a/0x3c0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x111/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f440b81c77e Code: 4d 89 d8 e8 d4 bc 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff951e4c10 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000481820 RCX: 00007f440b81c77e RDX: 0000000000000000 RSI: 00007fff951e4cd0 RDI: 0000000000000003 RBP: 00007fff951e4c20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff951f4fa8 R13: 00000000699ddede R14: 00007f440bb01000 R15: 0000000000486980 Modules linked in: sch_ets(E) netdevsim(E) ---[ end trace 0000000000000000 ]--- RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]--- Fix this using 64-bit integers for 'q_sum' and 'q_psum'.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23289", "url": "https://ubuntu.com/security/CVE-2026-23289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq() Fix a user triggerable leak on the system call failure path.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23279", "url": "https://ubuntu.com/security/CVE-2026-23279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix NULL pointer dereference in mesh_rx_csa_frame() In mesh_rx_csa_frame(), elems->mesh_chansw_params_ie is dereferenced at lines 1638 and 1642 without a prior NULL check: ifmsh->chsw_ttl = elems->mesh_chansw_params_ie->mesh_ttl; ... pre_value = le16_to_cpu(elems->mesh_chansw_params_ie->mesh_pre_value); The mesh_matches_local() check above only validates the Mesh ID, Mesh Configuration, and Supported Rates IEs. It does not verify the presence of the Mesh Channel Switch Parameters IE (element ID 118). When a received CSA action frame omits that IE, ieee802_11_parse_elems() leaves elems->mesh_chansw_params_ie as NULL, and the unconditional dereference causes a kernel NULL pointer dereference. A remote mesh peer with an established peer link (PLINK_ESTAB) can trigger this by sending a crafted SPECTRUM_MGMT/CHL_SWITCH action frame that includes a matching Mesh ID and Mesh Configuration IE but omits the Mesh Channel Switch Parameters IE. No authentication beyond the default open mesh peering is required. Crash confirmed on kernel 6.17.0-5-generic via mac80211_hwsim: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:ieee80211_mesh_rx_queued_mgmt+0x143/0x2a0 [mac80211] CR2: 0000000000000000 Fix by adding a NULL check for mesh_chansw_params_ie after mesh_matches_local() returns, consistent with how other optional IEs are guarded throughout the mesh code. The bug has been present since v3.13 (released 2014-01-19).", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23367", "url": "https://ubuntu.com/security/CVE-2026-23367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: radiotap: reject radiotap with unknown bits The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator->_next_ns_data isn't initialized (it's only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value. Fix this by moving the rejection of unknown radiotap fields down to after the in-namespace lookup, so it will really use iterator->_next_ns_data only for vendor namespaces, even in case undefined fields are present.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23318", "url": "https://ubuntu.com/security/CVE-2026-23318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Use correct version for UAC3 header validation The entry of the validators table for UAC3 AC header descriptor is defined with the wrong protocol version UAC_VERSION_2, while it should have been UAC_VERSION_3. This results in the validator never matching for actual UAC3 devices (protocol == UAC_VERSION_3), causing their header descriptors to bypass validation entirely. A malicious USB device presenting a truncated UAC3 header could exploit this to cause out-of-bounds reads when the driver later accesses unvalidated descriptor fields. The bug was introduced in the same commit as the recently fixed UAC3 feature unit sub-type typo, and appears to be from the same copy-paste error when the UAC3 section was created from the UAC2 section.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23370", "url": "https://ubuntu.com/security/CVE-2026-23370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data set_new_password() hex dumps the entire buffer, which contains plaintext password data, including current and new passwords. Remove the hex dump to avoid leaking credentials.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23352", "url": "https://ubuntu.com/security/CVE-2026-23352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/efi: defer freeing of boot services memory efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late(). There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area(). More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete. Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM. If the freed memory resides in the areas that memory map for them is still uninitialized, they won't be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages. Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map. Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that's undesirable late in boot when there is concurrency. More robust approach is to only defer freeing of the EFI boot services memory. Split efi_free_boot_services() in two. First efi_unmap_boot_services() collects ranges that should be freed into an array then efi_free_boot_services() later frees them after deferred init is complete.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23382", "url": "https://ubuntu.com/security/CVE-2026-23382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them In commit 2ff5baa9b527 (\"HID: appleir: Fix potential NULL dereference at raw event handle\"), we handle the fact that raw event callbacks can happen even for a HID device that has not been \"claimed\" causing a crash if a broken device were attempted to be connected to the system. Fix up the remaining in-tree HID drivers that forgot to add this same check to resolve the same issue.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23324", "url": "https://ubuntu.com/security/CVE-2026-23324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: usb: etas_es58x: correctly anchor the urb in the read bulk callback When submitting an urb, that is using the anchor pattern, it needs to be anchored before submitting it otherwise it could be leaked if usb_kill_anchored_urbs() is called. This logic is correctly done elsewhere in the driver, except in the read bulk callback so do that here also.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23298", "url": "https://ubuntu.com/security/CVE-2026-23298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ucan: Fix infinite loop from zero-length messages If a broken ucan device gets a message with the message length field set to 0, then the driver will loop for forever in ucan_read_bulk_callback(), hanging the system. If the length is 0, just skip the message and go on to the next one. This has been fixed in the kvaser_usb driver in the past in commit 0c73772cd2b8 (\"can: kvaser_usb: leaf: Fix potential infinite loop in command parsers\"), so there must be some broken devices out there like this somewhere.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23307", "url": "https://ubuntu.com/security/CVE-2026-23307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a message When looking at the data in a USB urb, the actual_length is the size of the buffer passed to the driver, not the transfer_buffer_length which is set by the driver as the max size of the buffer. When parsing the messages in ems_usb_read_bulk_callback() properly check the size both at the beginning of parsing the message to make sure it is big enough for the expected structure, and at the end of the message to make sure we don't overflow past the end of the buffer for the next message.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23290", "url": "https://ubuntu.com/security/CVE-2026-23290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: validate USB endpoints The pegasus driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23365", "url": "https://ubuntu.com/security/CVE-2026-23365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kalmia: validate USB endpoints The kalmia driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23312", "url": "https://ubuntu.com/security/CVE-2026-23312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: validate USB endpoints The kaweth driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23291", "url": "https://ubuntu.com/security/CVE-2026-23291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: properly drop the usb interface reference on disconnect When the device is disconnected from the driver, there is a \"dangling\" reference count on the usb interface that was grabbed in the probe callback. Fix this up by properly dropping the reference after we are done with it.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23253", "url": "https://ubuntu.com/security/CVE-2026-23253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: fix wrong reinitialization of ringbuffer on reopen dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock.", "cve_priority": "high", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-43123", "url": "https://ubuntu.com/security/CVE-2026-43123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: check return value of con2fb_acquire_newinfo() If fbcon_open() fails when called from con2fb_acquire_newinfo() then info->fbcon_par pointer remains NULL which is later dereferenced. Add check for return value of the function con2fb_acquire_newinfo() to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23220", "url": "https://ubuntu.com/security/CVE-2026-23220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error paths The problem occurs when a signed request fails smb2 signature verification check. In __process_request(), if check_sign_req() returns an error, set_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called. set_smb2_rsp_status() set work->next_smb2_rcv_hdr_off as zero. By resetting next_smb2_rcv_hdr_off to zero, the pointer to the next command in the chain is lost. Consequently, is_chained_smb2_message() continues to point to the same request header instead of advancing. If the header's NextCommand field is non-zero, the function returns true, causing __handle_ksmbd_work() to repeatedly process the same failed request in an infinite loop. This results in the kernel log being flooded with \"bad smb2 signature\" messages and high CPU usage. This patch fixes the issue by changing the return value from SERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures that the processing loop terminates immediately rather than attempting to continue from an invalidated offset.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-45911", "url": "https://ubuntu.com/security/CVE-2026-45911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix role switching during resume If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference. The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped. So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usb_hcd_is_primary_hcd+0x0/0x1c lr : cdns_host_resume+0x24/0x5c ... Call trace: usb_hcd_is_primary_hcd+0x0/0x1c (P) cdns_resume+0x6c/0xbc cdns3_controller_resume.isra.0+0xe8/0x17c cdns3_plat_resume+0x18/0x24 platform_pm_resume+0x2c/0x68 dpm_run_callback+0x90/0x248 device_resume+0x100/0x24c dpm_resume+0x190/0x2ec dpm_resume_end+0x18/0x34 suspend_devices_and_enter+0x2b0/0xa44 pm_suspend+0x16c/0x5fc state_store+0x80/0xec kobj_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x130/0x1dc vfs_write+0x240/0x370 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0x108 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-71287", "url": "https://ubuntu.com/security/CVE-2025-71287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memory: mtk-smi: fix device leak on larb probe Make sure to drop the reference taken when looking up the SMI device during larb probe on late probe failure (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23359", "url": "https://ubuntu.com/security/CVE-2026-23359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stack-out-of-bounds write in devmap get_upper_ifindexes() iterates over all upper devices and writes their indices into an array without checking bounds. Also the callers assume that the max number of upper devices is MAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack, but that assumption is not correct and the number of upper devices could be larger than MAX_NEST_DEV (e.g., many macvlans), causing a stack-out-of-bounds write. Add a max parameter to get_upper_ifindexes() to avoid the issue. When there are too many upper devices, return -EOVERFLOW and abort the redirect. To reproduce, create more than MAX_NEST_DEV(8) macvlans on a device with an XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS. Then send a packet to the device to trigger the XDP redirect path.", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43291", "url": "https://ubuntu.com/security/CVE-2026-43291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: nfc: nci: Fix parameter validation for packet data Since commit 9c328f54741b (\"net: nfc: nci: Add parameter validation for packet data\") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct).", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43283", "url": "https://ubuntu.com/security/CVE-2026-43283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle dma_free_coherent() in error path takes priv->rx_buf.alloc_len as the dma handle. This would lead to improper unmapping of the buffer. Change the dma handle to priv->rx_buf.alloc_phys.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43264", "url": "https://ubuntu.com/security/CVE-2026-43264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: of: display_timing: fix refcount leak in of_get_display_timings() of_parse_phandle() returns a device_node with refcount incremented, which is stored in 'entry' and then copied to 'native_mode'. When the error paths at lines 184 or 192 jump to 'entryfail', native_mode's refcount is not decremented, causing a refcount leak. Fix this by changing the goto target from 'entryfail' to 'timingfail', which properly calls of_node_put(native_mode) before cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43202", "url": "https://ubuntu.com/security/CVE-2026-43202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: vt8500lcdfb: fix missing dma_free_coherent() fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not freed if the error path is reached.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43203", "url": "https://ubuntu.com/security/CVE-2026-43203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: fore200e: fix use-after-free in tasklets during device removal When the PCA-200E or SBA-200E adapter is being detached, the fore200e is deallocated. However, the tx_tasklet or rx_tasklet may still be running or pending, leading to use-after-free bug when the already freed fore200e is accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet(). One of the race conditions can occur as follows: CPU 0 (cleanup) | CPU 1 (tasklet) fore200e_pca_remove_one() | fore200e_interrupt() fore200e_shutdown() | tasklet_schedule() kfree(fore200e) | fore200e_tx_tasklet() | fore200e-> // UAF Fix this by ensuring tx_tasklet or rx_tasklet is properly canceled before the fore200e is released. Add tasklet_kill() in fore200e_shutdown() to synchronize with any pending or running tasklets. Moreover, since fore200e_reset() could prevent further interrupts or data transfers, the tasklet_kill() should be placed after fore200e_reset() to prevent the tasklet from being rescheduled in fore200e_interrupt(). Finally, it only needs to do tasklet_kill() when the fore200e state is greater than or equal to FORE200E_STATE_IRQ, since tasklets are uninitialized in earlier states. In a word, the tasklet_kill() should be placed in the FORE200E_STATE_IRQ branch within the switch...case structure. This bug was identified through static analysis.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43149", "url": "https://ubuntu.com/security/CVE-2026-43149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean() The priv->rx_buffer and priv->tx_buffer are alloc'd together as contiguous buffers in uhdlc_init() but freed as two buffers in uhdlc_memclean(). Change the cleanup to only call dma_free_coherent() once on the whole buffer.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43273", "url": "https://ubuntu.com/security/CVE-2026-43273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: supply snapshot context in ceph_zero_partial_object() The ceph_zero_partial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.conf dd if=/dev/urandom of=/mnt/mycephfs/foo bs=64K count=1 mkdir /mnt/mycephfs/.snap/snap1 md5sum /mnt/mycephfs/.snap/snap1/foo fallocate -p -o 0 -l 4096 /mnt/mycephfs/foo echo 3 > /proc/sys/vm/drop/caches md5sum /mnt/mycephfs/.snap/snap1/foo # get different md5sum!!", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43159", "url": "https://ubuntu.com/security/CVE-2026-43159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix null dereference in find_network The variable pwlan has the possibility of being NULL when passed into rtw_free_network_nolock() which would later dereference the variable.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43211", "url": "https://ubuntu.com/security/CVE-2026-43211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: Fix pci_slot_trylock() error handling Commit a4e772898f8b (\"PCI: Add missing bridge lock to pci_bus_lock()\") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails. Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } } After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug. This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread. Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path. [Same patch later posted by Keith at https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com]", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43206", "url": "https://ubuntu.com/security/CVE-2026-43206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8 bytes via memset without checking the buffer size parameter. This allows unprivileged userspace to trigger an out-of bounds kernel memory write by passing a small buffer, leading to potential privilege escalation.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43275", "url": "https://ubuntu.com/security/CVE-2026-43275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Flush exception handling work when RPM level is zero Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0. When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race condition where the driver could attempt to access the host controller to handle an exception after the system had already entered a deep power-down state, resulting in a system crash. Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete and prevents illegal hardware access during the power-down sequence.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43145", "url": "https://ubuntu.com/security/CVE-2026-43145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_rproc: Fix invalid loaded resource table detection imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded resource table even when the current firmware does not provide one. When the device tree contains a \"rsc-table\" entry, priv->rsc_table is non-NULL and denotes where a resource table would be located if one is present in memory. However, when the current firmware has no resource table, rproc->table_ptr is NULL. The function still returns priv->rsc_table, and the remoteproc core interprets this as a valid loaded resource table. Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when there is no resource table for the current firmware (i.e. when rproc->table_ptr is NULL). This aligns the function's semantics with the remoteproc core: a loaded resource table is only reported when a valid table_ptr exists. With this change, starting firmware without a resource table no longer triggers a crash.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43147", "url": "https://ubuntu.com/security/CVE-2026-43147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV\" This reverts commit 05703271c3cd (\"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV\"), which causes a deadlock by recursively taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of pci_stop_and_remove_bus_device(). For example with the following sequence of commands: $ echo > /sys/bus/pci/devices//sriov_numvfs $ echo 1 > /sys/bus/pci/devices//remove A trimmed trace of the deadlock on a mlx5 device is as below: zsh/5715 is trying to acquire lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140 but task is already holding lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110 [<00000259779c844e>] print_deadlock_bug+0x31e/0x330 [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0 [<00000259779bffac>] lock_acquire+0x14c/0x350 [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520 [<000002597896413c>] mutex_lock_nested+0x3c/0x50 [<00000259784a07e4>] sriov_disable+0x34/0x140 [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core] [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core] [<00000259784857fc>] pci_device_remove+0x3c/0xa0 [<000002597851012e>] device_release_driver_internal+0x18e/0x280 [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0 [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80 [<00000259784972c2>] remove_store+0x72/0x90 [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200 [<0000025977d7241c>] vfs_write+0x24c/0x300 [<0000025977d72696>] ksys_write+0x86/0x110 [<000002597895b61c>] __do_syscall+0x14c/0x400 [<000002597896e0ee>] system_call+0x6e/0x90 This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43289", "url": "https://ubuntu.com/security/CVE-2026-43289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kexec: derive purgatory entry from symbol kexec_load_purgatory() derives image->start by locating e_entry inside an SHF_EXECINSTR section. If the purgatory object contains multiple executable sections with overlapping sh_addr, the entrypoint check can match more than once and trigger a WARN. Derive the entry section from the purgatory_start symbol when present and compute image->start from its final placement. Keep the existing e_entry fallback for purgatories that do not expose the symbol. WARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784 Call Trace: bzImage64_load+0x133/0xa00 __do_sys_kexec_file_load+0x2b3/0x5c0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e [me@linux.beauty: move helper to avoid forward declaration, per Baoquan]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43168", "url": "https://ubuntu.com/security/CVE-2026-43168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix reflink preserve cleanup issue commit c06c303832ec (\"ocfs2: fix xattr array entry __counted_by error\") doesn't handle all cases and the cleanup job for preserved xattr entries still has bug: - the 'last' pointer should be shifted by one unit after cleanup an array entry. - current code logic doesn't cleanup the first entry when xh_count is 1. Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43295", "url": "https://ubuntu.com/security/CVE-2026-43295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net() When idtab allocation fails, net is not registered with rio_add_net() yet, so kfree(net) is sufficient to release the memory. Set mport->net to NULL to avoid dangling pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43148", "url": "https://ubuntu.com/security/CVE-2026-43148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/smp: Add check for kcalloc() failure in parse_thread_groups() As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing it to of_property_read_u32_array().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43163", "url": "https://ubuntu.com/security/CVE-2026-43163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/bitmap: fix GPF in write_page caused by resize race A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod] This is a use-after-free race between bitmap_daemon_work() and __bitmap_resize(). The daemon iterates over `bitmap->storage.filemap` without locking, while the resize path frees that storage via md_bitmap_file_unmap(). `quiesce()` does not stop the md thread, allowing concurrent access to freed pages. Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43200", "url": "https://ubuntu.com/security/CVE-2026-43200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functions struct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target); While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specify the parameters in the correct order, pci_primary_epc_epf_unlink() and pci_secondary_epc_epf_unlink() specify the parameters in the wrong order, leading to the below kernel crash when using the unlink command in configfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0 [mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43158", "url": "https://ubuntu.com/security/CVE-2026-43158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix freemap adjustments when adding xattrs to leaf blocks xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) \t\t\t\t\t+ xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where \"rhs\" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 (\"xfs: fix attr leaf header freemap.size underflow\") and the previous patch that resets zero length freemap entries to have base = 0.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43187", "url": "https://ubuntu.com/security/CVE-2026-43187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: delete attr leaf freemap entries when empty Back in commit 2a2b5932db6758 (\"xfs: fix attr leaf header freemap.size underflow\"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the \"pushed-up\" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43130", "url": "https://ubuntu.com/security/CVE-2026-43130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode Commit 4fc82cd907ac (\"iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected\") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system. For example, if a VM fails to connect to the PCIe device, \"virsh destroy\" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd. Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput Although pci_device_is_present() is slower than pci_dev_is_disconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase. Besides, devtlb_invalidation_with_pasid() is called only in the paths below, which are far less frequent than memory map/unmap. 1. mm-struct release 2. {attach,release}_dev 3. set/remove PASID 4. dirty-tracking setup The gain in system stability far outweighs the negligible cost of using pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43133", "url": "https://ubuntu.com/security/CVE-2026-43133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation Commit cc3ed80ae69f (\"KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state\") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01. As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43196", "url": "https://ubuntu.com/security/CVE-2026-43196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: ti: pruss: Fix double free in pruss_clk_mux_setup() In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectly calls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np) on the error path. However, after the devm_add_action_or_reset() returns, the of_node_put(clk_mux_np) is called again, causing a double free. Fix by returning directly, to avoid the duplicate of_node_put().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43242", "url": "https://ubuntu.com/security/CVE-2026-43242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: ti: k3-socinfo: Fix regmap leak on probe failure The mmio regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43278", "url": "https://ubuntu.com/security/CVE-2026-43278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: clear cloned request bio pointer when last clone bio completes Stale rq->bio values have been observed to cause double-initialization of cloned bios in request-based device-mapper targets, leading to use-after-free and double-free scenarios. One such case occurs when using dm-multipath on top of a PCIe NVMe namespace, where cloned request bios are freed during blk_complete_request(), but rq->bio is left intact. Subsequent clone teardown then attempts to free the same bios again via blk_rq_unprep_clone(). The resulting double-free path looks like: nvme_pci_complete_batch() nvme_complete_batch() blk_mq_end_request_batch() blk_complete_request() // called on a DM clone request bio_endio() // first free of all clone bios ... rq->end_io() // end_clone_request() dm_complete_request(tio->orig) dm_softirq_done() dm_done() dm_end_request() blk_rq_unprep_clone() // second free of clone bios Fix this by clearing the clone request's bio pointer when the last cloned bio completes, ensuring that later teardown paths do not attempt to free already-released bios.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43312", "url": "https://ubuntu.com/security/CVE-2026-43312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov5647: Initialize subdev before controls In ov5647_init_controls() we call v4l2_get_subdevdata, but it is initialized by v4l2_i2c_subdev_init() in the probe, which currently happens after init_controls(). This can result in a segfault if the error condition is hit, and we try to access i2c_client, so fix the order.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43182", "url": "https://ubuntu.com/security/CVE-2026-43182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ccs: Avoid possible division by zero Calculating maximum M for scaler configuration involves dividing by MIN_X_OUTPUT_SIZE limit register's value. Albeit the value is presumably non-zero, the driver was missing the check it in fact was. Fix this.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43246", "url": "https://ubuntu.com/security/CVE-2026-43246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c/tw9906: Fix potential memory leak in tw9906_probe() In one of the error paths in tw9906_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43218", "url": "https://ubuntu.com/security/CVE-2026-43218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c/tw9903: Fix potential memory leak in tw9903_probe() In one of the error paths in tw9903_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43135", "url": "https://ubuntu.com/security/CVE-2026-43135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: Add missing unmap in snd_cx23885_hw_params() In error path, add cx23885_alsa_dma_unmap() to release the resource acquired by cx23885_alsa_dma_map().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43257", "url": "https://ubuntu.com/security/CVE-2026-43257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx88: Add missing unmap in snd_cx88_hw_params() In error path, add cx88_alsa_dma_unmap() to release resource acquired by cx88_alsa_dma_map().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43231", "url": "https://ubuntu.com/security/CVE-2026-43231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-keene: fix memory leak in error path Fix a memory leak in usb_keene_probe(). The v4l2 control handler is initialized and controls are added, but if v4l2_device_register() or video_register_device() fails afterward, the handler was never freed, leaking memory. Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensure the control handler is properly freed for all error paths after it is initialized.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43136", "url": "https://ubuntu.com/security/CVE-2026-43136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Check maxfield in hidpp_get_report_length() Do not crash when a report has no fields. Fake USB gadgets can send their own HID report descriptors and can define report structures without valid fields. This can be used to crash the kernel over USB.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43251", "url": "https://ubuntu.com/security/CVE-2026-43251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: prodikeys: Check presence of pm->input_ep82 Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, pm->input_ep82 stays NULL, which leads to a crash later. This does not happen with the real device, but can be provoked by imposing as one.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43140", "url": "https://ubuntu.com/security/CVE-2026-43140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: Do not crash on missing msc->input Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, msc->input stays NULL, leading to a crash at a later time. Detect this condition in the input_configured() hook and reject the device. This is not supposed to happen with actual magic mouse devices, but can be provoked by imposing as a magic mouse USB device.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43152", "url": "https://ubuntu.com/security/CVE-2026-43152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hid-pl: handle probe errors Errors in init must be reported back or we'll follow a NULL pointer the first time FF is used.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43315", "url": "https://ubuntu.com/security/CVE-2026-43315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeeding Drop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failing as it is trivially easy to trigger from userspace by modifying CPUID after loading CR3. E.g. modifying the state restoration selftest like so: --- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main(int argc, char *argv[]) /* Restore state in a new VM. */ vcpu = vm_recreate_with_one_vcpu(vm); - vcpu_load_state(vcpu, state); + + if (stage == 4) { + state->sregs.cr3 = BIT(44); + vcpu_load_state(vcpu, state); + + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36); + __vcpu_nested_state_set(vcpu, &state->nested); + } else { + vcpu_load_state(vcpu, state); + } /* * Restore XSAVE state in a dummy vCPU, first without doing generates: WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd] Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm] CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd] Call Trace: kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm] kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Simply delete the WARN instead of trying to prevent userspace from shoving \"illegal\" state into CR3. For better or worse, KVM's ABI allows userspace to set CPUID after SREGS, and vice versa, and KVM is very permissive when it comes to guest CPUID. I.e. attempting to enforce the virtual CPU model when setting CPUID could break userspace. Given that the WARN doesn't provide any meaningful protection for KVM or benefit for userspace, simply drop it even though the odds of breaking userspace are minuscule. Opportunistically delete a spurious newline.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43270", "url": "https://ubuntu.com/security/CVE-2026-43270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove() In mtk_mdp_probe(), vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43207", "url": "https://ubuntu.com/security/CVE-2026-43207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix error handling in probe function Add mtk_mdp_unregister_m2m_device() on the error handling path to prevent resource leak. Add check for the return value of vpu_get_plat_device() to prevent null pointer dereference. And vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43132", "url": "https://ubuntu.com/security/CVE-2026-43132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: correctly handle dm_bufio_client_create() failure If either of the calls to dm_bufio_client_create() in verity_fec_ctr() fails, then dm_bufio_client_destroy() is later called with an ERR_PTR() argument. That causes a crash. Fix this.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2025-71274", "url": "https://ubuntu.com/security/CVE-2025-71274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: core: fix race in driver_override_show() and use core helper The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string_attr macro with explicit show and store functions. The new driver_override_store uses the standard driver_set_override helper. Since the introduction of driver_set_override, the comments in include/linux/rpmsg.h have stated that this helper must be used to set or clear driver_override, but the implementation was not updated until now. Because driver_set_override modifies and frees the string while holding the device_lock, the new driver_override_show now correctly holds the device_lock during the read operation to prevent the race. Additionally, since rpmsg_string_attr has only ever been used for driver_override, removing the macro simplifies the code.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43233", "url": "https://ubuntu.com/security/CVE-2026-43233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: fix OOB read in decode_choice() In decode_choice(), the boundary check before get_len() uses the variable `len`, which is still 0 from its initialization at the top of the function: unsigned int type, ext, len = 0; ... if (ext || (son->attr & OPEN)) { BYTE_ALIGN(bs); if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */ return H323_ERROR_BOUND; len = get_len(bs); /* OOB read */ When the bitstream is exactly consumed (bs->cur == bs->end), the check nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent get_len() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well. This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nf_conntrack_h323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer. Fix this by checking for 2 bytes (the maximum that get_len() may read) instead of the uninitialized `len`. This matches the pattern used at every other get_len() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43205", "url": "https://ubuntu.com/security/CVE-2026-43205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: validate num_ifs to prevent out-of-bounds write The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes() but never validates it against DPSW_MAX_IF (64). This value controls iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices into the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reports num_ifs >= 64, the loop can write past the array bounds. Add a bound check for num_ifs in dpaa2_switch_init(). dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all ports match the flood filter, the loop fills all 64 slots and the control interface write overflows by one entry. The check uses >= because num_ifs == DPSW_MAX_IF is also functionally broken. build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ...", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43194", "url": "https://ubuntu.com/security/CVE-2026-43194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: consume xmit errors of GSO frames udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min. These tests use veth to simulate GRO. They attach a trivial (\"return XDP_PASS;\") XDP program to the veth to force TSO off and NAPI on. Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]). In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck. The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok | ok ok ok \\\\ \t\t\t snd_nxt \"x\" means packet lost by veth, and \"ok\" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent. So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above). Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely. We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-\"networks\" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix? Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link).", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43156", "url": "https://ubuntu.com/security/CVE-2026-43156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: enable basic endpoint checking pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors: - usb_rcvbulkpipe(dev, 1) for RX data - usb_sndbulkpipe(dev, 2) for TX data - usb_rcvintpipe(dev, 3) for status interrupts A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes. Add a pegasus_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion. Similar fix to - commit 90b7f2961798 (\"net: usb: rtl8150: enable basic endpoint checking\") - commit 9e7021d2aeae (\"net: usb: catc: enable basic endpoint checking\")", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43232", "url": "https://ubuntu.com/security/CVE-2026-43232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets When the FarSync T-series card is being detached, the fst_card_info is deallocated in fst_remove_one(). However, the fst_tx_task or fst_int_task may still be running or pending, leading to use-after-free bugs when the already freed fst_card_info is accessed in fst_process_tx_work_q() or fst_process_int_work_q(). A typical race condition is depicted below: CPU 0 (cleanup) | CPU 1 (tasklet) | fst_start_xmit() fst_remove_one() | tasklet_schedule() unregister_hdlc_device()| | fst_process_tx_work_q() //handler kfree(card) //free | do_bottom_half_tx() | card-> //use The following KASAN trace was captured: ================================================================== BUG: KASAN: slab-use-after-free in do_bottom_half_tx+0xb88/0xd00 Read of size 4 at addr ffff88800aad101c by task ksoftirqd/3/32 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcb/0x5d0 ? do_bottom_half_tx+0xb88/0xd00 kasan_report+0xb8/0xf0 ? do_bottom_half_tx+0xb88/0xd00 do_bottom_half_tx+0xb88/0xd00 ? _raw_spin_lock_irqsave+0x85/0xe0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx___hrtimer_run_queues+0x10/0x10 fst_process_tx_work_q+0x67/0x90 tasklet_action_common+0x1fa/0x720 ? hrtimer_interrupt+0x31f/0x780 handle_softirqs+0x176/0x530 __irq_exit_rcu+0xab/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 41 on cpu 3 at 72.330843s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 __kasan_kmalloc+0x7f/0x90 fst_add_one+0x1a5/0x1cd0 local_pci_probe+0xdd/0x190 pci_device_probe+0x341/0x480 really_probe+0x1c6/0x6a0 __driver_probe_device+0x248/0x310 driver_probe_device+0x48/0x210 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x101/0x190 __device_attach+0x198/0x3a0 device_initial_probe+0x78/0xa0 pci_bus_add_device+0x81/0xc0 pci_bus_add_devices+0x7e/0x190 enable_slot+0x9b9/0x1130 acpiphp_check_bridge.part.0+0x2e1/0x460 acpiphp_hotplug_notify+0x36c/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... Freed by task 41 on cpu 1 at 75.138639s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x135/0x410 fst_remove_one+0x2ca/0x540 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0x364/0x530 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device+0xd/0x20 disable_slot+0x116/0x260 acpiphp_disable_and_eject_slot+0x4b/0x190 acpiphp_hotplug_notify+0x230/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... The buggy address belongs to the object at ffff88800aad1000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 28 bytes inside of freed 1024-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xaad0 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x100000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000003 ffffea00002ab401 00000000ffffffff 00000000ffffffff head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88800aad0f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800aad0f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800aad1000: fa fb ---truncated---", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43134", "url": "https://ubuntu.com/security/CVE-2026-43134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ This adds a check for encryption key size upon receiving L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAP_CR_LE_BAD_KEY_SIZE.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43180", "url": "https://ubuntu.com/security/CVE-2026-43180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls netif_stop_queue() and netif_wake_queue(). These are TX queue flow control functions unrelated to RX multicast configuration. The premature netif_wake_queue() can re-enable TX while tx_urb is still in-flight, leading to a double usb_submit_urb() on the same URB: kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); } kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done } kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active } This triggers the WARN in usb_submit_urb(): \"URB submitted while active\" This is a similar class of bug fixed in rtl8150 by - commit 958baf5eaee3 (\"net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast\"). Also kaweth_set_rx_mode() is already functionally broken, the real set_rx_mode action is performed by kaweth_async_set_rx_mode(), which in turn is not a no-op only at ndo_open() time.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43139", "url": "https://ubuntu.com/security/CVE-2026-43139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix uninitialized saddr in xfrm6_get_saddr() xfrm6_get_saddr() does not check the return value of ipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6_get_saddr() still returns 0 (success). This causes the caller xfrm_tmpl_resolve_one() to use the uninitialized address in xfrm_state_find(), triggering KMSAN warning: ===================================================== BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940 xfrm_state_find+0x2424/0xa940 xfrm_resolve_and_create_bundle+0x906/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 xfrm_lookup_route+0x63/0x2b0 ip_route_output_flow+0x1ce/0x270 udp_sendmsg+0x2ce1/0x3400 inet_sendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64_sys_sendto+0x130/0x200 x64_sys_call+0x332b/0x3e70 do_syscall_64+0xd3/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable tmp.i.i created at: xfrm_resolve_and_create_bundle+0x3e3/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 ===================================================== Fix by checking the return value of ipv6_dev_get_saddr() and propagating the error.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43141", "url": "https://ubuntu.com/security/CVE-2026-43141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut Number of MW LUTs depends on NTB configuration and can be set to zero, in such scenario rounddown_pow_of_two will cause undefined behaviour and should not be performed. This patch ensures that rounddown_pow_of_two is called on valid value.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43241", "url": "https://ubuntu.com/security/CVE-2026-43241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access Number of MW LUTs depends on NTB configuration and can be set to MAX_MWS, This patch protects against invalid index out of bounds access to mw_sizes When invalid access print message to user that configuration is not valid.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43279", "url": "https://ubuntu.com/security/CVE-2026-43279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Add sanity check for OOB writes at silencing At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2025-71267", "url": "https://ubuntu.com/security/CVE-2025-71267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an ATTR_LIST attribute indicates a zero data size while the driver allocates memory for it. When ntfs_load_attr_list() processes a resident ATTR_LIST with data_size set to zero, it still allocates memory because of al_aligned(0). This creates an inconsistent state where ni->attr_list.size is zero, but ni->attr_list.le is non-null. This causes ni_enum_attr_ex to incorrectly assume that no attribute list exists and enumerates only the primary MFT record. When it finds ATTR_LIST, the code reloads it and restarts the enumeration, repeating indefinitely. The mount operation never completes, hanging the kernel thread. This patch adds validation to ensure that data_size is non-zero before memory allocation. When a zero-sized ATTR_LIST is detected, the function returns -EINVAL, preventing a DoS vulnerability.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2025-71265", "url": "https://ubuntu.com/security/CVE-2025-71265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an attribute header indicates an empty run list, while directory entries reference it as containing actual data. In NTFS, setting evcn=-1 with svcn=0 is a valid way to represent an empty run list, and run_unpack() correctly handles this by checking if evcn + 1 equals svcn and returning early without parsing any run data. However, this creates a problem when there is metadata inconsistency, where the attribute header claims to be empty (evcn=-1) but the caller expects to read actual data. When run_unpack() immediately returns success upon seeing this condition, it leaves the runs_tree uninitialized with run->runs as a NULL. The calling function attr_load_runs_range() assumes that a successful return means that the runs were loaded and sets clen to 0, expecting the next run_lookup_entry() call to succeed. Because runs_tree remains uninitialized, run_lookup_entry() continues to fail, and the loop increments vcn by zero (vcn += 0), leading to an infinite loop. This patch adds a retry counter to detect when run_lookup_entry() fails consecutively after attr_load_runs_vcn(). If the run is still not found on the second attempt, it indicates corrupted metadata and returns -EINVAL, preventing the Denial-of-Service (DoS) vulnerability.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2025-71266", "url": "https://ubuntu.com/security/CVE-2025-71266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: check return value of indx_find to avoid infinite loop We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed dentry in the ntfs3 filesystem can cause the kernel to hang during the lookup operations. By setting the HAS_SUB_NODE flag in an INDEX_ENTRY within a directory's INDEX_ALLOCATION block and manipulating the VCN pointer, an attacker can cause the indx_find() function to repeatedly read the same block, allocating 4 KB of memory each time. The kernel lacks VCN loop detection and depth limits, causing memory exhaustion and an OOM crash. This patch adds a return value check for fnd_push() to prevent a memory exhaustion vulnerability caused by infinite loops. When the index exceeds the size of the fnd->nodes array, fnd_push() returns -EINVAL. The indx_find() function checks this return value and stops processing, preventing further memory allocation.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-43225", "url": "https://ubuntu.com/security/CVE-2026-43225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix memory leak on failure path cfg80211_inform_bss_frame() may return NULL on failure. In that case, the allocated buffer 'buf' is not freed and the function returns early, leading to potential memory leak. Fix this by ensuring that 'buf' is freed on both success and failure paths.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43230", "url": "https://ubuntu.com/security/CVE-2026-43230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: Clear reconnect pending bit When canceling the reconnect worker, care must be taken to reset the reconnect-pending bit. If the reconnect worker has not yet been scheduled before it is canceled, the reconnect-pending bit will stay on forever.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43296", "url": "https://ubuntu.com/security/CVE-2026-43296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Workaround SQM/PSE stalls by disabling sticky NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated. work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21) These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43226", "url": "https://ubuntu.com/security/CVE-2026-43226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: No shortcut out of RDS_CONN_ERROR RDS connections carry a state \"rds_conn_path::cp_state\" and transitions from one state to another and are conditional upon an expected state: \"rds_conn_path_transition.\" There is one exception to this conditionality, which is \"RDS_CONN_ERROR\" that can be enforced by \"rds_conn_path_drop\" regardless of what state the condition is currently in. But as soon as a connection enters state \"RDS_CONN_ERROR\", the connection handling code expects it to go through the shutdown-path. The RDS/TCP multipath changes added a shortcut out of \"RDS_CONN_ERROR\" straight back to \"RDS_CONN_CONNECTING\" via \"rds_tcp_accept_one_path\" (e.g. after \"rds_tcp_state_change\"). A subsequent \"rds_tcp_reset_callbacks\" can then transition the state to \"RDS_CONN_RESETTING\" with a shutdown-worker queued. That'll trip up \"rds_conn_init_shutdown\", which was never adjusted to handle \"RDS_CONN_RESETTING\" and subsequently drops the connection with the dreaded \"DR_INV_CONN_STATE\", which leaves \"RDS_SHUTDOWN_WORK_QUEUED\" on forever. So we do two things here: a) Don't shortcut \"RDS_CONN_ERROR\", but take the longer path through the shutdown code. b) Add \"RDS_CONN_RESETTING\" to the expected states in \"rds_conn_init_shutdown\" so that we won't error out and get stuck, if we ever hit weird state transitions like this again.\"", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43190", "url": "https://ubuntu.com/security/CVE-2026-43190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_tcpmss: check remaining length before reading optlen Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload).", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43255", "url": "https://ubuntu.com/security/CVE-2026-43255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix WARNING in usb_tx_block The function usb_tx_block() submits cardp->tx_urb without ensuring that any previous transmission on this URB has completed. If a second call occurs while the URB is still active (e.g. during rapid firmware loading), usb_submit_urb() detects the active state and triggers a warning: 'URB submitted while active'. Fix this by enforcing serialization: call usb_kill_urb() before submitting the new request. This ensures the URB is idle and safe to reuse.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43314", "url": "https://ubuntu.com/security/CVE-2026-43314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: remove fake timeout to avoid leak request Since commit 15f73f5b3e59 (\"blk-mq: move failure injection out of blk_mq_complete_request\"), drivers are responsible for calling blk_should_fake_timeout() at appropriate code paths and opportunities. However, the dm driver does not implement its own timeout handler and relies on the timeout handling of its slave devices. If an io-timeout-fail error is injected to a dm device, the request will be leaked and never completed, causing tasks to hang indefinitely. Reproduce: 1. prepare dm which has iscsi slave device 2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times 3. read/write dm 4. iscsiadm -m node -u Result: hang task like below [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds. [ 862.244133] Tainted: G E 6.19.0-rc1+ #51 [ 862.244337] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000 [ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi] [ 862.245264] Call Trace: [ 862.245587] [ 862.245814] __schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120 [ 862.247688] elevator_change+0x16d/0x460 [ 862.247893] elevator_set_none+0x87/0xf0 [ 862.248798] blk_unregister_queue+0x12e/0x2a0 [ 862.248995] __del_gendisk+0x231/0x7e0 [ 862.250143] del_gendisk+0x12f/0x1d0 [ 862.250339] sd_remove+0x85/0x130 [sd_mod] [ 862.250650] device_release_driver_internal+0x36d/0x530 [ 862.250849] bus_remove_device+0x1dd/0x3f0 [ 862.251042] device_del+0x38a/0x930 [ 862.252095] __scsi_remove_device+0x293/0x360 [ 862.252291] scsi_remove_target+0x486/0x760 [ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi] [ 862.252886] process_one_work+0x633/0xe50 [ 862.253101] worker_thread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] ret_from_fork+0x2a6/0x470 [ 862.255852] ret_from_fork_asm+0x1a/0x30 [ 862.256037] Remove the blk_should_fake_timeout() check from dm, as dm has no native timeout handling and should not attempt to fake timeouts.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-71292", "url": "https://ubuntu.com/security/CVE-2025-71292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: nlink overflow in jfs_rename If nlink is maximal for a directory (-1) and inside that directory you perform a rename for some child directory (not moving from the parent), then the nlink of the first directory is first incremented and later decremented. Normally this is fine, but when nlink = -1 this causes a wrap around to 0, and then drop_nlink issues a warning. After applying the patch syzbot no longer issues any warnings. I also ran some basic fs tests to look for any regressions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43236", "url": "https://ubuntu.com/security/CVE-2026-43236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying the atmel_hlcdc_plane state structure without properly duplicating the drm_plane_state. In particular, state->commit remained set to the old state commit, which can lead to a use-after-free in the next drm_atomic_commit() call. Fix this by calling __drm_atomic_helper_duplicate_plane_state(), which correctly clones the base drm_plane_state (including the ->commit pointer). It has been seen when closing and re-opening the device node while another DRM client (e.g. fbdev) is still attached: ============================================================================= BUG kmalloc-64 (Not tainted): Poison overwritten ----------------------------------------------------------------------------- 0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0 pid=29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28 Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0 pid=169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0 flags=0x200(workingset|zone=0) Object 0xc611b340 @offset=832 fp=0xc611b7c0", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43269", "url": "https://ubuntu.com/security/CVE-2026-43269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback After several commits, the slab memory increases. Some drm_crtc_commit objects are not freed. The atomic_destroy_state callback only put the framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function to put all the objects that are no longer needed. It has been seen after hours of usage of a graphics application or using kmemleak: unreferenced object 0xc63a6580 (size 64): comm \"egt_basic\", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleak_alloc+0x34/0x3c __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43287", "url": "https://ubuntu.com/security/CVE-2026-43287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Account property blob allocations to memcg DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory. Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM. Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43183", "url": "https://ubuntu.com/security/CVE-2026-43183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx25821: Fix a resource leak in cx25821_dev_setup() Add release_mem_region() if ioremap() fails to release the memory region obtained by cx25821_get_resources().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43316", "url": "https://ubuntu.com/security/CVE-2026-43316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: solo6x10: Check for out of bounds chip_id Clang with CONFIG_UBSAN_SHIFT=y noticed a condition where a signed type (literal \"1\" is an \"int\") could end up being shifted beyond 32 bits, so instrumentation was added (and due to the double is_tw286x() call seen via inlining), Clang decides the second one must now be undefined behavior and elides the rest of the function[1]. This is a known problem with Clang (that is still being worked on), but we can avoid the entire problem by actually checking the existing max chip ID, and now there is no runtime instrumentation added at all since everything is known to be within bounds. Additionally use an unsigned value for the shift to remove the instrumentation even without the explicit bounds checking. [hverkuil: fix checkpatch warning for is_tw286x]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43223", "url": "https://ubuntu.com/security/CVE-2026-43223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix URB leak in pvr2_send_request_ex When pvr2_send_request_ex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2_send_request_ex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usb_submit_urb(). Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43302", "url": "https://ubuntu.com/security/CVE-2026-43302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Set DMA segment size to avoid debug warnings When using V3D rendering with CONFIG_DMA_API_DEBUG enabled, the kernel occasionally reports a segment size mismatch. This is because 'max_seg_size' is not set. The kernel defaults to 64K. setting 'max_seg_size' to the maximum will prevent 'debug_dma_map_sg()' from complaining about the over-mapping of the V3D segment length. DMA-API: v3d 1002000000.v3d: mapping sg segment longer than device claims to support [len=8290304] [max=65536] WARNING: CPU: 0 PID: 493 at kernel/dma/debug.c:1179 debug_dma_map_sg+0x330/0x388 CPU: 0 UID: 0 PID: 493 Comm: Xorg Not tainted 6.12.53-yocto-standard #1 Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_dma_map_sg+0x330/0x388 lr : debug_dma_map_sg+0x330/0x388 sp : ffff8000829a3ac0 x29: ffff8000829a3ac0 x28: 0000000000000001 x27: ffff8000813fe000 x26: ffffc1ffc0000000 x25: ffff00010fdeb760 x24: 0000000000000000 x23: ffff8000816a9bf0 x22: 0000000000000001 x21: 0000000000000002 x20: 0000000000000002 x19: ffff00010185e810 x18: ffffffffffffffff x17: 69766564206e6168 x16: 74207265676e6f6c x15: 20746e656d676573 x14: 20677320676e6970 x13: 5d34303334393134 x12: 0000000000000000 x11: 00000000000000c0 x10: 00000000000009c0 x9 : ffff8000800e0b7c x8 : ffff00010a315ca0 x7 : ffff8000816a5110 x6 : 0000000000000001 x5 : 000000000000002b x4 : 0000000000000002 x3 : 0000000000000008 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00010a315280 Call trace: debug_dma_map_sg+0x330/0x388 __dma_map_sg_attrs+0xc0/0x278 dma_map_sgtable+0x30/0x58 drm_gem_shmem_get_pages_sgt+0xb4/0x140 v3d_bo_create_finish+0x28/0x130 [v3d] v3d_create_bo_ioctl+0x54/0x180 [v3d] drm_ioctl_kernel+0xc8/0x140 drm_ioctl+0x2d4/0x4d8", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43124", "url": "https://ubuntu.com/security/CVE-2026-43124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore: ram_core: fix incorrect success return when vmap() fails In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43227", "url": "https://ubuntu.com/security/CVE-2026-43227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/sh_tmu: Always leave device running after probe The TMU device can be used as both a clocksource and a clockevent provider. The driver tries to be smart and power itself on and off, as well as enabling and disabling its clock when it's not in operation. This behavior is slightly altered if the TMU is used as an early platform device in which case the device is left powered on after probe, but the clock is still enabled and disabled at runtime. This has worked for a long time, but recent improvements in PREEMPT_RT and PROVE_LOCKING have highlighted an issue. As the TMU registers itself as a clockevent provider, clockevents_register_device(), it needs to use raw spinlocks internally as this is the context of which the clockevent framework interacts with the TMU driver. However in the context of holding a raw spinlock the TMU driver can't really manage its power state or clock with calls to pm_runtime_*() and clk_*() as these calls end up in other platform drivers using regular spinlocks to control power and clocks. This mix of spinlock contexts trips a lockdep warning. ============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90 For non-PREEMPT_RT builds this is not really an issue, but for PREEMPT_RT builds where normal spinlocks can sleep this might be an issue. Be cautious and always leave the power and clock running after probe.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43313", "url": "https://ubuntu.com/security/CVE-2026-43313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4() In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDE device and then reassigned an ISA device: dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...); dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...); If the first lookup succeeds but the second fails, dev becomes NULL. This leads to a potential null-pointer dereference when dev_dbg() is called: if (errata.piix4.bmisx) dev_dbg(&dev->dev, ...); To prevent this, use two temporary pointers and retrieve each device independently, avoiding overwriting dev with a possible NULL value. [ rjw: Subject adjustment, added an empty code line ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43266", "url": "https://ubuntu.com/security/CVE-2026-43266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EFI/CPER: don't go past the ARM processor CPER record buffer There's a logic inside GHES/CPER to detect if the section_length is too small, but it doesn't detect if it is too big. Currently, if the firmware receives an ARM processor CPER record stating that a section length is big, kernel will blindly trust section_length, producing a very long dump. For instance, a 67 bytes record with ERR_INFO_NUM set 46198 and section length set to 854918320 would dump a lot of data going a way past the firmware memory-mapped area. Fix it by adding a logic to prevent it to go past the buffer if ERR_INFO_NUM is too big, making it report instead: \t[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 \t[Hardware Error]: event severity: recoverable \t[Hardware Error]: Error 0, type: recoverable \t[Hardware Error]: section_type: ARM processor error \t[Hardware Error]: MIDR: 0xff304b2f8476870a \t[Hardware Error]: section length: 854918320, CPER size: 67 \t[Hardware Error]: section length is too big \t[Hardware Error]: firmware-generated error record is incorrect \t[Hardware Error]: ERR_INFO_NUM is 46198 [ rjw: Subject and changelog tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43277", "url": "https://ubuntu.com/security/CVE-2026-43277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: APEI/GHES: ensure that won't go past CPER allocated record The logic at ghes_new() prevents allocating too large records, by checking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB). Yet, the allocation is done with the actual number of pages from the CPER bios table location, which can be smaller. Yet, a bad firmware could send data with a different size, which might be bigger than the allocated memory, causing an OOPS: Unable to handle kernel paging request at virtual address fff00000f9b40000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000 [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 Workqueue: kacpi_notify acpi_os_execute_deferred pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : hex_dump_to_buffer+0x30c/0x4a0 lr : hex_dump_to_buffer+0x328/0x4a0 sp : ffff800080e13880 x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083 x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004 x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083 x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010 x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008 x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020 x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000 x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008 Call trace: hex_dump_to_buffer+0x30c/0x4a0 (P) print_hex_dump+0xac/0x170 cper_estatus_print_section+0x90c/0x968 cper_estatus_print+0xf0/0x158 __ghes_print_estatus+0xa0/0x148 ghes_proc+0x1bc/0x220 ghes_notify_hed+0x5c/0xb8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x80 acpi_hed_notify+0x28/0x40 acpi_ev_notify_dispatch+0x50/0x80 acpi_os_execute_deferred+0x24/0x48 process_one_work+0x15c/0x3b0 worker_thread+0x2d0/0x400 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44) ---[ end trace 0000000000000000 ]--- Prevent that by taking the actual allocated are into account when checking for CPER length. [ rjw: Subject tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43171", "url": "https://ubuntu.com/security/CVE-2026-43171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EFI/CPER: don't dump the entire memory region The current logic at cper_print_fw_err() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory. The end result can be: - the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region. Fix it by checking if the section length is too small before doing a hex dump. [ rjw: Subject tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43184", "url": "https://ubuntu.com/security/CVE-2026-43184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rnbd-srv: Zero the rsp buffer before using it Before using the data buffer to send back the response message, zero it completely. This prevents any stray bytes to be picked up by the client side when there the message is exchanged between different protocol versions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43261", "url": "https://ubuntu.com/security/CVE-2026-43261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Add support for TSV110 Spectre-BHB mitigation The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43262", "url": "https://ubuntu.com/security/CVE-2026-43262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fiemap page fault fix In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault. Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary. Fixes xfstest generic/742.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43209", "url": "https://ubuntu.com/security/CVE-2026-43209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: minix: Add required sanity checking to minix_check_superblock() The fs/minix implementation of the minix filesystem does not currently support any other value for s_log_zone_size than 0. This is also the only value supported in util-linux; see mkfs.minix.c line 511. In addition, this patch adds some sanity checking for the other minix superblock fields, and moves the minix_blocks_needed() checks for the zmap and imap also to minix_check_super_block(). This also closes a related syzbot bug report.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43268", "url": "https://ubuntu.com/security/CVE-2026-43268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: pretend special inodes as regular files Since commit af153bb63a33 (\"vfs: catch invalid modes in may_open()\") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23241", "url": "https://ubuntu.com/security/CVE-2026-23241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: add missing syscalls to read class The \"at\" variant of getxattr() and listxattr() are missing from the audit read class. Calling getxattrat() or listxattrat() on a file to read its extended attributes will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds missing syscalls to the audit read class.", "cve_priority": "medium", "cve_public_date": "2026-03-17 10:16:00 UTC" }, { "cve": "CVE-2025-71239", "url": "https://ubuntu.com/security/CVE-2025-71239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: add fchmodat2() to change attributes class fchmodat2(), introduced in version 6.6 is currently not in the change attribute class of audit. Calling fchmodat2() to change a file attribute in the same fashion than chmod() or fchmodat() will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds fchmodat2() to the change attributes class.", "cve_priority": "medium", "cve_public_date": "2026-03-17 10:15:00 UTC" }, { "cve": "CVE-2026-45964", "url": "https://ubuntu.com/security/CVE-2026-45964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path Commit 5940d1cf9f42 (\"SUNRPC: Rebalance a kref in auth_gss.c\") added a kref_get(&gss_auth->kref) call to balance the gss_put_auth() done in gss_release_msg(), but forgot to add a corresponding kref_put() on the error path when kstrdup_const() fails. If service_name is non-NULL and kstrdup_const() fails, the function jumps to err_put_pipe_version which calls put_pipe_version() and kfree(gss_msg), but never releases the gss_auth reference. This leads to a kref leak where the gss_auth structure is never freed. Add a forward declaration for gss_free_callback() and call kref_put() in the err_put_pipe_version error path to properly release the reference taken earlier.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45870", "url": "https://ubuntu.com/security/CVE-2026-45870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: auth_gss: fix memory leaks in XDR decoding error paths The gssx_dec_ctx(), gssx_dec_status(), and gssx_dec_name() functions allocate memory via gssx_dec_buffer(), which calls kmemdup(). When a subsequent decode operation fails, these functions return immediately without freeing previously allocated buffers, causing memory leaks. The leak in gssx_dec_ctx() is particularly relevant because the caller (gssp_accept_sec_context_upcall) initializes several buffer length fields to non-zero values, resulting in memory allocation: struct gssx_ctx rctxh = { .exported_context_token.len = GSSX_max_output_handle_sz, .mech.len = GSS_OID_MAX_LEN, .src_name.display_name.len = GSSX_max_princ_sz, .targ_name.display_name.len = GSSX_max_princ_sz }; If, for example, gssx_dec_name() succeeds for src_name but fails for targ_name, the memory allocated for exported_context_token, mech, and src_name.display_name remains unreferenced and cannot be reclaimed. Add error handling with goto-based cleanup to free any previously allocated buffers before returning an error.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45948", "url": "https://ubuntu.com/security/CVE-2026-45948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leak in ext4_ext_shift_extents() In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4_find_extent(), leading to a memory leak. Fix this by jumping to the out label to ensure the path is properly released.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45912", "url": "https://ubuntu.com/security/CVE-2026-45912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't cache extent during splitting extent Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful. Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, when ext4_split_extent_at() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4_find_extent() and ext4_cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting. In adition, if the unwritten extent cache is not shrunk during the splitting, ext4_cache_extents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46250", "url": "https://ubuntu.com/security/CVE-2026-46250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: MIPS: Work around LLVM bug when gp is used as global register variable On MIPS, __current_thread_info is defined as global register variable locating in $gp, and is simply assigned with new address during kernel relocation. This however is broken with LLVM, which always restores $gp if it finds $gp is clobbered in any form, including when intentionally through a global register variable. This is against GCC's documentation[1], which requires a callee-saved register used as global register variable not to be restored if it's clobbered. As a result, $gp will continue to point to the unrelocated kernel after the epilog of relocate_kernel(), leading to an early crash in init_idle, [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY [ 0.000000] Tainted: [W]=WARN [ 0.000000] Hardware name: loongson,loongson64v-4core-virtio [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240 [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001 [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002 [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80 [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80 [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90 [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90 [ 0.000000] Hi : 0000000000000000 [ 0.000000] Lo : 0000000000000000 [ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270 [ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270 [ 0.000000] Status: 540000e2\tKX SX UX KERNEL EXL [ 0.000000] Cause : 00000008 (ExcCode 02) [ 0.000000] BadVA : 0000000000000000 [ 0.000000] PrId : 00006305 (ICT Loongson-3) [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000) [ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528 [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000 [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258 [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98 [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [] init_idle+0x130/0x270 [ 0.000000] [] sched_init+0x5c8/0x6c0 [ 0.000000] [] start_kernel+0x27c/0x7a8 This bug has been reported to LLVM[2] and affects version from (at least) 18 to 21. Let's work around this by using inline assembly to assign $gp before a fix is widely available.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45974", "url": "https://ubuntu.com/security/CVE-2026-45974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not found If btrfs_search_slot_for_read() returns 1, it means we did not find any key greater than or equals to the key we asked for, meaning we have reached the end of the tree and therefore the path is not valid. If this happens we need to break out of the loop and stop, instead of continuing and accessing an invalid path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45965", "url": "https://ubuntu.com/security/CVE-2026-45965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix invalid deref of rawdata when export_binary is unset If the export_binary parameter is disabled on runtime, profiles that were loaded before that will still have their rawdata stored in apparmorfs, with a symbolic link to the rawdata on the policy directory. When one of those profiles are replaced, the rawdata is set to NULL, but when trying to resolve the symbolic links to rawdata for that profile, it will try to dereference profile->rawdata->name when profile->rawdata is now NULL causing an oops. Fix it by checking if rawdata is set. [ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088 [ 168.657420] #PF: supervisor read access in kernel mode [ 168.660619] #PF: error_code(0x0000) - not-present page [ 168.663613] PGD 0 P4D 0 [ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI [ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary) [ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330 [ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8 [ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282 [ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158 [ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80 [ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000 [ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80 [ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0 [ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000 [ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0 [ 168.701696] Call Trace: [ 168.702325] [ 168.702995] rawdata_get_link_data+0x1c/0x30 [ 168.704145] vfs_readlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64_sys_readlink+0x1e/0x30 [ 168.708653] x64_sys_call+0x1d77/0x26b0 [ 168.709525] do_syscall_64+0x81/0x500 [ 168.710348] ? do_statx+0x72/0xb0 [ 168.711109] ? putname+0x3e/0x80 [ 168.711845] ? __x64_sys_statx+0xb7/0x100 [ 168.712711] ? x64_sys_call+0x10fc/0x26b0 [ 168.713577] ? do_syscall_64+0xbf/0x500 [ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0 [ 168.715404] ? irqentry_exit+0xb2/0x740 [ 168.716359] ? exc_page_fault+0x90/0x1b0 [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45848", "url": "https://ubuntu.com/security/CVE-2026-45848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix NULL sock in aa_sock_file_perm Deal with the potential that sock and sock-sk can be NULL during socket setup or teardown. This could lead to an oops. The fix for NULL pointer dereference in __unix_needs_revalidation shows this is at least possible for af_unix sockets. While the fix for af_unix sockets applies for newer mediation this is still the fall back path for older af_unix mediation and other sockets, so ensure it is covered.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45970", "url": "https://ubuntu.com/security/CVE-2026-45970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: alb: fix UAF in rlb_arp_recv during bond up/down The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN. However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag. [ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? __pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry. Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45847", "url": "https://ubuntu.com/security/CVE-2026-45847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: remove WARN_ON_ONCE when accessing forward path array Although unlikely, recent support for IPIP tunnels increases chances of reaching this WARN_ON_ONCE if userspace manages to build a sufficiently long forward path. Remove it.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45890", "url": "https://ubuntu.com/security/CVE-2026-45890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen-netback: reject zero-queue configuration from guest A malicious or buggy Xen guest can write \"0\" to the xenbus key \"multi-queue-num-queues\". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range(). On systems with panic_on_warn=1, this allows a guest-to-host denial of service. The Xen network interface specification requires the queue count to be \"greater than zero\". Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45968", "url": "https://ubuntu.com/security/CVE-2026-45968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuidle: Skip governor when only one idle state is available On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash. [ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668 Fix this by adding a bail-out in cpuidle_select() that returns state 0 directly when state_count <= 1, bypassing the governor and keeping the tick running.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45935", "url": "https://ubuntu.com/security/CVE-2026-45935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot In the 'DeleteIndexEntryRoot' case of the 'do_action' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking. Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize); It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to size_t for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow. This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45864", "url": "https://ubuntu.com/security/CVE-2026-45864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent infinite loops caused by the next valid being the same When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1]. Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this. [1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45868", "url": "https://ubuntu.com/security/CVE-2026-45868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix refcount leak in pcs_add_gpio_func() of_parse_phandle_with_args() returns a device_node pointer with refcount incremented in gpiospec.np. The loop iterates through all phandles but never releases the reference, causing a refcount leak on each iteration. Add of_node_put() calls to release the reference after extracting the needed arguments and on the error path when devm_kzalloc() fails. This bug was detected by our static analysis tool and verified by my code review.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45883", "url": "https://ubuntu.com/security/CVE-2026-45883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: sca3000: Fix a resource leak in sca3000_probe() spi->irq from request_threaded_irq() not released when iio_device_register() fails. Add an return value check and jump to a common error handler when iio_device_register() fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45875", "url": "https://ubuntu.com/security/CVE-2026-45875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: arizona: Fix regulator resource leak on wm5102_clear_write_sequencer() failure The wm5102_clear_write_sequencer() helper may return an error and just return, bypassing the cleanup sequence and causing regulators to remain enabled, leading to a resource leak. Change the direct return to jump to the err_reset label to properly free the resources.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45978", "url": "https://ubuntu.com/security/CVE-2026-45978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: greybus: lights: avoid NULL deref gb_lights_light_config() stores channel_count before allocating the channels array. If kcalloc() fails, gb_lights_release() iterates the non-zero count and dereferences light->channels, which is NULL. Allocate channels first and only then publish channels_count so the cleanup path can't walk a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45954", "url": "https://ubuntu.com/security/CVE-2026-45954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe() In au1200fb_drv_probe(), when platform_get_irq fails(), it directly returns from the function with an error code, which causes a memory leak. Replace it with a goto label to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45857", "url": "https://ubuntu.com/security/CVE-2026-45857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: csiostor: Fix dereference of null pointer rn The error exit path when rn is NULL ends up deferencing the null pointer rn via the use of the macro CSIO_INC_STATS. Fix this by adding a new error return path label after the use of the macro to avoid the deference.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45856", "url": "https://ubuntu.com/security/CVE-2026-45856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45852", "url": "https://ubuntu.com/security/CVE-2026-45852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45869", "url": "https://ubuntu.com/security/CVE-2026-45869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: wm97xx: Fix NULL pointer dereference in power_supply_changed() In `probe()`, `request_irq()` is called before allocating/registering a `power_supply` handle. If an interrupt is fired between the call to `request_irq()` and `power_supply_register()`, the `power_supply` handle will be used uninitialized in `power_supply_changed()` in `wm97xx_bat_update()` (triggered from the interrupt handler). This will lead to a `NULL` pointer dereference since Fix this racy `NULL` pointer dereference by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Since the IRQ is the last thing requests in the `probe()` now, remove the error path for freeing it. Instead add one for unregistering the `power_supply` handle when IRQ request fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45916", "url": "https://ubuntu.com/security/CVE-2026-45916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sbs-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Keep the old behavior of just printing a warning in case of any failures during the IRQ request and finishing the probe successfully.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46270", "url": "https://ubuntu.com/security/CVE-2026-46270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: rt9455: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45936", "url": "https://ubuntu.com/security/CVE-2026-45936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: goldfish: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45885", "url": "https://ubuntu.com/security/CVE-2026-45885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cpcap-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45879", "url": "https://ubuntu.com/security/CVE-2026-45879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq25980: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45902", "url": "https://ubuntu.com/security/CVE-2026-45902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45867", "url": "https://ubuntu.com/security/CVE-2026-45867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: act8945a: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45946", "url": "https://ubuntu.com/security/CVE-2026-45946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Commit 1c1f13a006ed (\"power: supply: ab8500: Move to componentized binding\") introduced this issue during a refactorization. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45866", "url": "https://ubuntu.com/security/CVE-2026-45866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: caif: fix use-after-free in caif_serial ldisc_close() There is a use-after-free bug in caif_serial where handle_tx() may access ser->tty after the tty has been freed. The race condition occurs between ldisc_close() and packet transmission: CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldisc_close() tty_kref_put(ser->tty) [tty may be freed here] <-- race window --> caif_xmit() handle_tx() tty = ser->tty // dangling ptr tty->ops->write() // UAF! schedule_work() ser_release() unregister_netdevice() The root cause is that tty_kref_put() is called in ldisc_close() while the network device is still active and can receive packets. Since ser and tty have a 1:1 binding relationship with consistent lifecycles (ser is allocated in ldisc_open and freed in ser_release via unregister_netdevice, and each ser binds exactly one tty), we can safely defer the tty reference release to ser_release() where the network device is unregistered. Fix this by moving tty_kref_put() from ldisc_close() to ser_release(), after unregister_netdevice(). This ensures the tty reference is held as long as the network device exists, preventing the UAF. Note: We save ser->tty before unregister_netdevice() because ser is embedded in netdev's private data and will be freed along with netdev (needs_free_netdev = true). How to reproduce: Add mdelay(500) at the beginning of ldisc_close() to widen the race window, then run the reproducer program [1]. Note: There is a separate deadloop issue in handle_tx() when using PORT_UNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper serial backend). This deadloop exists even without this patch, and is likely caused by inconsistency between uart_write_room() and uart_write() in serial core. It has been addressed in a separate patch [2]. KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in handle_tx+0x5d1/0x620 Read of size 1 at addr ffff8881131e1490 by task caif_uaf_trigge/9929 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xd0/0x630 kasan_report+0xe4/0x120 handle_tx+0x5d1/0x620 dev_hard_start_xmit+0x9d/0x6c0 __dev_queue_xmit+0x6e2/0x4410 packet_xmit+0x243/0x360 packet_sendmsg+0x26cf/0x5500 __sys_sendto+0x4a3/0x520 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0xc9/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f615df2c0d7 Allocated by task 9930: Freed by task 64: Last potentially related work creation: The buggy address belongs to the object at ffff8881131e1000 which belongs to the cache kmalloc-cg-2k of size 2048 The buggy address is located 1168 bytes inside of freed 2048-byte region [ffff8881131e1000, ffff8881131e1800) The buggy address belongs to the physical page: page_owner tracks the page as allocated page last free pid 9778 tgid 9778 stack trace: Memory state around the buggy address: ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-31411", "url": "https://ubuntu.com/security/CVE-2026-31411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: fix crash due to unvalidated vcc pointer in sigd_send() Reproducer available at [1]. The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values. Fix this by introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found. Since struct atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock_hold/sock_put is sufficient to keep the vcc alive while it is being used. Note that there may be a race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety. [1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3", "cve_priority": "medium", "cve_public_date": "2026-04-08 14:16:00 UTC" }, { "cve": "CVE-2026-46259", "url": "https://ubuntu.com/security/CVE-2026-46259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent.", "cve_priority": "high", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45891", "url": "https://ubuntu.com/security/CVE-2026-45891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix double free issue for tx spare buffer In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory. Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory. The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer. Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new `tx_spare` fails. This ensures the error cleanup path only frees genuinely newly allocated buffers.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45873", "url": "https://ubuntu.com/security/CVE-2026-45873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets Userspace provides an optimized representation in case intervals are adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous set checks on start elements for this reason. However, it is possible to add intervals that overlap to this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end \tA B start end A C Restore the check on overlapping start elements to report an overlap.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46267", "url": "https://ubuntu.com/security/CVE-2026-46267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: hci: shdlc: Stop timers and work before freeing context llc_shdlc_deinit() purges SHDLC skb queues and frees the llc_shdlc structure while its timers and state machine work may still be active. Timer callbacks can schedule sm_work, and sm_work accesses SHDLC state and the skb queues. If teardown happens in parallel with a queued/running work item, it can lead to UAF and other shutdown races. Stop all SHDLC timers and cancel sm_work synchronously before purging the queues and freeing the context. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-46249", "url": "https://ubuntu.com/security/CVE-2026-46249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix PF driver crash with kexec kernel booting During a kexec reboot the hardware is not power-cycled, so AF state from the old kernel can persist into the new kernel. When AF and PF drivers are built as modules, the PF driver may probe before AF reinitializes the hardware. The PF driver treats the RVUM block revision as an indication that AF initialization is complete. If this value is left uncleared at shutdown, PF may incorrectly assume AF is ready and access stale hardware state, leading to a crash. Clear the RVUM block revision during AF shutdown to avoid PF mis-detecting AF readiness after kexec.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45915", "url": "https://ubuntu.com/security/CVE-2026-45915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: avoid parent link count underflow in rmdir Corrupted FAT images can leave a directory inode with an incorrect i_nlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls drop_nlink(dir) and can drive i_nlink to 0, triggering the WARN_ON in drop_nlink(). Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45983", "url": "https://ubuntu.com/security/CVE-2026-45983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: never defer requests during idmap lookup During v4 request compound arg decoding, some ops (e.g. SETATTR) can trigger idmap lookup upcalls. When those upcall responses get delayed beyond the allowed time limit, cache_check() will mark the request for deferral and cause it to be dropped. This prevents nfs4svc_encode_compoundres from being executed, and thus the session slot flag NFSD4_SLOT_INUSE never gets cleared. Subsequent client requests will fail with NFSERR_JUKEBOX, given that the slot will be marked as in-use, making the SEQUENCE op fail. Fix this by making sure that the RQ_USEDEFERRAL flag is always clear during nfs4svc_decode_compoundargs(), since no v4 request should ever be deferred.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45862", "url": "https://ubuntu.com/security/CVE-2026-45862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush cache for PASID table before using it When writing the address of a freshly allocated zero-initialized PASID table to a PASID directory entry, do that after the CPU cache flush for this PASID table, not before it, to avoid the time window when this PASID table may be already used by non-coherent IOMMU hardware while its contents in RAM is still some random old data, not zero-initialized.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45860", "url": "https://ubuntu.com/security/CVE-2026-45860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: increase the connection clean up limit to 64 After the optimization to only perform one GC per jiffy, a new problem was introduced. If more than 8 new connections are tracked per jiffy the list won't be cleaned up fast enough possibly reaching the limit wrongly. In order to prevent this issue, only skip the GC if it was already triggered during the same jiffy and the increment is lower than the clean up limit. In addition, increase the clean up limit to 64 connections to avoid triggering GC too often and do more effective GCs. This has been tested using a HTTP server and several performance tools while having nft_connlimit/xt_connlimit or OVS limit configured. Output of slowhttptest + OVS limit at 52000 connections: slow HTTP test status on 340th second: initializing: 0 pending: 432 connected: 51998 error: 0 closed: 0 service available: YES", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45969", "url": "https://ubuntu.com/security/CVE-2026-45969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: playstation: Add missing check for input_ff_create_memless The ps_gamepad_create() function calls input_ff_create_memless() without verifying its return value, which can lead to incorrect behavior or potential crashes when FF effects are triggered. Add a check for the return value of input_ff_create_memless().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-71304", "url": "https://ubuntu.com/security/CVE-2025-71304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: /smack/doi: accept previously used values Writing to /smack/doi a value that has ever been written there in the past disables networking for non-ambient labels. E.g. # cat /smack/doi 3 # netlabelctl -p cipso list Configured CIPSO mappings (1) DOI value : 3 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (3) domain: \"_\" (IPv4) protocol: UNLABELED domain: DEFAULT (IPv4) protocol: CIPSO, DOI = 3 domain: DEFAULT (IPv6) protocol: UNLABELED # cat /smack/ambient _ # cat /proc/$$/attr/smack/current _ # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.964 ms # echo foo >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.956 ms unknown option 86 # echo 4 >/smack/doi # echo 3 >/smack/doi !> [ 214.050395] smk_cipso_doi:691 cipso add rc = -17 # echo 3 >/smack/doi !> [ 249.402261] smk_cipso_doi:678 remove rc = -2 !> [ 249.402261] smk_cipso_doi:691 cipso add rc = -17 # ping -c1 10.1.95.12 !!> ping: 10.1.95.12: Address family for hostname not supported # echo _ >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.617 ms This happens because Smack keeps decommissioned DOIs, fails to re-add them, and consequently refuses to add the “default” domain map: # netlabelctl -p cipso list Configured CIPSO mappings (2) DOI value : 3 mapping type : PASS_THROUGH DOI value : 4 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (2) domain: \"_\" (IPv4) protocol: UNLABELED !> (no ipv4 map for default domain here) domain: DEFAULT (IPv6) protocol: UNLABELED Fix by clearing decommissioned DOI definitions and serializing concurrent DOI updates with a new lock. Also: - allow /smack/doi to live unconfigured, since adding a map (netlbl_cfg_cipsov4_map_add) may fail. CIPSO_V4_DOI_UNKNOWN(0) indicates the unconfigured DOI - add new DOI before removing the old default map, so the old map remains if the add fails (2008-02-04, Casey Schaufler)", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45904", "url": "https://ubuntu.com/security/CVE-2026-45904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling The recent commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug safe\") restructured the EEH driver to improve synchronization with the PCI hotplug layer. However, it inadvertently moved pci_lock_rescan_remove() outside its intended scope in eeh_handle_normal_event(), leading to broken PCI error reporting and improper EEH event triggering. Specifically, eeh_handle_normal_event() acquired pci_lock_rescan_remove() before calling eeh_pe_bus_get(), but eeh_pe_bus_get() itself attempts to acquire the same lock internally, causing nested locking and disrupting normal EEH event handling paths. This patch adds a boolean parameter do_lock to _eeh_pe_bus_get(), with two public wrappers: eeh_pe_bus_get() with locking enabled. eeh_pe_bus_get_nolock() that skips locking. Callers that already hold pci_lock_rescan_remove() now use eeh_pe_bus_get_nolock() to avoid recursive lock acquisition. Additionally, pci_lock_rescan_remove() calls are restored to the correct position—after eeh_pe_bus_get() and immediately before iterating affected PEs and devices. This ensures EEH-triggered PCI removes occur under proper bus rescan locking without recursive lock contention. The eeh_pe_loc_get() function has been split into two functions: eeh_pe_loc_get(struct eeh_pe *pe) which retrieves the loc for given PE. eeh_pe_loc_get_bus(struct pci_bus *bus) which retrieves the location code for given bus. This resolves lockdep warnings such as: [ 84.964298] [ T928] ============================================ [ 84.964304] [ T928] WARNING: possible recursive locking detected [ 84.964311] [ T928] 6.18.0-rc3 #51 Not tainted [ 84.964315] [ T928] -------------------------------------------- [ 84.964320] [ T928] eehd/928 is trying to acquire lock: [ 84.964324] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964342] [ T928] but task is already holding lock: [ 84.964347] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964357] [ T928] other info that might help us debug this: [ 84.964363] [ T928] Possible unsafe locking scenario: [ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928] lock(pci_rescan_remove_lock); [ 84.964378] [ T928] lock(pci_rescan_remove_lock); [ 84.964383] [ T928] *** DEADLOCK *** [ 84.964388] [ T928] May be due to missing lock nesting notation [ 84.964393] [ T928] 1 lock held by eehd/928: [ 84.964397] [ T928] #0: c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964408] [ T928] stack backtrace: [ 84.964414] [ T928] CPU: 2 UID: 0 PID: 928 Comm: eehd Not tainted 6.18.0-rc3 #51 VOLUNTARY [ 84.964417] [ T928] Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_022) hv:phyp pSeries [ 84.964419] [ T928] Call Trace: [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130 (unreliable) [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [ 84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c00000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46253", "url": "https://ubuntu.com/security/CVE-2026-46253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore/ram: fix buffer overflow in persistent_ram_save_old() persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz->old_log when it is NULL, but it unconditionally updates prz->old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1) 9. ramoops_get_next_prz() → persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45919", "url": "https://ubuntu.com/security/CVE-2026-45919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/rt: Skip currently executing CPU in rto_next_cpu() CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts. The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45871", "url": "https://ubuntu.com/security/CVE-2026-45871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Fix missing cleanup on get_burstcount() error get_burstcount() can return -EBUSY on timeout. When this happens, st33zp24_send() returns directly without releasing the locality acquired earlier. Use goto out_err to ensure proper cleanup when get_burstcount() fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45941", "url": "https://ubuntu.com/security/CVE-2026-45941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_infineon: Fix locality leak on get_burstcount() failure get_burstcount() can return -EBUSY on timeout. When this happens, the function returns directly without releasing the locality that was acquired at the beginning of tpm_tis_i2c_send(). Use goto out_err to ensure proper cleanup when get_burstcount() fails.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45984", "url": "https://ubuntu.com/security/CVE-2026-45984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix use-after-free in iomap inline data write path The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45960", "url": "https://ubuntu.com/security/CVE-2026-45960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: return error when node already exists in hfs_bnode_create When hfs_bnode_create() finds that a node is already hashed (which should not happen in normal operation), it currently returns the existing node without incrementing its reference count. This causes a reference count inconsistency that leads to a kernel panic when the node is later freed in hfs_bnode_put(): kernel BUG at fs/hfsplus/bnode.c:676! BUG_ON(!atomic_read(&node->refcnt)) This scenario can occur when hfs_bmap_alloc() attempts to allocate a node that is already in use (e.g., when node 0's bitmap bit is incorrectly unset), or due to filesystem corruption. Returning an existing node from a create path is not normal operation. Fix this by returning ERR_PTR(-EEXIST) instead of the node when it's already hashed. This properly signals the error condition to callers, which already check for IS_ERR() return values.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23243", "url": "https://ubuntu.com/security/CVE-2026-23243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umad: Reject negative data_len in ib_umad_write ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-23242", "url": "https://ubuntu.com/security/CVE-2026-23242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix potential NULL pointer dereference in header processing If siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(), qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data() dereferences qp->rx_fpdu->more_ddp_segs without checking, which may lead to a NULL pointer deref. Only check more_ddp_segs when rx_fpdu is present. KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-23235", "url": "https://ubuntu.com/security/CVE-2026-23235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix out-of-bounds access in sysfs attribute read/write Some f2fs sysfs attributes suffer from out-of-bounds memory access and incorrect handling of integer values whose size is not 4 bytes. For example: vm:~# echo 65537 > /sys/fs/f2fs/vde/carve_out vm:~# cat /sys/fs/f2fs/vde/carve_out 65537 vm:~# echo 4294967297 > /sys/fs/f2fs/vde/atgc_age_threshold vm:~# cat /sys/fs/f2fs/vde/atgc_age_threshold 1 carve_out maps to {struct f2fs_sb_info}->carve_out, which is a 8-bit integer. However, the sysfs interface allows setting it to a value larger than 255, resulting in an out-of-range update. atgc_age_threshold maps to {struct atgc_management}->age_threshold, which is a 64-bit integer, but its sysfs interface cannot correctly set values larger than UINT_MAX. The root causes are: 1. __sbi_store() treats all default values as unsigned int, which prevents updating integers larger than 4 bytes and causes out-of-bounds writes for integers smaller than 4 bytes. 2. f2fs_sbi_show() also assumes all default values are unsigned int, leading to out-of-bounds reads and incorrect access to integers larger than 4 bytes. This patch introduces {struct f2fs_attr}->size to record the actual size of the integer associated with each sysfs attribute. With this information, sysfs read and write operations can correctly access and update values according to their real data size, avoiding memory corruption and truncation.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23234", "url": "https://ubuntu.com/security/CVE-2026-23234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid UAF in f2fs_write_end_io() As syzbot reported an use-after-free issue in f2fs_write_end_io(). It is caused by below race condition: loop device\t\t\t\tumount - worker_thread - loop_process_work - do_req_filebacked - lo_rw_aio - lo_rw_aio_complete - blk_mq_end_request - blk_update_request - f2fs_write_end_io - dec_page_count - folio_end_writeback \t\t\t\t\t- kill_f2fs_super \t\t\t\t\t - kill_block_super \t\t\t\t\t - f2fs_put_super \t\t\t\t\t : free(sbi) : get_pages(, F2FS_WB_CP_DATA) accessed sbi which is freed In kill_f2fs_super(), we will drop all page caches of f2fs inodes before call free(sbi), it guarantee that all folios should end its writeback, so it should be safe to access sbi before last folio_end_writeback(). Let's relocate ckpt thread wakeup flow before folio_end_writeback() to resolve this issue.", "cve_priority": "low", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23236", "url": "https://ubuntu.com/security/CVE-2026-23236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: smscufx: properly copy ioctl memory to kernelspace The UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data from userspace to kernelspace, and instead directly references the memory, which can cause problems if invalid data is passed from userspace. Fix this all up by correctly copying the memory before accessing it within the kernel.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23266", "url": "https://ubuntu.com/security/CVE-2026-23266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: rivafb: fix divide error in nv3_arb() A userspace program can trigger the RIVA NV3 arbitration code by calling the FBIOPUT_VSCREENINFO ioctl on /dev/fb*. When doing so, the driver recomputes FIFO arbitration parameters in nv3_arb(), using state->mclk_khz (derived from the PRAMDAC MCLK PLL) as a divisor without validating it first. In a normal setup, state->mclk_khz is provided by the real hardware and is non-zero. However, an attacker can construct a malicious or misconfigured device (e.g. a crafted/emulated PCI device) that exposes a bogus PLL configuration, causing state->mclk_khz to become zero. Once nv3_get_param() calls nv3_arb(), the division by state->mclk_khz in the gns calculation causes a divide error and crashes the kernel. Fix this by checking whether state->mclk_khz is zero and bailing out before doing the division. The following log reveals it: rivafb: setting virtual Y resolution to 2184 divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 2187 Comm: syz-executor.0 Not tainted 5.18.0-rc1+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:nv3_arb drivers/video/fbdev/riva/riva_hw.c:439 [inline] RIP: 0010:nv3_get_param+0x3ab/0x13b0 drivers/video/fbdev/riva/riva_hw.c:546 Call Trace: nv3CalcArbitration.constprop.0+0x255/0x460 drivers/video/fbdev/riva/riva_hw.c:603 nv3UpdateArbitrationSettings drivers/video/fbdev/riva/riva_hw.c:637 [inline] CalcStateExt+0x447/0x1b90 drivers/video/fbdev/riva/riva_hw.c:1246 riva_load_video_mode+0x8a9/0xea0 drivers/video/fbdev/riva/fbdev.c:779 rivafb_set_par+0xc0/0x5f0 drivers/video/fbdev/riva/fbdev.c:1196 fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1033 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1109 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1188 __x64_sys_ioctl+0x122/0x190 fs/ioctl.c:856", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2025-71233", "url": "https://ubuntu.com/security/CVE-2025-71233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Avoid creating sub-groups asynchronously The asynchronous creation of sub-groups by a delayed work could lead to a NULL pointer dereference when the driver directory is removed before the work completes. The crash can be easily reproduced with the following commands: # cd /sys/kernel/config/pci_ep/functions/pci_epf_test # for i in {1..20}; do mkdir test && rmdir test; done BUG: kernel NULL pointer dereference, address: 0000000000000088 ... Call Trace: configfs_register_group+0x3d/0x190 pci_epf_cfs_work+0x41/0x110 process_one_work+0x18f/0x350 worker_thread+0x25a/0x3a0 Fix this issue by using configfs_add_default_group() API which does not have the deadlock problem as configfs_register_group() and does not require the delayed work handler. [mani: slightly reworded the description and added stable list]", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71232", "url": "https://ubuntu.com/security/CVE-2025-71232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Free sp in error path to fix system crash System crash seen during load/unload test in a loop, [61110.449331] qla2xxx [0000:27:00.0]-0042:0: Disabled MSI-X. [61110.467494] ============================================================================= [61110.467498] BUG qla2xxx_srbs (Tainted: G OE -------- --- ): Objects remaining in qla2xxx_srbs on __kmem_cache_shutdown() [61110.467501] ----------------------------------------------------------------------------- [61110.467502] Slab 0x000000000ffc8162 objects=51 used=1 fp=0x00000000e25d3d85 flags=0x57ffffc0010200(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [61110.467509] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1 [61110.467513] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023 [61110.467515] Call Trace: [61110.467516] [61110.467519] dump_stack_lvl+0x34/0x48 [61110.467526] slab_err.cold+0x53/0x67 [61110.467534] __kmem_cache_shutdown+0x16e/0x320 [61110.467540] kmem_cache_destroy+0x51/0x160 [61110.467544] qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467607] ? __do_sys_delete_module.constprop.0+0x178/0x280 [61110.467613] ? syscall_trace_enter.constprop.0+0x145/0x1d0 [61110.467616] ? do_syscall_64+0x5c/0x90 [61110.467619] ? exc_page_fault+0x62/0x150 [61110.467622] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [61110.467626] [61110.467627] Disabling lock debugging due to kernel taint [61110.467635] Object 0x0000000026f7e6e6 @offset=16000 [61110.467639] ------------[ cut here ]------------ [61110.467639] kmem_cache_destroy qla2xxx_srbs: Slab cache still has objects when called from qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467659] WARNING: CPU: 53 PID: 455206 at mm/slab_common.c:520 kmem_cache_destroy+0x14d/0x160 [61110.467718] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G B OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1 [61110.467720] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023 [61110.467721] RIP: 0010:kmem_cache_destroy+0x14d/0x160 [61110.467724] Code: 99 7d 07 00 48 89 ef e8 e1 6a 07 00 eb b3 48 8b 55 60 48 8b 4c 24 20 48 c7 c6 70 fc 66 90 48 c7 c7 f8 ef a1 90 e8 e1 ed 7c 00 <0f> 0b eb 93 c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 [61110.467725] RSP: 0018:ffffa304e489fe80 EFLAGS: 00010282 [61110.467727] RAX: 0000000000000000 RBX: ffffffffc0d9a860 RCX: 0000000000000027 [61110.467729] RDX: ffff8fd5ff9598a8 RSI: 0000000000000001 RDI: ffff8fd5ff9598a0 [61110.467730] RBP: ffff8fb6aaf78700 R08: 0000000000000000 R09: 0000000100d863b7 [61110.467731] R10: ffffa304e489fd20 R11: ffffffff913bef48 R12: 0000000040002000 [61110.467731] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [61110.467733] FS: 00007f64c89fb740(0000) GS:ffff8fd5ff940000(0000) knlGS:0000000000000000 [61110.467734] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [61110.467735] CR2: 00007f0f02bfe000 CR3: 00000020ad6dc005 CR4: 0000000000770ee0 [61110.467736] PKRU: 55555554 [61110.467737] Call Trace: [61110.467738] [61110.467739] qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467755] ? __do_sys_delete_module.constprop.0+0x178/0x280 Free sp in the error path to fix the crash.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71238", "url": "https://ubuntu.com/security/CVE-2025-71238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix bsg_done() causing double free Kernel panic observed on system, [5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000 [5353358.825194] #PF: supervisor write access in kernel mode [5353358.825195] #PF: error_code(0x0002) - not-present page [5353358.825196] PGD 100006067 P4D 0 [5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI [5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el9_5.x86_64 #1 [5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025 [5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10 [5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246 [5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000 [5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000 [5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000 [5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090 [5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000 [5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000 [5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0 [5353358.825221] PKRU: 55555554 [5353358.825222] Call Trace: [5353358.825223] [5353358.825224] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825229] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825232] ? sg_copy_buffer+0xc8/0x110 [5353358.825236] ? __die_body.cold+0x8/0xd [5353358.825238] ? page_fault_oops+0x134/0x170 [5353358.825242] ? kernelmode_fixup_or_oops+0x84/0x110 [5353358.825244] ? exc_page_fault+0xa8/0x150 [5353358.825247] ? asm_exc_page_fault+0x22/0x30 [5353358.825252] ? memcpy_erms+0x6/0x10 [5353358.825253] sg_copy_buffer+0xc8/0x110 [5353358.825259] qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx] [5353358.825317] qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx] Most routines in qla_bsg.c call bsg_done() only for success cases. However a few invoke it for failure case as well leading to a double free. Validate before calling bsg_done().", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23221", "url": "https://ubuntu.com/security/CVE-2026-23221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: fix use-after-free in driver_override_show() The driver_override_show() function reads the driver_override string without holding the device_lock. However, driver_override_store() uses driver_set_override(), which modifies and frees the string while holding the device_lock. This can result in a concurrent use-after-free if the string is freed by the store function while being read by the show function. Fix this by holding the device_lock around the read operation.", "cve_priority": "low", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23228", "url": "https://ubuntu.com/security/CVE-2026-23228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection() On kthread_run() failure in ksmbd_tcp_new_connection(), the transport is freed via free_transport(), which does not decrement active_num_conn, leaking this counter. Replace free_transport() with ksmbd_tcp_disconnect().", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23169", "url": "https://ubuntu.com/security/CVE-2026-23169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race in mptcp_pm_nl_flush_addrs_doit() syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id() and/or mptcp_pm_nl_is_backup() Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit() which is not RCU ready. list_splice_init_rcu() can not be called here while holding pernet->lock spinlock. Many thanks to Eulgyu Kim for providing a repro and testing our patches.", "cve_priority": "high", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-37786", "url": "https://ubuntu.com/security/CVE-2025-37786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: free routing table on probe failure If complete = true in dsa_tree_setup(), it means that we are the last switch of the tree which is successfully probing, and we should be setting up all switches from our probe path. After \"complete\" becomes true, dsa_tree_setup_cpu_ports() or any subsequent function may fail. If that happens, the entire tree setup is in limbo: the first N-1 switches have successfully finished probing (doing nothing but having allocated persistent memory in the tree's dst->ports, and maybe dst->rtable), and switch N failed to probe, ending the tree setup process before anything is tangible from the user's PoV. If switch N fails to probe, its memory (ports) will be freed and removed from dst->ports. However, the dst->rtable elements pointing to its ports, as created by dsa_link_touch(), will remain there, and will lead to use-after-free if dereferenced. If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirely possible because that is where ds->ops->setup() is, we get a kasan report like this: ================================================================== BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568 Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42 Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 The simplest way to fix the bug is to delete the routing table in its entirety. dsa_tree_setup_routing_table() has no problem in regenerating it even if we deleted links between ports other than those of switch N, because dsa_link_touch() first checks whether the port pair already exists in dst->rtable, allocating if not. The deletion of the routing table in its entirety already exists in dsa_tree_teardown(), so refactor that into a function that can also be called from the tree setup error path. In my analysis of the commit to blame, it is the one which added dsa_link elements to dst->rtable. Prior to that, each switch had its own ds->rtable which is freed when the switch fails to probe. But the tree is potentially persistent memory.", "cve_priority": "low", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2026-23237", "url": "https://ubuntu.com/security/CVE-2026-23237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: classmate-laptop: Add missing NULL pointer checks In a few places in the Classmate laptop driver, code using the accel object may run before that object's address is stored in the driver data of the input device using it. For example, cmpc_accel_sensitivity_store_v4() is the \"show\" method of cmpc_accel_sensitivity_attr_v4 which is added in cmpc_accel_add_v4(), before calling dev_set_drvdata() for inputdev->dev. If the sysfs attribute is accessed prematurely, the dev_get_drvdata(&inputdev->dev) call in in cmpc_accel_sensitivity_store_v4() returns NULL which leads to a NULL pointer dereference going forward. Moreover, sysfs attributes using the input device are added before initializing that device by cmpc_add_acpi_notify_device() and if one of them is accessed before running that function, a NULL pointer dereference will occur. For example, cmpc_accel_sensitivity_attr_v4 is added before calling cmpc_add_acpi_notify_device() and if it is read prematurely, the dev_get_drvdata(&acpi->dev) call in cmpc_accel_sensitivity_show_v4() returns NULL which leads to a NULL pointer dereference going forward. Fix this by adding NULL pointer checks in all of the relevant places.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23238", "url": "https://ubuntu.com/security/CVE-2026-23238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: romfs: check sb_set_blocksize() return value romfs_fill_super() ignores the return value of sb_set_blocksize(), which can fail if the requested block size is incompatible with the block device's configuration. This can be triggered by setting a loop device's block size larger than PAGE_SIZE using ioctl(LOOP_SET_BLOCK_SIZE, 32768), then mounting a romfs filesystem on that device. When sb_set_blocksize(sb, ROMBSIZE) is called with ROMBSIZE=4096 but the device has logical_block_size=32768, bdev_validate_blocksize() fails because the requested size is smaller than the device's logical block size. sb_set_blocksize() returns 0 (failure), but romfs ignores this and continues mounting. The superblock's block size remains at the device's logical block size (32768). Later, when sb_bread() attempts I/O with this oversized block size, it triggers a kernel BUG in folio_set_bh(): kernel BUG at fs/buffer.c:1582! BUG_ON(size > PAGE_SIZE); Fix by checking the return value of sb_set_blocksize() and failing the mount with -EINVAL if it returns 0.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-31687", "url": "https://ubuntu.com/security/CVE-2026-31687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: omap: do not register driver in probe() Commit 11a78b794496 (\"ARM: OMAP: MPUIO wake updates\") registers the omap_mpuio_driver from omap_mpuio_init(), which is called from omap_gpio_probe(). However, it neither makes sense to register drivers from probe() callbacks of other drivers, nor does the driver core allow registering drivers with a device lock already being held. The latter was revealed by commit dc23806a7c47 (\"driver core: enforce device_lock for driver_match_device()\") leading to a potential deadlock condition described in [1]. Additionally, the omap_mpuio_driver is never unregistered from the driver core, even if the module is unloaded. Hence, register the omap_mpuio_driver from the module initcall and unregister it in module_exit().", "cve_priority": "medium", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2025-71235", "url": "https://ubuntu.com/security/CVE-2025-71235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Delay module unload while fabric scan in progress System crash seen during load/unload test in a loop. [105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086 [105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0 [105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000 [105954.384923] FS: 0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000 [105954.384925] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0 [105954.384928] PKRU: 55555554 [105954.384929] Call Trace: [105954.384931] [105954.384934] qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx] [105954.384962] ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx] [105954.384980] ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx] [105954.384999] ? __wake_up_common+0x80/0x190 [105954.385004] ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx] [105954.385023] ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx] [105954.385040] ? __handle_irq_event_percpu+0x3d/0x190 [105954.385044] ? handle_irq_event+0x58/0xb0 [105954.385046] ? handle_edge_irq+0x93/0x240 [105954.385050] ? __common_interrupt+0x41/0xa0 [105954.385055] ? common_interrupt+0x3e/0xa0 [105954.385060] ? asm_common_interrupt+0x22/0x40 The root cause of this was that there was a free (dma_free_attrs) in the interrupt context. There was a device discovery/fabric scan in progress. A module unload was issued which set the UNLOADING flag. As part of the discovery, after receiving an interrupt a work queue was scheduled (which involved a work to be queued). Since the UNLOADING flag is set, the work item was not allocated and the mapped memory had to be freed. The free occurred in interrupt context leading to system crash. Delay the driver unload until the fabric scan is complete to avoid the crash.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71236", "url": "https://ubuntu.com/security/CVE-2025-71236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Validate sp before freeing associated memory System crash with the following signature [154563.214890] nvme nvme2: NVME-FC{1}: controller connect complete [154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Set ZIO exchange threshold to 3. [154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: SET ZIO Activity exchange threshold to 5. [154565.539974] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 0080 0000. [154565.545744] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 00a0 0000. [154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate). [154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate). [154565.553079] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [154565.553080] #PF: supervisor read access in kernel mode [154565.553082] #PF: error_code(0x0000) - not-present page [154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0 [154565.553089] Oops: 0000 1 PREEMPT SMP PTI [154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: loaded Tainted: G OE ------- --- 5.14.0-503.11.1.el9_5.x86_64 #1 [154565.553096] Hardware name: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 09/30/2024 [154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553141] Code: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 <4c> 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b [154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286 [154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002 [154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47 [154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a [154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0 [154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000 [154565.553152] FS: 0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000 [154565.553154] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0 [154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [154565.553159] PKRU: 55555554 [154565.553160] Call Trace: [154565.553162] [154565.553165] ? show_trace_log_lvl+0x1c4/0x2df [154565.553172] ? show_trace_log_lvl+0x1c4/0x2df [154565.553177] ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553215] ? __die_body.cold+0x8/0xd [154565.553218] ? page_fault_oops+0x134/0x170 [154565.553223] ? snprintf+0x49/0x70 [154565.553229] ? exc_page_fault+0x62/0x150 [154565.553238] ? asm_exc_page_fault+0x22/0x30 Check for sp being non NULL before freeing any associated memory", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71237", "url": "https://ubuntu.com/security/CVE-2025-71237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: Fix potential block overflow that cause system hang When a user executes the FITRIM command, an underflow can occur when calculating nblocks if end_block is too small. Since nblocks is of type sector_t, which is u64, a negative nblocks value will become a very large positive integer. This ultimately leads to the block layer function __blkdev_issue_discard() taking an excessively long time to process the bio chain, and the ns_segctor_sem lock remains held for a long period. This prevents other tasks from acquiring the ns_segctor_sem lock, resulting in the hang reported by syzbot in [1]. If the ending block is too small, typically if it is smaller than 4KiB range, depending on the usage of the segment 0, it may be possible to attempt a discard request beyond the device size causing the hang. Exiting successfully and assign the discarded size (0 in this case) to range->len. Although the start and len values in the user input range are too small, a conservative strategy is adopted here to safely ignore them, which is equivalent to a no-op; it will not perform any trimming and will not throw an error. [1] task:segctord state:D stack:28968 pid:6093 tgid:6093 ppid:2 task_flags:0x200040 flags:0x00080000 Call Trace: rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272 nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline] nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684 [ryusuke: corrected part of the commit message about the consequences]", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23229", "url": "https://ubuntu.com/security/CVE-2026-23229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add spinlock protection with virtqueue notification When VM boots with one virtio-crypto PCI device and builtin backend, run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head! It seems that the data virtqueue need protection when it is handled for virtio done notification. If the spinlock protection is added in virtcrypto_done_task(), openssl benchmark with multiple processes works well.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23222", "url": "https://ubuntu.com/security/CVE-2026-23222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly The existing allocation of scatterlists in omap_crypto_copy_sg_lists() was allocating an array of scatterlist pointers, not scatterlist objects, resulting in a 4x too small allocation. Use sizeof(*new_sg) to get the correct object size.", "cve_priority": "high", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23392", "url": "https://ubuntu.com/security/CVE-2026-23392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-45988", "url": "https://ubuntu.com/security/CVE-2026-45988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix re-decryption of RESPONSE packets If a RESPONSE packet gets a temporary failure during processing, it may end up in a partially decrypted state - and then get requeued for a retry. Fix this by just discarding the packet; we will send another CHALLENGE packet and thereby elicit a further response. Similarly, discard an incoming CHALLENGE packet if we get an error whilst generating a RESPONSE; the server will send another CHALLENGE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46195", "url": "https://ubuntu.com/security/CVE-2026-46195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46135", "url": "https://ubuntu.com/security/CVE-2026-46135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.", "cve_priority": "critical", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31402", "url": "https://ubuntu.com/security/CVE-2026-31402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.", "cve_priority": "critical", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43071", "url": "https://ubuntu.com/security/CVE-2026-43071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dcache: Limit the minimal number of bucket to two There is an OOB read problem on dentry_hashtable when user sets 'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260 There will be only one bucket in dentry_hashtable when dhash_entries is set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then, following process will access more than one buckets(which memory region is not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB! Fix it by limiting the minimal number of dentry_hashtable bucket to two, so that 'd_hash_shift' won't exceeds the bit width of type u32.", "cve_priority": "low", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-46119", "url": "https://ubuntu.com/security/CVE-2026-46119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix slab-out-of-bounds access in auth message processing If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY contains a positive value in its result field, it is treated as an error code by ceph_handle_auth_reply() and returned to handle_auth_reply(). Thereafter, an attempt is made to send the preallocated message of type CEPH_MSG_AUTH, where the returned value is interpreted as the size of the front segment to send. If the result value in the message is greater than the size of the memory buffer allocated for the front segment, an out-of-bounds access occurs, and the content of the memory region beyond this buffer is sent out. This patch fixes the issue by treating only negative values in the result field as errors. Positive values are therefore treated as success in the same way as a zero value. Additionally, a BUG_ON is added to __send_prepared_auth_request() comparing the len parameter to front_alloc_len to prevent sending the message if it exceeds the bounds of the allocation and to make it easier to catch any logic flaws leading to this.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-43501", "url": "https://ubuntu.com/security/CVE-2026-43501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: \tskb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards.", "cve_priority": "critical", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46043", "url": "https://ubuntu.com/security/CVE-2026-46043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43493", "url": "https://ubuntu.com/security/CVE-2026-43493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications.", "cve_priority": "high", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-31637", "url": "https://ubuntu.com/security/CVE-2026-31637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: reject undecryptable rxkad response tickets rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether crypto_skcipher_decrypt() succeeded. A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes. Check the decrypt result and abort the connection with RXKADBADTICKET when ticket decryption fails.", "cve_priority": "critical", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31657", "url": "https://ubuntu.com/security/CVE-2026-31657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: hold claim backbone gateways by reference batadv_bla_add_claim() can replace claim->backbone_gw and drop the old gateway's last reference while readers still follow the pointer. The netlink claim dump path dereferences claim->backbone_gw->orig and takes claim->backbone_gw->crc_lock without pinning the underlying backbone gateway. batadv_bla_check_claim() still has the same naked pointer access pattern. Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate on a stable gateway reference until the read-side work is complete. This keeps the dump and claim-check paths aligned with the lifetime rules introduced for the other BLA claim readers.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31685", "url": "https://ubuntu.com/security/CVE-2026-31685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_eui64: reject invalid MAC header for all packets `eui64_mt6()` derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address. The existing guard only rejects an invalid MAC header when `par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()` can still reach `eth_hdr(skb)` even when the MAC header is not valid. Fix this by removing the `par->fragoff != 0` condition so that packets with an invalid MAC header are rejected before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43117", "url": "https://ubuntu.com/security/CVE-2026-43117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() If overlay is used on top of btrfs, dentry->d_sb translates to overlay's super block and fsid assignment will lead to a crash. Use file_inode(file)->i_sb to always get btrfs_sb.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43114", "url": "https://ubuntu.com/security/CVE-2026-43114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry New test case fails unexpectedly when avx2 matching functions are used. The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo. This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f - This is expected to work, because its the same set after all and it was already loaded once. But with avx2, this fails: nft reports a clashing element. The reported clash is of following form: We successfully re-inserted a . b c . d Then we try to insert a . d avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next. Due to incorrect masking, the skip-step finds the next matching element *only considering the first field*, i.e. we return the already reinserted \"a . b\", even though the last field is different and the entry should not have been matched. No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback. Bisection points to 7711f4bb4b36 (\"netfilter: nft_set_pipapo: fix range overlap detection\") but that fix merely uncovers this bug. Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate. The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31478", "url": "https://ubuntu.com/security/CVE-2026-31478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len() After this commit (e2b76ab8b5c9 \"ksmbd: add support for read compound\"), response buffer management was changed to use dynamic iov array. In the new design, smb2_calc_max_out_buf_len() expects the second argument (hdr2_len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31668", "url": "https://ubuntu.com/security/CVE-2026-31668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: separate dst_cache for input and output paths in seg6 lwtunnel The seg6 lwtunnel uses a single dst_cache per encap route, shared between seg6_input_core() and seg6_output_core(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup. Fix this by splitting the cache into cache_input and cache_output, so each path maintains its own cached dst independently.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31659", "url": "https://ubuntu.com/security/CVE-2026-31659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject oversized global TT response buffers batadv_tt_prepare_tvlv_global_data() builds the allocation length for a global TT response in 16-bit temporaries. When a remote originator advertises a large enough global TT, the TT payload length plus the VLAN header offset can exceed 65535 and wrap before kmalloc(). The full-table response path still uses the original TT payload length when it fills tt_change, so the wrapped allocation is too small and batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object before the later packet-size check runs. Fix this by rejecting TT responses whose TVLV value length cannot fit in the 16-bit TVLV payload length field.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31649", "url": "https://ubuntu.com/security/CVE-2026-31649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix integer underflow in chain mode The jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb->len (total length including page fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc); When a packet has a small linear portion (nopaged_len <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax * i pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware. Fix this by introducing a buf_len local variable clamped to min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmac_xmit() handles page fragments afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31669", "url": "https://ubuntu.com/security/CVE-2026-31669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix slab-use-after-free in __inet_lookup_established The ehash table lookups are lockless and rely on SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability during RCU read-side critical sections. Both tcp_prot and tcpv6_prot have their slab caches created with this flag via proto_register(). However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into tcpv6_prot_override during inet_init() (fs_initcall, level 5), before inet6_init() (module_init/device_initcall, level 6) has called proto_register(&tcpv6_prot). At that point, tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab remains NULL permanently. This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so when these sockets are freed without SOCK_RCU_FREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcu_read_lock can then access freed memory, triggering a slab-use-after-free in __inet_lookup_established. Fix this by splitting the IPv6-specific initialization out of mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called from mptcp_proto_v6_init() before protocol registration. This ensures tcpv6_prot_override.slab correctly inherits the SLAB_TYPESAFE_BY_RCU slab cache.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43011", "url": "https://ubuntu.com/security/CVE-2026-43011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix potential double free of skb When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain: x25_queue_rx_frame returns 1 | v x25_state3_machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25_process_rx_frame returns queued=0 | v x25_backlog_rcv at line 452 sees queued=0 and calls kfree_skb(skb) again This would free the same skb twice. Looking at x25_backlog_rcv: net/x25/x25_in.c:x25_backlog_rcv() { ... queued = x25_process_rx_frame(sk, skb); ... if (!queued) kfree_skb(skb); }", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43037", "url": "https://ubuntu.com/security/CVE-2026-43037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip4ip6_err() Oskar Kjos reported the following problem. ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr value. __ip_options_echo() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->__data, a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE). To fix this we clear skb2->cb[], as suggested by Oskar Kjos. Also add minimal IPv4 header validation (version == 4, ihl >= 5).", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43038", "url": "https://ubuntu.com/security/CVE-2026-43038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31682", "url": "https://ubuntu.com/security/CVE-2026-31682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: linearize skb before parsing ND options br_nd_send() parses neighbour discovery options from ns->opt[] and assumes that these options are in the linear part of request. Its callers only guarantee that the ICMPv6 header and target address are available, so the option area can still be non-linear. Parsing ns->opt[] in that case can access data past the linear buffer. Linearize request before option parsing and derive ns from the linear network header.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-23450", "url": "https://ubuntu.com/security/CVE-2026-23450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1]. smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release(). This leads to two issues: 1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed. The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race): CPU A (softirq) CPU B (process ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* No lock on listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash! Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed. Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight. - Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock(). - Use rcu_read_lock() to protect reading sk_user_data. - Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely. Note: smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected. Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied. [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23428", "url": "https://ubuntu.com/security/CVE-2026-23428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of share_conf in compound request smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without validating tcon->t_state. ksmbd_tree_conn_lookup() checks t_state == TREE_CONNECTED on the initial lookup path, but the compound reuse path bypasses this check entirely. If a prior command in the compound (SMB2_TREE_DISCONNECT) sets t_state to TREE_DISCONNECTED and frees share_conf via ksmbd_share_config_put(), subsequent commands dereference the freed share_conf through work->tcon->share_conf. KASAN report: [ 4.144653] ================================================================== [ 4.145059] BUG: KASAN: slab-use-after-free in smb2_write+0xc74/0xe70 [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44 [ 4.145772] [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY [ 4.145871] 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 [ 4.145875] Workqueue: ksmbd-io handle_ksmbd_work [ 4.145888] Call Trace: [ 4.145892] [ 4.145894] dump_stack_lvl+0x64/0x80 [ 4.145910] print_report+0xce/0x660 [ 4.145919] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 4.145928] ? smb2_write+0xc74/0xe70 [ 4.145931] kasan_report+0xce/0x100 [ 4.145934] ? smb2_write+0xc74/0xe70 [ 4.145937] smb2_write+0xc74/0xe70 [ 4.145939] ? __pfx_smb2_write+0x10/0x10 [ 4.145942] ? _raw_spin_unlock+0xe/0x30 [ 4.145945] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 4.145948] ? smb2_tree_disconnect+0x31c/0x480 [ 4.145951] handle_ksmbd_work+0x40f/0x1080 [ 4.145953] process_one_work+0x5fa/0xef0 [ 4.145962] ? assign_work+0x122/0x3e0 [ 4.145964] worker_thread+0x54b/0xf70 [ 4.145967] ? __pfx_worker_thread+0x10/0x10 [ 4.145970] kthread+0x346/0x470 [ 4.145976] ? recalc_sigpending+0x19b/0x230 [ 4.145980] ? __pfx_kthread+0x10/0x10 [ 4.145984] ret_from_fork+0x4fb/0x6c0 [ 4.145992] ? __pfx_ret_from_fork+0x10/0x10 [ 4.145995] ? __switch_to+0x36c/0xbe0 [ 4.145999] ? __pfx_kthread+0x10/0x10 [ 4.146003] ret_from_fork_asm+0x1a/0x30 [ 4.146013] [ 4.146014] [ 4.149858] Allocated by task 44: [ 4.149953] kasan_save_stack+0x33/0x60 [ 4.150061] kasan_save_track+0x14/0x30 [ 4.150169] __kasan_kmalloc+0x8f/0xa0 [ 4.150274] ksmbd_share_config_get+0x1dd/0xdd0 [ 4.150401] ksmbd_tree_conn_connect+0x7e/0x600 [ 4.150529] smb2_tree_connect+0x2e6/0x1000 [ 4.150645] handle_ksmbd_work+0x40f/0x1080 [ 4.150761] process_one_work+0x5fa/0xef0 [ 4.150873] worker_thread+0x54b/0xf70 [ 4.150978] kthread+0x346/0x470 [ 4.151071] ret_from_fork+0x4fb/0x6c0 [ 4.151176] ret_from_fork_asm+0x1a/0x30 [ 4.151286] [ 4.151332] Freed by task 44: [ 4.151418] kasan_save_stack+0x33/0x60 [ 4.151526] kasan_save_track+0x14/0x30 [ 4.151634] kasan_save_free_info+0x3b/0x60 [ 4.151751] __kasan_slab_free+0x43/0x70 [ 4.151861] kfree+0x1ca/0x430 [ 4.151952] __ksmbd_tree_conn_disconnect+0xc8/0x190 [ 4.152088] smb2_tree_disconnect+0x1cd/0x480 [ 4.152211] handle_ksmbd_work+0x40f/0x1080 [ 4.152326] process_one_work+0x5fa/0xef0 [ 4.152438] worker_thread+0x54b/0xf70 [ 4.152545] kthread+0x346/0x470 [ 4.152638] ret_from_fork+0x4fb/0x6c0 [ 4.152743] ret_from_fork_asm+0x1a/0x30 [ 4.152853] [ 4.152900] The buggy address belongs to the object at ffff88810430c180 [ 4.152900] which belongs to the cache kmalloc-96 of size 96 [ 4.153226] The buggy address is located 20 bytes inside of [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0) [ 4.153549] [ 4.153596] The buggy address belongs to the physical page: [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c [ 4.154000] flags: 0x ---truncated---", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23455", "url": "https://ubuntu.com/security/CVE-2026-23455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read. Add a check to ensure len is positive after the decrement.", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43186", "url": "https://ubuntu.com/security/CVE-2026-43186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43185", "url": "https://ubuntu.com/security/CVE-2026-43185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix signededness bug in smb_direct_prepare_negotiation() smb_direct_prepare_negotiation() casts an unsigned __u32 value from sp->max_recv_size and req->preferred_send_size to a signed int before computing min_t(int, ...). A maliciously provided preferred_send_size of 0x80000000 will return as smaller than max_recv_size, and then be used to set the maximum allowed alowed receive size for the next message. By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow. This fix replaces min_t(int, ...) with min_t(u32)", "cve_priority": "critical", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43341", "url": "https://ubuntu.com/security/CVE-2026-43341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31607", "url": "https://ubuntu.com/security/CVE-2026-31607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: validate number_of_packets in usbip_pack_ret_submit() When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the *original* number_of_packets from the CMD_SUBMIT. A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region. KASAN confirmed this with kernel 7.0.0-rc5: BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69 The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40) The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 (\"usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input\") and b78d830f0049 (\"usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input\"). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets. This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size. Kelvin Mbogo's series (\"usb: usbip: fix integer overflow in usbip_recv_iso()\", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit. Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43383", "url": "https://ubuntu.com/security/CVE-2026-43383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-md5: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2025-68263", "url": "https://ubuntu.com/security/CVE-2025-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: ipc: fix use-after-free in ipc_msg_send_request ipc_msg_send_request() waits for a generic netlink reply using an ipc_msg_table_entry on the stack. The generic netlink handler (handle_generic_event()/handle_response()) fills entry->response under ipc_msg_table_lock, but ipc_msg_send_request() used to validate and free entry->response without holding the same lock. Under high concurrency this allows a race where handle_response() is copying data into entry->response while ipc_msg_send_request() has just freed it, leading to a slab-use-after-free reported by KASAN in handle_generic_event(): BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd] Write of size 12 at addr ffff888198ee6e20 by task pool/109349 ... Freed by task: kvfree ipc_msg_send_request [ksmbd] ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd] Fix by: - Taking ipc_msg_table_lock in ipc_msg_send_request() while validating entry->response, freeing it when invalid, and removing the entry from ipc_msg_table. - Returning the final entry->response pointer to the caller only after the hash entry is removed under the lock. - Returning NULL in the error path, preserving the original API semantics. This makes all accesses to entry->response consistent with handle_response(), which already updates and fills the response buffer under ipc_msg_table_lock, and closes the race that allowed the UAF.", "cve_priority": "critical", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2026-46243", "url": "https://ubuntu.com/security/CVE-2026-46243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key.", "cve_priority": "medium", "cve_public_date": "2026-06-01 17:17:00 UTC" }, { "cve": "CVE-2026-43414", "url": "https://ubuntu.com/security/CVE-2026-43414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Completely fix fcport double free In qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free(). When an error happens, this function is called by qla2x00_sp_release(), when kref_put() releases the first and the last reference. qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport(). Doing it one more time after kref_put() is a bad idea.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43407", "url": "https://ubuntu.com/security/CVE-2026-43407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply() This patch fixes an out-of-bounds access in ceph_handle_auth_reply() that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In ceph_handle_auth_reply(), the value of the payload_len field of such a message is stored in a variable of type int. A value greater than INT_MAX leads to an integer overflow and is interpreted as a negative value. This leads to decrementing the pointer address by this value and subsequently accessing it because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. This patch fixes the issue by changing the data type of payload_len to u32. Additionally, the data type of result_msg_len is changed to u32, as it is also a variable holding a non-negative length. Also, an additional layer of sanity checks is introduced, ensuring that directly after reading it from the message, payload_len and result_msg_len are not greater than the overall segment length. BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph] Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262 CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ceph-msgr ceph_con_workfn [libceph] Call Trace: dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x620 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x72/0x210 kasan_report+0xe7/0x130 ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] __asan_report_load_n_noabort+0xf/0x20 ceph_handle_auth_reply+0x642/0x7a0 [libceph] mon_dispatch+0x973/0x23d0 [libceph] ? apparmor_socket_recvmsg+0x6b/0xa0 ? __pfx_mon_dispatch+0x10/0x10 [libceph] ? __kasan_check_write+0x14/0x30i ? mutex_unlock+0x7f/0xd0 ? __pfx_mutex_unlock+0x10/0x10 ? __pfx_do_recvmsg+0x10/0x10 [libceph] ceph_con_process_message+0x1f1/0x650 [libceph] process_message+0x1e/0x450 [libceph] ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] ? save_fpregs_to_fpstate+0xb0/0x230 ? raw_spin_rq_unlock+0x17/0xa0 ? finish_task_switch.isra.0+0x13b/0x760 ? __switch_to+0x385/0xda0 ? __kasan_check_write+0x14/0x30 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 ceph_con_workfn+0x248/0x10c0 [libceph] process_one_work+0x629/0xf80 ? __kasan_check_write+0x14/0x30 worker_thread+0x87f/0x1570 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_try_to_wake_up+0x10/0x10 ? kasan_print_address_stack_frame+0x1f7/0x280 ? __pfx_worker_thread+0x10/0x10 kthread+0x396/0x830 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? __pfx_kthread+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? recalc_sigpending+0x180/0x210 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3f7/0x610 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x385/0xda0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 [ idryomov: replace if statements with ceph_decode_need() for payload_len and result_msg_len ]", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43406", "url": "https://ubuntu.com/security/CVE-2026-43406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in process_message_header() If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in process_message_header(). Perform an explicit bounds check before decoding the message header.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43304", "url": "https://ubuntu.com/security/CVE-2026-43304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.", "cve_priority": "critical", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-37924", "url": "https://ubuntu.com/security/CVE-2025-37924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in kerberos authentication Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbd_free_user but before sess->user is set to NULL.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37778", "url": "https://ubuntu.com/security/CVE-2025-37778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix dangling pointer in krb_authenticate krb_authenticate frees sess->user and does not set the pointer to NULL. It calls ksmbd_krb5_authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2_sess_setup, which calls krb_authenticate, will be accessing free'd memory when it later uses sess->user.", "cve_priority": "high", "cve_public_date": "2025-05-01 14:15:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1104.109 -proposed tracker (LP: #2157390)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] resync retpoline extraction", "", " [ Ubuntu: 5.15.0-186.196 ]", "", " * jammy/linux: 5.15.0-186.196 -proposed tracker (LP: #2157405)", " * [Jammy] Priority inversion problem in epoll for rt kernel (LP: #2154194)", " - eventpoll: Replace rwlock with spinlock", " * CVE-2026-46137", " - mptcp: pm: ADD_ADDR rtx: fix potential data-race", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901)", " - Linux 5.15.208", " - ALSA: asihpi: avoid write overflow check warning", " - can: mcp251x: add error handling for power enable in open and resume", " - ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg0xxx", " - ASoC: soc-core: call missing INIT_LIST_HEAD() for card_aux_list", " - ALSA: usb-audio: Fix quirk flags for NeuralDSP Quad Cortex", " - pinctrl: intel: Fix the revision for new features (1kOhm PD, HW", " debouncer)", " - HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3", " - ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585", " - ASoC: stm32_sai: fix incorrect BCLK polarity for DSP_A/B, LEFT_J", " - soc: aspeed: socinfo: Mask table entries for accurate SoC ID matching", " - arm64: dts: imx8mq: Set the correct gpu_ahb clock frequency", " - PCI: hv: Set default NUMA node to 0 for devices without affinity info", " - drm/vc4: Protect madv read in vc4_gem_object_mmap() with madv_lock", " - epoll: use refcount to reduce ep_mutex contention", " - tracing/probe: reject non-closed empty immediate strings", " - e1000: check return value of e1000_read_eeprom", " - gpio: tegra: fix irq_release_resources calling enable instead of disable", " - i3c: fix uninitialized variable use in i2c setup", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - mips: mm: Allocate tlb_vpn array atomically", " - MIPS: Always record SEGBITS in cpu_data.vmbits", " - MIPS: mm: Suppress TLB uniquification on EHINV hardware", " - MIPS: mm: Rewrite TLB uniquification for the hidden bit feature", " - ALSA: usb-audio: Update for native DSD support quirks", " - usb: storage: Expand range of matched versions for VL817 quirks entry", " - USB: serial: option: add Telit Cinterion FN990A MBIM composition", " - fsl-mc: Use driver_set_override() instead of open-coding", " - checkpatch: add support for Assisted-by tag", " - gfs2: Improve gfs2_consist_inode() usage", " - PCI/ACPI: Restrict program_hpx_type2() to AER bits", " - netfilter: nft_set_pipapo: do not rely on ZERO_SIZE_PTR", " - powerpc64/bpf: do not increment tailcall count when prog is NULL", " - arm64: dts: imx8mq-librem5: Set the DVS voltages lower", " - arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage to 0.81V", " - Revert \"arm64: dts: imx8mq-librem5: Set the DVS voltages lower\"", " - arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V", " - ocfs2: add inline inode consistency check to", " ocfs2_validate_inode_block()", " - rxrpc: Fix key quota calculation for multitoken keys", " - fs/ocfs2: fix comments mentioning i_mutex", " - MPTCP: fix lock class name family in pm_nl_create_listen_socket", " - Revert \"nvme: nvme-fc: Ensure ->ioerr_work is cancelled in", " nvme_fc_delete_ctrl()\"", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", " - s390/xor: Fix xor_xc_2() inline assembly constraints", " - net: add skb_header_pointer_careful() helper", " - x86/uprobes: Fix XOL allocation failure for 32-bit tasks", " - iio: imu: inv_icm42600: fix odr switch when turning buffer off", " - vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check", " - net: usb: lan78xx: Fix double free issue with interrupt buffer", " allocation", " - SAUCE: Revert \"fs/ntfs3: Fixed overflow check in mi_enum_attr()\"", " - SAUCE: Revert \"fs/ntfs3: Sequential field availability check in", " mi_enum_attr()\"", " - SAUCE: Revert \"ntfs3: Add bounds checking to mi_enum_attr()\"", " - cpufreq: governor: Free dbs_data directly when gov->init() fails", " - scripts/dtc: Remove unused dts_version in dtc-lexer.l", " - rxrpc: Fix anonymous key handling", " - iommu: fix a reference count leak in iommu_sva_bind_device()", " - fuse: quiet down complaints in fuse_conn_limit_write", " - ALSA: usb-audio: apply quirk for MOONDROP JU Jiu", " - tty: n_gsm: fix flow control handling in tx path", " - ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free", " - ALSA: usb-audio: Avoid false E-MU sample-rate notifications", " - ALSA: usb-audio: Fix Audio Advantage Micro II SPDIF switch", " - usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable()", " - ALSA: usb-audio: Evaluate packsize caps at the right place", " - firmware: google: framebuffer: Do not mark framebuffer as busy", " - device property: Make modifications of fwnode \"flags\" thread safe", " - driver core: Don't let a device probe until it's ready", " - um: drivers: call kernel_strrchr() explicitly in cow_user.c", " - Revert \"ALSA: usb: Increase volume range that triggers a warning\"", " - lib/ts_kmp: fix integer overflow in pattern length calculation", " - media: i2c: imx219: Check return value of devm_gpiod_get_optional() in", " imx219_probe()", " - ALSA: aoa: i2sbus: fix OF node lifetime handling", " - ALSA: seq_oss: return full count for successful SEQ_FULLSIZE writes", " - nvme-pci: add NVME_QUIRK_DISABLE_WRITE_ZEROES for Kingston OM3SGP4", " - parisc: _llseek syscall is only available for 32-bit userspace", " - selftests/mqueue: Fix incorrectly named file", " - ALSA: caiaq: Fix control_put() result and cache rollback", " - ALSA: 6fire: Fix input volume change detection", " - iio: adc: ad7768-1: fix one-shot mode data acquisition", " - drm/arcpgu: fix device node leak", " - tpm: avoid -Wunused-but-set-variable", " - power: supply: axp288_charger: Do not cancel work before initializing it", " - mmc: block: use single block write in retry", " - tpm: tpm_tis: add error logging for data transfer", " - rtc: ntxec: fix OF node reference imbalance", " - userfaultfd: allow registration of ranges below mmap_min_addr", " - KVM: nSVM: Mark all of vmcb02 dirty when restoring nested state", " - KVM: SVM: Explicitly mark vmcb01 dirty after modifying VMCB intercepts", " - KVM: nSVM: Ensure AVIC is inhibited when restoring a vCPU to guest mode", " - KVM: nSVM: Always inject a #GP if mapping VMCB12 fails on nested VMRUN", " - KVM: nSVM: Clear GIF on nested #VMEXIT(INVALID)", " - KVM: nSVM: Add missing consistency check for nCR3 validity", " - io_uring/poll: fix EPOLL_URING_WAKE sometimes not being honored", " - io_uring/poll: fix backport of io_poll_add() changes", " - mtd: docg3: Convert to platform remove callback returning void", " - taskstats: set version in TGID exit notifications", " - crypto: arm64/aes - Fix 32-bit aes_mac_update() arg treated as 64-bit", " - crypto: atmel-ecc - Release client on allocation failure", " - crypto: hisilicon - Fix dma_unmap_single() direction", " - IB/core: Fix zero dmac race in neighbor resolution", " - ktest: Fix the month in the name of the failure directory", " - seg6: fix seg6 lwtunnel output redirect for L2 reduced encap mode", " - driver core: Add kernel-doc for DEV_FLAG_COUNT enum value", " - ALSA: caiaq: Fix potentially leftover ep1_in_urb at error path", " - ALSA: caiaq: Don't abort when no input device is available", " - drm/amdgpu: fix zero-size GDS range init on RDNA4", " - ALSA: caiaq: fix usb_dev refcount leak on probe failure", " - ACPI: scan: Use acpi_dev_put() in object add error paths", " - ACPI: CPPC: Fix related_cpus inconsistency during CPU hotplug", " - ACPI: video: force native backlight on HP OMEN 16 (8A44)", " - spi: rockchip: fix controller deregistration", " - um: virt-pci: Fix build failure", " - ipmi:ssif: Fix a shutdown race", " - ipmi:ssif: Remove unnecessary indention", " - ipmi:ssif: NULL thread on error", " - ALSA: usb-audio: Fix UAC3 cluster descriptor size check", " - USB: omap_udc: DMA: Don't enable burst 4 mode", " - USB: serial: option: add Telit Cinterion LE910Cx compositions", " - usb: ulpi: fix memory leak on ulpi_register() error paths", " - ALSA: firewire-tascam: Do not drop unread control events", " - xfrm: provide message size for XFRM_MSG_MAPPING", " - spi: zynqmp-gqspi: fix controller deregistration", " - parisc: Fix IRQ leak in LASI driver", " - hwmon: (ltc2992) Clamp threshold writes to hardware range", " - hwmon: (ltc2992) Fix u32 overflow in power read path", " - hwmon: (corsair-psu) Close HID device on probe errors", " - extcon: ptn5150: handle pending IRQ events during system resume", " - hv_sock: fix ARM64 support", " - udf: reject descriptors with oversized CRC length", " - thermal/drivers/sprd: Fix temperature clamping in", " sprd_thm_temp_to_rawdata", " - thermal/drivers/sprd: Fix raw temperature clamping in", " sprd_thm_rawdata_to_temp", " - cpuidle: powerpc: avoid double clear when breaking snooze", " - ASoC: fsl_easrc: fix comment typo", " - ASoC: Intel: bytcr_wm5102: Fix MCLK leak on platform_clock_control error", " - dm: don't report warning when doing deferred remove", " - dm-verity-fec: correctly reject too-small FEC devices", " - dm-verity-fec: correctly reject too-small hash devices", " - s390/debug: Reject zero-length input in debug_input_flush_fn()", " - PCI/AER: Clear only error bits in PCIe Device Status", " - PCI/AER: Stop ruling out unbound devices as error source", " - power: supply: max17042: avoid overflow when determining health", " - mptcp: use MPJoinSynAckHMacFailure for SynAck HMAC failure", " - mptcp: use MPTCP_RST_EMPTCP for ACK HMAC validation failure", " - mptcp: sockopt: set timestamp flags on subflow socket, not msk", " - platform/x86: hp-wmi: Ignore backlight and FnLock events", " - media: uvcvideo: Enable VB2_DMABUF for metadata stream", " - media: i2c: ov8856: free control handler on error in", " ov8856_init_controls()", " - regulator: max77650: fix OF node reference imbalance", " - media: rc: streamzap: Error handling in probe", " - regulator: act8945a: fix OF node reference imbalance", " - regulator: bd9571mwv: fix OF node reference imbalance", " - media: dib8000: avoid division by 0 in dib8000_set_dds()", " - media: i2c: imx412: Assert reset GPIO during probe", " - spi: mtk-nor: fix controller deregistration", " - spi: imx: fix runtime pm leak on probe deferral", " - spi: orion: fix clock imbalance on registration failure", " - drm/radeon: add missing revision check for CI", " - drm/amdgpu/gfx9: drop unnecessary 64-bit fence flag check in KIQ", " - drm/amdgpu/pm: add missing revision check for CI", " - drm/amdgpu/pm: align Hawaii mclk workaround with radeon", " - drm/amdgpu/vcn3: Avoid overflow on msg bound check", " - bcache: fix uninitialized closure object", " - fs/omfs: reject s_sys_blocksize smaller than OMFS_DIR_START", " - drbd: Balance RCU calls in drbd_adm_dump_devices()", " - nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()", " - pstore/ram: fix resource leak when ioremap() fails", " - devres: fix missing node debug info in devm_krealloc()", " - thermal/drivers/spear: Fix error condition for reading st,thermal-flags", " - debugfs: check for NULL pointer in debugfs_create_str()", " - irqchip/irq-pic32-evic: Address warning related to wrong printf()", " formatter", " - locking: Fix rwlock support in ", " - firmware: dmi: Correct an indexing error in dmi.h", " - wifi: mwifiex: Fix memory leak in mwifiex_11n_aggregate_pkt()", " - wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished", " irq_prepare_bcn_tasklet", " - dpaa2: add independent dependencies for FSL_DPAA2_SWITCH", " - [Config] Disable FSL_DPAA2_SWITCH on armhf, ppc64el", " - dpaa2: compile dpaa2 even CONFIG_FSL_DPAA2_ETH=n", " - kernel: param: rename locate_module_kobject", " - kernel: globalize lookup_or_create_module_kobject()", " - params: Replace __modinit with __init_or_module", " - module: Fix freeing of charp module parameters when CONFIG_SYSFS=n", " - bpf, devmap: Remove unnecessary if check in for loop", " - bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path", " - r8152: fix incorrect register write to USB_UPHY_XTAL", " - powerpc/crash: fix backup region offset update to elfcorehdr", " - macvlan: annotate data-races around port->bc_queue_len_used", " - wifi: brcmfmac: Fix error pointer dereference", " - bpf-lsm: Make bpf_lsm_userns_create() sleepable", " - bpf: Drop task_to_inode and inet_conn_established from lsm sleepable", " hooks", " - net: bcmgenet: fix off-by-one in bcmgenet_put_txcb", " - netfilter: xt_socket: enable defrag after all other checks", " - netfilter: nft_fwd_netdev: check ttl/hl before forwarding", " - 6pack: propagage new tty types", " - net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf", " - net/rds: Optimize rds_ib_laddr_check", " - net/rds: Restrict use of RDS/IB to the initial network namespace", " - ppp: require CAP_NET_ADMIN in target netns for unattached ioctls", " - bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb", " - Bluetooth: L2CAP: Fix printing wrong information if SDU length exceeds", " MTU", " - Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error", " - Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER", " - Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp", " - net: phy: qcom: at803x: Use the correct bit to disable extended next", " page", " - sctp: fix missing encap_port propagation for GSO fragments", " - net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master", " - drm/komeda: fix integer overflow in AFBC framebuffer size check", " - ASoC: sti: Return errors from regmap_field_alloc()", " - ASoC: sti: use managed regmap_field allocations", " - dm cache: fix null-deref with concurrent writes in passthrough mode", " - dm cache: fix write path cache coherency in passthrough mode", " - dm cache policy smq: fix missing locks in invalidating cache blocks", " - dm cache: fix concurrent write failure in passthrough mode", " - dm cache: support shrinking the origin device", " - dm cache: fix dirty mapping checking in passthrough mode switching", " - dm cache metadata: fix memory leak on metadata abort retry", " - dm log: fix out-of-bounds write due to region_count overflow", " - spi: fsl-qspi: Use reinit_completion() for repeated operations", " - drm/sun4i: Fix resource leaks", " - dm init: ensure device probing has finished in dm-mod.waitfor=", " - fbdev: matroxfb: Mark variable with __maybe_unused to avoid W=1 build", " break", " - spi: hisi-kunpeng: prevent infinite while() loop in hisi_spi_flush_fifo", " - drm/msm/dsi: rename MSM8998 DSI version from V2_2_0 to V2_0_0", " - drm/panel: simple: Correct G190EAN01 prepare timing", " - ALSA: core: Validate compress device numbers without dynamic minors", " - drm/amd/pm/ci: Use highest MCLK on CI when MCLK DPM is disabled", " - drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs", " - drm/amd/pm/smu7: Fix SMU7 voltage dependency on display clock", " - drm/amd/pm/ci: Fix powertune defaults for Hawaii 0x67B0", " - drm/amd/pm/ci: Clear EnabledForActivity field for memory levels", " - drm/amd/pm/ci: Fill DW8 fields from SMC", " - drm/amd/pm/smu7: Add SCLK cap for quirky Hawaii board", " - ALSA: hda/realtek: Whitespace fix", " - ALSA: hda/realtek: fix code style (ERROR: else should follow close brace", " '}')", " - drm/msm/a6xx: Fix HLSQ register dumping", " - drm/msm/a6xx: Use barriers while updating HFI Q headers", " - pmdomain: ti: omap_prm: Fix a reference leak on device node", " - pmdomain: imx: scu-pd: Fix device_node reference leak during ->probe()", " - ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_arc_mode_put()", " - ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_mode_put()", " - ASoC: fsl_easrc: Check the variable range in fsl_easrc_iec958_put_bits()", " - ASoC: fsl_easrc: Fix value type in fsl_easrc_iec958_get_bits()", " - ASoC: fsl_easrc: Change the type for iec958 channel status controls", " - PCI: Enable AtomicOps only if Root Port supports them", " - Documentation: fix a hugetlbfs reservation statement", " - selftest: memcg: skip memcg_sock test if address family not supported", " - PCI: Add PCIE_PME_TO_L2_TIMEOUT_US L2 ready timeout value", " - PCI: tegra194: Fix polling delay for L2 state", " - PCI: tegra194: Increase LTSSM poll time on surprise link down", " - PCI: tegra194: Disable LTSSM after transition to Detect on surprise link", " down", " - PCI: tegra194: Use devm_gpiod_get_optional() to parse \"nvidia,refclk-", " select\"", " - PCI: tegra194: Disable direct speed change for Endpoint mode", " - ALSA: sc6000: Use standard print API", " - ALSA: sc6000: Keep the programmed board state in card-private data", " - ktest: Avoid undef warning when WARNINGS_FILE is unset", " - ktest: Honor empty per-test option overrides", " - ktest: Run POST_KTEST hooks on failure and cancellation", " - quota: Fix race of dquot_scan_active() with quota deactivation", " - gfs2: add some missing log locking", " - gfs2: prevent NULL pointer dereference during unmount", " - efi/capsule-loader: fix incorrect sizeof in phys array reallocation", " - ksmbd: fix use-after-free from async crypto on Qualcomm crypto engine", " - ARM: dts: mediatek: mt7623: fix efuse fallback compatible", " - memory: tegra124-emc: Fix dll_change check", " - memory: tegra30-emc: Fix dll_change check", " - soc: qcom: ocmem: use scoped device node handling to simplify error", " paths", " - soc: qcom: ocmem: register reasons for probe deferrals", " - soc: qcom: ocmem: return -EPROBE_DEFER is ocmem is not available", " - arm64: dts: qcom: sdm845-xiaomi-beryllium: Mark l1a regulator as powered", " during boot", " - unshare: fix nsproxy leak in ksys_unshare() on set_cred_ucounts()", " failure", " - ocfs2/dlm: validate qr_numregions in dlm_match_regions()", " - ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison", " - soc: qcom: aoss: compare against normalized cooling state", " - ocfs2: fix listxattr handling when the buffer is full", " - ocfs2: validate bg_bits during freefrag scan", " - ocfs2: validate group add input before caching", " - dmaengine: dw-axi-dmac: Remove unnecessary return statement from void", " function", " - dmaengine: mxs-dma: Fix missing return value from", " of_dma_controller_register()", " - tracing: Rebuild full_name on each hist_field_name() call", " - ima: check return value of crypto_shash_final() in boot aggregate", " - HID: asus: make asus_resume adhere to linux kernel coding standards", " - HID: asus: do not abort probe when not necessary", " - mtd: physmap_of_gemini: Fix disabled pinctrl state check", " - mtd: spi-nor: core: correct the op.dummy.nbytes when check read", " operations", " - mtd: spi-nor: swp: check SR_TB flag when getting tb_mask", " - mtd: parsers: ofpart: call of_node_put() only in ofpart_fail path", " - mtd: parsers: ofpart: call of_node_get() for dedicated subpartitions", " - mtd: rawnand: sunxi: fix sunxi_nfc_hw_ecc_read_extra_oob", " - HID: usbhid: fix deadlock in hid_post_reset()", " - pinctrl: pinctrl-pic32: Fix resource leak", " - perf branch: Avoid incrementing NULL", " - perf: tools: cs-etm: Fix print issue for Coresight debug in ETE/TRBE", " trace", " - pinctrl: abx500: Fix type of 'argument' variable", " - perf expr: Return -EINVAL for syntax error in expr__find_ids()", " - perf util: Kill die() prototype, dead for a long time", " - i3c: mipi-i3c-hci: fix IBI payload length calculation for final status", " - driver core: device.h: remove extern from function prototypes", " - driver core: Move dev_err_probe() to where it belogs", " - dev_printk: add new dev_err_probe() helpers", " - backlight: sky81452-backlight: Check return value of", " devm_gpiod_get_optional() in sky81452_bl_parse_dt()", " - platform/surface: surfacepro3_button: Drop wakeup source on remove", " - leds: lgm-sso: Remove duplicate assignments for priv->mmap", " - tty: hvc: remove HVC_IUCV_MAGIC", " - tty: hvc_iucv: fix off-by-one in number of supported devices", " - platform/x86: panasonic-laptop: Fix OPTD notifier registration and", " cleanup", " - mfd: mc13xxx-core: Fix memory leak in mc13xxx_add_subdevice_pdata()", " - nfs/blocklayout: Fix compilation error (`make W=1`) in", " bl_write_pagelist()", " - fs/ntfs3: terminate the cached volume label after UTF-8 conversion", " - platform/x86: dell_rbu: avoid uninit value usage in packet_size_write()", " - platform/x86: dell-wmi-sysman: bound enumeration string aggregation", " - RDMA/core: Prefer NLA_NUL_STRING", " - scsi: sg: Resolve soft lockup issue when opening /dev/sgX", " - scsi: target: core: Fix integer overflow in UNMAP bounds check", " - dt-bindings: clock: qcom,gcc-sc8180x: Add missing GDSCs", " - clk: qcom: gcc-sc8180x: Add missing GDSCs", " - clk: qcom: gcc-sc8180x: Use retention for USB power domains", " - clk: qcom: gcc-sc8180x: Use retention for PCIe power domains", " - clk: qcom: dispcc-sm8250: Use shared ops on the mdss vsync clk", " - clk: qcom: dispcc-sm8250: Enable parents for pixel clocks", " - clk: imx: imx6q: Fix device node reference leak in pll6_bypassed()", " - clk: imx: imx6q: Fix device node reference leak in", " of_assigned_ldb_sels()", " - clk: imx8mq: Correct the CSI PHY sels", " - clk: qoriq: avoid format string warning", " - clk: xgene: Fix mapping leak in xgene_pllclk_init()", " - dt-bindings: clock: qcom,dispcc-sc7180: Define MDSS resets", " - clk: qcom: dispcc-sc7180: Add missing MDSS resets", " - lib/hexdump: print_hex_dump_bytes() calls print_hex_dump_debug()", " - crypto: sa2ul - Fix AEAD fallback algorithm names", " - crypto: ccp - copy IV using skcipher ivsize", " - PCMCIA: Fix garbled log messages for KERN_CONT", " - net/sched: sch_cake: fix NAT destination port not being updated in", " cake_update_flowkeys", " - nexthop: fix IPv6 route referencing IPv4 nexthop", " - net/sched: taprio: stop going through private ops for dequeue and peek", " - net/sched: taprio: replace safety precautions with comments", " - net/sched: taprio: continue with other TXQs if one dequeue() failed", " - net/sched: taprio: refactor one skb dequeue from TXQ to separate", " function", " - net/sched: taprio: rename close_time to end_time", " - net/sched: taprio: fix use-after-free in advance_sched() on schedule", " switch", " - tcp: annotate data-races around (tp->write_seq - tp->snd_nxt)", " - i40e: don't advertise IFF_SUPP_NOFCS", " - e1000e: Unroll PTP in probe error handling", " - ipv6: fix possible UAF in icmpv6_rcv()", " - sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks", " - dissector: do not set invalid PPP protocol", " - flow_dissector: Add number of vlan tags dissector", " - flow_dissector: Add PPPoE dissectors", " - pppoe: drop PFC frames", " - netfilter: nft_osf: restrict it to ipv4", " - netfilter: conntrack: remove sprintf usage", " - netfilter: xtables: restrict several matches to inet family", " - ipvs: fix MTU check for GSO packets in tunnel mode", " - netfilter: nfnetlink_osf: fix out-of-bounds read on option matching", " - netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check", " - arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number", " - ksmbd: destroy tree_conn_ida in ksmbd_session_destroy()", " - ksmbd: scope conn->binding slowpath to bound sessions only", " - net/rds: zero per-item info buffer before handing it to visitors", " - net_sched: sch_hhf: annotate data-races in hhf_dump_stats()", " - net/sched: sch_pie: annotate data-races in pie_dump_stats()", " - net/sched: sch_fq_codel: remove data-races from fq_codel_dump_stats()", " - net: sched: gred/red: remove unused variables in struct red_stats", " - net/sched: sch_red: annotate data-races in red_dump_stats()", " - net/sched: sch_sfb: annotate data-races in sfb_dump_stats()", " - nfp: fix swapped arguments in nfp_encode_basic_qdr() calls", " - tipc: fix double-free in tipc_buf_append()", " - vhost_net: fix sleeping with preempt-disabled in vhost_net_busy_poll()", " - fs/adfs: validate nzones in adfs_validate_bblk()", " - rtc: abx80x: Disable alarm feature if no interrupt attached", " - fbdev: offb: fix PCI device reference leak on probe failure", " - mailbox: mailbox-test: free channels on probe error", " - cgroup/rdma: fix integer overflow in rdmacg_try_charge()", " - mailbox: add sanity check for channel array", " - mailbox: mailbox-test: don't free the reused channel", " - mailbox: mailbox-test: initialize struct earlier", " - mailbox: mailbox-test: make data_ready a per-instance variable", " - btrfs: fix double-decrement of bytes_may_use in", " submit_one_async_extent()", " - tracing: branch: Fix inverted check on stat tracer registration", " - drm/amdgpu: fix spelling typos", " - drm/amdgpu/uvd3.1: Don't validate the firmware when already validated", " - drm/amdgpu/gfx6: Support harvested SI chips with disabled TCCs (v2)", " - netfilter: xt_policy: fix strict mode inbound policy matching", " - netfilter: nf_conntrack_sip: don't use simple_strtoul", " - scsi: sr: Add memory allocation failure handling for get_capabilities()", " - cdrom, scsi: sr: propagate read-only status to block layer via", " set_disk_ro()", " - netdevsim: zero initialize struct iphdr in dummy sk_buff", " - net: sched: sch_netem: Refactor code in 4-state loss generator", " - net/sched: netem: fix probability gaps in 4-state loss model", " - net/sched: netem: fix queue limit check to include reordered packets", " - net/sched: netem: validate slot configuration", " - net: sched: choke: remove unused variables in struct choke_sched_data", " - net/sched: sch_choke: annotate data-races in choke_dump_stats()", " - net/sched: sch_fq_pie: annotate data-races in fq_pie_dump_stats()", " - vrf: Fix a potential NPD when removing a port from a VRF", " - net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()", " - net: usb: rtl8150: free skb on usb_submit_urb() failure in xmit", " - NFC: trf7970a: Ignore antenna noise when checking for RF field", " - net: phy: dp83869: fix setting CLK_O_SEL field.", " - ASoC: codecs: ab8500: Fix casting of private data", " - netfilter: skip recording stale or retransmitted INIT", " - sctp: discard stale INIT after handshake completion", " - ipv4: rename and move ip_route_output_tunnel()", " - ipv4: remove \"proto\" argument from udp_tunnel_dst_lookup()", " - ipv4: add new arguments to udp_tunnel_dst_lookup()", " - ipv6: rename and move ip6_dst_lookup_tunnel()", " - net/sched: sch_cake: annotate data-races in cake_dump_stats() (V)", " - ALSA: hda/conexant: add a new hda codec SN6140", " - ALSA: hda/conexant: fix some typos", " - ALSA: hda/conexant: Renaming the codec with device ID 0x1f86 and 0x1f87", " - ALSA: hda/conexant: Fix missing error check for jack detection", " - drm/amd/display: Allow DCE link encoder without AUX registers", " - drm/amd/display: Read EDID from VBIOS embedded panel info", " - btrfs: tracepoints: fix sleep while in atomic context in", " btrfs_sync_file()", " - flow_dissector: do not dissect PPPoE PFC frames", " - flow_dissector: Do not count vlan tags inside tunnel payload", " - net/sched: sch_pie: annotate more data-races in pie_dump_stats()", " - crypto: af_alg - Cap AEAD AD length to 0x80000000", " - i40e: Cleanup PTP pins on probe failure", " - audit: fix incorrect inheritable capability in CAPSET records", " - netfilter: nft_ct: fix missing expect put in obj eval", " - net: atlantic: preserve PCI wake-from-D3 on shutdown when WOL enabled", " - audit: enforce AUDIT_LOCKED for AUDIT_TRIM and AUDIT_MAKE_EQUIV", " - KVM: Reject wrapped offset in kvm_reset_dirty_gfn()", " - KVM: x86: Fix Xen hypercall tracepoint argument assignment", " - drm/i915/dp: Fix VSC dynamic range signaling for RGB formats", " - ALSA: usb-audio: Bound MIDI endpoint descriptor scans", " - ceph: fix a buffer leak in __ceph_setxattr()", " - powerpc/warp: Fix error handling in pika_dtm_thread", " - libceph: Fix potential out-of-bounds access in osdmap_decode()", " - libceph: Fix potential null-ptr-deref in decode_choose_args()", " - libceph: Fix potential out-of-bounds access in crush_decode()", " - libceph: handle rbtree insertion error in decode_choose_args()", " - iommu/vt-d: Disable DMAR for Intel Q35 IGFX", " - drm/i915: skip __i915_request_skip() for already signaled requests", " - drm/panfrost: Fix wait_bo ioctl leaking positive return from", " dma_resv_wait_timeout()", " - drm/gma500/oaktrail_hdmi: fix i2c adapter leak on setup", " - s390/debug: Reject zero-length input before trimming a newline", " - Revert \"x86/vdso: Fix output operand size of RDPID\"", " - sysfs: don't remove existing directory on update failure", " - hwmon: (pmbus/adm1266) widen blackbox-info buffer to I2C_SMBUS_BLOCK_MAX", " - ALSA: ua101: Reject too-short USB descriptors", " - ALSA: asihpi: Fix potential OOB array access at reading cache", " - net: wwan: iosm: fix potential memory leaks in ipc_imem_init()", " - Bluetooth: bnep: Fix UAF read of dev->name", " - phonet/pep: disable BH around forwarded sk_receive_skb()", " - net: bcmgenet: keep RBUF EEE/PM disabled", " - netfilter: ip6t_hbh: reject oversized option lists", " - netfilter: nf_queue: hold bridge skb->dev while queued", " - netfilter: ipset: stop hash:* range iteration at end", " - ring-buffer: Fix reporting of missed events in iterator", " - vsock/vmci: fix UAF when peer resets connection during handshake", " - wifi: ath11k: clear shared SRNG pointer state on restart", " - ipv4: raw: reject IP_HDRINCL packets with ihl < 5", " - ixgbevf: fix use-after-free in VEPA multicast source pruning", " - wifi: cfg80211: advance loop vars in cfg80211_merge_profile()", " - tracing: Do not call map->ops->elt_free() if elt_alloc() fails", " - scsi: isci: Fix use-after-free in device removal path", " - spi: sprd: fix error pointer deref after DMA setup failure", " - spi: ti-qspi: fix use-after-free after DMA setup failure", " - RDMA/siw: Reject MPA FPDU length underflow before signed receive math", " - device property: set fwnode->secondary to NULL in fwnode_init()", " - drm/bridge: it66121: acquire reset GPIO in probe", " - drm/bridge: megachips: remove bridge when irq request fails", " - drm/amd/display: Fix integer overflow in bios_get_image()", " - drm/amd/display: Validate payload length and link_index in", " dc_process_dmub_aux_transfer_async", " - batman-adv: mcast: fix use-after-free in orig_node RCU release", " - batman-adv: clear current gateway during teardown", " - batman-adv: dat: handle forward allocation error", " - batman-adv: fix fragment reassembly length accounting", " - batman-adv: fix tp_meter counter underflow during shutdown", " - batman-adv: frag: disallow unicast fragment in fragment", " - batman-adv: bla: fix report_work leak on backbone_gw purge", " - batman-adv: tp_meter: avoid use of uninit sender vars", " - batman-adv: tt: fix negative last_changeset_len", " - batman-adv: tt: fix negative tt_buff_len", " - hwmon: (pmbus/adm1266) seed timestamp from the real-time clock", " - hwmon: (pmbus/adm1266) reject implausible blackbox record_count", " - hwmon: (pmbus/adm1266) include PEC byte in pmbus_block_xfer read buffer", " - hwmon: (pmbus/adm1266) bounce blackbox records through a protocol-sized", " buffer", " - hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR", " - hwmon: (pmbus/adm1266) don't clobber GPIO bits before PDIO read in", " get_multiple", " - hwmon: (pmbus/adm1266) register the gpio_chip after pmbus_do_probe()", " - hwmon: (pmbus/adm1266) register the nvmem device after pmbus_do_probe()", " - hwmon: (pmbus/adm1266) reject short block-read responses in the GPIO", " accessors", " - firmware: arm_ffa: Check for NULL FF-A ID table while driver", " registration", " - firmware: arm_ffa: Skip free_pages on RX buffer alloc failure", " - kunit: config: Enable KUNIT_DEBUGFS by default", " - kunit: config: KUNIT_DEBUGFS should depend on DEBUG_FS", " - ARM: integrator: Fix early initialization", " - netfilter: x_tables: unregister the templates first", " - tcp: Fix imbalanced icsk_accept_queue count.", " - ice: fix locking in ice_dcb_rebuild()", " - phy: marvell: mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register", " access", " - irqchip/ath79-cpu: Remove unused function", " - net: ethernet: cortina: Make RX SKB per-port", " - net: ethernet: cortina: Drop half-assembled SKB", " - net: ethernet: cortina: Carry over frag counter", " - net: ethernet: cs89x0: remove stale CONFIG_MACH_MX31ADS reference", " - wifi: ath11k: fix error path leaks in some WMI WOW calls", " - HID: quirks: really enable the intended work around for appledisplay", " - ethtool: fix ethnl_bitmap32_not_zero() bit interval semantics", " - drm/msm: Fix iommu_map_sgtable() return value check and avoid WARN", " - net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring", " - net: tls: prevent chain-after-chain in plain text SG", " - drm/msm/snapshot: fix dumping of the unaligned regions", " - net: dsa: mt7530: sync driver-specific behavior of MT7531 variants", " - net: dsa: mt7530: fix FDB entries not aging out with short timeout", " - net: dsa: mt7530: rename mt753x_bpdu_port_fw enum to mt753x_to_cpu_fw", " - net: dsa: mt7530: preserve VLAN tags on trapped link-local frames", " - net: mana: Fix TOCTOU double-fetch of hwc_msg_id from DMA buffer", " - platform/x86: adv_swbutton: Check ACPI_HANDLE() against NULL", " - platform/x86: hp_accel: Check ACPI_COMPANION() against NULL", " - platform/x86: intel-hid: Check ACPI_HANDLE() against NULL", " - platform/x86: intel-vbtn: Check ACPI_HANDLE() against NULL", " - RDMA/rtrs: Fix use-after-free in path file creation cleanup", " - net: bridge: Flush multicast groups when snooping is disabled", " - bridge: mcast: Fix a possible use-after-free when removing a bridge port", " - tracing: Avoid NULL return from hist_field_name() on truncation", " - net: ag71xx: check error for platform_get_irq", " - string: add mem_is_zero() helper to check if memory area is all zeros", " - gpiolib: cdev: use !mem_is_zero() instead of memchr_inv(s, 0, n)", " - gpio: cdev: check if uAPI v2 config attributes are correctly zeroed", " - net: mana: validate rx_req_idx to prevent out-of-bounds array access", " - Linux 5.15.209", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46275", " - Bluetooth: hci_uart: fix UAFs and race conditions in close and init", " paths", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-23141", " - KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory", " accesses", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43052", " - wifi: mac80211: check tdls flag in ieee80211_tdls_oper", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-22107", " - net: dsa: sja1105: fix kasan out-of-bounds warning in", " sja1105_table_delete_entry()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-21863", " - io_uring: prevent opcode speculation", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46274", " - io-wq: check that the predecessor is hashed in io_wq_remove_pending()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45846", " - bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45844", " - netfilter: arp_tables: fix IEEE1394 ARP payload parsing", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45843", " - slip: bound decode() reads against the compressed packet length", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45842", " - slip: reject VJ receive packets on instances with no rstate array", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45841", " - netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45840", " - openvswitch: cap upcall PID array size and pre-size vport replies", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46319", " - net/sched: act_ct: Only release RCU read lock after ct_ft", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45839", " - bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45838", " - bpf: fix end-of-list detection in cgroup_storage_get_next_key()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46214", " - vsock/virtio: fix accept queue count leak on transport mismatch", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46234", " - vsock: fix buffer size clamping order", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45836", " - Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46231", " - batman-adv: bla: put backbone reference on failed claim hash insert", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46233", " - batman-adv: bla: only purge non-released claims", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46212", " - batman-adv: bla: prevent use-after-free when deleting claims", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46238", " - batman-adv: stop caching unowned originator pointers in BAT IV", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46206", " - batman-adv: reject new tp_meter sessions during teardown", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46198", " - batman-adv: fix integer overflow on buff_pos", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46227", " - sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in", " SCTP_SENDALL", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46220", " - drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46197", " - drm/amdkfd: validate SVM ioctl nattr against buffer size", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46209", " - drm/gem: Fix inconsistent plane dimension calculation in", " drm_gem_fb_init_with_funcs()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46230", " - drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46219", " - spi: mpc52xx: fix use-after-free on unbind", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46236", " - media: rc: xbox_remote: heed DMA restrictions", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46205", " - staging: media: atomisp: Disallow all private IOCTLs", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46168", " - mptcp: fix scheduling with atomic in timestamp sockopt", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46189", " - RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46133", " - RDMA/rxe: Reject unknown opcodes before ICRC processing", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46127", " - RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46178", " - RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46112", " - RDMA/hns: Fix unlocked call to hns_roce_qp_remove()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46304", " - nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46161", " - md/raid10: fix divide-by-zero in setup_geo() with zero far_copies", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46124", " - isofs: validate block number from NFS file handle in isofs_export_iget", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46303", " - isofs: validate Rock Ridge CE continuation extent against volume size", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46294", " - dm: fix a buffer overflow in ioctl processing", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46107", " - dm-thin: fix metadata refcount underflow", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46301", " - spi: topcliff-pch: fix use-after-free on unbind", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46273", " - ibmveth: Disable GSO for packets with small MSS", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43502", " - net/rds: handle zerocopy send cleanup before the message is queued", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46120", " - ip6_gre: Use cached t->net in ip6erspan_changelink().", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46184", " - sound: ua101: fix division by zero at probe", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46132", " - net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in", " rtnl_fill_vfinfo", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46150", " - fanotify: fix false positive on permission events", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45834", " - Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45835", " - Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46186", " - Bluetooth: virtio_bt: validate rx pkt_type header length", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46123", " - Bluetooth: virtio_bt: clamp rx length before skb_put", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46172", " - ipv6: xfrm6: release dst on error in xfrm6_rcv_encap()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46146", " - ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46167", " - usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46151", " - usb: usblp: fix heap leak in IEEE 1284 device ID via short response", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46122", " - wifi: b43: enforce bounds check on firmware key index in b43_rx()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46307", " - wifi: ath5k: do not access array OOB", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46187", " - wifi: rsi: fix kthread lifetime race between self-exit and external-stop", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46163", " - wifi: b43legacy: enforce bounds check on firmware key index in RX path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46044", " - ipmi:ssif: Clean up kthread on errors", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43496", " - net/sched: sch_red: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-56727", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31489", " - spi: meson-spicc: Fix double-put in remove path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31476", " - ksmbd: do not expire session on binding failure", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43497", " - fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46108", " - ipmi:si: Return state to normal if message allocation fails", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46128", " - ipmi: Check event message buffer response for bad data", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46177", " - ipmi: Add limits to event and receive message requests", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46149", " - scsi: target: configfs: Bound snprintf() return in", " tg_pt_gp_members_show()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46101", " - netfilter: reject zero shift in nft_bitwise", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46099", " - net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46033", " - crypto: authencesn - reject short ahash digests during instance creation", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46062", " - ntfs3: fix integer overflow in run_unpack() volume boundary check", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46072", " - ntfs3: add buffer boundary checks to run_unpack()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46023", " - dm mirror: fix integer overflow in create_dirty_log()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46077", " - crypto: atmel-tdes - fix DMA sync direction", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45986", " - crypto: ccree - fix a memory leak in cc_mac_digest()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46019", " - crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46015", " - tcp: call sk_data_ready() after listener migration", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46040", " - inotify: fix watch count leak when fsnotify_add_inode_mark_locked()", " fails", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46070", " - md/raid5: validate payload size before accessing journal metadata", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46051", " - md/raid5: fix soft lockup in retry_aligned_read()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46046", " - ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46285", " - mtd: docg3: fix use-after-free in docg3_release()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46082", " - KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45987", " - KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46024", " - libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46037", " - ipv4: icmp: validate reply type before using icmp_pointers", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46027", " - net/smc: avoid early lgr access in smc_clc_wait_msg", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46053", " - net: rds: fix MR cleanup on copy error", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46004", " - ALSA: caiaq: Handle probe errors properly", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46050", " - md/raid10: fix deadlock with check operation and nowait requests", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46049", " - ALSA: ctxfi: Add fallback to default RSR for S/PDIF", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46002", " - ext2: reject inodes with zero i_nlink and valid mode in ext2_iget()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46047", " - net: qrtr: ns: Fix use-after-free in driver remove()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46009", " - PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46102", " - net: strparser: fix skb_head leak in strp_abort_strp()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46098", " - net: caif: clear client service pointer on teardown", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46088", " - ALSA: control: Validate buf_len before strnlen() in", " snd_ctl_elem_init_enum_names()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46080", " - ocfs2: split transactions in dio completion to avoid credit exhaustion", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-21739", " - scsi: ufs: core: Fix use-after free in init error and remove paths", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46064", " - ibmasm: fix heap over-read in ibmasm_send_i2o_message()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45994", " - ibmasm: fix OOB reads in command_file_write due to missing size checks", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46022", " - misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46006", " - drm/nouveau: fix u32 overflow in pushbuf reloc bounds check", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46018", " - ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31696", " - rxrpc: Fix missing validation of ticket length in non-XDR key preparsing", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31697", " - crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31698", " - crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command", " failed", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31699", " - crypto: ccp: Don't attempt to copy CSR to userspace if PSP command", " failed", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31701", " - ALSA: caiaq: take a reference on the USB device in create_card()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31694", " - fuse: reject oversized dirents in page cache", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31716", " - fs/ntfs3: validate rec->used in journal-replay file record check", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31676", " - rxrpc: only handle RESPONSE during service challenge", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31409", " - ksmbd: unset conn->binding on failed binding request", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-53596", " - drivers: base: Free devm resources when unregistering a device", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-50012", " - cpufreq: Avoid a bad reference count on CPU node", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38192", " - net: clear the dst when changing skb protocol", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-21712", " - md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43328", " - cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error", " path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23066", " - rxrpc: Fix recvmsg() unconditional requeue", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-50248", " - ntfs3: Add bounds checking to mi_enum_attr()", " - fs/ntfs3: Sequential field availability check in mi_enum_attr()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-27407", " - fs/ntfs3: Fixed overflow check in mi_enum_attr()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-45896", " - fs/ntfs3: Add more attributes checks in mi_enum_attr()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-52737", " - btrfs: lock the inode in shared mode before starting fiemap", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38626", " - f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-46770", " - ice: Add netif_device_attach/detach into PF reset flow", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38105", " - ALSA: usb-audio: Kill timer properly at removal", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-27389", " - pstore: inode: Only d_invalidate() is needed", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-52682", " - f2fs: fix to wait on block writeback for post_read case", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-56719", " - net: stmmac: fix TSO DMA API usage causing oops", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-41079", " - nvmet: always initialize cqe.result", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-53545", " - drm/amdgpu: unmap and remove csa_va properly", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-68239", " - binfmt_misc: restore write access before closing files opened by", " open_exec()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38659", " - gfs2: No more self recovery", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-49961", " - bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-47809", " - dlm: fix possible lkb_resource null dereference", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38250", " - Bluetooth: hci_core: Fix use-after-free in vhci_flush()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43281", " - mailbox: Prevent out-of-bounds access in of_mbox_index_xlate()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23157", " - btrfs: do not strictly require dirty metadata threshold for metadata", " writepages", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23141", " - btrfs: send: check for inline extents in range_is_hole_in_parent()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-40005", " - spi: cadence-quadspi: Implement refcount to handle unbind during busy", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-53629", " - fs: dlm: fix use after free in midcomms commit", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-71221", " - dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23204", " - net/sched: cls_u32: use skb_header_pointer_careful()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-71161", " - dm-verity: disable recursive forward error correction", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-50552", " - blk-mq: use quiesced elevator switch when reinitializing queues", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-36922", " - wifi: iwlwifi: read txq->read_ptr under lock", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-53221", " - f2fs: fix null-ptr-deref in f2fs_submit_page_bio()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-56657", " - ALSA: control: Avoid WARN() for symlink errors", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-49803", " - netdevsim: Fix memory leak of nsim_dev->fa_cookie", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-50116", " - tty: n_gsm: fix deadlock and link starvation in outgoing data path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31586", " - mm: blk-cgroup: fix use-after-free in cgwb_release_workfn()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31598", " - ocfs2: fix possible deadlock between unlink and dio_end_io_write", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31642", " - rxrpc: Fix call removal to use RCU safe deletion", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31664", " - xfrm: clear trailing padding in build_polexpire()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43075", " - ocfs2: fix out-of-bounds write in ocfs2_write_end_inline", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43076", " - ocfs2: validate inline data i_size during inode read", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23444", " - wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38710", " - gfs2: Validate i_depth for exhash directories", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23442", " - ipv6: add NULL checks for idev in SRv6 paths", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31594", " - PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-50073", " - net: tap: NULL pointer derefence in dev_parse_header_protocol when", " skb->dev is null", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31576", " - media: hackrf: fix to not free memory after the device is registered in", " hackrf_probe()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43058", " - media: vidtv: fix pass-by-value structs causing MSAN warnings", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31577", " - nilfs2: fix NULL i_assoc_inode dereference in", " nilfs_mdt_save_to_shadow_map", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31578", " - media: as102: fix to not free memory after the device is registered in", " as102_usb_probe()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31580", " - bcache: fix cached_dev.sb_bio use-after-free and crash", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31581", " - ALSA: 6fire: fix use-after-free on disconnect", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31583", " - media: em28xx: fix use-after-free in em28xx_v4l2_open()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31585", " - media: vidtv: fix nfeeds state corruption on start_streaming failure", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31686", " - mm/kasan: fix double free for kasan pXds", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31588", " - KVM: x86: Use scratch field in MMIO fragment to hold small write values", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31630", " - rxrpc: proc: size address buffers for %pISpc output", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23399", " - nf_tables: nft_dynset: fix possible stateful expression memleak in error", " path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-35865", " - smb: client: fix potential UAF in smb2_is_valid_oplock_break()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31590", " - KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31596", " - ocfs2: handle invalid dinode in ocfs2_group_extend", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31597", " - ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31599", " - media: vidtv: fix NULL pointer dereference in", " vidtv_channel_pmt_match_sections", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31602", " - ALSA: ctxfi: Limit PTP to a single page", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31603", " - staging: sm750fb: fix division by zero in ps_to_hz()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31605", " - fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31615", " - usb: gadget: renesas_usb3: validate endpoint index in standard request", " handlers", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31616", " - usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31617", " - usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31618", " - fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31619", " - ALSA: fireworks: bound device-supplied status before string array lookup", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31622", " - NFC: digital: Bounds check NFC-A cascade depth in SDD response handler", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31623", " - net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31624", " - HID: core: clamp report_size in s32ton() to avoid undefined shift", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31625", " - HID: alps: fix NULL pointer dereference in alps_raw_event()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31626", " - staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31627", " - i2c: s3c24xx: check the size of the SMBUS message before using it", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31532", " - can: raw: fix ro->uniq use-after-free in raw_rcv()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31629", " - nfc: llcp: add missing return after LLCP_CLOSED checks", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31407", " - netfilter: conntrack: add missing netlink policy validations", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43079", " - perf/x86/intel/uncore: Skip discovery table for offline dies", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43080", " - l2tp: Drop large packets with UDP encap", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31673", " - af_unix: read UNIX_DIAG_VFS data under unix_state_lock", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31681", " - netfilter: xt_multiport: validate range encoding in checkentry", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43085", " - netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43089", " - xfrm_user: fix info leak in build_mapping()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43093", " - xsk: tighten UMEM headroom validation to account for tailroom and min", " frame", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43098", " - nfc: s3fwrn5: allocate rx skb before consuming bytes", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43099", " - ipv4: icmp: fix null-ptr-deref in icmp_build_probe()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43103", " - net: lapbether: handle NETDEV_PRE_TYPE_CHANGE", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31684", " - net: sched: act_csum: validate nested VLAN headers", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43074", " - eventpoll: defer struct eventpoll free to RCU grace period", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43104", " - drm/vc4: Fix a memory leak in hang state error path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43105", " - drm/vc4: Fix memory leak of BO array in hang state", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43110", " - wifi: brcmfmac: validate bsscfg indices in IF events", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43111", " - HID: roccat: fix use-after-free in roccat_report_event", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43112", " - fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43113", " - wifi: wl1251: validate packet IDs before indexing tx_frames", " * Jammy update: v5.15.207 upstream stable release (LP: #2156629)", " - Buffer overflow in drivers/xen/sys-hypervisor.c", " - xen/privcmd: fix double free via VMA splitting", " - Linux 5.15.204", " - Linux 5.15.205", " - Linux 5.15.206", " - Linux 5.15.207", " * Jammy update: v5.15.207 upstream stable release (LP: #2156629) //", " CVE-2025-54518 // CVE-2026-46174", " - x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op", " cache", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550)", " - ARM: clean up the memset64() C wrapper", " - Revert \"UBUNTU: SAUCE: Fix skb_vlan_inet_prepare() usage\"", " - ip6_tunnel: Fix usage of skb_vlan_inet_prepare()", " - scsi: lpfc: Properly set WC for DPP mapping", " - scsi: ufs: core: Always initialize the UIC done completion", " - scsi: ufs: core: Move link recovery for hibern8 exit failure to", " wl_resume", " - ALSA: usb-audio: Cap the packet size pre-calculations", " - ALSA: usb-audio: Use inclusive terms", " - btrfs: fix incorrect key offset in error message in", " check_dev_extent_item()", " - memory: mtk-smi: Convert to platform remove callback returning void", " - ARM: OMAP2+: add missing of_node_put before break and return", " - ARM: omap2: Fix reference count leaks in omap_control_init()", " - scsi: ata: Call scsi_done() directly", " - ata: libata-scsi: drop DPRINTK calls for cdb translation", " - ata: libata: remove pointless VPRINTK() calls", " - ata: libata-scsi: refactor ata_scsi_translate()", " - drm/tegra: dsi: fix device leak on probe", " - mfd: qcom-pm8xxx: switch away from using chained IRQ handlers", " - mfd: qcom-pm8xxx: Convert to platform remove callback returning void", " - mfd: qcom-pm8xxx: Fix OF populate on driver rebind", " - mfd: omap-usb-host: Convert to platform remove callback returning void", " - mfd: omap-usb-host: Fix OF populate on driver rebind", " - clk: tegra: tegra124-emc: fix device leak on set_rate()", " - usb: cdns3: remove redundant if branch", " - usb: cdns3: call cdns_power_is_lost() only once in cdns_resume()", " - ALSA: hda/conexant: Add quirk for HP ZBook Studio G4", " - hwmon: (max16065) Use READ/WRITE_ONCE to avoid compiler optimization", " induced race", " - fbcon: Use delayed work for cursor", " - fbcon: Extract fbcon_open/release helpers", " - fbcon: move more common code into fb_open()", " - ALSA: hda/conexant: Fix headphone jack handling on Acer Swift SF314", " - net: arcnet: com20020-pci: fix support for 2.5Mbit cards", " - eventpoll: Fix integer overflow in ep_loop_check_proc()", " - platform/x86: dell-wmi: Add audio/mic mute key codes", " - selftests: mptcp: more stable simult_flows tests", " - platform/x86: thinkpad_acpi: Fix errors reading battery thresholds", " - net: ethernet: ti: am65-cpsw-nuss/cpsw-ale: Fix multicast entry handling", " in ALE table", " - net: dpaa2: replace dpaa2_mac_is_type_fixed() with", " dpaa2_mac_is_type_phy()", " - net: dpaa2-switch: assign port_priv->mac after dpaa2_mac_connect() call", " - net: dpaa2-switch replace direct MAC access with", " dpaa2_switch_port_has_mac()", " - net: dpaa2-switch: serialize changes to priv->mac with a mutex", " - dpaa2-switch: do not clear any interrupts automatically", " - dpaa2-switch: Fix interrupt storm after receiving bad if_id in IRQ", " handler", " - indirect_call_wrapper: do not reevaluate function pointer", " - xen/acpi-processor: fix _CST detection using undersized evaluation", " buffer", " - amd-xgbe: fix sleep while atomic on suspend/resume", " - net: nfc: nci: Fix zero-length proprietary notifications", " - nfc: nci: clear NCI_DATA_EXCHANGE before calling completion callback", " - net: stmmac: Fix error handling in VLAN add and delete paths", " - ACPI: PM: Save NVS memory on Lenovo G70-35", " - ACPI: OSI: Add DMI quirk for Acer Aspire One D255", " - scsi: ses: Fix devices attaching to different hosts", " - ALSA: usb-audio: Avoid implicit feedback mode on DIYINHK USB Audio 2.0", " - ALSA: usb-audio: Check max frame size for implicit feedback mode, too", " - powerpc/uaccess: Fix inline assembly for clang build on PPC32", " - remoteproc: sysmon: Correct subsys_name_len type in QMI request", " - remoteproc: mediatek: Unprepare SCP clock during system suspend", " - powerpc: 83xx: km83xx: Fix keymile vendor prefix", " - bonding: handle BOND_LINK_FAIL, BOND_LINK_BACK as valid link states", " - ASoC: soc-core: drop delayed_work_pending() check before flush", " - ASoC: soc-core: accept zero format at snd_soc_runtime_set_dai_fmt()", " - ASoC: core: Exit all links before removing their components", " - ASoC: core: Do not call link_exit() on uninitialized rtd objects", " - can: hi311x: hi3110_open(): add check for hi3110_power_enable() return", " value", " - regulator: pca9450: Make IRQ optional", " - regulator: pca9450: Correct interrupt type", " - sched: idle: Make skipping governor callbacks more consistent", " - i40e: fix src IP mask checks and memcpy argument names in cloud filter", " - ACPI: OSL: fix __iomem type on return from acpi_os_map_generic_address()", " - ASoC: detect empty DMI strings", " - octeontx2-af: devlink: fix NIX RAS reporter recovery condition", " - net: usb: lan78xx: fix silent drop of packets with checksum errors", " - net: usb: lan78xx: skip LTM configuration for LAN7850", " - usb/core/quirks: Add Huawei ME906S-device to wakeup quirk", " - usb: misc: uss720: properly clean up reference in uss720_probe()", " - usb: core: don't power off roothub PHYs if phy_set_mode() fails", " - usb: cdc-acm: Restore CAP_BRK functionnality to CH343", " - USB: usbcore: Introduce usb_bulk_msg_killable()", " - usb: mdc800: handle signal and read racing", " - mm/tracing: rss_stat: ensure curr is false from kthread context", " - mmc: mmci: Fix device_node reference leak in of_get_dml_pipe_index()", " - libceph: reject preamble if control segment is empty", " - libceph: admit message frames only in CEPH_CON_S_OPEN state", " - time: add kernel-doc in time.c", " - time/jiffies: Mark jiffies_64_to_clock_t() notrace", " - device property: Allow secondary lookup in fwnode_get_next_child_node()", " - irqchip/gic-v3-its: Limit number of per-device MSIs to the range the ITS", " supports", " - net: mana: Ring doorbell at 4 CQ wraparounds", " - ice: fix retry for AQ command 0x06EE", " - parisc: Increase initial mapping to 64 MB with KALLSYMS", " - parisc: Fix initial page table creation for boot", " - net: ethernet: arc: emac: quiesce interrupts before requesting IRQ", " - tracing: Fix trace_buf_size= cmdline parameter with sizes >= 2G", " - lib/bootconfig: fix off-by-one in xbc_verify_tree() unclosed brace error", " - lib/bootconfig: fix snprintf truncation check in", " xbc_node_compose_key_after()", " - lib/bootconfig: check bounds before writing in __xbc_open_brace()", " - btrfs: abort transaction on failure to update root in the received", " subvol ioctl", " - iio: dac: ds4424: reject -128 RAW value", " - iio: chemical: sps30_serial: fix buffer size in sps30_serial_read_meas()", " - iio: potentiometer: mcp4131: fix double application of wiper shift", " - iio: chemical: bme680: Fix measurement wait duration calculation", " - iio: gyro: mpu3050-i2c: fix pm_runtime error handling", " - iio: imu: inv_icm42600: fix odr switch to the same value", " - i3c: mipi-i3c-hci: Use ETIMEDOUT instead of ETIME for timeout errors", " - i3c: mipi-i3c-hci: Restart DMA ring correctly after dequeue abort", " - i3c: mipi-i3c-hci: Add missing TID field to no-op command descriptor", " - l2tp: do not use sock_hold() in pppol2tp_session_get_sock()", " - mmc: sdhci-pci-gli: fix GL9750 DMA write corruption", " - mmc: sdhci: fix timing selection for 1-bit bus width", " - mtd: rawnand: pl353: make sure optimal timings are applied", " - mtd: rawnand: cadence: Fix error check for dma_alloc_coherent() in", " cadence_nand_init()", " - iommu/vt-d: Fix intel iommu iotlb sync hardlockup and retry", " - serial: 8250_pci: add support for the AX99100", " - serial: 8250: Add late synchronize_irq() to shutdown to handle DW UART", " BUSY", " - serial: uartlite: fix PM runtime usage count underflow on probe", " - drm/radeon: apply state adjust rules to some additional HAINAN vairants", " - mm/hugetlb: make detecting shared pte more reliable", " - mm/hugetlb: fix copy_hugetlb_page_range() to use ->pt_share_count", " - mm/hugetlb: fix two comments related to huge_pmd_unshare()", " - mm/rmap: fix two comments related to huge_pmd_unshare()", " - mm/hugetlb: fix excessive IPI broadcasts when unsharing PMD tables using", " mmu_gather", " - net: stmmac: dwmac-loongson: Set clk_csr_i to 100-150MHz", " - net: Handle napi_schedule() calls from non-interrupt", " - ext4: always allocate blocks only from groups inode can use", " - wifi: cfg80211: move scan done work to wiphy work", " - drm/amd/display: Use GFP_ATOMIC in dc_create_stream_for_sink", " - mptcp: pm: avoid sending RM_ADDR over same subflow", " - btrfs: tree-checker: fix misleading root drop_level error message", " - of: Add cleanup.h based auto release via __free(device_node) markings", " - firmware: arm_scpi: Fix device_node reference leak in probe path", " - Bluetooth: LE L2CAP: Disconnect if received packet's SDU exceeds IMTU", " - Bluetooth: LE L2CAP: Disconnect if sum of payload sizes exceed SDU", " - Bluetooth: SMP: make SM/PER/KDU/BI-04-C happy", " - Bluetooth: qca: fix ROM version reading on WCN3998 chips", " - netfilter: xt_time: use unsigned int for monthday bit shift", " - net: bcmgenet: increase WoL poll timeout", " - net: mana: Improve the HWC error handling", " - sched: idle: Consolidate the handling of two special cases", " - igc: fix missing update of skb->tail in igc_xmit_frame()", " - wifi: wlcore: Return -ENOMEM instead of -EAGAIN if there is not enough", " headroom", " - ACPI: processor: Fix previous acpi_processor_errata_piix4() fix", " - net: macb: fix uninitialized rx_fs_lock", " - net: dsa: bcm_sf2: fix missing clk_disable_unprepare() in error paths", " - hwmon: (pmbus/isl68137) Fix unchecked return value and use sysfs_emit()", " - i2c: fsi: Fix a potential leak in fsi_i2c_probe()", " - mtd: rawnand: brcmnand: skip DMA during panic write", " - lib/bootconfig: check xbc_init_node() return in override path", " - tools/bootconfig: fix fd leak in load_xbc_file() on fstat failure", " - sh: platform_early: remove pdev->driver_override check", " - bpf: Release module BTF IDR before module unload", " - platform/x86: intel-hid: Add Dell 14 Plus 2-in-1 to dmi_vgbs_allow_list", " - nvme-pci: cap queue creation to used queues", " - platform/x86: intel-hid: Enable 5-button array on ThinkPad X1 Fold 16", " Gen 1", " - platform/x86: touchscreen_dmi: Add quirk for y-inverted Goodix", " touchscreen on SUPI S10", " - HID: magicmouse: fix battery reporting for Apple Magic Trackpad 2", " - net: usb: r8152: add TRENDnet TUC-ET2G", " - HID: mcp2221: cancel last I2C command on read error", " - ASoC: fsl_easrc: Fix event generation in fsl_easrc_iec958_set_reg()", " - ASoC: fsl_easrc: Fix event generation in fsl_easrc_iec958_put_bits()", " - dma-buf: Include ioctl.h in UAPI header", " - ALSA: hda/realtek: Add headset jack quirk for Thinkpad X390", " - xfrm: call xdo_dev_state_delete during state update", " - xfrm: Fix the usage of skb->sk", " - can: statistics: add missing atomic access in hot path", " - pinctrl: mediatek: common: Fix probe failure for devices without EINT", " - ionic: fix persistent MAC address override on PF", " - rtnetlink: count IFLA_INFO_SLAVE_KIND in if_nlmsg_size", " - platform/olpc: olpc-xo175-ec: Fix overflow error message to print inlen", " - net: enetc: fix the output issue of 'ethtool --show-ring'", " - dma-mapping: add missing `inline` for `dma_free_attrs`", " - netlink: introduce NLA_POLICY_MAX_BE", " - netfilter: nft_payload: reject out-of-range attributes via policy", " - netlink: hide validation union fields from kdoc", " - netlink: introduce bigendian integer types", " - netlink: allow be16 and be32 types in all uint policy checks", " - regmap: Synchronize cache for the page selector", " - RDMA/rw: Fall back to direct SGE on MR pool exhaustion", " - RDMA/irdma: Update ibqp state to error if QP is already in error state", " - RDMA/irdma: Remove a NOP wait_event() in irdma_modify_qp_roce()", " - RDMA/irdma: Clean up unnecessary dereference of event->cm_node", " - RDMA/irdma: Remove reset check from irdma_modify_qp_to_err()", " - RDMA/irdma: Return EINVAL for invalid arp index error", " - scsi: scsi_transport_sas: Fix the maximum channel scanning issue", " - x86/efi: efi_unmap_boot_services: fix calculation of ranges_to_free size", " - drm/i915/gmbus: fix spurious timeout on 512-byte burst reads", " - ASoC: Intel: catpt: Fix the device initialization", " - ACPICA: include/acpi/acpixf.h: Fix indentation", " - ACPICA: Allow address_space_handler Install and _REG execution as 2", " separate steps", " - ACPI: EC: Fix EC address space handler unregistration", " - ACPI: EC: Fix ECDT probe ordering issues", " - hwmon: (adm1177) fix sysfs ABI violation and current unit conversion", " - sysctl: fix uninitialized variable in proc_do_large_bitmap", " - ASoC: adau1372: Fix unchecked clk_prepare_enable() return value", " - ASoC: adau1372: Fix clock leak on PLL lock failure", " - s390/barrier: Make array_index_mask_nospec() __always_inline", " - cpufreq: conservative: Reset requested_freq on limits change", " - alarmtimer: Fix argument order in alarm_timer_forward()", " - scsi: ses: Handle positive SCSI error from ses_recv_diag()", " - jbd2: gracefully abort on checkpointing state corruptions", " - ext4: make recently_deleted() properly work with lazy itable", " initialization", " - phy: ti: j721e-wiz: Fix device node reference leak in", " wiz_get_lane_phy_types()", " - dmaengine: xilinx: xilinx_dma: Fix dma_device directions", " - dmaengine: xilinx: xilinx_dma: Fix residue calculation for cyclic DMA", " - dmaengine: xilinx: xilinx_dma: Fix unmasked residue subtraction", " - btrfs: fix super block offset in error message in btrfs_validate_super()", " - btrfs: fix lost error when running device stats on multiple devices fs", " - dmaengine: idxd: Remove usage of the deprecated ida_simple_xx() API", " - dmaengine: idxd: Fix freeing the allocated ida too late", " - dmaengine: xilinx_dma: Program interrupt delay timeout", " - dmaengine: xilinx_dma: Fix reset related timeout with two-channel AXIDMA", " - btrfs: don't take device_list_mutex when querying zone info", " - objtool: Fix Clang jump table detection", " - dt-bindings: auxdisplay: ht16k33: Use unevaluatedProperties to fix", " common property warning", " - tg3: Fix race for querying speed/duplex", " - net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec", " - netfilter: ipset: use nla_strcmp for IPSET_ATTR_NAME attr", " - net/mlx5: Avoid \"No data available\" when FW version queries fail", " - net: hsr: fix VLAN add unwind on slave errors", " - hwmon: (pxe1610) Check return value of page-select write in probe", " - hwmon: (tps53679) Fix device ID comparison and printing in", " tps53676_identify()", " - hwmon: (occ) Fix missing newline in occ_show_extended()", " - riscv: kgdb: fix several debug register assignment bugs", " - USB: serial: option: add MeiG Smart SRM825WN", " - MIPS: Fix the GCC version check for `__multi3' workaround", " - drm/ast: dp501: Fix initialization of SCU2C", " - USB: serial: io_edgeport: add support for Blackbox IC135A", " - USB: serial: option: add support for Rolling Wireless RW135R-GL", " - USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam", " - Input: synaptics-rmi4 - fix a locking bug in an error path", " - Input: i8042 - add TUXEDO InfinityBook Max 16 Gen10 AMD to i8042 quirk", " table", " - Input: xpad - add support for Razer Wolverine V3 Pro", " - iio: dac: ad5770r: fix error return in ad5770r_read_raw()", " - iio: light: vcnl4035: fix scan buffer on big-endian", " - iio: imu: st_lsm6dsx: Set FIFO ODR for accelerometer and gyroscope only", " - iio: gyro: mpu3050: Fix out-of-sequence free_irq()", " - usb: quirks: add DELAY_INIT quirk for another Silicon Motion flash drive", " - usb: ehci-brcm: fix sleep during atomic", " - nvmet-tcp: fix use-before-check of sg in bounds validation", " - phy: renesas: rcar-gen3-usb2: Fix role detection on unbind/bind", " - phy: renesas: rcar-gen3-usb2: Move IRQ request in probe", " - phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver", " data", " - phy: renesas: rcar-gen3-usb2: Assert PLL reset on PHY power off", " - cdc-acm: new quirk for EPSON HMD", " - thunderbolt: Fix property read in nhi_wake_supported()", " - usb: gadget: dummy_hcd: fix premature URB completion when ZLP follows", " partial transfer", " - can: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on", " usb_submit_urb() error", " - can: gs_usb: gs_usb_receive_bulk_callback(): fix error message", " - Input: uinput - take event lock when submitting FF request \"event\"", " - media: uvcvideo: Use heuristic to find stream entity", " - arm64: dts: hisilicon: poplar: Correct PCIe reset GPIO polarity", " - arm64: dts: hisilicon: hi3798cv200: Add missing dma-ranges", " - net: qualcomm: qca_uart: report the consumed byte on RX skb allocation", " failure", " - rxrpc: Fix key/keyring checks in setsockopt(RXRPC_SECURITY_KEY/KEYRING)", " - netlink: add nla be16/32 types to minlen array", " - xen/privcmd: unregister xenstore notifier on module exit", " - Revert \"mptcp: add needs_id for netlink appending addr\"", " - ext4: fix the might_sleep() warnings in kvfree()", " - dmaengine: sh: rz-dmac: Move CHCTRL updates under spinlock", " - dmaengine: sh: rz-dmac: Protect the driver specific lists", " - net: macb: Move devm_{free,request}_irq() out of spin lock area", " - x86/cpu: Enable FSGSBASE early in cpu_init_exception_handling()", " - i2c: cp2615: replace deprecated strncpy with strscpy", " - io_uring/poll: correctly handle io_poll_add() return value on update", " - Linux 5.15.203", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-71150", " - ksmbd: Fix refcount leak when invalid session is found on session lookup", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23395", " - Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31549", " - i2c: cp2615: fix serial string NULL-deref at probe", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31433", " - ksmbd: fix potencial OOB in get_file_all_info() for compound requests", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31480", " - tracing: Fix potential deadlock in cpu hotplug with osnoise", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31466", " - mm/huge_memory: fix folio isn't locked in softleaf_to_folio()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43054", " - scsi: target: tcm_loop: Drain commands in target_reset handler", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23401", " - KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO", " SPTE", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31454", " - xfs: save ailp before dropping the AIL lock in push callbacks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31446", " - ext4: fix use-after-free in update_super_work when racing with umount", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31450", " - ext4: publish jinode after initialization", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31726", " - usb: gadget: uvc: fix NULL pointer dereference during unbind race", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31728", " - usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31721", " - usb: gadget: f_hid: move list and spinlock inits from bind to alloc", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31670", " - net: rfkill: prevent unlimited numbers of rfkill events from being", " created", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31634", " - rxrpc: fix reference count leak in rxrpc_server_keyring()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31651", " - mmc: vub300: fix NULL-deref on disconnect", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31656", " - drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31658", " - net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31660", " - nfc: pn533: allocate rx skb before consuming bytes", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31661", " - wifi: brcmsmac: Fix dma_free_coherent() size", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31662", " - tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31665", " - netfilter: nft_ct: fix use-after-free in timeout object destroy", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2024-56557", " - iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2024-36898", " - gpiolib: cdev: fix uninitialised kfifo", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-40016", " - media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31667", " - Input: uinput - fix circular locking dependency with ff-core", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31671", " - xfrm_user: fix info leak in build_report()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31672", " - wifi: rt2x00usb: fix devres lifetime", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43336", " - lib/crypto: chacha: Zeroize permuted_state before it leaves scope", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31695", " - wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2024-56584", " - io_uring/tctx: work around xa_store() allocation error issue", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31720", " - usb: gadget: f_uac1_legacy: validate control request size", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43342", " - usb: gadget: f_rndis: Protect RNDIS options with mutex", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43343", " - usb: gadget: f_subset: Fix unbalanced refcnt in geth_free", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-68256", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-40103", " - smb: client: Fix refcount leak for cifs_sb_tlink", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-38006", " - net: mctp: Don't access ifa_index when missing", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-40323", " - fbcon: Set fb_display[i]->mode to NULL when the mode is released", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23031", " - can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43324", " - USB: dummy-hcd: Fix interrupt synchronization error", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43327", " - USB: dummy-hcd: Fix locking/synchronization error", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31737", " - net: ftgmac100: fix ring allocation unwind on open failure", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31738", " - vxlan: validate ND option lengths in vxlan_na_create", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31747", " - comedi: me4000: Fix potential overrun of firmware buffer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31748", " - comedi: me_daq: Fix potential overrun of firmware buffer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31749", " - comedi: ni_atmio16d: Fix invalid clean-up after failed attach", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43340", " - comedi: Reinit dev->spinlock between attachments to low-level drivers", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31751", " - comedi: dt2815: add hardware detection to prevent crash", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31752", " - bridge: br_nd_send: validate ND option lengths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31754", " - usb: cdns3: gadget: fix state inconsistency on gadget init failure", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31755", " - usb: cdns3: gadget: fix NULL pointer dereference in ep_queue", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31756", " - usb: dwc2: gadget: Fix spin_lock/unlock mismatch in", " dwc2_hsotg_udc_stop()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31758", " - usb: usbtmc: Flush anchored URBs in usbtmc_release", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31759", " - usb: ulpi: fix double free in ulpi_register_interface() error path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31761", " - iio: gyro: mpu3050: Move iio_device_register() to correct location", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31762", " - iio: gyro: mpu3050: Fix irq resource leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31763", " - iio: gyro: mpu3050: Fix incorrect free_irq() variable", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31770", " - hwmon: (occ) Fix division by zero in occ_show_power_1()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43334", " - Bluetooth: SMP: force responder MITM requirements before building the", " pairing response", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31773", " - Bluetooth: SMP: derive legacy responder STK authentication from MITM", " state", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31776", " - ALSA: ctxfi: Fix missing SPDIFI1 index handling", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31778", " - ALSA: caiaq: fix stack out-of-bounds read in init_card", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31780", " - wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31781", " - drm/ioc32: stop speculation on the drm_compat_ioctl path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43333", " - bpf: reject direct access to nullable PTR_TO_BUF pointers", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31415", " - ipv6: avoid overflows in ip6_datagram_send_ctl()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31422", " - net/sched: cls_flow: fix NULL pointer dereference on shared blocks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31421", " - net/sched: cls_fw: fix NULL pointer dereference on shared blocks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31417", " - net/x25: Fix overflow when accumulating packets", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43014", " - net: macb: properly unregister fixed rate clocks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43015", " - net: macb: fix clk handling on PCI glue driver removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31425", " - rds: ib: reject FRMR registration before IB connection is established", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43020", " - Bluetooth: MGMT: validate LTK enc_size on load", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43024", " - netfilter: nf_tables: reject immediate NF_QUEUE verdict", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31424", " - netfilter: x_tables: restrict xt_check_match/xt_check_target extensions", " for NFPROTO_ARP", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43026", " - netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43027", " - netfilter: nf_conntrack_helper: pass helper to expect cleanup", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43028", " - netfilter: x_tables: ensure names are nul-terminated", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31416", " - netfilter: nfnetlink_log: account for netlink header size", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43329", " - netfilter: flowtable: strictly check for maximum number of actions", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31680", " - net: ipv6: flowlabel: defer exclusive option free until RCU teardown", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43030", " - bpf: Fix regsafe() for pointers to packet", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43032", " - NFC: pn533: bound the UART receive buffer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43035", " - net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to", " zero to prevent an info-leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43339", " - ipv6: prevent possible UaF in addrconf_permanent_addr()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31423", " - net/sched: sch_hfsc: fix divide-by-zero in rtsc_min()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43040", " - net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX", " fields to zero to prevent an info-leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43041", " - net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory", " leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43043", " - crypto: af-alg - fix NULL pointer dereference in scatterwalk", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43046", " - btrfs: reject root items with drop_progress and zero drop_level", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43047", " - HID: multitouch: Check to ensure report responses match the request", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43050", " - atm: lec: fix use-after-free in sock_def_readable()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43051", " - HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31555", " - futex: Clear stale exiting pointer in futex_lock_pi() retry path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43065", " - ext4: always drain queued discard work in ext4_mb_release()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43066", " - ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31447", " - ext4: reject mount if bigalloc with s_first_data_block != 0", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43068", " - ext4: avoid allocate block from corrupted group in", " ext4_mb_find_by_goal()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31452", " - ext4: convert inline data to extents when truncate exceeds inline size", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31455", " - xfs: stop reclaim before pushing AIL during unmount", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31464", " - scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31467", " - erofs: add GFP_NOIO in the bio completion if needed", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31469", " - virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and", " napi_tx is false", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31473", " - media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31570", " - can: gw: fix OOB heap access in cgw_csum_crc8_rel()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31483", " - s390/syscalls: Add spectre boundary for syscall dispatch table", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31485", " - spi: spi-fsl-lpspi: fix teardown order issue (UAF)", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31565", " - RDMA/irdma: Fix deadlock during netdev reset with active connections", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31494", " - net: macb: use the current queue number for stats", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31495", " - netfilter: ctnetlink: use netlink policy range checks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31427", " - netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in", " process_sdp", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31674", " - netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31428", " - netfilter: nfnetlink_log: fix uninitialized padding leak in", " NFULA_PAYLOAD", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31497", " - Bluetooth: btusb: clamp SCO altsetting table indices", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31498", " - Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31507", " - net/smc: fix double-free of smc_spd_priv when tee() duplicates splice", " pipe buffer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31679", " - openvswitch: validate MPLS set/set_masked payload length", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31508", " - net: openvswitch: Avoid releasing netdev before teardown completes", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31509", " - nfc: nci: fix circular locking dependency in nci_close_device", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31510", " - Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43069", " - Bluetooth: hci_ll: Fix firmware leak on error path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31408", " - Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing", " sock_hold", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31512", " - Bluetooth: L2CAP: Validate PDU length before reading SDU length in", " l2cap_ecred_data_rcv()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31515", " - af_key: validate families in pfkey_send_migrate()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31518", " - esp: fix skb leak with espintcp and async crypto", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31521", " - module: Fix kernel panic when a symbol st_shndx is out of bounds", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31522", " - HID: magicmouse: avoid memory leak in magicmouse_report_fixup()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31523", " - nvme-pci: ensure we're polling a polled queue", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31524", " - HID: asus: avoid memory leak in asus_report_fixup()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31788", " - xen/privcmd: restrict usage in unprivileged domU", " - xen/privcmd: add boot control for restricted usage in domU", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31540", " - drm/i915/gt: Check set_default_submission() before deferencing", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23434", " - mtd: rawnand: serialize lock/unlock against other NAND operations", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23398", " - icmp: fix NULL pointer dereference in icmp_tag_validation()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23438", " - net: mvpp2: guard flow control update with global_tx_fc in buffer", " switching", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23397", " - nfnetlink_osf: validate individual option lengths in fingerprints", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31546", " - net: bonding: fix NULL deref in bond_debug_rlb_hash_show", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23439", " - udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23396", " - wifi: mac80211: fix NULL deref in mesh_matches_local()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23446", " - net: usb: aqc111: Do not perform PM inside suspend callback", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23452", " - PM: runtime: Fix a race condition related to device removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23454", " - net: mana: fix use-after-free in mana_hwc_destroy_channel() by", " reordering teardown", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23391", " - netfilter: xt_CT: drop pending enqueued packets on template removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43060", " - netfilter: nft_ct: drop pending enqueued packets on removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-68206", " - netfilter: nft_ct: add seqadj extension for natted connections", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23456", " - netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23457", " - netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in", " sip_help_tcp()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23458", " - netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-39764", " - netfilter: ctnetlink: remove refcounting in expectation dumpers", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23460", " - net/rose: fix NULL pointer dereference in rose_transmit_link on", " reconnect", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23462", " - Bluetooth: HIDP: Fix possible UAF", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31551", " - wifi: mac80211: Fix static_branch_dec() underflow for aql_disable.", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23463", " - soc: fsl: qbman: fix race condition in qman_destroy_fq", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31683", " - batman-adv: avoid OGM aggregation when skb tailroom is insufficient", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31550", " - pmdomain: bcm: bcm2835-power: Increase ASB control timeout", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23368", " - net: phy: register phy led_triggers during probe to avoid AB-BA deadlock", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23303", " - smb: client: Don't log plaintext credentials in cifs_set_cifscreds", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23335", " - RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23336", " - wifi: cfg80211: cancel rfkill_block work in wiphy_unregister()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23281", " - wifi: libertas: fix use-after-free in lbs_free_adapter()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-38562", " - ksmbd: fix null pointer dereference error in generate_encryptionkey", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45920", " - ext4: fix dirtyclusters double decrement on fs shutdown", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45899", " - ext4: drop extent cache when splitting extent fails", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45985", " - ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting", " I/O", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45924", " - ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23227", " - drm/exynos: vidi: use ctx->lock to protect struct vidi_context member", " variables related to memory alloc/free", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45958", " - drm/exynos: vidi: fix to avoid directly dereferencing user pointer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45956", " - drm/exynos: vidi: use priv->vidi_dev for ctx lookup in", " vidi_connection_ioctl()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23100", " - mm/hugetlb: fix hugetlb_pmd_shared()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43061", " - serial: 8250: Fix TX deadlock when using DMA", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23474", " - mtd: Avoid boot crash in RedBoot partition table parser", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31393", " - Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43062", " - Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31396", " - net: macb: fix use-after-free access to PTP clock", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31545", " - NFC: nxp-nci: allow GPIOs to sleep", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31399", " - nvdimm/bus: Fix potential use after free in asynchronous initialization", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31400", " - sunrpc: fix cache_request leak in cache_release", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2024-46715", " - driver: iio: add missing checks on iio_info's callback access", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23113", " - io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-39748", " - bpf: Forget ranges when refining tnum after JSET", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43357", " - iio: gyro: mpu3050-core: fix pm_runtime error handling", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43476", " - iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43363", " - x86/apic: Disable x2apic on resume if the kernel expects so", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43365", " - xfs: fix undersized l_iclog_roundoff values", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43370", " - drm/amdgpu: Fix use-after-free race in VM acquire", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43373", " - net: ncsi: fix skb leak in error paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43380", " - hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43381", " - nouveau/dpcd: return EBUSY for aux xfer if the device is asleep", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43382", " - batman-adv: Avoid double-rtnl_lock ELP metric worker", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31405", " - media: dvb-net: fix OOB access in ULE extension header tables", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43387", " - staging: rtl8723bs: properly validate the data in rtw_get_ie_ex()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43386", " - staging: rtl8723bs: fix potential out-of-bounds read in", " rtw_restruct_wmm_ie", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43420", " - ceph: fix i_nlink underrun during async unlink", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43405", " - libceph: Use u32 for non-negative values in ceph_monmap_decode()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43411", " - tipc: fix divide-by-zero in tipc_sk_filter_connect()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43484", " - mmc: core: Avoid bitfield RMW for claim/retune flags", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43425", " - usb: image: mdc800: kill download URB on timeout", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43426", " - usb: renesas_usbhs: fix use-after-free in ISR during device removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43427", " - usb: class: cdc-wdm: fix reordering issue in read code path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43428", " - USB: core: Limit the length of unkillable synchronous timeouts", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43429", " - USB: usbtmc: Use usb_bulk_msg_killable() with user-specified timeouts", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43430", " - usb: yurex: fix race in probe", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43432", " - usb: xhci: Fix memory leak in xhci_disable_slot()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43439", " - cgroup: fix race between task migration and iteration", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43480", " - ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock", " acquisition", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43445", " - e1000/e1000e: Fix leak in DMA error cleanup", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43449", " - nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_set", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43450", " - netfilter: nfnetlink_cthelper: fix OOB read in", " nfnl_cthelper_dump_table()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43451", " - netfilter: nfnetlink_queue: fix entry leak in bridge verdict error path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43452", " - netfilter: x_tables: guard option walkers against 1-byte tail reads", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43453", " - netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43458", " - serial: caif: hold tty->link reference in ldisc_open and ser_release", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43459", " - ASoC: soc-core: flush delayed work before removing DAIs and widgets", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23277", " - net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL", " slave xmit", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43466", " - net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43469", " - xprtrdma: Decrement re_receiving on the early exit paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-54505 // CVE-2026-31628", " - x86/CPU: Fix FPDSS on Zen1", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43472", " - unshare: fix unshare_fs() handling", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43473", " - scsi: mpi3mr: Add NULL checks when resetting request and reply queues", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43475", " - scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23270", " - net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared", " blocks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23300", " - net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23293", " - net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23381", " - net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23372", " - nfc: rawsock: cancel tx_work before socket teardown", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23339", " - nfc: nci: free skb on nci_transceive early error paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23340", " - net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless", " qdiscs", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23304", " - ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23420", " - wifi: wlcore: Fix a locking bug", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23357", " - can: mcp251x: fix deadlock in error path of mcp251x_open", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23362", " - can: bcm: fix locking for bcm_op runtime updates", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23286", " - atm: lec: fix null-ptr-deref in lec_arp_clear_vccs", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23296", " - scsi: core: Fix refcount leak for tagset_refcnt", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23356", " - drbd: fix \"LOGIC BUG\" in drbd_al_begin_io_nonblock()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23388", " - Squashfs: check metadata block offset is within range", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23379", " - net/sched: ets: fix divide by zero in the offload path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23289", " - IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23279", " - wifi: mac80211: fix NULL pointer dereference in mesh_rx_csa_frame()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23367", " - wifi: radiotap: reject radiotap with unknown bits", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23318", " - ALSA: usb-audio: Use correct version for UAC3 header validation", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23370", " - platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23352", " - x86/efi: defer freeing of boot services memory", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23382", " - HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23324", " - can: usb: etas_es58x: correctly anchor the urb in the read bulk callback", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23298", " - can: ucan: Fix infinite loop from zero-length messages", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23307", " - can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a", " message", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23290", " - net: usb: pegasus: validate USB endpoints", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23365", " - net: usb: kalmia: validate USB endpoints", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23312", " - net: usb: kaweth: validate USB endpoints", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23291", " - nfc: pn533: properly drop the usb interface reference on disconnect", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23253", " - media: dvb-core: fix wrong reinitialization of ringbuffer on reopen", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43123", " - fbcon: check return value of con2fb_acquire_newinfo()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23220", " - ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error", " paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45911", " - usb: cdns3: fix role switching during resume", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-71287", " - memory: mtk-smi: fix device leak on larb probe", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23359", " - bpf: Fix stack-out-of-bounds write in devmap", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272)", " - auxdisplay: arm-charlcd: fix release_mem_region() size", " - i3c: remove i2c board info from i2c_dev_desc", " - i3c: Move device name assignment after i3c_bus_init", " - fs: add for 'init_fs'", " - gfs2: Add metapath_dibh helper", " - btrfs: qgroup: return correct error when deleting qgroup relation item", " - md/raid10: fix any_working flag handling in raid10_sync_request", " - iomap: fix submission side handling of completion side errors", " - PM: wakeup: Handle empty list in wakeup_sources_walk_start()", " - PM: sleep: wakeirq: harden dev_pm_clear_wake_irq() against races", " - libbpf: Fix dumping big-endian bitfields", " - libbpf: Fix OOB read in btf_dump_get_bitfield_value", " - ARM: VDSO: Patch out __vdso_clock_getres() if unavailable", " - crypto: cavium - fix dma_free_coherent() size", " - crypto: octeontx - fix dma_free_coherent() size", " - hrtimer: Fix trace oddity", " - crypto: hisilicon/trng - modifying the order of header files", " - crypto: hisilicon/trng - support tfms sharing the device", " - scsi: efct: Use IRQF_ONESHOT and default primary handler", " - EDAC/altera: Remove IRQF_ONESHOT", " - mfd: wm8350-core: Use IRQF_ONESHOT", " - EDAC/i5000: Fix snprintf() size calculation in calculate_dimm_size()", " - EDAC/i5400: Fix snprintf() limit calculation in calculate_dimm_size()", " - clk: qcom: Return correct error code in qcom_cc_probe_by_index()", " - arm64: dts: qcom: sdm630: correct QFPROM byte offsets", " - arm64: dts: qcom: sdm630: fix gpu_speed_bin size", " - arm64: dts: qcom: sdm845-oneplus: Don't mark ts supply boot-on", " - ARM: dts: allwinner: sun5i-a13-utoo-p66: delete \"power-gpios\" property", " - powerpc/uaccess: Move barrier_nospec() out of", " allow_read_{from/write}_user()", " - soc: qcom: cmd-db: Use devm_memremap() to fix memory leak in", " cmd_db_dev_probe", " - ARM: dts: lpc32xx: Set motor PWM #pwm-cells property value to 3 cells", " - arm: dts: lpc32xx: add clocks property to Motor Control PWM device tree", " node", " - arm64: dts: amlogic: axg: assign the MMC signal clocks", " - arm64: dts: amlogic: gx: assign the MMC signal clocks", " - arm64: dts: amlogic: g12: assign the MMC B and C signal clocks", " - arm64: dts: amlogic: g12: assign the MMC A signal clock", " - arm64: dts: qcom: sdm845-db845c: specify power for WiFi CH1", " - smack: /smack/doi must be > 0", " - drm/amdgpu: Use explicit VCN instance 0 in SR-IOV init", " - regulator: core: move supply check earlier in set_machine_constraints()", " - media: ccs: Accommodate C-PHY into the calculation", " - media: uvcvideo: Fix allocation for small frame sizes", " - platform/chrome: cros_ec_lightbar: Fix response size initialization", " - spi: tools: Add include folder to .gitignore", " - PCI: mediatek: Fix IRQ domain leak when MSI allocation fails", " - PCI: Do not attempt to set ExtTag for VFs", " - PCI/portdrv: Fix potential resource leak", " - netfilter: nf_conncount: make nf_conncount_gc_list() to disable BH", " - PCI: Mark 3ware-9650SA Root Port Extended Tags as broken", " - tcp: tcp_tx_timestamp() must look at the rtx queue", " - wifi: ath10k: sdio: add missing lock protection in", " ath10k_sdio_fw_crashed_dump()", " - PCI: Initialize RCB from pci_configure_device()", " - ucount: check for CAP_SYS_RESOURCE using ns_capable_noaudit()", " - bonding: only set speed/duplex to unknown, if getting speed failed", " - netfilter: nft_set_hash: fix get operation on big endian", " - ethtool: add support to set/get tx copybreak buf size via ethtool", " - net: hns3: add support to set/get tx copybreak buf size via ethtool for", " hns3 driver", " - net: hns3: remove the way to set tx spare buf via module parameter", " - net: hns3: fix ethtool tx copybreak buf size indicating not aligned", " issue", " - net: hns3: add max order judgement for tx spare buffer", " - ionic: Rate limit unknown xcvr type messages", " - octeontx2-pf: Unregister devlink on probe failure", " - RDMA/rtrs: server: remove dead code", " - IB/cache: update gid cache on client reregister event", " - RDMA/hns: Notify ULP of remaining soft-WCs during reset", " - power: supply: ab8500_bmdata: Use standard phandle", " - power: supply: ab8500: Use core battery parser", " - power: reset: nvmem-reboot-mode: respect cell size for nvmem_cell_write", " - power: supply: bq27xxx: fix wrong errno when bus ops are unsupported", " - RDMA/rtrs-srv: Refactor the handling of failure case in map_cont_bufs", " - RDMA/rtrs-srv: Correct the checking of ib_map_mr_sg", " - RDMA/rtrs-srv: fix SG mapping", " - mtd: rawnand: cadence: Fix return type of CDMA send-and-wait helper", " - crypto: ccp - Add an S4 restore flow", " - RDMA/core: Fix a couple of obvious typos in comments", " - svcrdma: Remove queue-shortening warnings", " - svcrdma: Clean up comment in svc_rdma_accept()", " - svcrdma: Increase the per-transport rw_ctx count", " - svcrdma: Reduce the number of rdma_rw contexts per-QP", " - RDMA/core: add rdma_rw_max_sge() helper for SQ sizing", " - mtd: parsers: ofpart: fix OF node refcount leak in", " parse_fixed_partitions()", " - RDMA/uverbs: Add __GFP_NOWARN to ib_uverbs_unmarshall_recv() kmalloc", " - pNFS: fix a missing wake up while waiting on NFS_LAYOUT_DRAIN", " - nvdimm: virtio_pmem: serialize flush requests", " - tracing: Remove duplicate ENABLE_EVENT_STR and DISABLE_EVENT_STR macros", " - clk: qcom: rcg2: compute 2d using duty fraction directly", " - clk: meson: gxbb: Limit the HDMI PLL OD to /4 on GXL/GXM SoCs", " - clk: qcom: gcc-msm8953: Remove ALWAYS_ON flag from cpp_gdsc", " - clk: Move clk_{save,restore}_context() to COMMON_CLK section", " - clk: qcom: dispcc-sdm845: Enable parents for pixel clocks", " - dmaengine: mediatek: uart-apdma: Fix above 4G addressing TX/RX", " - dma: dma-axi-dmac: fix SW cyclic transfers", " - serial: imx: change SERIAL_IMX_CONSOLE to bool", " - serial: SH_SCI: improve \"DMA support\" prompt", " - mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms", " - coresight: etm3x: Fix cpulocked warning on cpuhp", " - Revert \"mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms\"", " - drivers: iio: mpu3050: use dev_err_probe for regulator request", " - usb: bdc: fix sleep during atomic", " - pinctrl: equilibrium: Fix device node reference leak in pinbank_init()", " - ovl: Fix uninit-value in ovl_fill_real", " - pinctrl: qcom: Update macro name to LPI specific", " - pinctrl: qcom: Update lpi pin group custiom functions with framework", " generic functions", " - pinctrl: qcom: Extract chip specific LPASS LPI code", " - [Config] Enable CONFIG_PINCTRL_SM8250_LPASS_LPI=m", " - pinctrl: qcom: sm8250-lpass-lpi: Fix i2s2_data_groups definition", " - backlight: qcom-wled: Support ovp values for PMI8994", " - ACPI: CPPC: Fix remaining for_each_possible_cpu() to use online CPUs", " - selftests: mlxsw: tc_restrictions: Fix test failure with new iproute2", " - net/rds: rds_sendmsg should not discard payload_len", " - selftests: forwarding: vxlan_bridge_1d: fix test failure with", " br_netfilter enabled", " - netfilter: nf_conntrack_h323: don't pass uninitialised l3num value", " - ipv6: fix a race in ip6_sock_set_v6only()", " - bpftool: Fix truncated netlink dumps", " - octeontx2-af: Fix default entries mcam entry action", " - apparmor: fix rlimit for posix cpu timers", " - drm/i915/acpi: free _DSM package when no connectors", " - ext4: use optimized mballoc scanning regardless of inode format", " - ata: pata_ftide010: Fix some DMA timings", " - perf callchain: Fix srcline printing with inlines", " - libperf: Don't remove -g when EXTRA_CFLAGS are used", " - libperf build: Always place libperf includes first", " - rtc: interface: Alarm race handling should not discard preceding error", " - hfsplus: fix volume corruption issue for generic/498", " - i3c: master: svc: Initialize 'dev' to NULL in svc_i3c_master_ibi_isr()", " - tools/power cpupower: Reset errno before strtoull()", " - s390/purgatory: Add -Wno-default-const-init-unsafe to KBUILD_CFLAGS", " - x86/xen/pvh: Enable PAE mode for 32-bit guest only when CONFIG_X86_PAE", " is set", " - ACPICA: Abort AML bytecode execution when executing AML_FATAL_OP", " - s390/perf: Disable register readout on sampling events", " - xenbus: Use .freeze/.thaw to handle xenbus devices", " - blk-mq-debugfs: add missing debugfs_mutex in", " blk_mq_debugfs_register_hctxs()", " - sparc: Synchronize user stack on fork and clone", " - sparc: don't reference obsolete termio struct for TC* constants", " - bpf: verifier improvement in 32bit shift sign extension pattern", " - clocksource/drivers/timer-integrator-ap: Add missing Kconfig dependency", " on OF", " - mailbox: bcm-ferxrm-mailbox: Use default primary handler", " - char: tpm: cr50: Remove IRQF_ONESHOT", " - arm64: tegra: smaug: Add usb-role-switch support", " - parisc: Prevent interrupts during reboot", " - media: dvb-core: dmxdevfilter must always flush bufs", " - spi: stm32: fix Overrun issue at < 8bpw", " - media: omap3isp: isp_video_mbus_to_pix/pix_to_mbus fixes", " - media: omap3isp: isppreview: always clamp in preview_try_format()", " - media: omap3isp: set initial format", " - ASoC: wm8962: Add WM8962_ADC_MONOMIX to \"3D Coefficients\" mask", " - ASoC: wm8962: Don't report a microphone if it's shorted to ground on", " plug", " - media: adv7180: fix frame interval in progressive mode", " - drm/amdkfd: Fix GART PTE for non-4K pagesize in svm_migrate_gart_map()", " - hyper-v: Mark inner union in hv_kvp_exchg_msg_value as packed", " - virt: vbox: uapi: Mark inner unions in packed structs as packed", " - drm/atmel-hlcdc: don't reject the commit if the src rect has fractional", " parts", " - HID: multitouch: add eGalaxTouch EXC3188 support", " - HID: elecom: Add support for ELECOM HUGE Plus M-HT1MRBK", " - gpio: aspeed-sgpio: Change the macro to support deferred probe", " - spi: spi-mem: Protect dirmap_create() with spi_mem_access_start/end", " - ASoC: es8328: Add error unwind in resume", " - modpost: Amend ppc64 save/restfpr symnames for -Os build", " - ALSA: usb-audio: Add iface reset and delay quirk for AB13X USB Audio", " - jfs: Add missing set_freezable() for freezable kthread", " - iommu/arm-smmu-v3: Improve CMDQ lock fairness and efficiency", " - ipv6: annotate data-races in ip6_multipath_hash_{policy,fields}()", " - ipv6: exthdrs: annotate data-race over multiple sysctl", " - ext4: mark group add fast-commit ineligible", " - ext4: mark group extend fast-commit ineligible", " - netfilter: nf_conntrack: Add allow_clash to generic protocol handler", " - openrisc: define arch-specific version of nop()", " - net: usb: r8152: fix transmit queue timeout", " - net: hns3: extend HCLGE_FD_AD_QID to 11 bits", " - wifi: iwlegacy: add missing mutex protection in il4965_store_tx_power()", " - wifi: iwlegacy: add missing mutex protection in", " il3945_store_measurement()", " - ipv4: fib: Annotate access to struct fib_alias.fa_state.", " - Bluetooth: hci_conn: use mod_delayed_work for active mode timeout", " - Bluetooth: btusb: Add device ID for Realtek RTL8761BU", " - wifi: ath10k: fix lock protection in", " ath10k_wmi_event_peer_sta_ps_state_chg()", " - net: usb: sr9700: remove code to drive nonexistent multicast filter", " - vmw_vsock: bypass false-positive Wnonnull warning with gcc-16", " - PCI: Mark ASM1164 SATA controller to avoid bus reset", " - PCI/AER: Clear stale errors on reporting agents upon probe", " - PCI: Fix pci_slot_lock () device locking", " - PCI: Add ACS quirk for Qualcomm Hamoa & Glymur", " - PCI: Mark Nvidia GB10 to avoid bus reset", " - myri10ge: avoid uninitialized variable use", " - nfc: nxp-nci: remove interrupt trigger type", " - RDMA/rtrs-clt: For conn rejection use actual err number", " - scsi: buslogic: Reduce stack usage", " - tracing: Fix false sharing in hwlat get_sample()", " - mailbox: sprd: mask interrupts that are not handled", " - remoteproc: mediatek: Break lock dependency to `prepare_lock`", " - mailbox: sprd: clear delivery flag before handling TX done", " - clk: microchip: core: correct return value on *_get_parent()", " - m68k: nommu: fix memmove() with differently aligned src and dest for", " 68000", " - staging: rtl8723bs: fix missing status update on sdio_alloc_irq()", " failure", " - serial: 8250_dw: handle clock enable errors in runtime_resume", " - misc: eeprom: Fix EWEN/EWDS/ERAL commands for 93xx56 and 93xx66", " - serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA", " termination is done", " - fix it87_wdt early reboot by reporting running timer", " - binder: don't use %pK through printk", " - phy: mvebu-cp110-utmi: fix dr_mode property read from dts", " - phy: fsl-imx8mq-usb: disable bind/unbind platform driver feature", " - Revert \"mfd: da9052-spi: Change read-mask to write-mask\"", " - iio: Use IRQF_NO_THREAD", " - iio: magnetometer: Remove IRQF_ONESHOT", " - MIPS: Loongson: Make cpumask_of_node() robust against NUMA_NO_NODE", " - fs/ntfs3: avoid calling run_get_entry() when run == NULL in", " ntfs_read_run_nb_ra()", " - include: uapi: netfilter_bridge.h: Cover for musl libc", " - ARM: 9467/1: mm: Don't use %pK through printk", " - drm/amd/display: Avoid updating surface with the same surface under MPO", " - drm/amdgpu: Adjust usleep_range in fence wait", " - ALSA: usb-audio: Update the number of packets properly at receiving", " - drm/amdgpu: Add HAINAN clock adjustment", " - drm/radeon: Add HAINAN clock adjustment", " - btrfs: replace BUG() with error handling in __btrfs_balance()", " - lan78xx: Fix memory allocation bug", " - net: usb: lan78xx: scan all MDIO addresses on LAN7801", " - wifi: cfg80211: wext: fix IGTK key ID off-by-one", " - Bluetooth: L2CAP: Fix invalid response to L2CAP_ECRED_RECONF_REQ", " - Bluetooth: hci_qca: Cleanup on all setup failures", " - Bluetooth: L2CAP: Fix response to L2CAP_ECRED_CONN_REQ", " - tipc: fix duplicate publication key in tipc_service_insert_publ()", " - RDMA/core: Fix stale RoCE GIDs during netdev events at registration", " - RDMA/efa: Fix typo in efa_alloc_mr()", " - fpga: dfl: use subsys_initcall to allow built-in drivers to be added", " - arm64: Disable branch profiling for all arm64 code", " - media: cx25821: Add missing unmap in snd_cx25821_hw_params()", " - media: i2c: ov5647: Correct pixel array offset", " - media: i2c: ov5647: Correct minimum VBLANK value", " - media: i2c: ov5647: Sensor should report RAW color space", " - media: i2c: ov5647: Fix PIXEL_RATE value for VGA mode", " - media: i2c: ov5647: use our own mutex for the ctrl lock", " - dm-integrity: fix a typo in the code for write/discard race", " - clk: tegra: tegra124-emc: Fix potential memory leak in", " tegra124_clk_register_emc()", " - s390/pci: Handle futile config accesses of disabled devices directly", " - dm-unstripe: fix mapping bug when there are multiple targets in a table", " - arm64: dts: rockchip: Do not enable hdmi_sound node on Pinebook Pro", " - media: venus: vdec: fix error state assignment for zero bytesused", " - drm: of: drm_of_panel_bridge_remove(): fix device_node leak", " - mm, page_alloc, thp: prevent reclaim for __GFP_THISNODE THP allocations", " - selftests/mm/charge_reserved_hugetlb: drop mount size for hugetlbfs", " - xfs: mark data structures corrupt on EIO and ENODATA", " - xfs: fix remote xattr valuelblk check", " - nfsd: fix return error code for nfsd_map_name_to_[ug]id", " - usb: gadget: tegra-xudc: Add handling for BLCG_COREPLL_PWRDN", " - bus: fsl-mc: fix an error handling in fsl_mc_device_add()", " - dm mpath: make pg_init_delay_msecs settable", " - iio: gyro: itg3200: Fix unchecked return value in read_raw", " - PCI/IOV: Fix race between SR-IOV enable/disable and hotplug", " - arm64: Fix non-atomic __READ_ONCE() with CONFIG_LTO=y", " - btrfs: continue trimming remaining devices on failure", " - usb: dwc2: fix resume failure if dr_mode is host", " - mtd: rawnand: pl353: Fix software ECC support", " - tipc: fix RCU dereference race in tipc_aead_users_dec()", " - net: cpsw_new: Fix unnecessary netdev unregistration in cpsw_probe()", " error path", " - parisc: kernel: replace kfree() with put_device() in create_tree_node()", " - MIPS: rb532: Fix MMIO UART resource registration", " - net: ethernet: marvell: skge: remove incorrect conflicting PCI ID", " - tracing: Fix to set write permission to per-cpu buffer_size_kb", " - net: intel: fix PCI device ID conflict between i40e and ipw2200", " - fbdev: ffb: fix corrupted video output on Sun FFB1", " - drm/amdgpu: keep vga memory on MacBooks with switchable graphics", " - NTB: ntb_transport: Fix too small buffer for debugfs_name", " - Linux 5.15.202", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43291", " - net: nfc: nci: Fix parameter validation for packet data", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43283", " - net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43264", " - fbdev: of: display_timing: fix refcount leak in of_get_display_timings()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43202", " - fbdev: vt8500lcdfb: fix missing dma_free_coherent()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43203", " - atm: fore200e: fix use-after-free in tasklets during device removal", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43149", " - net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43273", " - ceph: supply snapshot context in ceph_zero_partial_object()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43159", " - staging: rtl8723bs: fix null dereference in find_network", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43211", " - PCI: Fix pci_slot_trylock() error handling", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43206", " - drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43275", " - scsi: ufs: core: Flush exception handling work when RPM level is zero", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43145", " - remoteproc: imx_rproc: Fix invalid loaded resource table detection", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43147", " - Revert \"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling", " SR-IOV\"", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43289", " - kexec: derive purgatory entry from symbol", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43168", " - ocfs2: fix reflink preserve cleanup issue", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43295", " - rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43148", " - powerpc/smp: Add check for kcalloc() failure in parse_thread_groups()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43163", " - md/bitmap: fix GPF in write_page caused by resize race", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43200", " - PCI: endpoint: Fix swapped parameters in", " pci_{primary/secondary}_epc_epf_unlink() functions", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43158", " - xfs: fix freemap adjustments when adding xattrs to leaf blocks", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43187", " - xfs: delete attr leaf freemap entries when empty", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43130", " - iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in", " scalable mode", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43133", " - KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43196", " - soc: ti: pruss: Fix double free in pruss_clk_mux_setup()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43242", " - soc: ti: k3-socinfo: Fix regmap leak on probe failure", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43278", " - dm: clear cloned request bio pointer when last clone bio completes", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43312", " - media: i2c: ov5647: Initialize subdev before controls", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43182", " - media: ccs: Avoid possible division by zero", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43246", " - media: i2c/tw9906: Fix potential memory leak in tw9906_probe()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43218", " - media: i2c/tw9903: Fix potential memory leak in tw9903_probe()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43135", " - media: cx23885: Add missing unmap in snd_cx23885_hw_params()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43257", " - media: cx88: Add missing unmap in snd_cx88_hw_params()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43231", " - media: radio-keene: fix memory leak in error path", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43136", " - HID: logitech-hidpp: Check maxfield in hidpp_get_report_length()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43251", " - HID: prodikeys: Check presence of pm->input_ep82", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43140", " - HID: magicmouse: Do not crash on missing msc->input", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43152", " - HID: hid-pl: handle probe errors", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43315", " - KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3()", " succeeding", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43270", " - media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43207", " - media: mtk-mdp: Fix error handling in probe function", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43132", " - dm-verity: correctly handle dm_bufio_client_create() failure", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71274", " - rpmsg: core: fix race in driver_override_show() and use core helper", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43233", " - netfilter: nf_conntrack_h323: fix OOB read in decode_choice()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43205", " - dpaa2-switch: validate num_ifs to prevent out-of-bounds write", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43194", " - net: consume xmit errors of GSO frames", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43156", " - net: usb: pegasus: enable basic endpoint checking", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43232", " - net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43134", " - Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43180", " - net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43139", " - xfrm6: fix uninitialized saddr in xfrm6_get_saddr()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43141", " - ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43241", " - ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43279", " - ALSA: usb-audio: Add sanity check for OOB writes at silencing", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71267", " - fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71265", " - fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent", " metadata", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71266", " - fs: ntfs3: check return value of indx_find to avoid infinite loop", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43225", " - staging: rtl8723bs: fix memory leak on failure path", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43230", " - net/rds: Clear reconnect pending bit", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43296", " - octeontx2-af: Workaround SQM/PSE stalls by disabling sticky", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43226", " - net/rds: No shortcut out of RDS_CONN_ERROR", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43190", " - netfilter: xt_tcpmss: check remaining length before reading optlen", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43255", " - wifi: libertas: fix WARNING in usb_tx_block", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43314", " - dm: remove fake timeout to avoid leak request", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71292", " - jfs: nlink overflow in jfs_rename", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43236", " - drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43269", " - drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43287", " - drm: Account property blob allocations to memcg", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43183", " - media: cx25821: Fix a resource leak in cx25821_dev_setup()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43316", " - media: solo6x10: Check for out of bounds chip_id", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43223", " - media: pvrusb2: fix URB leak in pvr2_send_request_ex", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43302", " - drm/v3d: Set DMA segment size to avoid debug warnings", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43124", " - pstore: ram_core: fix incorrect success return when vmap() fails", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43227", " - clocksource/drivers/sh_tmu: Always leave device running after probe", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43313", " - ACPI: processor: Fix NULL-pointer dereference in", " acpi_processor_errata_piix4()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43266", " - EFI/CPER: don't go past the ARM processor CPER record buffer", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43277", " - APEI/GHES: ensure that won't go past CPER allocated record", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43171", " - EFI/CPER: don't dump the entire memory region", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43184", " - rnbd-srv: Zero the rsp buffer before using it", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43261", " - arm64: Add support for TSV110 Spectre-BHB mitigation", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43262", " - gfs2: fiemap page fault fix", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43209", " - minix: Add required sanity checking to minix_check_superblock()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43268", " - hfsplus: pretend special inodes as regular files", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-23241", " - audit: add missing syscalls to read class", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71239", " - audit: add fchmodat2() to change attributes class", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45964", " - SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45870", " - SUNRPC: auth_gss: fix memory leaks in XDR decoding error paths", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45948", " - ext4: fix memory leak in ext4_ext_shift_extents()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45912", " - ext4: don't cache extent during splitting extent", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46250", " - MIPS: Work around LLVM bug when gp is used as global register variable", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45974", " - btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not", " found", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45965", " - apparmor: fix invalid deref of rawdata when export_binary is unset", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45848", " - apparmor: fix NULL sock in aa_sock_file_perm", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45970", " - bonding: alb: fix UAF in rlb_arp_recv during bond up/down", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45847", " - net: remove WARN_ON_ONCE when accessing forward path array", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45890", " - xen-netback: reject zero-queue configuration from guest", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45968", " - cpuidle: Skip governor when only one idle state is available", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45935", " - fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45864", " - fs/ntfs3: prevent infinite loops caused by the next valid being the same", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45868", " - pinctrl: single: fix refcount leak in pcs_add_gpio_func()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45883", " - iio: sca3000: Fix a resource leak in sca3000_probe()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45875", " - mfd: arizona: Fix regulator resource leak on", " wm5102_clear_write_sequencer() failure", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45978", " - staging: greybus: lights: avoid NULL deref", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45954", " - fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45857", " - scsi: csiostor: Fix dereference of null pointer rn", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45856", " - RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45852", " - RDMA/rxe: Fix double free in rxe_srq_from_init", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45869", " - power: supply: wm97xx: Fix NULL pointer dereference in", " power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45916", " - power: supply: sbs-battery: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46270", " - power: supply: rt9455: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45936", " - power: supply: goldfish: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45885", " - power: supply: cpcap-battery: Fix use-after-free in", " power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45879", " - power: supply: bq25980: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45902", " - power: supply: bq256xx: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45867", " - power: supply: act8945a: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45946", " - power: supply: ab8500: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45866", " - serial: caif: fix use-after-free in caif_serial ldisc_close()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-31411", " - net: atm: fix crash due to unvalidated vcc pointer in sigd_send()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46259", " - procfs: fix missing RCU protection when reading real_parent in", " do_task_stat()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45891", " - net: hns3: fix double free issue for tx spare buffer", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45873", " - netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46267", " - nfc: hci: shdlc: Stop timers and work before freeing context", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46249", " - octeontx2-af: Fix PF driver crash with kexec kernel booting", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45915", " - fat: avoid parent link count underflow in rmdir", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45983", " - nfsd: never defer requests during idmap lookup", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45862", " - iommu/vt-d: Flush cache for PASID table before using it", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45860", " - netfilter: nf_conncount: increase the connection clean up limit to 64", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45969", " - HID: playstation: Add missing check for input_ff_create_memless", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71304", " - smack: /smack/doi: accept previously used values", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45904", " - powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event", " handling", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46253", " - pstore/ram: fix buffer overflow in persistent_ram_save_old()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45919", " - sched/rt: Skip currently executing CPU in rto_next_cpu()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45871", " - tpm: st33zp24: Fix missing cleanup on get_burstcount() error", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45941", " - tpm: tpm_i2c_infineon: Fix locality leak on get_burstcount() failure", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45984", " - gfs2: Fix use-after-free in iomap inline data write path", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45960", " - hfsplus: return error when node already exists in hfs_bnode_create", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-23243", " - RDMA/umad: Reject negative data_len in ib_umad_write", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-23242", " - RDMA/siw: Fix potential NULL pointer dereference in header processing", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198)", " - crypto: octeontx - Fix length check to avoid truncation in", " ucode_load_store", " - scsi: qla2xxx: Query FW again before proceeding with login", " - ALSA: hda/realtek: Fix headset mic for TongFang X6AR55xU", " - gpio: sprd: Change sprd_gpio lock to raw_spin_lock", " - drm/tegra: hdmi: sor: Fix error: variable ‘j’ set but not used", " - platform/x86: panasonic-laptop: Fix sysfs group leak in error path", " - gpiolib: acpi: Fix gpio count with string references", " - Revert \"wireguard: device: enable threaded NAPI\"", " - selftests: mptcp: pm: ensure unknown flags are ignored", " - crypto: virtio - Remove duplicated virtqueue_kick in", " virtio_crypto_skcipher_crypt_req", " - bus: fsl-mc: Replace snprintf and sprintf with sysfs_emit in sysfs show", " functions", " - scsi: qla2xxx: Use named initializers for port_[d]state_str", " - scsi: qla2xxx: Remove dead code (GNN ID)", " - scsi: qla2xxx: Reduce fabric scan duplicate code", " - PCI: endpoint: Automatically create a function specific attributes group", " - PCI: endpoint: Remove unused field in struct pci_epf_group", " - USB: serial: option: add Telit FN920C04 RNDIS compositions", " - Linux 5.15.201", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23235", " - f2fs: fix out-of-bounds access in sysfs attribute read/write", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23234", " - f2fs: fix to avoid UAF in f2fs_write_end_io()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23236", " - fbdev: smscufx: properly copy ioctl memory to kernelspace", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23266", " - fbdev: rivafb: fix divide error in nv3_arb()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71233", " - PCI: endpoint: Avoid creating sub-groups asynchronously", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71232", " - scsi: qla2xxx: Free sp in error path to fix system crash", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71238", " - scsi: qla2xxx: Fix bsg_done() causing double free", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23221", " - bus: fsl-mc: fix use-after-free in driver_override_show()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23228", " - smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23169", " - mptcp: fix race in mptcp_pm_nl_flush_addrs_doit()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-37786", " - net: dsa: free routing table on probe failure", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23237", " - platform/x86: classmate-laptop: Add missing NULL pointer checks", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23238", " - romfs: check sb_set_blocksize() return value", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-31687", " - gpio: omap: do not register driver in probe()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71235", " - scsi: qla2xxx: Delay module unload while fabric scan in progress", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71236", " - scsi: qla2xxx: Validate sp before freeing associated memory", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71237", " - nilfs2: Fix potential block overflow that cause system hang", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23229", " - crypto: virtio - Add spinlock protection with virtqueue notification", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23222", " - crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly", " * CVE-2026-23392", " - netfilter: nf_tables: register hooks last when adding new", " chain/flowtable", " - netfilter: nf_tables: release flowtable after rcu grace period on error", " * CVE-2026-45988", " - rxrpc: Fix re-decryption of RESPONSE packets", " * CVE-2026-46195", " - smb: client: validate dacloffset before building DACL pointers", " * CVE-2026-46135", " - nvmet-tcp: fix race between ICReq handling and queue teardown", " * CVE-2026-31402", " - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache", " * CVE-2026-43071", " - dcache: Limit the minimal number of bucket to two", " * CVE-2026-46119", " - libceph: Fix slab-out-of-bounds access in auth message processing", " * CVE-2026-43501", " - ipv6: rpl: reserve mac_len headroom when recompressed SRH grows", " * CVE-2026-46043", " - RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv", " * CVE-2026-43493", " - crypto: pcrypt - Fix handling of MAY_BACKLOG requests", " * CVE-2026-31637", " - rxrpc: reject undecryptable rxkad response tickets", " * CVE-2026-31657", " - batman-adv: hold claim backbone gateways by reference", " * CVE-2026-31685", " - netfilter: ip6t_eui64: reject invalid MAC header for all packets", " * CVE-2026-43117", " - btrfs: tracepoints: get correct superblock from dentry in event", " btrfs_sync_file()", " * CVE-2026-43114", " - netfilter: nft_set_pipapo_avx2: don't return non-matching entry on", " expiry", " * CVE-2026-31478", " - ksmbd: replace hardcoded hdr2_len with offsetof() in", " smb2_calc_max_out_buf_len()", " * CVE-2026-31668", " - seg6: separate dst_cache for input and output paths in seg6 lwtunnel", " * CVE-2026-31659", " - batman-adv: reject oversized global TT response buffers", " * CVE-2026-31649", " - net: stmmac: fix integer underflow in chain mode", " * CVE-2026-31669", " - mptcp: fix slab-use-after-free in __inet_lookup_established", " * CVE-2026-43011", " - net/x25: Fix potential double free of skb", " * CVE-2026-43037", " - ip6_tunnel: clear skb2->cb[] in ip4ip6_err()", " * CVE-2026-43038", " - ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()", " * CVE-2026-31682", " - bridge: br_nd_send: linearize skb before parsing ND options", " * CVE-2026-23450", " - net/smc: Only save the original clcsock callback functions", " - net/smc: Fix slab-out-of-bounds issue in fallback", " - net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()", " * CVE-2026-23428", " - ksmbd: fix use-after-free of share_conf in compound request", " * CVE-2026-23455", " - netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()", " * CVE-2026-43186", " - ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()", " * CVE-2026-43185", " - ksmbd: fix signededness bug in smb_direct_prepare_negotiation()", " * CVE-2026-43341", " - net/ipv6: ioam6: prevent schema length wraparound in trace fill", " * CVE-2026-31607", " - usbip: validate number_of_packets in usbip_pack_ret_submit()", " * CVE-2026-43383", " - net/tcp-md5: Fix MAC comparison to be constant-time", " * CVE-2025-68263", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " * CVE-2026-46243", " - smb: client: reject userspace cifs.spnego descriptions", " * CVE-2026-43414", " - scsi: qla2xxx: Completely fix fcport double free", " * CVE-2026-43407", " - libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply()", " * CVE-2026-43406", " - libceph: prevent potential out-of-bounds reads in", " process_message_header()", " * CVE-2026-43304", " - libceph: define and enforce CEPH_MAX_KEY_LEN", " * CVE-2025-37924", " - ksmbd: fix use-after-free in kerberos authentication", " * CVE-2025-37778", " - ksmbd: Fix dangling pointer in krb_authenticate", "" ], "package": "linux-kvm", "version": "5.15.0-1104.109", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2157390, 1786013, 2157405, 2154194, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156629, 2156629, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198 ], "author": "Hannah Peuckmann ", "date": "Tue, 30 Jun 2026 09:18:47 +0200" } ], "notes": "linux-kvm-headers-5.15.0-1104 version '5.15.0-1104.109' (source package linux-kvm version '5.15.0-1104.109') was added. linux-kvm-headers-5.15.0-1104 version '5.15.0-1104.109' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1103-kvm. As such we can use the source package version of the removed package, '5.15.0-1103.108', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-modules-5.15.0-1104-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1103.108", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1104.109", "version": "5.15.0-1104.109" }, "cves": [ { "cve": "CVE-2026-46137", "url": "https://ubuntu.com/security/CVE-2026-46137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: fix potential data-race This mptcp_pm_add_timer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bh_lock_sock(). If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46275", "url": "https://ubuntu.com/security/CVE-2026-46275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart. The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the `hu` struct. When the scheduled work executes later, it blindly dereferences the freed `hu` struct. Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently. Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities.", "cve_priority": "high", "cve_public_date": "2026-06-08 16:16:00 UTC" }, { "cve": "CVE-2025-23141", "url": "https://ubuntu.com/security/CVE-2025-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where \"accepting\" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit can access guest memory. The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triple_fault_event_test selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario. ============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted ----------------------------- include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2026-43052", "url": "https://ubuntu.com/security/CVE-2026-43052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check tdls flag in ieee80211_tdls_oper When NL80211_TDLS_ENABLE_LINK is called, the code only checks if the station exists but not whether it is actually a TDLS station. This allows the operation to proceed for non-TDLS stations, causing unintended side effects like modifying channel context and HT protection before failing. Add a check for sta->sta.tdls early in the ENABLE_LINK case, before any side effects occur, to ensure the operation is only allowed for actual TDLS peers.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2025-22107", "url": "https://ubuntu.com/security/CVE-2025-22107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry() There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-21863", "url": "https://ubuntu.com/security/CVE-2025-21863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: prevent opcode speculation sqe->opcode is used for different tables, make sure we santitise it against speculations.", "cve_priority": "low", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2026-46274", "url": "https://ubuntu.com/security/CVE-2026-46274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io-wq: check that the predecessor is hashed in io_wq_remove_pending() io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0]. Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory. Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot.", "cve_priority": "high", "cve_public_date": "2026-06-08 16:16:00 UTC" }, { "cve": "CVE-2026-45846", "url": "https://ubuntu.com/security/CVE-2026-45846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst() bareudp_fill_metadata_dst() passes bareudp->sock to udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check. The socket is only created in bareudp_open() and NULLed in bareudp_stop(), so calling this function while the device is down triggers a NULL dereference via sock->sk. BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160) Call Trace: bareudp_fill_metadata_dst (drivers/net/bareudp.c:532) do_execute_actions (net/openvswitch/actions.c:901) ovs_execute_actions (net/openvswitch/actions.c:1589) ovs_packet_cmd_execute (net/openvswitch/datapath.c:700) genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1209) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths in the same driver.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45844", "url": "https://ubuntu.com/security/CVE-2026-45844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: arp_tables: fix IEEE1394 ARP payload parsing Weiming Shi says: \"arp_packet_match() unconditionally parses the ARP payload assuming two hardware addresses are present (source and target). However, IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address field, and arp_hdr_len() already accounts for this by returning a shorter length for ARPHRD_IEEE1394 devices. As a result, on IEEE1394 interfaces arp_packet_match() advances past a nonexistent target hardware address and reads the wrong bytes for both the target device address comparison and the target IP address. This causes arptables rules to match against garbage data, leading to incorrect filtering decisions: packets that should be accepted may be dropped and vice versa. The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already handles this correctly by skipping the target hardware address for ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match().\" Mangle the original patch to always return 0 (no match) in case user matches on the target hardware address which is never present in IEEE1394. Note that this returns 0 (no match) for either normal and inverse match because matching in the target hardware address in ARPHRD_IEEE1394 has never been supported by arptables. This is intentional, matching on the target hardware address should never evaluate true for ARPHRD_IEEE1394. Moreover, adjust arpt_mangle to drop the packet too as AI suggests: In arpt_mangle, the logic assumes a standard ARP layout. Because IEEE1394 (FireWire) omits the target hardware address, the linear pointer arithmetic miscalculates the offset for the target IP address. This causes mangling operations to write to the wrong location, leading to packet corruption. To ensure safety, this patch drops packets (NF_DROP) when mangling is requested for these fields on IEEE1394 devices, as the current implementation cannot correctly map the FireWire ARP payload. This omits both mangling target hardware and IP address. Even if IP address mangling should be possible in IEEE1394, this would require to adjust arpt_mangle offset calculation, which has never been supported. Based on patch from Weiming Shi .", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45843", "url": "https://ubuntu.com/security/CVE-2026-45843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: bound decode() reads against the compressed packet length slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code. A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets. Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45842", "url": "https://ubuntu.com/security/CVE-2026-45842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: reject VJ receive packets on instances with no rstate array slhc_init() accepts rslots == 0 as a valid configuration, with the documented meaning of 'no receive compression'. In that case the allocation loop in slhc_init() is skipped, so comp->rstate stays NULL and comp->rslot_limit stays 0 (from the kzalloc of struct slcompress). The receive helpers do not defend against that configuration. slhc_uncompress() dereferences comp->rstate[x] when the VJ header carries an explicit connection ID, and slhc_remember() later assigns cs = &comp->rstate[...] after only comparing the packet's slot number to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the range check, and the code dereferences a NULL rstate. The configuration is reachable in-tree through PPP. PPPIOCSMAXCID stores its argument in a signed int, and (val >> 16) uses arithmetic shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1 is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because /dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path is reachable from an unprivileged user namespace. Once the malformed VJ state is installed, any inbound VJ-compressed or VJ-uncompressed frame that selects slot 0 crashes the kernel in softirq context: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519) Call Trace: ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466) ppp_input (drivers/net/ppp/ppp_generic.c:2359) ppp_async_process (drivers/net/ppp/ppp_async.c:492) tasklet_action_common (kernel/softirq.c:926) handle_softirqs (kernel/softirq.c:623) run_ksoftirqd (kernel/softirq.c:1055) smpboot_thread_fn (kernel/smpboot.c:160) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) Reject the receive side on such instances instead of touching rstate. slhc_uncompress() falls through to its existing 'bad' label, which bumps sls_i_error and enters the toss state. slhc_remember() mirrors that with an explicit sls_i_error increment followed by slhc_toss(); the sls_i_runt counter is not used here because a missing rstate is an internal configuration state, not a runt packet. The transmit path is unaffected: the only in-tree caller that picks rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and slip.c always calls slhc_init(16, 16), so comp->tstate remains valid and slhc_compress() continues to work.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45841", "url": "https://ubuntu.com/security/CVE-2026-45841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO nf_osf_match_one() computes ctx->window % f->wss.val in the OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a subsequent matching TCP SYN divides by zero and panics the kernel. Reject the bogus fingerprint in nfnl_osf_add_callback() above the per-option for-loop. f->wss is per-fingerprint, not per-option, so the check must run regardless of f->opt_num (including 0). Also reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that as \"should not happen\". Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:220) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:348) nf_hook_slow (net/netfilter/core.c:622) ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv (include/linux/skbuff.h:1162) __netif_receive_skb_one_core (net/core/dev.c:6181) process_backlog (net/core/dev.c:6642) __napi_poll (net/core/dev.c:7710) net_rx_action (net/core/dev.c:7945) handle_softirqs (kernel/softirq.c:622)", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45840", "url": "https://ubuntu.com/security/CVE-2026-45840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: cap upcall PID array size and pre-size vport replies The vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENL_UNS_ADMIN_PERM. kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Kernel panic - not syncing: Fatal exception Reject attempts to set more PIDs than nr_cpu_ids in ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply size in ovs_vport_cmd_msg_size() based on that bound, similar to the existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the two sides stay consistent.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46319", "url": "https://ubuntu.com/security/CVE-2026-46319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: Only release RCU read lock after ct_ft When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero() is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft object. This vulnerability can lead to privilege escalation. Analysis from zdi-disclosures@trendmicro.com: When initializing act_ct, tcf_ct_init() is called, which internally triggers tcf_ct_flow_table_get(). static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params) { struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ... } static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params) { void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj; } At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft from zones_ht . The lookup is performed within an RCU read critical section through rcu_read_lock() / rcu_read_unlock(), which prevents the object from being freed. However, at the point of function return, rcu_read_unlock() has already been called, and there is nothing preventing ct_ft from being freed before reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomes the race window, during which ct_ft can be freed. Free Process: tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put(). static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft) { if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); } } At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work static void tcf_ct_flow_table_cleanup_work(struct work_struct *work) { struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE); } tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes between [1] and [2], UAF occurs. This race condition has a very short race window, making it generally difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was inserted after[1]", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-45839", "url": "https://ubuntu.com/security/CVE-2026-45839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec() CO-RE accessor strings are colon-separated indices that describe a path from a root BTF type to a target field, e.g. \"0:1:2\" walks through nested struct members. bpf_core_parse_spec() parses each component with sscanf(\"%d\"), so negative values like -1 are silently accepted. The subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the upper bound and always pass for negative values because C integer promotion converts the __u16 btf_vlen result to int, making the comparison (int)(-1) >= (int)(N) false for any positive N. When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff, producing an out-of-bounds read far past the members array. A crafted BPF program with a negative CO-RE accessor on any struct that exists in vmlinux BTF (e.g. task_struct) crashes the kernel deterministically during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y (default on major distributions). The bug is reachable with CAP_BPF: BUG: unable to handle page fault for address: ffffed11818b6626 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full) RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354) RAX: 00000000ffffffff Call Trace: bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321) bpf_core_apply (kernel/bpf/btf.c:9507) check_core_relo (kernel/bpf/verifier.c:19475) bpf_check (kernel/bpf/verifier.c:26031) bpf_prog_load (kernel/bpf/syscall.c:3089) __sys_bpf (kernel/bpf/syscall.c:6228) CO-RE accessor indices are inherently non-negative (struct member index, array element index, or enumerator index), so reject them immediately after parsing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45838", "url": "https://ubuntu.com/security/CVE-2026-45838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix end-of-list detection in cgroup_storage_get_next_key() list_next_entry() never returns NULL -- when the current element is the last entry it wraps to the list head via container_of(). The subsequent NULL check is therefore dead code and get_next_key() never returns -ENOENT for the last element, instead reading storage->key from a bogus pointer that aliases internal map fields and copying the result to userspace. Replace it with list_entry_is_head() so the function correctly returns -ENOENT when there are no more entries.", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46214", "url": "https://ubuntu.com/security/CVE-2026-46214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix accept queue count leak on transport mismatch virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listener to reject all new connections. Fix by moving sk_acceptq_added() to after the transport validation, matching the pattern used by vmci_transport and hyperv_transport.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46234", "url": "https://ubuntu.com/security/CVE-2026-46234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: fix buffer size clamping order In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint. This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size. Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45836", "url": "https://ubuntu.com/security/CVE-2026-45836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46231", "url": "https://ubuntu.com/security/CVE-2026-46231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: put backbone reference on failed claim hash insert When batadv_bla_add_claim() fails to insert a new claim into the hash, it leaked a reference to the backbone_gw for which the claim was intended. Call batadv_backbone_gw_put() on the error path to release the reference and avoid leaking the backbone_gw object.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46233", "url": "https://ubuntu.com/security/CVE-2026-46233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: only purge non-released claims When batadv_bla_purge_claims() goes through the list of claims, it is only traversing the hash list with an rcu_read_lock(). Due to a potential parallel batadv_claim_put(), it can happen that it encounters a claim which was actually in the process of being released+freed by batadv_claim_release(). In this case, backbone_gw is set to NULL before the delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is then no longer allowed because it would cause a NULL-ptr derefence. To avoid this, only claims with a valid reference counter must be purged. All others are already taken care of.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46212", "url": "https://ubuntu.com/security/CVE-2026-46212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: prevent use-after-free when deleting claims When batadv_bla_del_backbone_claims() removes all claims for a backbone, it does this by dropping the link entry in the hash list. This list entry itself was one of the references which need to be dropped at the same time via batadv_claim_put(). But the batadv_claim_put() must not be done before the last access to the claim object in this function. Otherwise the claim might be freed already by the batadv_claim_release() function before the list entry was dropped.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46238", "url": "https://ubuntu.com/security/CVE-2026-46238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop caching unowned originator pointers in BAT IV BAT IV keeps the last-hop neighbor address in each neigh_node, but some paths also cache an originator pointer derived from a temporary lookup. That pointer is not owned by the neigh_node and may no longer refer to a live originator entry after purge handling runs. Stop storing the auxiliary originator pointer in the BAT IV neighbor state. When BAT IV needs the neighbor originator data, resolve it from the stored neighbor address and drop the reference again after use. [sven: avoid bonding logic for outgoing OGM]", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46206", "url": "https://ubuntu.com/security/CVE-2026-46206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject new tp_meter sessions during teardown Prevent tp_meter from starting new sender or receiver sessions after mesh_state has left BATADV_MESH_ACTIVE.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46198", "url": "https://ubuntu.com/security/CVE-2026-46198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix integer overflow on buff_pos Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size check is done using the int type in batadv_iv_ogm_aggr_packet whereas the buff_pos variable uses the s16 type. This could lead to an out-of-bound read.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46227", "url": "https://ubuntu.com/security/CVE-2026-46227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the \"sk != asoc->base.sk\" and \"asoc->base.dead\" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 (\"sctp: walk the list of asoc safely\") was added for.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46220", "url": "https://ubuntu.com/security/CVE-2026-46220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission sdma_v4_0_ring_emit_fence() contains two BUG_ON(addr & 0x3) assertions that verify fence writeback addresses are dword-aligned. These assertions can be reached from unprivileged userspace via crafted DRM_IOCTL_AMDGPU_CS submissions, causing a fatal kernel panic in a scheduler worker thread. Replace both BUG_ON() calls with WARN_ON() to log the condition without crashing the kernel. A misaligned fence address at this point indicates a driver bug, but crashing the kernel is never the correct response when the assertion is reachable from userspace. The CS IOCTL path is the correct place to filter invalid submissions; the ring emission callback is too late to do anything about it. (cherry picked from commit b90250bd933afd1ba94d86d6b13821997b22b18e)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46197", "url": "https://ubuntu.com/security/CVE-2026-46197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: validate SVM ioctl nattr against buffer size Validate nattr field against the buffer size, preventing out-of-bounds buffer access via user-controlled attribute count. (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46209", "url": "https://ubuntu.com/security/CVE-2026-46209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1); However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value. A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46230", "url": "https://ubuntu.com/security/CVE-2026-46230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg Check bounds against the end of the BO whenever we access the msg.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46219", "url": "https://ubuntu.com/security/CVE-2026-46219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix use-after-free on unbind The state machine work is scheduled by the interrupt handler and therefore needs to be cancelled after disabling interrupts to avoid a potential use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46236", "url": "https://ubuntu.com/security/CVE-2026-46236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: xbox_remote: heed DMA restrictions The buffer for IO must not be part of the device structure because that violates the DMA coherency rules.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46205", "url": "https://ubuntu.com/security/CVE-2026-46205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: media: atomisp: Disallow all private IOCTLs Disallow all private IOCTLs. These aren't quite as safe as one could assume of IOCTL handlers; disable them for now. Instead of removing the code, return in the beginning of the function if cmd is non-zero in order to keep static checkers happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46168", "url": "https://ubuntu.com/security/CVE-2026-46168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix scheduling with atomic in timestamp sockopt Using lock_sock_fast() (atomic context) around sock_set_timestamp() and sock_set_timestamping() is unsafe, as both helpers can sleep. Replace lock_sock_fast() with sleepable lock_sock()/release_sock() to avoid scheduling while atomic panic.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46189", "url": "https://ubuntu.com/security/CVE-2026-46189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path Sashiko points out that pvrdma_uar_free() is already called within pvrdma_dealloc_ucontext(), so calling it before triggers a double free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46133", "url": "https://ubuntu.com/security/CVE-2026-46133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject unknown opcodes before ICRC processing Even after applying commit 7244491dab34 (\"RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv\"), a single unauthenticated UDP packet can still trigger panic. That patch handled payload_size() underflow only for valid opcodes with short packets, not for packets carrying an unknown opcode. The unknown-opcode OOB read described below predates that commit and reaches back to the initial Soft RoCE driver. The check added there reads pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The rxe_opcode[] array has 256 entries but is only populated for defined IB opcodes; any other entry (for example opcode 0xff) is zero-initialized, so length == 0 and the check degenerates to pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES which underflows when length == 0 and passes a huge value to rxe_crc32(), causing an out-of-bounds read of the skb payload. Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma link add rxe0 type rxe netdev eth0 A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and QPN=IB_MULTICAST_QPN triggers: BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170 Read of size 1 at addr ... The buggy address is located 0 bytes to the right of allocated 704-byte region Call Trace: crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 Subsequent packets with the same shape fault on unmapped memory and panic the kernel. The trigger requires only module load and \"rdma link add\"; no QP, no connection, and no authentication. Fix this by rejecting packets whose opcode has no rxe_opcode[] entry, detected via the zero mask or zero length, before any length arithmetic runs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46127", "url": "https://ubuntu.com/security/CVE-2026-46127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp() Sashiko points out that pd->uctx isn't initialized until late in the function so all these error flow references are NULL and will crash. Use the uctx that isn't NULL.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46178", "url": "https://ubuntu.com/security/CVE-2026-46178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq() Sashiko points out that mlx4_srq_alloc() was not undone during error unwind, add the missing call to mlx4_srq_free().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46112", "url": "https://ubuntu.com/security/CVE-2026-46112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix unlocked call to hns_roce_qp_remove() Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory. Grab the same locks the other two callers use.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46304", "url": "https://ubuntu.com/security/CVE-2026-46304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the final controller reference through nvmet_cq_put(). If that triggers nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on the same nvmet-wq. Call chain: nvmet_tcp_schedule_release_queue() kref_put(&queue->kref, nvmet_tcp_release_queue) nvmet_tcp_release_queue() queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq process_one_work() nvmet_tcp_release_queue_work() nvmet_cq_put(&queue->nvme_cq) nvmet_cq_destroy() nvmet_ctrl_put(cq->ctrl) nvmet_ctrl_free() flush_work(&ctrl->async_event_work) <--- nvmet_wq Previously Scheduled by :- \t\t nvmet_add_async_event \t\t queue_work(nvmet_wq, &ctrl->async_event_work); This trips lockdep with a possible recursive locking warning. [ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55 [ 5223.061801] loop0: detected capacity change from 0 to 2097152 [ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 [ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420) [ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349. [ 5223.128453] nvme nvme1: new ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349 [ 5233.199447] nvme nvme1: Removing ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\" [ 5233.227718] ============================================ [ 5233.231283] WARNING: possible recursive locking detected [ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N [ 5233.238434] -------------------------------------------- [ 5233.241852] kworker/u192:6/2413 is trying to acquire lock: [ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 [ 5233.251438] but task is already holding lock: [ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.261125] other info that might help us debug this: [ 5233.265333] Possible unsafe locking scenario: [ 5233.269217] CPU0 [ 5233.270795] ---- [ 5233.272436] lock((wq_completion)nvmet-wq); [ 5233.275241] lock((wq_completion)nvmet-wq); [ 5233.278020] *** DEADLOCK *** [ 5233.281793] May be due to missing lock nesting notation [ 5233.286195] 3 locks held by kworker/u192:6/2413: [ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0 [ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 [ 5233.304290] stack backtrace: [ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full) [ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST [ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp] [ 5233.306532] Call Trace: [ 5233.306534] [ 5233.306536] dump_stack_lvl+0x73/0xb0 [ 5233.306552] print_deadlock_bug+0x225/0x2f0 [ 5233.306556] __lock_acquire+0x13f0/0x2290 [ 5233.306563] lock_acquire+0xd0/0x300 [ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306571] ? __flush_work+0x20b/0x530 [ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306577] touch_wq_lockdep_map+0x3b/0x90 [ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90 [ 52 ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46161", "url": "https://ubuntu.com/security/CVE-2026-46161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix divide-by-zero in setup_geo() with zero far_copies setup_geo() extracts near_copies (nc) and far_copies (fc) from the user-provided layout parameter without checking for zero. When fc=0 with the \"improved\" far set layout selected, 'geo->far_set_size = disks / fc' triggers a divide-by-zero. Validate nc and fc immediately after extraction, returning -1 if either is zero.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46124", "url": "https://ubuntu.com/security/CVE-2026-46124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate block number from NFS file handle in isofs_export_iget isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker- controlled block number (ifid->block or ifid->parent_block) from the NFS file handle to isofs_export_iget(), which only rejects block == 0 before calling isofs_iget() and ultimately sb_bread(). A crafted file handle with fh_len sufficient to pass the check added by commit 0405d4b63d08 (\"isofs: Prevent the use of too small fid\") can still drive the server to read any in-range block on the backing device as if it were an iso_directory_record. That earlier fix was assigned CVE-2025-37780. sb_bread() on an out-of-range block returns NULL cleanly via the EIO path, so there is no memory-safety violation. For in-range reads of adjacent-partition data on the same block device, the unrelated bytes end up in iso_inode_info fields that reach the NFS client as dentry metadata. The deployment surface (isofs exported over NFS from loop-mounted images) is narrow and requires an authenticated NFS peer, but the malformed-file-handle class is reportable as hardening next to the existing CVE-2025-37780 fix. Reject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent() call sites with a single line.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46303", "url": "https://ubuntu.com/security/CVE-2026-46303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b (\"[PATCH] rock.c: handle corrupted directories\") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 (\"isofs: Fix infinite looping over CE entries\") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.", "cve_priority": "medium", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46294", "url": "https://ubuntu.com/security/CVE-2026-46294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a buffer overflow in ioctl processing Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the \"outptr\" variable to the next 8-byte boundary: \toutptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The \"for\" loop is iterated again, it executes: \tremaining = len - (outptr - outbuf); 5. If \"outptr\" points past \"outbuf + len\", the arithmetics wraps around and the variable \"remaining\" contains unusually high number 6. With \"remaining\" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, \"outptr = align_ptr(outptr)\" can't overshoot the input buffer and the bug can't happen accidentally", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46107", "url": "https://ubuntu.com/security/CVE-2026-46107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-thin: fix metadata refcount underflow There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count. If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in \"device mapper: space map common: unable to decrement block\" errors. Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46301", "url": "https://ubuntu.com/security/CVE-2026-46301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: topcliff-pch: fix use-after-free on unbind Give the driver a chance to flush its queue before releasing the DMA buffers on driver unbind", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46273", "url": "https://ubuntu.com/security/CVE-2026-46273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmveth: Disable GSO for packets with small MSS Some physical adapters on Power systems do not support segmentation offload when the MSS is less than 224 bytes. Attempting to send such packets causes the adapter to freeze, stopping all traffic until manually reset. Implement ndo_features_check to disable GSO for packets with small MSS values. The network stack will perform software segmentation instead. The 224-byte minimum matches ibmvnic commit (\"ibmvnic: Enforce stronger sanity checks on GSO packets\") which uses the same physical adapters in SEA configurations. The issue occurs specifically when the hardware attempts to perform segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets (gso_segs == 1) do not trigger the problematic LSO code path and are transmitted normally without segmentation. Add an ndo_features_check callback to disable GSO when MSS < 224 bytes. Also call vlan_features_check() to ensure proper handling of VLAN packets, particularly QinQ (802.1ad) configurations where the hardware parser may not support certain offload features. Validated using iptables to force small MSS values. Without the fix, the adapter freezes. With the fix, packets are segmented in software and transmission succeeds. Comprehensive regression testing completedd (MSS tests, performance, stability).", "cve_priority": "high", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-43502", "url": "https://ubuntu.com/security/CVE-2026-43502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: handle zerocopy send cleanup before the message is queued A zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket. The purge path currently infers zerocopy state from rm->m_rs, so an unqueued message can be cleaned up as if it owned normal payload pages. However, zerocopy ownership is really determined by the presence of op_mmp_znotifier, regardless of whether the message has reached the socket queue. Capture op_mmp_znotifier up front in rds_message_purge() and use it as the cleanup discriminator. If the message is already associated with a socket, keep the existing completion path. Otherwise, drop the pinned page accounting directly and release the notifier before putting the payload pages. This keeps early send failure cleanup consistent with the zerocopy lifetime rules without changing the normal queued completion path.", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46120", "url": "https://ubuntu.com/security/CVE-2026-46120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: Use cached t->net in ip6erspan_changelink(). After commit 5e72ce3e3980 (\"net: ipv6: Use link netns in newlink() of rtnl_link_ops\"), ip6erspan_newlink() correctly resolves the per-netns ip6gre hash via link_net. ip6erspan_changelink() was not converted in that series and still uses dev_net(dev), which diverges from the device's creation netns after IFLA_NET_NS_FD migration. This re-inserts the tunnel into the wrong per-netns hash. The original netns keeps a stale entry. When that netns is later destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a slab-use-after-free reported by KASAN, followed by a kernel BUG at net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify(). Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). ip6gre_changelink() earlier in the same file already uses the cached t->net; only ip6erspan_changelink() has the wrong shape.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46184", "url": "https://ubuntu.com/security/CVE-2026-46184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sound: ua101: fix division by zero at probe Add a missing sanity check for bNrChannels in detect_usb_format() to prevent a division by zero in playback_urb_complete() and capture_urb_complete(). USB core does not validate class-specific descriptor fields such as bNrChannels, so drivers must verify them before use. If a device provides bNrChannels = 0, frame_bytes becomes zero and is later used as a divisor in the URB completion handlers, leading to a kernel crash.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46132", "url": "https://ubuntu.com/security/CVE-2026-46132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack without initialisation: \tstruct ifla_vf_broadcast vf_broadcast; The struct contains a single fixed 32-byte field: \t/* include/uapi/linux/if_link.h */ \tstruct ifla_vf_broadcast { \t\t__u8 broadcast[32]; \t}; The function then copies dev->broadcast into it using dev->addr_len as the length: \tmemcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len); On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via: \tnla_put(skb, IFLA_VF_BROADCAST, \t\tsizeof(vf_broadcast), &vf_broadcast) leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK request, repeatable. The other vf_* structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vf_vlan_info, node_guid and port_guid a few lines above. vf_broadcast was simply missed when it was added. Reachability: any unprivileged local process can open AF_NETLINK / NETLINK_ROUTE without capabilities and send RTM_GETLINK with an IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nla_put() when reproduced. Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf_* structs in the same function.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46150", "url": "https://ubuntu.com/security/CVE-2026-46150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fanotify: fix false positive on permission events fsnotify_get_mark_safe() may return false for a mark on an unrelated group, which results in bypassing the permission check. Fix by skipping over detached marks that are not in the current group.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45834", "url": "https://ubuntu.com/security/CVE-2026-45834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-45835", "url": "https://ubuntu.com/security/CVE-2026-45835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46186", "url": "https://ubuntu.com/security/CVE-2026-46186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: validate rx pkt_type header length virtbt_rx_handle() reads the leading pkt_type byte from the RX skb and forwards the remainder to hci_recv_frame() for every event/ACL/SCO/ISO type, without checking that the remaining payload is at least the fixed HCI header for that type. After the preceding patch bounds the backend-supplied used.len to [1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches hci_recv_frame() with skb->len already pulled to 0. If the byte happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification fast-path in hci_dev_classify_pkt_type() dereferences hci_acl_hdr(skb)->handle whenever the HCI device has an active CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of uninitialized RX-buffer data. The same hazard exists for every packet type the driver accepts because none of the switch cases in virtbt_rx_handle() check skb->len against the per-type minimum HCI header size before handing the frame to the core. After stripping pkt_type, require skb->len to cover the fixed header size for the selected type (event 2, ACL 4, SCO 3, ISO 4) before calling hci_recv_frame(); drop ratelimited otherwise. Unknown pkt_type values still take the original kfree_skb() default path. Use bt_dev_err_ratelimited() because both the length and pkt_type values come from an untrusted backend that can otherwise flood the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46123", "url": "https://ubuntu.com/security/CVE-2026-46123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: clamp rx length before skb_put virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one(). Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device. The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory. Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle(). Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log. Same class of bug as commit c04db81cd028 (\"net/9p: Fix buffer overflow in USB transport layer\"), which hardened the USB 9p transport against unchecked device-reported length.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46172", "url": "https://ubuntu.com/security/CVE-2026-46172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: xfrm6: release dst on error in xfrm6_rcv_encap() xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6_route_input_lookup() returns a referenced dst entry even when the lookup resolves to an error route. If dst->error is set, xfrm6_rcv_encap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries. Release the dst before jumping to the drop path.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46146", "url": "https://ubuntu.com/security/CVE-2026-46146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3() The convert_chmap_v3() has a loop with its increment size of cs_desc->wLength, but we forgot to validate cs_desc->wLength itself, which may lead to potential endless loop by a malformed descriptor. Add a proper size check to abort the loop for plugging the hole.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46167", "url": "https://ubuntu.com/security/CVE-2026-46167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. Ideally that short command should be detected and error out, but many printers are known to send \"incorrect\" responses back so we can't just do that. statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl. usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller. Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no \"leak\" of information happening.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46151", "url": "https://ubuntu.com/security/CVE-2026-46151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix heap leak in IEEE 1284 device ID via short response usblp_ctrl_msg() collapses the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GET_DEVICE_ID control transfer short and the driver has no way to know. usblp_cache_device_id_string() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves device_id_string[2..1022] holding stale kmalloc heap. That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf(\"%s\", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device. Fix this up by just zapping the buffer with zeros before each request sent to the device.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46122", "url": "https://ubuntu.com/security/CVE-2026-46122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43: enforce bounds check on firmware key index in b43_rx() The firmware-controlled key index in b43_rx() can exceed the dev->key[] array size (58 entries). The existing B43_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read. Make the B43_WARN_ON check enforcing by dropping the frame when the firmware returns an invalid key index.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46307", "url": "https://ubuntu.com/security/CVE-2026-46307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath5k: do not access array OOB Vincent reports: > The ath5k driver seems to do an array-index-out-of-bounds access as > shown by the UBSAN kernel message: > UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20 > index 4 is out of range for type 'ieee80211_tx_rate [4]' > ... > Call Trace: > > dump_stack_lvl+0x5d/0x80 > ubsan_epilogue+0x5/0x2b > __ubsan_handle_out_of_bounds.cold+0x46/0x4b > ath5k_tasklet_tx+0x4e0/0x560 [ath5k] > tasklet_action_common+0xb5/0x1c0 It is real. 'ts->ts_final_idx' can be 3 on 5212, so: info->status.rates[ts->ts_final_idx + 1].idx = -1; with the array defined as: struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES]; while the size is: #define IEEE80211_TX_MAX_RATES 4 is indeed bogus. Set this 'idx = -1' sentinel only if the array index is less than the array size. As mac80211 will not look at rates beyond the size (IEEE80211_TX_MAX_RATES). Note: The effect of the OOB write is negligible. It just overwrites the next member of info->status, i.e. ack_signal.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46187", "url": "https://ubuntu.com/security/CVE-2026-46187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: fix kthread lifetime race between self-exit and external-stop RSI driver use both self-exit(kthread_complete_and_exit) and external-stop (kthread_stop) when killing a kthread. Generally, kthread_stop() is called first, and in this case, no particular issues occur. However, in rare instances where kthread_complete_and_exit() is called first and then kthread_stop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again. Therefore, to prevent this with minimal modification, you must remove kthread_stop() and change the code to wait until the self-exit operation is completed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46163", "url": "https://ubuntu.com/security/CVE-2026-46163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43legacy: enforce bounds check on firmware key index in RX path Same fix as b43: the firmware-controlled key index in b43legacy_rx() can exceed dev->max_nr_keys. The existing B43legacy_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read of dev->key[]. Make the check enforcing by dropping the frame for invalid indices.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46044", "url": "https://ubuntu.com/security/CVE-2026-46044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:ssif: Clean up kthread on errors If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43496", "url": "https://ubuntu.com/security/CVE-2026-43496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peeked When red qdisc has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] [ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq] [ 78.672148][ T363] ? __pfx__printk+0x10/0x10 [ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0 [ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0 [ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red] [ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf] [ 78.673566][ T363] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead.", "cve_priority": "medium", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2024-56727", "url": "https://ubuntu.com/security/CVE-2024-56727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c Adding error pointer check after calling otx2_mbox_get_rsp().", "cve_priority": "medium", "cve_public_date": "2024-12-29 12:15:00 UTC" }, { "cve": "CVE-2026-31489", "url": "https://ubuntu.com/security/CVE-2026-31489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: meson-spicc: Fix double-put in remove path meson_spicc_probe() registers the controller with devm_spi_register_controller(), so teardown already drops the controller reference via devm cleanup. Calling spi_controller_put() again in meson_spicc_remove() causes a double-put.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31476", "url": "https://ubuntu.com/security/CVE-2026-31476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: do not expire session on binding failure When a multichannel session binding request fails (e.g. wrong password), the error path unconditionally sets sess->state = SMB2_SESSION_EXPIRED. However, during binding, sess points to the target session looked up via ksmbd_session_lookup_slowpath() -- which belongs to another connection's user. This allows a remote attacker to invalidate any active session by simply sending a binding request with a wrong password (DoS). Fix this by skipping session expiration when the failed request was a binding attempt, since the session does not belong to the current connection. The reference taken by ksmbd_session_lookup_slowpath() is still correctly released via ksmbd_user_session_put().", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43497", "url": "https://ubuntu.com/security/CVE-2026-43497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages to userspace but sets no vm_ops on the VMA. This means the kernel cannot track active mmaps. When dlfb_realloc_framebuffer() replaces the backing buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated. On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages while userspace PTEs still reference them, resulting in a use-after-free: the process retains read/write access to freed kernel pages. Add vm_operations_struct with open/close callbacks that maintain an atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(), check mmap_count and return -EBUSY if the buffer is currently mapped, preventing buffer replacement while userspace holds stale PTEs. Tested with PoC using dummy_hcd + raw_gadget USB device emulation.", "cve_priority": "low", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46108", "url": "https://ubuntu.com/security/CVE-2026-46108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:si: Return state to normal if message allocation fails There were places where nothing would get started if a message allocation failed, so the driver needs to return to normal state.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46128", "url": "https://ubuntu.com/security/CVE-2026-46128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Check event message buffer response for bad data The event message buffer response data size got checked later when processing, but check it right after the response comes back. It appears some BMCs may return an empty message instead of an error when fetching events. There are apparently some new BMCs that make this error, so we need to compensate.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46177", "url": "https://ubuntu.com/security/CVE-2026-46177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Add limits to event and receive message requests The driver would just fetch events and receive messages until the BMC said it was done. To avoid issues with BMCs that never say they are done, add a limit of 10 fetches at a time. In addition, an si interface has an attn state it can return from the hardware which is supposed to cause a flag fetch to see if the driver needs to fetch events or message or a few other things. If the attn bit gets stuck, it's a similar problem. So allow messages in between flag fetches so the driver itself doesn't get stuck. This is a more general fix than the previous fix for the specific bad BMC, but should fix the more general issue of a BMC that won't stop saying it has data. This has been there from the beginning of the driver. It's not a bug per-se, but it is accounting for bugs in BMCs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46149", "url": "https://ubuntu.com/security/CVE-2026-46149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show() target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered. Commit 27e06650a5ea (\"scsi: target: target_core_configfs: Add length check to avoid buffer overflow\") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46101", "url": "https://ubuntu.com/security/CVE-2026-46101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: reject zero shift in nft_bitwise Reject zero shift operands for nft_bitwise left and right shift expressions during initialization. The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour. Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46099", "url": "https://ubuntu.com/security/CVE-2026-46099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels seg6_input_core() and rpl_input() call ip6_route_input() which sets a NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking dst_hold() unconditionally. On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpu_rt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence: ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1] rt_genid_bump_ipv6() -> bumps fib6_sernum [fib6_sernum from W to Z] ip6_route_output() -> ip6_pol_route() -> FIB lookup resolves fib6_nh [nhid=N] -> rt6_get_pcpu_route() pcpu_rt->sernum != fib6_sernum [W <> Z, stale] -> prev = xchg(rt6i_pcpu, NULL) -> dst_release(prev) [prev is pcpu_rt, refcount 1->0, dead] dst = skb_dst(skb) [dst is the dead pcpu_rt] dst_cache_set_ip6(dst) -> dst_hold() on dead dst -> WARN / use-after-free For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release the pcpu_rt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6_nh and its rt6i_pcpu entry. Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after ip6_route_input() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6_route_output() already returns a refcounted dst.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46033", "url": "https://ubuntu.com/security/CVE-2026-46033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject short ahash digests during instance creation authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46062", "url": "https://ubuntu.com/security/CVE-2026-46062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix integer overflow in run_unpack() volume boundary check The volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses raw addition which can wrap around for large lcn and len values, bypassing the validation. Use check_add_overflow() as is already done for the adjacent prev_lcn + dlcn and vcn64 + len checks added by commit 3ac37e100385 (\"ntfs3: Fix integer overflow in run_unpack()\"). Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46072", "url": "https://ubuntu.com/security/CVE-2026-46072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: add buffer boundary checks to run_unpack() run_unpack() checks `run_buf < run_last` at the top of the while loop but then reads size_size and offset_size bytes via run_unpack_s64() without verifying they fit within the remaining buffer. A crafted NTFS image with truncated run data in an MFT attribute triggers an OOB heap read of up to 15 bytes when the filesystem is mounted. Add boundary checks before each run_unpack_s64() call to ensure the declared field size does not exceed the remaining buffer. Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46023", "url": "https://ubuntu.com/security/CVE-2026-46023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm mirror: fix integer overflow in create_dirty_log() The argument count calculation in create_dirty_log() performs `*args_used = 2 + param_count` before validating against argc. When a user provides a param_count close to UINT_MAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent `argc < *args_used` check to be bypassed. The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array. Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46077", "url": "https://ubuntu.com/security/CVE-2026-46077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-tdes - fix DMA sync direction Before DMA output is consumed by the CPU, ->dma_addr_out must be synced with dma_sync_single_for_cpu() instead of dma_sync_single_for_device(). Using the wrong direction can return stale cache data on non-coherent platforms.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45986", "url": "https://ubuntu.com/security/CVE-2026-45986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccree - fix a memory leak in cc_mac_digest() Add cc_unmap_result() if cc_map_hash_request_final() fails to prevent potential memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46019", "url": "https://ubuntu.com/security/CVE-2026-46019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the first page using free_page(), leaking the remaining 3 pages. Use free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46015", "url": "https://ubuntu.com/security/CVE-2026-46015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: call sk_data_ready() after listener migration When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46040", "url": "https://ubuntu.com/security/CVE-2026-46040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails When fsnotify_add_inode_mark_locked() fails in inotify_new_watch(), the error path calls inotify_remove_from_idr() but does not call dec_inotify_watches() to undo the preceding inc_inotify_watches(). This leaks a watch count, and repeated failures can exhaust the max_user_watches limit with -ENOSPC even when no watches are active. Prior to commit 1cce1eea0aff (\"inotify: Convert to using per-namespace limits\"), the watch count was incremented after fsnotify_add_mark_locked() succeeded, so this path was not affected. The conversion moved inc_inotify_watches() before the mark insertion without adding the corresponding rollback. Add the missing dec_inotify_watches() call in the error path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46070", "url": "https://ubuntu.com/security/CVE-2026-46070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: validate payload size before accessing journal metadata r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block. A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets. Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46051", "url": "https://ubuntu.com/security/CVE-2026-46051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix soft lockup in retry_aligned_read() When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46046", "url": "https://ubuntu.com/security/CVE-2026-46046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all() The commit c8e008b60492 (\"ext4: ignore xattrs past end\") introduced a refcount leak in when block_csum is false. ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to get iloc.bh, but never releases it with brelse().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46285", "url": "https://ubuntu.com/security/CVE-2026-46285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: docg3: fix use-after-free in docg3_release() In docg3_release(), the docg3 pointer is obtained from cascade->floors[0]->priv before the loop that calls doc_release_device() on each floor. doc_release_device() frees the docg3 struct via kfree(docg3) at line 1881. After the loop, docg3->cascade->bch dereferences the already-freed pointer. Fix this by accessing cascade->bch directly, which is equivalent since docg3->cascade points back to the same cascade struct, and is already available as a local variable. This also removes the now-unused docg3 local variable.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46082", "url": "https://ubuntu.com/security/CVE-2026-46082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. [sean: tag for stable@]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45987", "url": "https://ubuntu.com/security/CVE-2026-45987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2 After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46024", "url": "https://ubuntu.com/security/CVE-2026-46024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply() If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for both protocol and result, this is currently not treated as an error. In case of ac->negotiating == true and ac->protocol > 0, this leads to setting ac->protocol = 0 and ac->ops = NULL. Thereafter, the check for ac->protocol != protocol returns false, and init_protocol() is not called. Subsequently, ac->ops->handle_reply() is called, which leads to a null pointer dereference, because ac->ops is still NULL. This patch changes the check for ac->protocol != protocol to !ac->protocol, as this also includes the case when the protocol was set to zero in the message. This causes the message to be treated as containing a bad auth protocol.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46037", "url": "https://ubuntu.com/security/CVE-2026-46037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: validate reply type before using icmp_pointers Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type. That value is outside the range covered by icmp_pointers[], which only describes the traditional ICMP types up to NR_ICMP_TYPES. Avoid consulting icmp_pointers[] for reply types outside that range, and use array_index_nospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46027", "url": "https://ubuntu.com/security/CVE-2026-46027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid early lgr access in smc_clc_wait_msg A CLC decline can be received while the handshake is still in an early stage, before the connection has been associated with a link group. The decline handling in smc_clc_wait_msg() updates link-group level sync state for first-contact declines, but that state only exists after link group setup has completed. Guard the link-group update accordingly and keep the per-socket peer diagnosis handling unchanged. This preserves the existing sync_err handling for established link-group contexts and avoids touching link-group state before it is available.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46053", "url": "https://ubuntu.com/security/CVE-2026-46053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: fix MR cleanup on copy error __rds_rdma_map() hands sg/pages ownership to the transport after get_mr() succeeds. If copying the generated cookie back to user space fails after that point, the error path must not free those resources again before dropping the MR reference. Remove the duplicate unpin/free from the put_user() failure branch so that MR teardown is handled only through the existing final cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46004", "url": "https://ubuntu.com/security/CVE-2026-46004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Handle probe errors properly The probe procedure of setup_card() in caiaq driver doesn't treat the error cases gracefully, e.g. the error from snd_card_register() calls snd_card_free() but continues. This would lead to a UAF for the further calls like snd_usb_caiaq_control_init(), as Berk suggested in another patch in the link below. However, the problem is not only that; in general, this function drops the all error handlings (as it's a void function) although its caller can propagate an error to snd_probe(), which eventually calls snd_card_free() as a proper error path. That said, we should treat each error case in setup_card(), and just return the error code promptly, which is then handled later as a fatal error in snd_probe(). This patch achieves it by changing the setup_card() to return an error code. Also, the superfluous snd_card_free() call is removed, too. Note that card->private_free can be set still safely at returning an error. All called functions in card_free() have checks of the unassigned resources or NULL checks.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46050", "url": "https://ubuntu.com/security/CVE-2026-46050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix deadlock with check operation and nowait requests When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b (\"raid10: cleanup memleak at raid10_make_request\") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case. This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0. Output of r10conf state of the array when we hit this condition: crash> struct r10conf \tbarrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0, Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier(): md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46049", "url": "https://ubuntu.com/security/CVE-2026-46049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Add fallback to default RSR for S/PDIF spdif_passthru_playback_get_resources() uses atc->pll_rate as the RSR for the MSR calculation loop. However, pll_rate is only updated in atc_pll_init() and not in hw_pll_init(), so it remains 0 after the card init. When spdif_passthru_playback_setup() skips atc_pll_init() for 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin indefinitely. Add fallback to use atc->rsr when atc->pll_rate is 0. This reflects the hardware state, since hw_card_init() already configures the PLL to the default RSR.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46002", "url": "https://ubuntu.com/security/CVE-2026-46002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext2: reject inodes with zero i_nlink and valid mode in ext2_iget() ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is zero or i_dtime is set, treating them as deleted. However, the case of i_nlink == 0 with a non-zero mode and zero dtime slips through. Since ext2 has no orphan list, such a combination can only result from filesystem corruption - a legitimate inode deletion always sets either i_dtime or clears i_mode before freeing the inode. A crafted image can exploit this gap to present such an inode to the VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via ext2_unlink(), ext2_rename() and ext2_rmdir(): WARNING: CPU: 3 PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295 vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477 do_unlinkat+0x53e/0x730 fs/namei.c:4541 __x64_sys_unlink+0xc6/0x110 fs/namei.c:4587 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 646 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rename+0x35e/0x850 fs/ext2/namei.c:374 vfs_rename+0xf2f/0x2060 fs/namei.c:5021 do_renameat2+0xbe2/0xd50 fs/namei.c:5178 __x64_sys_rename+0x7e/0xa0 fs/namei.c:5223 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 634 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311 vfs_rmdir+0x204/0x690 fs/namei.c:4348 do_rmdir+0x372/0x3e0 fs/namei.c:4407 __x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Extend the existing i_nlink == 0 check to also catch this case, reporting the corruption via ext2_error() and returning -EFSCORRUPTED. This rejects the inode at load time and prevents it from reaching any of the namei.c paths. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46047", "url": "https://ubuntu.com/security/CVE-2026-46047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Fix use-after-free in driver remove() In the remove callback, if a packet arrives after destroy_workqueue() is called, but before sock_release(), the qrtr_ns_data_ready() callback will try to queue the work, causing use-after-free issue. Fix this issue by saving the default 'sk_data_ready' callback during qrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback at the start of remove(). This ensures that even if a packet arrives after destroy_workqueue(), the work struct will not be dereferenced. Note that it is also required to ensure that the RX threads are completed before destroying the workqueue, because the threads could be using the qrtr_ns_data_ready() callback.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46009", "url": "https://ubuntu.com/security/CVE-2026-46009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to do later. This leads to an oops when .allow_link fails or when .drop_link is performed. Remove the helper. Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46102", "url": "https://ubuntu.com/security/CVE-2026-46102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: strparser: fix skb_head leak in strp_abort_strp() When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46098", "url": "https://ubuntu.com/security/CVE-2026-46098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: caif: clear client service pointer on teardown `caif_connect()` can tear down an existing client after remote shutdown by calling `caif_disconnect_client()` followed by `caif_free_client()`. `caif_free_client()` releases the service layer referenced by `adap_layer->dn`, but leaves that pointer stale. When the socket is later destroyed, `caif_sock_destructor()` calls `caif_free_client()` again and dereferences the freed service pointer. Clear the client/service links before releasing the service object so repeated teardown becomes harmless.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46088", "url": "https://ubuntu.com/security/CVE-2026-46088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names() snd_ctl_elem_init_enum_names() advances pointer p through the names buffer while decrementing buf_len. If buf_len reaches zero but items remain, the next iteration calls strnlen(p, 0). While strnlen(p, 0) returns 0 and would hit the existing name_len == 0 error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks maxlen against __builtin_dynamic_object_size(). When Clang loses track of p's object size inside the loop, this triggers a BRK exception panic before the return value is examined. Add a buf_len == 0 guard at the loop entry to prevent calling fortified strnlen() on an exhausted buffer. Found by kernel fuzz testing through Xiaomi Smartphone.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46080", "url": "https://ubuntu.com/security/CVE-2026-46080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: split transactions in dio completion to avoid credit exhaustion During ocfs2 dio operations, JBD2 may report warnings via following call trace: ocfs2_dio_end_io_write ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_split_extent ocfs2_try_to_merge_extent ocfs2_extend_rotate_transaction ocfs2_extend_trans jbd2__journal_restart start_this_handle output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449 To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to handle extents in a batch of transaction. Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode should only be removed from the orphan list after the extent tree update is complete. This ensures that if a crash occurs in the middle of extent tree updates, we won't leave stale blocks beyond EOF. This patch also changes the logic for updating the inode size and removing orphan, making it similar to ext4_dio_write_end_io(). Both operations are performed only when everything looks good. Finally, thanks to Jans and Joseph for providing the bug fix prototype and suggestions.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-21739", "url": "https://ubuntu.com/security/CVE-2025-21739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix use-after free in init error and remove paths devm_blk_crypto_profile_init() registers a cleanup handler to run when the associated (platform-) device is being released. For UFS, the crypto private data and pointers are stored as part of the ufs_hba's data structure 'struct ufs_hba::crypto_profile'. This structure is allocated as part of the underlying ufshcd and therefore Scsi_host allocation. During driver release or during error handling in ufshcd_pltfrm_init(), this structure is released as part of ufshcd_dealloc_host() before the (platform-) device associated with the crypto call above is released. Once this device is released, the crypto cleanup code will run, using the just-released 'struct ufs_hba::crypto_profile'. This causes a use-after-free situation: Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0 In other words, the initialisation code flow is: platform-device probe ufshcd_pltfrm_init() ufshcd_alloc_host() scsi_host_alloc() allocation of struct ufs_hba creation of scsi-host devices devm_blk_crypto_profile_init() devm registration of cleanup handler using platform-device and during error handling of ufshcd_pltfrm_init() or during driver removal: ufshcd_dealloc_host() scsi_host_put() put_device(scsi-host) release of struct ufs_hba put_device(platform-device) crypto cleanup handler To fix this use-after free, change ufshcd_alloc_host() to register a devres action to automatically cleanup the underlying SCSI device on ufshcd destruction, without requiring explicit calls to ufshcd_dealloc_host(). This way: * the crypto profile and all other ufs_hba-owned resources are destroyed before SCSI (as they've been registered after) * a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as it's not needed anymore * no future drivers using ufshcd_alloc_host() could ever forget adding the cleanup", "cve_priority": "low", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2026-46064", "url": "https://ubuntu.com/security/CVE-2026-46064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix heap over-read in ibmasm_send_i2o_message() The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO. Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure. Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controller's free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it. Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45994", "url": "https://ubuntu.com/security/CVE-2026-45994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix OOB reads in command_file_write due to missing size checks The command_file_write() handler allocates a kernel buffer of exactly count bytes and copies user data into it, but does not validate the buffer against the dot command protocol before passing it to get_dot_command_size() and get_dot_command_timeout(). Since both the allocation size (count) and the header fields (command_size, data_size) are independently user-controlled, an attacker can cause get_dot_command_size() to return a value exceeding the allocation, triggering OOB reads in get_dot_command_timeout() and an out-of-bounds memcpy_toio() that leaks kernel heap memory to the service processor. Fix with two guards: reject writes smaller than sizeof(struct dot_command_header) before allocation, then after copying user data reject commands where the buffer is smaller than the total size declared by the header (sizeof(header) + command_size + data_size). This ensures all subsequent header and payload field accesses stay within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46022", "url": "https://ubuntu.com/security/CVE-2026-46022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt() ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60). A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started. The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes: queue_begin + reader * sizeof(struct remote_input) with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception. Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46006", "url": "https://ubuntu.com/security/CVE-2026-46006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix u32 overflow in pushbuf reloc bounds check nouveau_gem_pushbuf_reloc_apply() validates each relocation with if (r->reloc_bo_offset + 4 > nvbo->bo.base.size) but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size. Cast to u64 so the addition happens in 64-bit arithmetic. [ Add Fixes: tag. - Danilo ]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46018", "url": "https://ubuntu.com/security/CVE-2026-46018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES parse_uac2_sample_rate_range() caps the number of enumerated rates at MAX_NR_RATES, but it only breaks out of the current rate loop. A malformed UAC2 RANGE response with additional triplets continues parsing the remaining triplets and repeatedly prints \"invalid uac2 rates\" while probe still holds register_mutex. Stop the whole parse once the cap is reached and return the number of rates collected so far.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-31696", "url": "https://ubuntu.com/security/CVE-2026-31696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing validation of ticket length in non-XDR key preparsing In rxrpc_preparse(), there are two paths for parsing key payloads: the XDR path (for large payloads) and the non-XDR path (for payloads <= 28 bytes). While the XDR path (rxrpc_preparse_xdr_rxkad()) correctly validates the ticket length against AFSTOKEN_RK_TIX_MAX, the non-XDR path fails to do so. This allows an unprivileged user to provide a very large ticket length. When this key is later read via rxrpc_read(), the total token size (toksize) calculation results in a value that exceeds AFSTOKEN_LENGTH_MAX, triggering a WARN_ON(). [ 2001.302904] WARNING: CPU: 2 PID: 2108 at net/rxrpc/key.c:778 rxrpc_read+0x109/0x5c0 [rxrpc] Fix this by adding a check in the non-XDR parsing path of rxrpc_preparse() to ensure the ticket length does not exceed AFSTOKEN_RK_TIX_MAX, bringing it into parity with the XDR parsing logic.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31697", "url": "https://ubuntu.com/security/CVE-2026-31697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388 CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31698", "url": "https://ubuntu.com/security/CVE-2026-31698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033 CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31699", "url": "https://ubuntu.com/security/CVE-2026-31699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405 CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31701", "url": "https://ubuntu.com/security/CVE-2026-31701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: take a reference on the USB device in create_card() The caiaq driver stores a pointer to the parent USB device in cdev->chip.dev but never takes a reference on it. The card's private_free callback, snd_usb_caiaq_card_free(), can run asynchronously via snd_card_free_when_closed() after the USB device has already been disconnected and freed, so any access to cdev->chip.dev in that path dereferences a freed usb_device. On top of the refcounting issue, the current card_free implementation calls usb_reset_device(cdev->chip.dev). A reset in a free callback is inappropriate: the device is going away, the call takes the device lock in a teardown context, and the reset races with the disconnect path that the callback is already cleaning up after. Take a reference on the USB device in create_card() with usb_get_dev(), drop it with usb_put_dev() in the free callback, and remove the usb_reset_device() call.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31694", "url": "https://ubuntu.com/security/CVE-2026-31694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject oversized dirents in page cache fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31716", "url": "https://ubuntu.com/security/CVE-2026-31716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate rec->used in journal-replay file record check check_file_record() validates rec->total against the record size but never validates rec->used. The do_action() journal-replay handlers read rec->used from disk and use it to compute memmove lengths: DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next)) When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall. This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay Fix this up by bounding rec->used correctly. This is much like commit b2bc7c44ed17 (\"fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\") which checked different values in this same switch statement.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31676", "url": "https://ubuntu.com/security/CVE-2026-31676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31409", "url": "https://ubuntu.com/security/CVE-2026-31409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: unset conn->binding on failed binding request When a multichannel SMB2_SESSION_SETUP request with SMB2_SESSION_REQ_FLAG_BINDING fails ksmbd sets conn->binding = true but never clears it on the error path. This leaves the connection in a binding state where all subsequent ksmbd_session_lookup_all() calls fall back to the global sessions table. This fix it by clearing conn->binding = false in the error path.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2023-53596", "url": "https://ubuntu.com/security/CVE-2023-53596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: base: Free devm resources when unregistering a device In the current code, devres_release_all() only gets called if the device has a bus and has been probed. This leads to issues when using bus-less or driver-less devices where the device might never get freed if a managed resource holds a reference to the device. This is happening in the DRM framework for example. We should thus call devres_release_all() in the device_del() function to make sure that the device-managed actions are properly executed when the device is unregistered, even if it has neither a bus nor a driver. This is effectively the same change than commit 2f8d16a996da (\"devres: release resources on device_del()\") that got reverted by commit a525a3ddeaca (\"driver core: free devres in device_release\") over memory leaks concerns. This patch effectively combines the two commits mentioned above to release the resources both on device_del() and device_release() and get the best of both worlds.", "cve_priority": "low", "cve_public_date": "2025-10-04 16:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2025-38192", "url": "https://ubuntu.com/security/CVE-2025-38192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: clear the dst when changing skb protocol A not-so-careful NAT46 BPF program can crash the kernel if it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10) The output interface has a 4->6 program attached at ingress. We try to loop the multicast skb back to the sending socket. Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr and changes skb->protocol to v6. We enter ip6_rcv_core which tries to use skb_dst(). But the dst is still an IPv4 one left after IPv4 mcast output. Clear the dst in all BPF helpers which change the protocol. Try to preserve metadata dsts, those may carry non-routing metadata.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-21712", "url": "https://ubuntu.com/security/CVE-2025-21712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime After commit ec6bb299c7c3 (\"md/md-bitmap: add 'sync_size' into struct md_bitmap_stats\"), following panic is reported: Oops: general protection fault, probably for non-canonical address RIP: 0010:bitmap_get_stats+0x2b/0xa0 Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Root cause is that bitmap_get_stats() can be called at anytime if mddev is still there, even if bitmap is destroyed, or not fully initialized. Deferenceing bitmap in this case can crash the kernel. Meanwhile, the above commit start to deferencing bitmap->storage, make the problem easier to trigger. Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2026-43328", "url": "https://ubuntu.com/security/CVE-2026-43328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error path When kobject_init_and_add() fails, cpufreq_dbs_governor_init() calls kobject_put(&dbs_data->attr_set.kobj). The kobject release callback cpufreq_dbs_data_release() calls gov->exit(dbs_data) and kfree(dbs_data), but the current error path then calls gov->exit(dbs_data) and kfree(dbs_data) again, causing a double free. Keep the direct kfree(dbs_data) for the gov->init() failure path, but after kobject_init_and_add() has been called, let kobject_put() handle the cleanup through cpufreq_dbs_data_release().", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-23066", "url": "https://ubuntu.com/security/CVE-2026-23066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recvmsg() unconditional requeue If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at the front of the recvmsg queue already has its mutex locked, it requeues the call - whether or not the call is already queued. The call may be on the queue because MSG_PEEK was also passed and so the call was not dequeued or because the I/O thread requeued it. The unconditional requeue may then corrupt the recvmsg queue, leading to things like UAFs or refcount underruns. Fix this by only requeuing the call if it isn't already on the queue - and moving it to the front if it is already queued. If we don't queue it, we have to put the ref we obtained by dequeuing it. Also, MSG_PEEK doesn't dequeue the call so shouldn't call rxrpc_notify_socket() for the call if we didn't use up all the data on the queue, so fix that also.", "cve_priority": "high", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-27407", "url": "https://ubuntu.com/security/CVE-2024-27407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fixed overflow check in mi_enum_attr()", "cve_priority": "high", "cve_public_date": "2024-05-17 12:15:00 UTC" }, { "cve": "CVE-2023-45896", "url": "https://ubuntu.com/security/CVE-2023-45896", "cve_description": "ntfs3 in the Linux kernel through 6.8.0 allows a physically proximate attacker to read kernel memory by mounting a filesystem (e.g., if a Linux distribution is configured to allow unprivileged mounts of removable media) and then leveraging local access to trigger an out-of-bounds read. A length value can be larger than the amount of memory allocated. NOTE: the supplier's perspective is that there is no vulnerability when an attack requires an attacker-modified filesystem image.", "cve_priority": "medium", "cve_public_date": "2024-08-28 05:15:00 UTC" }, { "cve": "CVE-2023-52737", "url": "https://ubuntu.com/security/CVE-2023-52737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: lock the inode in shared mode before starting fiemap Currently fiemap does not take the inode's lock (VFS lock), it only locks a file range in the inode's io tree. This however can lead to a deadlock if we have a concurrent fsync on the file and fiemap code triggers a fault when accessing the user space buffer with fiemap_fill_next_extent(). The deadlock happens on the inode's i_mmap_lock semaphore, which is taken both by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by syzbot and triggers a trace like the following: task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 wait_on_state fs/btrfs/extent-io-tree.c:707 [inline] wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751 lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742 find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488 writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863 __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174 extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091 extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211 do_writepages+0x3c3/0x680 mm/page-writeback.c:2581 filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388 __filemap_fdatawrite_range mm/filemap.c:421 [inline] filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439 btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline] start_ordered_ops fs/btrfs/file.c:1737 [inline] btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839 generic_write_sync include/linux/fs.h:2885 [inline] btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684 call_write_iter include/linux/fs.h:2189 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9 RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006 RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8 INFO: task syz-executor361:5697 blocked for more than 145 seconds. Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095 __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260 btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526 do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947 wp_page_shared+0x15e/0x380 mm/memory.c:3295 handle_pte_fault mm/memory.c:4949 [inline] __handle_mm_fault mm/memory.c:5073 [inline] handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219 do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428 handle_page_fault arch/x86/mm/fault.c:1519 [inline] exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233 Code: 74 0a 89 (...) RSP: 0018:ffffc9000570f330 EFLAGS: 000502 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-05-21 16:15:00 UTC" }, { "cve": "CVE-2025-38626", "url": "https://ubuntu.com/security/CVE-2025-38626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode w/ \"mode=lfs\" mount option, generic/299 will cause system panic as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2835! Call Trace: f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720 The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may trigger foreground gc only if it allocates any physical block, it will be a little bit later when there is multiple threads writing data w/ aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so f2fs_map_blocks() does block allocations aggressively. In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_blocks().", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2024-46770", "url": "https://ubuntu.com/security/CVE-2024-46770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Add netif_device_attach/detach into PF reset flow Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. getting coalesce settings can result in a NULL pointer dereference seen below. Reproduction steps: Once the driver is fully initialized, trigger reset: \t# echo 1 > /sys/class/net//device/reset when reset is in progress try to get coalesce settings using ethtool: \t# ethtool -c BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7 RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice] RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206 RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000 R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40 FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0 Call Trace: ice_get_coalesce+0x17/0x30 [ice] coalesce_prepare_data+0x61/0x80 ethnl_default_doit+0xde/0x340 genl_family_rcv_msg_doit+0xf2/0x150 genl_rcv_msg+0x1b3/0x2c0 netlink_rcv_skb+0x5b/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x19c/0x290 netlink_sendmsg+0x222/0x490 __sys_sendto+0x1df/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7faee60d8e27 Calling netif_device_detach() before reset makes the net core not call the driver when ethtool command is issued, the attempt to execute an ethtool command during reset will result in the following message: netlink error: No such device instead of NULL pointer dereference. Once reset is done and ice_rebuild() is executing, the netif_device_attach() is called to allow for ethtool operations to occur again in a safe manner.", "cve_priority": "medium", "cve_public_date": "2024-09-18 08:15:00 UTC" }, { "cve": "CVE-2025-38105", "url": "https://ubuntu.com/security/CVE-2025-38105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Kill timer properly at removal The USB-audio MIDI code initializes the timer, but in a rare case, the driver might be freed without the disconnect call. This leaves the timer in an active state while the assigned object is released via snd_usbmidi_free(), which ends up with a kernel warning when the debug configuration is enabled, as spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be killed properly. While we're at it, replace the existing timer_delete_sync() at the disconnect callback with timer_shutdown_sync(), too.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2024-27389", "url": "https://ubuntu.com/security/CVE-2024-27389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore: inode: Only d_invalidate() is needed Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning: WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410 Using the combo of d_drop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use d_invalidate() and update the code to not bother checking for error codes that can never happen. ---", "cve_priority": "medium", "cve_public_date": "2024-05-01 13:15:00 UTC" }, { "cve": "CVE-2023-52682", "url": "https://ubuntu.com/security/CVE-2023-52682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait on block writeback for post_read case If inode is compressed, but not encrypted, it missed to call f2fs_wait_on_block_writeback() to wait for GCed page writeback in IPU write path. Thread A\t\t\t\tGC-Thread \t\t\t\t\t- f2fs_gc \t\t\t\t\t - do_garbage_collect \t\t\t\t\t - gc_data_segment \t\t\t\t\t - move_data_block \t\t\t\t\t - f2fs_submit_page_write \t\t\t\t\t migrate normal cluster's block via \t\t\t\t\t meta_inode's page cache - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_submit_page_bio IRQ - f2fs_read_end_io \t\t\t\t\tIRQ \t\t\t\t\told data overrides new data due to \t\t\t\t\tout-of-order GC and common IO. \t\t\t\t\t- f2fs_read_end_io", "cve_priority": "medium", "cve_public_date": "2024-05-17 15:15:00 UTC" }, { "cve": "CVE-2024-56719", "url": "https://ubuntu.com/security/CVE-2024-56719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix TSO DMA API usage causing oops Commit 66600fac7a98 (\"net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data\") moved the assignment of tx_skbuff_dma[]'s members to be later in stmmac_tso_xmit(). The buf (dma cookie) and len stored in this structure are passed to dma_unmap_single() by stmmac_tx_clean(). The DMA API requires that the dma cookie passed to dma_unmap_single() is the same as the value returned from dma_map_single(). However, by moving the assignment later, this is not the case when priv->dma_cap.addr64 > 32 as \"des\" is offset by proto_hdr_len. This causes problems such as: dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed and with DMA_API_DEBUG enabled: DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes] Fix this by maintaining \"des\" as the original DMA cookie, and use tso_des to pass the offset DMA cookie to stmmac_tso_allocator(). Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/", "cve_priority": "medium", "cve_public_date": "2024-12-29 09:15:00 UTC" }, { "cve": "CVE-2024-41079", "url": "https://ubuntu.com/security/CVE-2024-41079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: always initialize cqe.result The spec doesn't mandate that the first two double words (aka results) for the command queue entry need to be set to 0 when they are not used (not specified). Though, the target implemention returns 0 for TCP and FC but not for RDMA. Let's make RDMA behave the same and thus explicitly initializing the result field. This prevents leaking any data from the stack.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2023-53545", "url": "https://ubuntu.com/security/CVE-2023-53545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: unmap and remove csa_va properly Root PD BO should be reserved before unmap and remove a bo_va from VM otherwise lockdep will complain. v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian) [14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu] [14616.937096] Call Trace: [14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu] [14616.937187] drm_file_free+0x1d6/0x300 [drm] [14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm] [14616.937220] drm_release+0x5e/0x100 [drm] [14616.937234] __fput+0x9f/0x280 [14616.937239] ____fput+0xe/0x20 [14616.937241] task_work_run+0x61/0x90 [14616.937246] exit_to_user_mode_prepare+0x215/0x220 [14616.937251] syscall_exit_to_user_mode+0x2a/0x60 [14616.937254] do_syscall_64+0x48/0x90 [14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd", "cve_priority": "medium", "cve_public_date": "2025-10-04 16:15:00 UTC" }, { "cve": "CVE-2025-68239", "url": "https://ubuntu.com/security/CVE-2025-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: restore write access before closing files opened by open_exec() bm_register_write() opens an executable file using open_exec(), which internally calls do_open_execat() and denies write access on the file to avoid modification while it is being executed. However, when an error occurs, bm_register_write() closes the file using filp_close() directly. This does not restore the write permission, which may cause subsequent write operations on the same file to fail. Fix this by calling exe_file_allow_write_access() before filp_close() to restore the write permission properly.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-38659", "url": "https://ubuntu.com/security/CVE-2025-38659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: No more self recovery When a node withdraws and it turns out that it is the only node that has the filesystem mounted, gfs2 currently tries to replay the local journal to bring the filesystem back into a consistent state. Not only is that a very bad idea, it has also never worked because gfs2_recover_func() will refuse to do anything during a withdraw. However, before even getting to this point, gfs2_recover_func() dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free before commit 04133b607a78 (\"gfs2: Prevent double iput for journal on error\") and is a NULL pointer dereference since then. Simply get rid of self recovery to fix that.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2022-49961", "url": "https://ubuntu.com/security/CVE-2022-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg->precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored state. To show a concrete example of the problem: 0000000000000000 : 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 10: r2 = -1 0000000000000058 : 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit 00000000000000b8 : 23: w0 = 0 24: exit For the first case, the single line execution's exploration will prune the search at insn 14 for the branch insn 9's second leg as it will be verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will always be 0 so at runtime we don't get error for being greater than UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just sees reg->precise as false for both r2 registers in both states, hence considers them equal for purposes of states_equal. If we propagated precise markers using the backtracking support, we would use the precise marking to then ensure that old r2 (UINT_MAX) was within the new r2 (1) and this would never be true, so the verification would rightfully fail. The end result is that the out of bounds access at instruction 19 would be permitted without this fix. Note that reg->precise is always set to true when user does not have CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static or global functions)), hence this is only a problem when precision marks need to be explicitly propagated (i.e. privileged users with CAP_BPF). A simplified test case has been included in the next patch to prevent future regressions.", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2024-47809", "url": "https://ubuntu.com/security/CVE-2024-47809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix possible lkb_resource null dereference This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded. The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference. In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.", "cve_priority": "medium", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2025-38250", "url": "https://ubuntu.com/security/CVE-2025-38250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix use-after-free in vhci_flush() syzbot reported use-after-free in vhci_flush() without repro. [0] From the splat, a thread close()d a vhci file descriptor while its device was being used by iotcl() on another thread. Once the last fd refcnt is released, vhci_release() calls hci_unregister_dev(), hci_free_dev(), and kfree() for struct vhci_data, which is set to hci_dev->dev->driver_data. The problem is that there is no synchronisation after unlinking hdev from hci_dev_list in hci_unregister_dev(). There might be another thread still accessing the hdev which was fetched before the unlink operation. We can use SRCU for such synchronisation. Let's run hci_dev_reset() under SRCU and wait for its completion in hci_unregister_dev(). Another option would be to restore hci_dev->destruct(), which was removed in commit 587ae086f6e4 (\"Bluetooth: Remove unused hci-destruct cb\"). However, this would not be a good solution, as we should not run hci_unregister_dev() while there are in-flight ioctl() requests, which could lead to another data-race KCSAN splat. Note that other drivers seem to have the same problem, for exmaple, virtbt_remove(). [0]: BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718 CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name ---truncated---", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2026-43281", "url": "https://ubuntu.com/security/CVE-2026-43281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate() Although it is guided that `#mbox-cells` must be at least 1, there are many instances of `#mbox-cells = <0>;` in the device tree. If that is the case and the corresponding mailbox controller does not provide `fw_xlate` and of_xlate` function pointers, `fw_mbox_index_xlate()` will be used by default and out-of-bounds accesses could occur due to lack of bounds check in that function.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23157", "url": "https://ubuntu.com/security/CVE-2026-23157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not strictly require dirty metadata threshold for metadata writepages [BUG] There is an internal report that over 1000 processes are waiting at the io_schedule_timeout() of balance_dirty_pages(), causing a system hang and trigger a kernel coredump. The kernel is v6.4 kernel based, but the root problem still applies to any upstream kernel before v6.18. [CAUSE] From Jan Kara for his wisdom on the dirty page balance behavior first. This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB. Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there's dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying. When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit. So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in that cgroup. So that means the only way to reduce the dirty pages of that cgroup is to writeback the dirty pages of btrfs btree inode, and only after that those processes can exit balance_dirty_pages(). Now back to the btrfs part, btree_writepages() is responsible for writing back dirty btree inode pages. The problem here is, there is a btrfs internal threshold that if the btree inode's dirty bytes are below the 32M threshold, it will not do any writeback. This behavior is to batch as much metadata as possible so we won't write back those tree blocks and then later re-COW them again for another modification. This internal 32MiB is higher than the existing dirty page size (28MiB), meaning no writeback will happen, causing a deadlock between btrfs and cgroup: - Btrfs doesn't want to write back btree inode until more dirty pages - Cgroup/MM doesn't want more dirty pages for btrfs btree inode Thus any process touching that btree inode is put into sleep until the number of dirty pages is reduced. Thanks Jan Kara a lot for the analysis of the root cause. [ENHANCEMENT] Since kernel commit b55102826d7d (\"btrfs: set AS_KERNEL_FILE on the btree_inode\"), btrfs btree inode pages will only be charged to the root cgroup which should have a much larger limit than btrfs' 32MiB threshold. So it should not affect newer kernels. But for all current LTS kernels, they are all affected by this problem, and backporting the whole AS_KERNEL_FILE may not be a good idea. Even for newer kernels I still think it's a good idea to get rid of the internal threshold at btree_writepages(), since for most cases cgroup/MM has a better view of full system memory usage than btrfs' fixed threshold. For internal callers using btrfs_btree_balance_dirty() since that function is already doing internal threshold check, we don't need to bother them. But for external callers of btree_writepages(), just respect their requests and write back whatever they want, ignoring the internal btrfs threshold to avoid such deadlock on btree inode dirty page balancing.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23141", "url": "https://ubuntu.com/security/CVE-2026-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: check for inline extents in range_is_hole_in_parent() Before accessing the disk_bytenr field of a file extent item we need to check if we are dealing with an inline extent. This is because for inline extents their data starts at the offset of the disk_bytenr field. So accessing the disk_bytenr means we are accessing inline data or in case the inline data is less than 8 bytes we can actually cause an invalid memory access if this inline extent item is the first item in the leaf or access metadata from other items.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-40005", "url": "https://ubuntu.com/security/CVE-2025-40005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: Implement refcount to handle unbind during busy driver support indirect read and indirect write operation with assumption no force device removal(unbind) operation. However force device removal(removal) is still available to root superuser. Unbinding driver during operation causes kernel crash. This changes ensure driver able to handle such operation for indirect read and indirect write by implementing refcount to track attached devices to the controller and gracefully wait and until attached devices remove operation completed before proceed with removal operation.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2023-53629", "url": "https://ubuntu.com/security/CVE-2023-53629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: dlm: fix use after free in midcomms commit While working on processing dlm message in softirq context I experienced the following KASAN use-after-free warning: [ 151.760477] ================================================================== [ 151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347 [ 151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828 [ 151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014 [ 151.768726] Call Trace: [ 151.769277] [ 151.769748] dump_stack_lvl+0x5b/0x86 [ 151.770556] print_report+0x180/0x4c8 [ 151.771378] ? kasan_complete_mode_report_info+0x7c/0x1e0 [ 151.772241] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.773069] kasan_report+0x93/0x1a0 [ 151.773668] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.774514] __asan_load4+0x7e/0xa0 [ 151.775089] dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.775890] ? create_message.isra.29.constprop.64+0x57/0xc0 [ 151.776770] send_common+0x19f/0x1b0 [ 151.777342] ? remove_from_waiters+0x60/0x60 [ 151.778017] ? lock_downgrade+0x410/0x410 [ 151.778648] ? __this_cpu_preempt_check+0x13/0x20 [ 151.779421] ? rcu_lockdep_current_cpu_online+0x88/0xc0 [ 151.780292] _convert_lock+0x46/0x150 [ 151.780893] convert_lock+0x7b/0xc0 [ 151.781459] dlm_lock+0x3ac/0x580 [ 151.781993] ? 0xffffffffc0540000 [ 151.782522] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.783379] ? dlm_scan_rsbs+0xa70/0xa70 [ 151.784003] ? preempt_count_sub+0xd6/0x130 [ 151.784661] ? is_module_address+0x47/0x70 [ 151.785309] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.786166] ? 0xffffffffc0540000 [ 151.786693] ? lockdep_init_map_type+0xc3/0x360 [ 151.787414] ? 0xffffffffc0540000 [ 151.787947] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.789004] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.789858] ? 0xffffffffc0540000 [ 151.790392] ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture] [ 151.791347] ? delay_tsc+0x94/0xc0 [ 151.791898] torture_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.792735] ? torture_start+0x30/0x30 [dlm_locktorture] [ 151.793606] lock_torture+0x177/0x270 [dlm_locktorture] [ 151.794448] ? torture_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture] [ 151.795539] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.796476] ? do_raw_spin_lock+0x11e/0x1e0 [ 151.797152] ? mark_held_locks+0x34/0xb0 [ 151.797784] ? _raw_spin_unlock_irqrestore+0x30/0x70 [ 151.798581] ? __kthread_parkme+0x79/0x110 [ 151.799246] ? trace_preempt_on+0x2a/0xf0 [ 151.799902] ? __kthread_parkme+0x79/0x110 [ 151.800579] ? preempt_count_sub+0xd6/0x130 [ 151.801271] ? __kasan_check_read+0x11/0x20 [ 151.801963] ? __kthread_parkme+0xec/0x110 [ 151.802630] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.803569] kthread+0x192/0x1d0 [ 151.804104] ? kthread_complete_and_exit+0x30/0x30 [ 151.804881] ret_from_fork+0x1f/0x30 [ 151.805480] [ 151.806111] Allocated by task 1347: [ 151.806681] kasan_save_stack+0x26/0x50 [ 151.807308] kasan_set_track+0x25/0x30 [ 151.807920] kasan_save_alloc_info+0x1e/0x30 [ 151.808609] __kasan_slab_alloc+0x63/0x80 [ 151.809263] kmem_cache_alloc+0x1ad/0x830 [ 151.809916] dlm_allocate_mhandle+0x17/0x20 [ 151.810590] dlm_midcomms_get_mhandle+0x96/0x260 [ 151.811344] _create_message+0x95/0x180 [ 151.811994] create_message.isra.29.constprop.64+0x57/0xc0 [ 151.812880] send_common+0x129/0x1b0 [ 151.813467] _convert_lock+0x46/0x150 [ 151.814074] convert_lock+0x7b/0xc0 [ 151.814648] dlm_lock+0x3ac/0x580 [ 151.815199] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.816258] torture_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.817129] lock_t ---truncated---", "cve_priority": "high", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2025-71221", "url": "https://ubuntu.com/security/CVE-2025-71221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue() Add proper locking in mmp_pdma_residue() to prevent use-after-free when accessing descriptor list and descriptor contents. The race occurs when multiple threads call tx_status() while the tasklet on another CPU is freeing completed descriptors: CPU 0 CPU 1 ----- ----- mmp_pdma_tx_status() mmp_pdma_residue() -> NO LOCK held list_for_each_entry(sw, ..) DMA interrupt dma_do_tasklet() -> spin_lock(&desc_lock) list_move(sw->node, ...) spin_unlock(&desc_lock) | dma_pool_free(sw) <- FREED! -> access sw->desc <- UAF! This issue can be reproduced when running dmatest on the same channel with multiple threads (threads_per_chan > 1). Fix by protecting the chain_running list iteration and descriptor access with the chan->desc_lock spinlock.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23204", "url": "https://ubuntu.com/security/CVE-2026-23204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: use skb_header_pointer_careful() skb_header_pointer() does not fully validate negative @offset values. Use skb_header_pointer_careful() instead. GangMin Kim provided a report and a repro fooling u32_classify(): BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0 net/sched/cls_u32.c:221", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-71161", "url": "https://ubuntu.com/security/CVE-2025-71161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: disable recursive forward error correction There are two problems with the recursive correction: 1. It may cause denial-of-service. In fec_read_bufs, there is a loop that has 253 iterations. For each iteration, we may call verity_hash_for_block recursively. There is a limit of 4 nested recursions - that means that there may be at most 253^4 (4 billion) iterations. Red Hat QE team actually created an image that pushes dm-verity to this limit - and this image just makes the udev-worker process get stuck in the 'D' state. 2. It doesn't work. In fec_read_bufs we store data into the variable \"fio->bufs\", but fio bufs is shared between recursive invocations, if \"verity_hash_for_block\" invoked correction recursively, it would overwrite partially filled fio->bufs.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2022-50552", "url": "https://ubuntu.com/security/CVE-2022-50552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: use quiesced elevator switch when reinitializing queues The hctx's run_work may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally. nvme nvme0: resetting controller nvme nvme0: 32/0/0 default/read/poll queues BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:kyber_has_work+0x29/0x70 ... Call Trace: __blk_mq_do_dispatch_sched+0x83/0x2b0 __blk_mq_sched_dispatch_requests+0x12e/0x170 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x2b/0x50 process_one_work+0x1ef/0x380 worker_thread+0x2d/0x3e0", "cve_priority": "low", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2024-36922", "url": "https://ubuntu.com/security/CVE-2024-36922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: read txq->read_ptr under lock If we read txq->read_ptr without lock, we can read the same value twice, then obtain the lock, and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in the WARN_ONCE() a little later. Fix that by reading txq->read_ptr under lock.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2024-53221", "url": "https://ubuntu.com/security/CVE-2024-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix null-ptr-deref in f2fs_submit_page_bio() There's issue as follows when concurrently installing the f2fs.ko module and mounting the f2fs file system: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs] Call Trace: f2fs_submit_page_bio+0x126/0x8b0 [f2fs] __get_meta_page+0x1d4/0x920 [f2fs] get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs] validate_checkpoint+0xac/0x290 [f2fs] f2fs_get_valid_checkpoint+0x207/0x950 [f2fs] f2fs_fill_super+0x1007/0x39b0 [f2fs] mount_bdev+0x183/0x250 legacy_get_tree+0xf4/0x1e0 vfs_get_tree+0x88/0x340 do_new_mount+0x283/0x5e0 path_mount+0x2b2/0x15b0 __x64_sys_mount+0x1fe/0x270 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Above issue happens as the biset of the f2fs file system is not initialized before register \"f2fs_fs_type\". To address above issue just register \"f2fs_fs_type\" at the last in init_f2fs_fs(). Ensure that all f2fs file system resources are initialized.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-56657", "url": "https://ubuntu.com/security/CVE-2024-56657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Avoid WARN() for symlink errors Using WARN() for showing the error of symlink creations don't give more information than telling that something goes wrong, since the usual code path is a lregister callback from each control element creation. More badly, the use of WARN() rather confuses fuzzer as if it were serious issues. This patch downgrades the warning messages to use the normal dev_err() instead of WARN(). For making it clearer, add the function name to the prefix, too.", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2022-49803", "url": "https://ubuntu.com/security/CVE-2022-49803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Fix memory leak of nsim_dev->fa_cookie kmemleak reports this issue: unreferenced object 0xffff8881bac872d0 (size 8): comm \"sh\", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie .. nsim_drv_remove() The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To fix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove().", "cve_priority": "medium", "cve_public_date": "2025-05-01 15:16:00 UTC" }, { "cve": "CVE-2022-50116", "url": "https://ubuntu.com/security/CVE-2022-50116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix deadlock and link starvation in outgoing data path The current implementation queues up new control and user packets as needed and processes this queue down to the ldisc in the same code path. That means that the upper and the lower layer are hard coupled in the code. Due to this deadlocks can happen as seen below while transmitting data, especially during ldisc congestion. Furthermore, the data channels starve the control channel on high transmission load on the ldisc. Introduce an additional control channel data queue to prevent timeouts and link hangups during ldisc congestion. This is being processed before the user channel data queue in gsm_data_kick(), i.e. with the highest priority. Put the queue to ldisc data path into a workqueue and trigger it whenever new data has been put into the transmission queue. Change gsm_dlci_data_sweep() accordingly to fill up the transmission queue until TX_THRESH_HI. This solves the locking issue, keeps latency low and provides good performance on high data load. Note that now all packets from a DLCI are removed from the internal queue if the associated DLCI was closed. This ensures that no data is sent by the introduced write task to an already closed DLCI. BUG: spinlock recursion on CPU#0, test_v24_loop/124 lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0 CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x34/0x44 do_raw_spin_lock+0x76/0xa0 _raw_spin_lock_irqsave+0x72/0x80 uart_write_room+0x3b/0xc0 gsm_data_kick+0x14b/0x240 [n_gsm] gsmld_write_wakeup+0x35/0x70 [n_gsm] tty_wakeup+0x53/0x60 tty_port_default_wakeup+0x1b/0x30 serial8250_tx_chars+0x12f/0x220 serial8250_handle_irq.part.0+0xfe/0x150 serial8250_default_handle_irq+0x48/0x80 serial8250_interrupt+0x56/0xa0 __handle_irq_event_percpu+0x78/0x1f0 handle_irq_event+0x34/0x70 handle_fasteoi_irq+0x90/0x1e0 __common_interrupt+0x69/0x100 common_interrupt+0x48/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:__do_softirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00 RSP: 0018:ffffc90000003f98 EFLAGS: 00000286 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7 RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? __do_softirq+0x73/0x34e irq_exit_rcu+0xb5/0x100 common_interrupt+0xa4/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50 Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 3d 97 33 ff 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44 RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? _raw_spin_unlock_irqrestore+0x23/0x50 gsmtty_write+0x65/0x80 [n_gsm] n_tty_write+0x33f/0x530 ? swake_up_all+0xe0/0xe0 file_tty_write.constprop.0+0x1b1/0x320 ? n_tty_flush_buffer+0xb0/0xb0 new_sync_write+0x10c/0x190 vfs_write+0x282/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f3e5e35c15c Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2026-31586", "url": "https://ubuntu.com/security/CVE-2026-31586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: blk-cgroup: fix use-after-free in cgwb_release_workfn() cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) ** Stack based on commit 66672af7a095 (\"Add linux-next specific files for 20260410\") I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh (The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.) Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31598", "url": "https://ubuntu.com/security/CVE-2026-31598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible deadlock between unlink and dio_end_io_write ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key. Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir \t ocfs2_expand_inline_dir \t down_write(&oi->ip_alloc_sem) <- Lock B Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode) Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31642", "url": "https://ubuntu.com/security/CVE-2026-31642", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call removal to use RCU safe deletion Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop. This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by: Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that. rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31664", "url": "https://ubuntu.com/security/CVE-2026-31664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear trailing padding in build_polexpire() build_expire() clears the trailing padding bytes of struct xfrm_user_expire after setting the hard field via memset_after(), but the analogous function build_polexpire() does not do this for struct xfrm_user_polexpire. The padding bytes after the __u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners, leaking kernel heap memory contents. Add the missing memset_after() call, matching build_expire().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43075", "url": "https://ubuntu.com/security/CVE-2026-43075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix out-of-bounds write in ocfs2_write_end_inline KASAN reports a use-after-free write of 4086 bytes in ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF. The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk id_count field to determine whether a write fits in inline data. On a corrupted filesystem, id_count can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer. Call trace (crash path): vfs_copy_file_range (fs/read_write.c:1634) do_splice_direct splice_direct_to_actor iter_file_splice_write ocfs2_file_write_iter generic_perform_write ocfs2_write_end ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949) ocfs2_write_end_inline (fs/ocfs2/aops.c:1915) memcpy_from_folio <-- KASAN: write OOB So add id_count upper bound check in ocfs2_validate_inode_block() to alongside the existing i_size check to fix it.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43076", "url": "https://ubuntu.com/security/CVE-2026-43076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate inline data i_size during inode read When reading an inode from disk, ocfs2_validate_inode_block() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's i_size can exceed the actual inline data capacity (id_count). This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory. In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry() Fix by adding a validation check in ocfs2_validate_inode_block() to ensure inodes with inline data have i_size <= id_count. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-23444", "url": "https://ubuntu.com/security/CVE-2026-23444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do. Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free. Document the skb ownership guarantee in the function's kdoc.", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2025-38710", "url": "https://ubuntu.com/security/CVE-2025-38710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Validate i_depth for exhash directories A fuzzer test introduced corruption that ends up with a depth of 0 in dir_e_read(), causing an undefined shift by 32 at: index = hash >> (32 - dip->i_depth); As calculated in an open-coded way in dir_make_exhash(), the minimum depth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 is invalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time. So we can avoid the undefined behaviour by checking for depth values lower than the minimum in gfs2_dinode_in(). Values greater than the maximum are already being checked for there. Also switch the calculation in dir_make_exhash() to use ilog2() to clarify how the depth is calculated. Tested with the syzkaller repro.c and xfstests '-g quick'.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2026-23442", "url": "https://ubuntu.com/security/CVE-2026-23442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: add NULL checks for idev in SRv6 paths __in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER). Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31594", "url": "https://ubuntu.com/security/CVE-2026-31594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to perform later. This leads to an oops when .allow_link fails or when .drop_link is performed. The following is an example oops of the former case: Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pci_epc_remove_epf+0x78/0xe0 (P) pci_primary_epc_epf_link+0x88/0xa8 configfs_symlink+0x1f4/0x5a0 vfs_symlink+0x134/0x1d8 do_symlinkat+0x88/0x138 __arm64_sys_symlinkat+0x74/0xe0 [...] Remove the helper, and drop pci_epc_put(). EPC device refcounting is tied to the configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2022-50073", "url": "https://ubuntu.com/security/CVE-2022-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null Fixes a NULL pointer derefence bug triggered from tap driver. When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null (in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb) virtio_net_hdr_to_skb calls dev_parse_header_protocol which needs skb->dev field to be valid. The line that trigers the bug is in dev_parse_header_protocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->header_ops || !dev->header_ops->parse_protocol) 22e1: mov 0x10(%rbx),%rax 22e5:\t mov 0x230(%rax),%rax Setting skb->dev before the call in tap.c fixes the issue. BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tap_get_user+0x3f1/0x540 [tap] tap_sendmsg+0x56/0x362 [tap] ? get_tx_bufs+0xc2/0x1e0 [vhost_net] handle_tx_copy+0x114/0x670 [vhost_net] handle_tx+0xb0/0xe0 [vhost_net] handle_tx_kick+0x15/0x20 [vhost_net] vhost_worker+0x7b/0xc0 [vhost] ? vhost_vring_call_reset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2026-31576", "url": "https://ubuntu.com/security/CVE-2026-31576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: hackrf: fix to not free memory after the device is registered in hackrf_probe() In hackrf driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open hackrf fd \t\t\t\t\t\t.... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... \t\t\t\t\t\tsys_ioctl(fd, ...); \t\t\t\t\t\t v4l2_ioctl(); \t\t\t\t\t\t video_is_registered() // UAF!! \t\t\t\t\t\t.... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t v4l2_release() // UAF!! \t\t\t\t\t\t hackrf_video_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked. However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver's release() is invoked. Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven't been released yet. And since release() free memory too, race to use-after-free and double-free vuln occur. To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43058", "url": "https://ubuntu.com/security/CVE-2026-43058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix pass-by-value structs causing MSAN warnings vidtv_ts_null_write_into() and vidtv_ts_pcr_write_into() take their argument structs by value, causing MSAN to report uninit-value warnings. While only vidtv_ts_null_write_into() has triggered a report so far, both functions share the same issue. Fix by passing both structs by const pointer instead, avoiding the stack copy of the struct along with its MSAN shadow and origin metadata. The functions do not modify the structs, which is enforced by the const qualifier.", "cve_priority": "medium", "cve_public_date": "2026-05-02 07:16:00 UTC" }, { "cve": "CVE-2026-31577", "url": "https://ubuntu.com/security/CVE-2026-31577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map The DAT inode's btree node cache (i_assoc_inode) is initialized lazily during btree operations. However, nilfs_mdt_save_to_shadow_map() assumes i_assoc_inode is already initialized when copying dirty pages to the shadow map during GC. If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before any btree operation has occurred on the DAT inode, i_assoc_inode is NULL leading to a general protection fault. Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always initialized before any GC operation can use it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31578", "url": "https://ubuntu.com/security/CVE-2026-31578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: as102: fix to not free memory after the device is registered in as102_usb_probe() In as102_usb driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open as102 fd \t\t\t\t\t\t.... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t as102_release() // UAF!! \t\t\t\t\t\t as102_usb_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a USB character device registered with usb_register_dev() is later unregistered (via usb_deregister_dev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked. In as102, as102_usb_probe() calls usb_register_dev() and then, on an error path, does usb_deregister_dev() and frees as102_dev_t right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102_release() --> as102_usb_release() and access or free as102_dev_t again, occur a race to use-after-free and double-free vuln. The fix is to never kfree(as102_dev_t) directly once usb_register_dev() has succeeded. After deregistration, defer freeing memory to .release(). In other words, let release() perform the last kfree when the final open FD is closed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31580", "url": "https://ubuntu.com/security/CVE-2026-31580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bcache: fix cached_dev.sb_bio use-after-free and crash In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention: ``` [6888366.280350] Call Trace: [6888366.280452] blk_update_request+0x14e/0x370 [6888366.280561] blk_mq_end_request+0x1a/0x130 [6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd] [6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd] [6888366.280903] __complete_request+0x22/0x70 [libceph] [6888366.281032] osd_dispatch+0x15e/0xb40 [libceph] [6888366.281164] ? inet_recvmsg+0x5b/0xd0 [6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph] [6888366.281405] ceph_con_process_message+0x79/0x140 [libceph] [6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph] [6888366.281661] ceph_con_workfn+0x329/0x680 [libceph] ``` After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped. Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio. This patch hopes to wait for sb_write to complete in cached_dev_free. It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31581", "url": "https://ubuntu.com/security/CVE-2026-31581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: fix use-after-free on disconnect In usb6fire_chip_abort(), the chip struct is allocated as the card's private data (via snd_card_new with sizeof(struct sfire_chip)). When snd_card_free_when_closed() is called and no file handles are open, the card and embedded chip are freed synchronously. The subsequent chip->card = NULL write then hits freed slab memory. Call trace: usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline] usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953 Fix by moving the card lifecycle out of usb6fire_chip_abort() and into usb6fire_chip_disconnect(). The card pointer is saved in a local before any teardown, snd_card_disconnect() is called first to prevent new opens, URBs are aborted while chip is still valid, and snd_card_free_when_closed() is called last so chip is never accessed after the card may be freed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31583", "url": "https://ubuntu.com/security/CVE-2026-31583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free in em28xx_v4l2_open() em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock, creating a race with em28xx_v4l2_init()'s error path and em28xx_v4l2_fini(), both of which free the em28xx_v4l2 struct and set dev->v4l2 to NULL under dev->lock. This race leads to two issues: - use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler, since the video_device is embedded in the freed em28xx_v4l2 struct. - NULL pointer dereference in em28xx_resolution_set() when accessing v4l2->norm, since dev->v4l2 has been set to NULL. Fix this by moving the mutex_lock() before the dev->v4l2 read and adding a NULL check for dev->v4l2 under the lock.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31585", "url": "https://ubuntu.com/security/CVE-2026-31585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix nfeeds state corruption on start_streaming failure syzbot reported a memory leak in vidtv_psi_service_desc_init [1]. When vidtv_start_streaming() fails inside vidtv_start_feed(), the nfeeds counter is left incremented even though no feed was actually started. This corrupts the driver state: subsequent start_feed calls see nfeeds > 1 and skip starting the mux, while stop_feed calls eventually try to stop a non-existent stream. This state corruption can also lead to memory leaks, since the mux and channel resources may be partially allocated during a failed start_streaming but never cleaned up, as the stop path finds dvb->streaming == false and returns early. Fix by decrementing nfeeds back when start_streaming fails, keeping the counter in sync with the actual number of active feeds. [1] BUG: memory leak unreferenced object 0xffff888145b50820 (size 32): comm \"syz.0.17\", pid 6068, jiffies 4294944486 backtrace (crc 90a0c7d4): vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31686", "url": "https://ubuntu.com/security/CVE-2026-31686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/kasan: fix double free for kasan pXds kasan_free_pxd() assumes the page table is always struct page aligned. But that's not always the case for all architectures. E.g. In case of powerpc with 64K pagesize, PUD table (of size 4096) comes from slab cache named pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's just directly pass the start of the pxd table which is passed as the 1st argument. This fixes the below double free kasan issue seen with PMEM: radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages ================================================================== BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20 Free of addr c0000003c38e0000 by task ndctl/2164 CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeries Call Trace: dump_stack_lvl+0x88/0xc4 (unreliable) print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140 kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec ---- interrupt: 3000 at 0x7fff93b3d3f4 NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000 REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392) MSR: 800000000280f033 CR: 48888208 XER: 00000000 <...> NIP [00007fff93b3d3f4] 0x7fff93b3d3f4 LR [00007fff93b3d3f4] 0x7fff93b3d3f4 ---- interrupt: 3000 The buggy address belongs to the object at c0000003c38e0000 which belongs to the cache pgtable-2^9 of size 4096 The buggy address is located 0 bytes inside of 4096-byte region [c0000003c38e0000, c0000003c38e1000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:c0000003bfd63e01 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) page_type: f5(slab) raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected [ 138.953636] [ T2164] Memory state around the buggy address: [ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953669] [ T2164] ^ [ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953692] [ T2164] ================================================================== [ 138.953701] [ T2164] Disabling lock debugging due to kernel taint", "cve_priority": "low", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2026-31588", "url": "https://ubuntu.com/security/CVE-2026-31588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use scratch field in MMIO fragment to hold small write values When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value. This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, *and* both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable. The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by overwrite the data value with garbage. Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *al ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31630", "url": "https://ubuntu.com/security/CVE-2026-31630", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: proc: size address buffers for %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with \"%pISpc\". That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23399", "url": "https://ubuntu.com/security/CVE-2026-23399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nf_tables: nft_dynset: fix possible stateful expression memleak in error path If cloning the second stateful expression in the element via GFP_ATOMIC fails, then the first stateful expression remains in place without being released.   unreferenced object (percpu) 0x607b97e9cab8 (size 16):     comm \"softirq\", pid 0, jiffies 4294931867     hex dump (first 16 bytes on cpu 3):       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     backtrace (crc 0):       pcpu_alloc_noprof+0x453/0xd80       nft_counter_clone+0x9c/0x190 [nf_tables]       nft_expr_clone+0x8f/0x1b0 [nf_tables]       nft_dynset_new+0x2cb/0x5f0 [nf_tables]       nft_rhash_update+0x236/0x11c0 [nf_tables]       nft_dynset_eval+0x11f/0x670 [nf_tables]       nft_do_chain+0x253/0x1700 [nf_tables]       nft_do_chain_ipv4+0x18d/0x270 [nf_tables]       nf_hook_slow+0xaa/0x1e0       ip_local_deliver+0x209/0x330", "cve_priority": "medium", "cve_public_date": "2026-03-28 08:15:00 UTC" }, { "cve": "CVE-2024-35865", "url": "https://ubuntu.com/security/CVE-2024-35865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.", "cve_priority": "medium", "cve_public_date": "2024-05-19 09:15:00 UTC" }, { "cve": "CVE-2026-31590", "url": "https://ubuntu.com/security/CVE-2026-31590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION Drop the WARN in sev_pin_memory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing: struct kvm_enc_region range = { .addr = 0, .size = -1ul, }; __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range); Note, the checks in sev_mem_enc_register_region() that presumably exist to verify the incoming address+size are completely worthless, as both \"addr\" and \"size\" are u64s and SEV is 64-bit only, i.e. they _can't_ be greater than ULONG_MAX. That wart will be cleaned up in the near future. \tif (range->addr > ULONG_MAX || range->size > ULONG_MAX) \t\treturn -EINVAL; Opportunistically add a comment to explain why the code calculates the number of pages the \"hard\" way, e.g. instead of just shifting @ulen.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31596", "url": "https://ubuntu.com/security/CVE-2026-31596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle invalid dinode in ocfs2_group_extend [BUG] kernel BUG at fs/ocfs2/resize.c:308! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308 Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe Call Trace: ... ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... [CAUSE] ocfs2_group_extend() assumes that the global bitmap inode block returned from ocfs2_inode_lock() has already been validated and BUG_ONs when the signature is not a dinode. That assumption is too strong for crafted filesystems because the JBD2-managed buffer path can bypass structural validation and return an invalid dinode to the resize ioctl. [FIX] Validate the dinode explicitly in ocfs2_group_extend(). If the global bitmap buffer does not contain a valid dinode, report filesystem corruption with ocfs2_error() and fail the resize operation instead of crashing the kernel.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31597", "url": "https://ubuntu.com/security/CVE-2026-31597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY, as documented in mm/filemap.c: \"If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap().\" When this happens, a concurrent munmap() can call remove_vma() and free the vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call dereferences it -- a use-after-free. Fix this by saving ip_blkno as a plain integer before calling filemap_fault(), and removing vma from the trace event. Since ip_blkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31599", "url": "https://ubuntu.com/security/CVE-2026-31599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections syzbot reported a general protection fault in vidtv_psi_desc_assign [1]. vidtv_psi_pmt_stream_init() can return NULL on memory allocation failure, but vidtv_channel_pmt_match_sections() does not check for this. When tail is NULL, the subsequent call to vidtv_psi_desc_assign(&tail->descriptor, desc) dereferences a NULL pointer offset, causing a general protection fault. Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean up the already-allocated stream chain and return. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629 Call Trace: vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline] vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479 vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31602", "url": "https://ubuntu.com/security/CVE-2026-31602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Limit PTP to a single page Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic. ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ct_vm_map() tries to access beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count remain unchanged.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31603", "url": "https://ubuntu.com/security/CVE-2026-31603", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: sm750fb: fix division by zero in ps_to_hz() ps_to_hz() is called from hw_sm750_crtc_set_mode() without validating that pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO causes a division by zero. Fix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent with other framebuffer drivers.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31605", "url": "https://ubuntu.com/security/CVE-2026-31605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31615", "url": "https://ubuntu.com/security/CVE-2026-31615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: renesas_usb3: validate endpoint index in standard request handlers The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math. This is just like what was done in commit ee0d382feb44 (\"usb: gadget: aspeed_udc: validate endpoint index for ast udc\") for the aspeed driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31616", "url": "https://ubuntu.com/security/CVE-2026-31616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete() A broken/bored/mean USB host can overflow the skb_shared_info->frags[] array on a Linux gadget exposing a Phonet function by sending an unbounded sequence of full-page OUT transfers. pn_rx_complete() finalizes the skb only when req->actual < req->length, where req->length is set to PAGE_SIZE by the gadget. If the host always sends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never be reset and each completion will add another fragment via skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17), subsequent frag stores overwrite memory adjacent to the shinfo on the heap. Drop the skb and account a length error when the frag limit is reached, matching the fix applied in t7xx by commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\").", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31617", "url": "https://ubuntu.com/security/CVE-2026-31617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb() The block_len read from the host-supplied NTB header is checked against ntb_max but has no lower bound. When block_len is smaller than opts->ndp_size, the bounds check of: \tndp_index > (block_len - opts->ndp_size) will underflow producing a huge unsigned value that ndp_index can never exceed, defeating the check entirely. The same underflow occurs in the datagram index checks against block_len - opts->dpe_size. With those checks neutered, a malicious USB host can choose ndp_index and datagram offsets that point past the actual transfer, and the skb_put_data() copies adjacent kernel memory into the network skb. Fix this by rejecting block lengths that cannot hold at least the NTB header plus one NDP. This will make block_len - opts->ndp_size and block_len - opts->dpe_size both well-defined. Commit 8d2b1a1ec9f5 (\"CDC-NCM: avoid overflow in sanity checking\") fixed a related class of issues on the host side of NCM.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31618", "url": "https://ubuntu.com/security/CVE-2026-31618", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31619", "url": "https://ubuntu.com/security/CVE-2026-31619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: fireworks: bound device-supplied status before string array lookup The status field in an EFW response is a 32-bit value supplied by the firewire device. efr_status_names[] has 17 entries so a status value outside that range goes off into the weeds when looking at the %s value. Even worse, the status could return EFR_STATUS_INCOMPLETE which is 0x80000000, and is obviously not in that array of potential strings. Fix this up by properly bounding the index against the array size and printing \"unknown\" if it's not recognized.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31622", "url": "https://ubuntu.com/security/CVE-2026-31622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: digital: Bounds check NFC-A cascade depth in SDD response handler The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3 or 4 bytes to target->nfcid1 on each round, but the number of cascade rounds is controlled entirely by the peer device. The peer sets the cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the cascade-incomplete bit in the SEL_RES (deciding whether another round follows). ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver actually enforces this. This means a malicious peer can keep the cascade running, writing past the heap-allocated nfc_target with each round. Fix this by rejecting the response when the accumulated UID would exceed the buffer. Commit e329e71013c9 (\"NFC: nci: Bounds check struct nfc_target arrays\") fixed similar missing checks against the same field on the NCI path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31623", "url": "https://ubuntu.com/security/CVE-2026-31623", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete() A malicious USB device claiming to be a CDC Phonet modem can overflow the skb_shared_info->frags[] array by sending an unbounded sequence of full-page bulk transfers. Drop the skb and increment the length error when the frag limit is reached. This matches the same fix that commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\") did for the t7xx driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31624", "url": "https://ubuntu.com/security/CVE-2026-31624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: clamp report_size in s32ton() to avoid undefined shift s32ton() shifts by n-1 where n is the field's report_size, a value that comes directly from a HID device. The HID parser bounds report_size only to <= 256, so a broken HID device can supply a report descriptor with a wide field that triggers shift exponents up to 256 on a 32-bit type when an output report is built via hid_output_field() or hid_set_field(). Commit ec61b41918587 (\"HID: core: fix shift-out-of-bounds in hid_report_raw_event\") added the same n > 32 clamp to the function snto32(), but s32ton() was never given the same fix as I guess syzbot hadn't figured out how to fuzz a device the same way. Fix this up by just clamping the max value of n, just like snto32() does.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31625", "url": "https://ubuntu.com/security/CVE-2026-31625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: alps: fix NULL pointer dereference in alps_raw_event() Commit ecfa6f34492c (\"HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them\") attempted to fix up the HID drivers that had missed the previous fix that was done in 2ff5baa9b527 (\"HID: appleir: Fix potential NULL dereference at raw event handle\"), but the alps driver was missed. Fix this up by properly checking in the hid-alps driver that it had been claimed correctly before attempting to process the raw event.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31626", "url": "https://ubuntu.com/security/CVE-2026-31626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify() Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using uninitialized data. Smatch warns that only 6 bytes are copied to this 8-byte (u64) variable, leaving the last two bytes uninitialized: drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify() warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes) Initializing the variable at the start of the function fixes this warning and ensures predictable behavior.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31627", "url": "https://ubuntu.com/security/CVE-2026-31627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: s3c24xx: check the size of the SMBUS message before using it The first byte of an i2c SMBUS message is the size, and it should be verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX before processing it. This is the same logic that was added in commit a6e04f05ce0b (\"i2c: tegra: check msg length in SMBUS block read\") to the i2c tegra driver.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31532", "url": "https://ubuntu.com/security/CVE-2026-31532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: fix ro->uniq use-after-free in raw_rcv() raw_release() unregisters raw CAN receive filters via can_rx_unregister(), but receiver deletion is deferred with call_rcu(). This leaves a window where raw_rcv() may still be running in an RCU read-side critical section after raw_release() frees ro->uniq, leading to a use-after-free of the percpu uniq storage. Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific socket destructor. can_rx_unregister() takes an extra reference to the socket and only drops it from the RCU callback, so freeing uniq from sk_destruct ensures the percpu area is not released until the relevant callbacks have drained. [mkl: applied manually]", "cve_priority": "high", "cve_public_date": "2026-04-23 12:17:00 UTC" }, { "cve": "CVE-2026-31629", "url": "https://ubuntu.com/security/CVE-2026-31629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: add missing return after LLCP_CLOSED checks In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket state is LLCP_CLOSED, the code correctly calls release_sock() and nfc_llcp_sock_put() but fails to return. Execution falls through to the remainder of the function, which calls release_sock() and nfc_llcp_sock_put() again. This results in a double release_sock() and a refcount underflow via double nfc_llcp_sock_put(), leading to a use-after-free. Add the missing return statements after the LLCP_CLOSED branches in both functions to prevent the fall-through.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31407", "url": "https://ubuntu.com/security/CVE-2026-31407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: add missing netlink policy validations Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink. These attributes are used by the kernel without any validation. Extend the netlink policies accordingly. Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-43079", "url": "https://ubuntu.com/security/CVE-2026-43079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Skip discovery table for offline dies This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0. WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore] Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at \"pmu->boxes[die] = box\" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43080", "url": "https://ubuntu.com/security/CVE-2026-43080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: Drop large packets with UDP encap syzbot reported a WARN on my patch series [1]. The actual issue is an overflow of 16-bit UDP length field, and it exists in the upstream code. My series added a debug WARN with an overflow check that exposed the issue, that's why syzbot tripped on my patches, rather than on upstream code. syzbot's repro: r0 = socket$pppl2tp(0x18, 0x1, 0x1) r1 = socket$inet6_udp(0xa, 0x2, 0x0) connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c) connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\\x00', '\\xff\\xff', @empty}}}}, 0x32) writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)=\"ee\", 0x34000}], 0x1) It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP encapsulation, and l2tp_xmit_core doesn't check for overflows when it assigns the UDP length field. The value gets trimmed to 16 bites. Add an overflow check that drops oversized packets and avoids sending packets with trimmed UDP length to the wire. syzbot's stack trace (with my patch applied): len >= 65536u WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957 Modules linked in: CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline] RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline] RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327 Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f RSP: 0018:ffffc90003d67878 EFLAGS: 00010293 RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000 RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004 R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900 R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000 FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0 Call Trace: pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x503/0x550 net/socket.c:1195 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1 vfs_writev+0x33c/0x990 fs/read_write.c:1059 do_writev+0x154/0x2e0 fs/read_write.c:1105 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f636479c629 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629 RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31673", "url": "https://ubuntu.com/security/CVE-2026-31673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: read UNIX_DIAG_VFS data under unix_state_lock Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unix_release_sock() clears u->path under unix_state_lock() and drops the path reference after unlocking. Read the inode and device numbers for UNIX_DIAG_VFS while holding unix_state_lock(), then emit the netlink attribute after dropping the lock. This keeps the VFS data stable while the reply is being built.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31681", "url": "https://ubuntu.com/security/CVE-2026-31681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_multiport: validate range encoding in checkentry ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end. The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule. Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43085", "url": "https://ubuntu.com/security/CVE-2026-43085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator When batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send() appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSG_DONE message body. Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes the nfgenmsg payload via nfnl_fill_hdr(), consistent with how __build_packet_message() already constructs NFULNL_MSG_PACKET headers.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43089", "url": "https://ubuntu.com/security/CVE-2026-43089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_mapping() struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43093", "url": "https://ubuntu.com/security/CVE-2026-43093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: tighten UMEM headroom validation to account for tailroom and min frame The current headroom validation in xdp_umem_reg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skb_shared_info stored at the end of XSK frame would be corrupted. HW typically works with 128-aligned sizes so let us provide this value as bare minimum. Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43098", "url": "https://ubuntu.com/security/CVE-2026-43098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: s3fwrn5: allocate rx skb before consuming bytes s3fwrn82_uart_read() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already deliver a complete frame before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43099", "url": "https://ubuntu.com/security/CVE-2026-43099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: fix null-ptr-deref in icmp_build_probe() ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing this error pointer to dev_hold() will cause a kernel crash with null-ptr-deref. Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting \"No Such Interface\".", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43103", "url": "https://ubuntu.com/security/CVE-2026-43103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lapbether: handle NETDEV_PRE_TYPE_CHANGE lapbeth_data_transmit() expects the underlying device type to be ARPHRD_ETHER. Returning NOTIFY_BAD from lapbeth_device_event() makes sure bonding driver can not break this expectation.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31684", "url": "https://ubuntu.com/security/CVE-2026-31684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_csum: validate nested VLAN headers tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43074", "url": "https://ubuntu.com/security/CVE-2026-43074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: defer struct eventpoll free to RCU grace period In certain situations, ep_free() in eventpoll.c will kfree the epi->ep eventpoll struct while it still being used by another concurrent thread. Defer the kfree() to an RCU callback to prevent UAF.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43104", "url": "https://ubuntu.com/security/CVE-2026-43104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix a memory leak in hang state error path When vc4_save_hang_state() encounters an early return condition, it returns without freeing the previously allocated `kernel_state`, leaking memory. Add the missing kfree() calls by consolidating the early return paths into a single place.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43105", "url": "https://ubuntu.com/security/CVE-2026-43105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix memory leak of BO array in hang state The hang state's BO array is allocated separately with kzalloc() in vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the missing kfree() for the BO array before freeing the hang state struct.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43110", "url": "https://ubuntu.com/security/CVE-2026-43110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: validate bsscfg indices in IF events brcmf_fweh_handle_if_event() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check. Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array. [add missing wifi prefix]", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43111", "url": "https://ubuntu.com/security/CVE-2026-43111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: fix use-after-free in roccat_report_event roccat_report_event() iterates over the device->readers list without holding the readers_lock. This allows a concurrent roccat_release() to remove and free a reader while it's still being accessed, leading to a use-after-free. Protect the readers list traversal with the readers_lock mutex.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43112", "url": "https://ubuntu.com/security/CVE-2026-43112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath When cifs_sanitize_prepath is called with an empty string or a string containing only delimiters (e.g., \"/\"), the current logic attempts to check *(cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read. This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL. The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.", "cve_priority": "low", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43113", "url": "https://ubuntu.com/security/CVE-2026-43113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wl1251: validate packet IDs before indexing tx_frames wl1251_tx_packet_cb() uses the firmware completion ID directly to index the fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it. Reject completion IDs that fall outside wl->tx_frames[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2025-54518", "url": "https://ubuntu.com/security/CVE-2025-54518", "cve_description": "Improper isolation of shared resources within the CPU operation cache on Zen 2-based products could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation.", "cve_priority": "high", "cve_public_date": "2026-05-15 05:16:00 UTC" }, { "cve": "CVE-2026-46174", "url": "https://ubuntu.com/security/CVE-2026-46174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2025-71150", "url": "https://ubuntu.com/security/CVE-2025-71150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix refcount leak when invalid session is found on session lookup When a session is found but its state is not SMB2_SESSION_VALID, It indicates that no valid session was found, but it is missing to decrement the reference count acquired by the session lookup, which results in a reference count leak. This patch fixes the issue by explicitly calling ksmbd_user_session_put to release the reference to the session.", "cve_priority": "medium", "cve_public_date": "2026-01-23 15:16:00 UTC" }, { "cve": "CVE-2026-23395", "url": "https://ubuntu.com/security/CVE-2026-23395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ Currently the code attempts to accept requests regardless of the command identifier which may cause multiple requests to be marked as pending (FLAG_DEFER_SETUP) which can cause more than L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer causing an overflow. The spec is quite clear that the same identifier shall not be used on subsequent requests: 'Within each signaling channel a different Identifier shall be used for each successive request or indication.' https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d So this attempts to check if there are any channels pending with the same identifier and rejects if any are found.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31549", "url": "https://ubuntu.com/security/CVE-2026-31549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: cp2615: fix serial string NULL-deref at probe The cp2615 driver uses the USB device serial string as the i2c adapter name but does not make sure that the string exists. Verify that the device has a serial number before accessing it to avoid triggering a NULL-pointer dereference (e.g. with malicious devices).", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31433", "url": "https://ubuntu.com/security/CVE-2026-31433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potencial OOB in get_file_all_info() for compound requests When a compound request consists of QUERY_DIRECTORY + QUERY_INFO (FILE_ALL_INFORMATION) and the first command consumes nearly the entire max_trans_size, get_file_all_info() would blindly call smbConvertToUTF16() with PATH_MAX, causing out-of-bounds write beyond the response buffer. In get_file_all_info(), there was a missing validation check for the client-provided OutputBufferLength before copying the filename into FileName field of the smb2_file_all_info structure. If the filename length exceeds the available buffer space, it could lead to potential buffer overflows or memory corruption during smbConvertToUTF16 conversion. This calculating the actual free buffer size using smb2_calc_max_out_buf_len() and returning -EINVAL if the buffer is insufficient and updating smbConvertToUTF16 to use the actual filename length (clamped by PATH_MAX) to ensure a safe copy operation.", "cve_priority": "high", "cve_public_date": "2026-04-22 09:16:00 UTC" }, { "cve": "CVE-2026-31480", "url": "https://ubuntu.com/security/CVE-2026-31480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential deadlock in cpu hotplug with osnoise The following sequence may leads deadlock in cpu hotplug: task1 task2 task3 ----- ----- ----- mutex_lock(&interface_lock) [CPU GOING OFFLINE] cpus_write_lock(); osnoise_cpu_die(); kthread_stop(task3); wait_for_completion(); osnoise_sleep(); mutex_lock(&interface_lock); cpus_read_lock(); [DEAD LOCK] Fix by swap the order of cpus_read_lock() and mutex_lock(&interface_lock).", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31466", "url": "https://ubuntu.com/security/CVE-2026-31466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix folio isn't locked in softleaf_to_folio() On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows: \tCPU0 CPU1 deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags. This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio() because of the race between folio split and zap_nonpresent_ptes() leading to a folio incorrectly undergoing modification without a folio lock being held. This is a BUG_ON() before commit 93976a20345b (\"mm: eliminate further swapops predicates\"), which in merged in v6.19-rc1. To fix it, add missing smp_rmb() if the softleaf entry is migration entry in softleaf_to_folio() and softleaf_to_page(). [tujinjiang@huawei.com: update function name and comments]", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43054", "url": "https://ubuntu.com/security/CVE-2026-43054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Drain commands in target_reset handler tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS without draining any in-flight commands. The SCSI EH documentation (scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver has made lower layers \"forget about timed out scmds\" and is ready for new commands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug, mpi3mr) enforces this by draining or completing outstanding commands before returning SUCCESS. Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight scsi_cmnd structures for recovery commands (e.g. TUR) while the target core still has async completion work queued for the old se_cmd. The memset in queuecommand zeroes se_lun and lun_ref_active, causing transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN reference prevents transport_clear_lun_ref() from completing, hanging configfs LUN unlink forever in D-state: INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transport_clear_lun_ref+0x78/0x90 [target_core_mod] core_tpg_remove_lun+0x28/0xb0 [target_core_mod] target_fabric_port_unlink+0x50/0x60 [target_core_mod] configfs_unlink+0x156/0x1f0 [configfs] vfs_unlink+0x109/0x290 do_unlinkat+0x1d5/0x2d0 Fix this by making tcm_loop_target_reset() actually drain commands: 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that the target core knows about (those not yet CMD_T_COMPLETE). 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and flush_work() on each se_cmd — this drains any deferred completion work for commands that already had CMD_T_COMPLETE set before the TMR (which the TMR skips via __target_check_io_state()). This is the same pattern used by mpi3mr, scsi_debug, and libsas to drain outstanding commands during reset.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-23401", "url": "https://ubuntu.com/security/CVE-2026-23401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE When installing an emulated MMIO SPTE, do so *after* dropping/zapping the existing SPTE (if it's shadow-present). While commit a54aa15c6bda3 was right about it being impossible to convert a shadow-present SPTE to an MMIO SPTE due to a _guest_ write, it failed to account for writes to guest memory that are outside the scope of KVM. E.g. if host userspace modifies a shadowed gPTE to switch from a memslot to emulted MMIO and then the guest hits a relevant page fault, KVM will install the MMIO SPTE without first zapping the shadow-present SPTE. ------------[ cut here ]------------ is_shadow_present_pte(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm] Call Trace: mmu_set_spte+0x237/0x440 [kvm] ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47fa3f ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-04-01 09:16:00 UTC" }, { "cve": "CVE-2026-31454", "url": "https://ubuntu.com/security/CVE-2026-31454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: save ailp before dropping the AIL lock in push callbacks In xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the AIL lock is dropped to perform buffer IO. Once the cluster buffer no longer protects the log item from reclaim, the log item may be freed by background reclaim or the dquot shrinker. The subsequent spin_lock() call dereferences lip->li_ailp, which is a use-after-free. Fix this by saving the ailp pointer in a local variable while the AIL lock is held and the log item is guaranteed to be valid.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31446", "url": "https://ubuntu.com/security/CVE-2026-31446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in update_super_work when racing with umount Commit b98535d09179 (\"ext4: fix bug_on in start_this_handle during umount filesystem\") moved ext4_unregister_sysfs() before flushing s_sb_upd_work to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups reads during unmount. However, this introduced a use-after-free because update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which accesses the kobject's kernfs_node after it has been freed by kobject_del() in ext4_unregister_sysfs(): update_super_work ext4_put_super ----------------- -------------- ext4_unregister_sysfs(sb) kobject_del(&sbi->s_kobj) __kobject_del() sysfs_remove_dir() kobj->sd = NULL sysfs_put(sd) kernfs_put() // RCU free ext4_notify_error_sysfs(sbi) sysfs_notify(&sbi->s_kobj) kn = kobj->sd // stale pointer kernfs_get(kn) // UAF on freed kernfs_node ext4_journal_destroy() flush_work(&sbi->s_sb_upd_work) Instead of reordering the teardown sequence, fix this by making ext4_notify_error_sysfs() detect that sysfs has already been torn down by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call in that case. A dedicated mutex (s_error_notify_mutex) serializes ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs() to prevent TOCTOU races where the kobject could be deleted between the state_in_sysfs check and the sysfs_notify() call.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31450", "url": "https://ubuntu.com/security/CVE-2026-31450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: publish jinode after initialization ext4_inode_attach_jinode() publishes ei->jinode to concurrent users. It used to set ei->jinode before jbd2_journal_init_jbd_inode(), allowing a reader to observe a non-NULL jinode with i_vfs_inode still unset. The fast commit flush path can then pass this jinode to jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and may crash. Below is the crash I observe: ``` BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xas_find_marked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: filemap_get_folios_tag+0x87/0x2a0 __filemap_fdatawait_range+0x5f/0xd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? cap_safe_nice+0x37/0x70 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 filemap_fdatawait_range_keep_errors+0x12/0x40 ext4_fc_commit+0x697/0x8b0 ? ext4_file_write_iter+0x64b/0x950 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? vfs_write+0x356/0x480 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ext4_sync_file+0xf7/0x370 do_fsync+0x3b/0x80 ? syscall_trace_enter+0x108/0x1d0 __x64_sys_fdatasync+0x16/0x20 do_syscall_64+0x62/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... ``` Fix this by initializing the jbd2_inode first. Use smp_wmb() and WRITE_ONCE() to publish ei->jinode after initialization. Readers use READ_ONCE() to fetch the pointer.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31726", "url": "https://ubuntu.com/security/CVE-2026-31726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix NULL pointer dereference during unbind race Commit b81ac4395bbe (\"usb: gadget: uvc: allow for application to cleanly shutdown\") introduced two stages of synchronization waits totaling 1500ms in uvc_function_unbind() to prevent several types of kernel panics. However, this timing-based approach is insufficient during power management (PM) transitions. When the PM subsystem starts freezing user space processes, the wait_event_interruptible_timeout() is aborted early, which allows the unbind thread to proceed and nullify the gadget pointer (cdev->gadget = NULL): [ 814.123447][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind() [ 814.178583][ T3173] PM: suspend entry (deep) [ 814.192487][ T3173] Freezing user space processes [ 814.197668][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind no clean disconnect, wait for release When the PM subsystem resumes or aborts the suspend and tasks are restarted, the V4L2 release path is executed and attempts to access the already nullified gadget pointer, triggering a kernel panic: [ 814.292597][ C0] PM: pm_system_irq_wakeup: 479 triggered dhdpcie_host_wake [ 814.386727][ T3173] Restarting tasks ... [ 814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 814.404021][ T4558] pc : usb_gadget_deactivate+0x14/0xf4 [ 814.404031][ T4558] lr : usb_function_deactivate+0x54/0x94 [ 814.404078][ T4558] Call trace: [ 814.404080][ T4558] usb_gadget_deactivate+0x14/0xf4 [ 814.404083][ T4558] usb_function_deactivate+0x54/0x94 [ 814.404087][ T4558] uvc_function_disconnect+0x1c/0x5c [ 814.404092][ T4558] uvc_v4l2_release+0x44/0xac [ 814.404095][ T4558] v4l2_release+0xcc/0x130 Address the race condition and NULL pointer dereference by: 1. State Synchronization (flag + mutex) Introduce a 'func_unbound' flag in struct uvc_device. This allows uvc_function_disconnect() to safely skip accessing the nullified cdev->gadget pointer. As suggested by Alan Stern, this flag is protected by a new mutex (uvc->lock) to ensure proper memory ordering and prevent instruction reordering or speculative loads. This mutex is also used to protect 'func_connected' for consistent state management. 2. Explicit Synchronization (completion) Use a completion to synchronize uvc_function_unbind() with the uvc_vdev_release() callback. This prevents Use-After-Free (UAF) by ensuring struct uvc_device is freed after all video device resources are released.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31728", "url": "https://ubuntu.com/security/CVE-2026-31728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop A race condition between gether_disconnect() and eth_stop() leads to a NULL pointer dereference. Specifically, if eth_stop() is triggered concurrently while gether_disconnect() is tearing down the endpoints, eth_stop() attempts to access the cleared endpoint descriptor, causing the following NPE: Unable to handle kernel NULL pointer dereference Call trace: __dwc3_gadget_ep_enable+0x60/0x788 dwc3_gadget_ep_enable+0x70/0xe4 usb_ep_enable+0x60/0x15c eth_stop+0xb8/0x108 Because eth_stop() crashes while holding the dev->lock, the thread running gether_disconnect() fails to acquire the same lock and spins forever, resulting in a hardlockup: Core - Debugging Information for Hardlockup core(7) Call trace: queued_spin_lock_slowpath+0x94/0x488 _raw_spin_lock+0x64/0x6c gether_disconnect+0x19c/0x1e8 ncm_set_alt+0x68/0x1a0 composite_setup+0x6a0/0xc50 The root cause is that the clearing of dev->port_usb in gether_disconnect() is delayed until the end of the function. Move the clearing of dev->port_usb to the very beginning of gether_disconnect() while holding dev->lock. This cuts off the link immediately, ensuring eth_stop() will see dev->port_usb as NULL and safely bail out.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31721", "url": "https://ubuntu.com/security/CVE-2026-31721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: move list and spinlock inits from bind to alloc There was an issue when you did the following: - setup and bind an hid gadget - open /dev/hidg0 - use the resulting fd in EPOLL_CTL_ADD - unbind the UDC - bind the UDC - use the fd in EPOLL_CTL_DEL When CONFIG_DEBUG_LIST was enabled, a list_del corruption was reported within remove_wait_queue (via ep_remove_wait_queue). After some debugging I found out that the queues, which f_hid registers via poll_wait were the problem. These were initialized using init_waitqueue_head inside hidg_bind. So effectively, the bind function re-initialized the queues while there were still items in them. The solution is to move the initialization from hidg_bind to hidg_alloc to extend their lifetimes to the lifetime of the function instance. Additionally, I found many other possibly problematic init calls in the bind function, which I moved as well.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31670", "url": "https://ubuntu.com/security/CVE-2026-31670", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rfkill: prevent unlimited numbers of rfkill events from being created Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a \"large\" number (i.e. 1000) to prevent abuses like this.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31634", "url": "https://ubuntu.com/security/CVE-2026-31634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix reference count leak in rxrpc_server_keyring() This patch fixes a reference count leak in rxrpc_server_keyring() by checking if rx->securities is already set.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31651", "url": "https://ubuntu.com/security/CVE-2026-31651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix NULL-deref on disconnect Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31656", "url": "https://ubuntu.com/security/CVE-2026-31656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` <4> [487.221889] Workqueue: i915-unordered engine_retire [i915] <4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] Call Trace: <4> [487.222711] <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ? __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ? __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ? __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] ``` Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it. (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31658", "url": "https://ubuntu.com/security/CVE-2026-31658", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit() When dma_map_single() fails in tse_start_xmit(), the function returns NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure. Add dev_kfree_skb_any() before returning to properly free the skb.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31660", "url": "https://ubuntu.com/security/CVE-2026-31660", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: allocate rx skb before consuming bytes pn532_receive_buf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already hand a complete frame to pn533_recv_frame() before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31661", "url": "https://ubuntu.com/security/CVE-2026-31661", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: Fix dma_free_coherent() size dma_alloc_consistent() may change the size to align it. The new size is saved in alloced. Change the free size to match the allocation size.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31662", "url": "https://ubuntu.com/security/CVE-2026-31662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round. Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31665", "url": "https://ubuntu.com/security/CVE-2026-31665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: fix use-after-free in timeout object destroy nft_ct_timeout_obj_destroy() frees the timeout object with kfree() immediately after nf_ct_untimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcu_dereference() in nf_ct_timeout_data(). Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c. KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2024-56557", "url": "https://ubuntu.com/security/CVE-2024-56557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer The AD7923 was updated to support devices with 8 channels, but the size of tx_buf and ring_xfer was not increased accordingly, leading to a potential buffer overflow in ad7923_update_scan_mode().", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2024-36898", "url": "https://ubuntu.com/security/CVE-2024-36898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: fix uninitialised kfifo If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace. Initialise the kfifo in the case where the software debounce is already active.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2025-40016", "url": "https://ubuntu.com/security/CVE-2025-40016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID. In a previous attempt commit 3dd075fe8ebb (\"media: uvcvideo: Require entities to have a non-zero unique ID\"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2026-31667", "url": "https://ubuntu.com/security/CVE-2026-31667", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: uinput - fix circular locking dependency with ff-core A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller): ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex The cycle is caused by four lock acquisition paths: 1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex. 2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex. 3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex. 4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex. Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes. To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock. Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible. Lock ordering after the fix: ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31671", "url": "https://ubuntu.com/security/CVE-2026-31671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_report() struct xfrm_user_report is a __u8 proto field followed by a struct xfrm_selector which means there is three \"empty\" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31672", "url": "https://ubuntu.com/security/CVE-2026-31672", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00usb: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the USB anchor lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43336", "url": "https://ubuntu.com/security/CVE-2026-43336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: chacha: Zeroize permuted_state before it leaves scope Since the ChaCha permutation is invertible, the local variable 'permuted_state' is sufficient to compute the original 'state', and thus the key, even after the permutation has been done. While the kernel is quite inconsistent about zeroizing secrets on the stack (and some prominent userspace crypto libraries don't bother at all since it's not guaranteed to work anyway), the kernel does try to do it as a best practice, especially in cases involving the RNG. Thus, explicitly zeroize 'permuted_state' before it goes out of scope.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31695", "url": "https://ubuntu.com/security/CVE-2026-31695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free Currently we execute `SET_NETDEV_DEV(dev, &priv->lowerdev->dev)` for the virt_wifi net devices. However, unregistering a virt_wifi device in netdev_run_todo() can happen together with the device referenced by SET_NETDEV_DEV(). It can result in use-after-free during the ethtool operations performed on a virt_wifi device that is currently being unregistered. Such a net device can have the `dev.parent` field pointing to the freed memory, but ethnl_ops_begin() calls `pm_runtime_get_sync(dev->dev.parent)`. Let's remove SET_NETDEV_DEV for virt_wifi to avoid bugs like this: ================================================================== BUG: KASAN: slab-use-after-free in __pm_runtime_resume+0xe2/0xf0 Read of size 2 at addr ffff88810cfc46f8 by task pm/606 Call Trace: dump_stack_lvl+0x4d/0x70 print_report+0x170/0x4f3 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 kasan_report+0xda/0x110 ? __pm_runtime_resume+0xe2/0xf0 ? __pm_runtime_resume+0xe2/0xf0 __pm_runtime_resume+0xe2/0xf0 ethnl_ops_begin+0x49/0x270 ethnl_set_features+0x23c/0xab0 ? __pfx_ethnl_set_features+0x10/0x10 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xf/0xf0 ? local_clock+0x10/0x30 ? kasan_save_track+0x25/0x60 ? __kasan_kmalloc+0x7f/0x90 ? genl_family_rcv_msg_attrs_parse.isra.0+0x150/0x2c0 genl_family_rcv_msg_doit+0x1e7/0x2c0 ? __pfx_genl_family_rcv_msg_doit+0x10/0x10 ? __pfx_cred_has_capability.isra.0+0x10/0x10 ? stack_trace_save+0x8e/0xc0 genl_rcv_msg+0x411/0x660 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_ethnl_set_features+0x10/0x10 netlink_rcv_skb+0x121/0x380 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_down_read+0x10/0x10 genl_rcv+0x23/0x30 netlink_unicast+0x60f/0x830 ? __pfx_netlink_unicast+0x10/0x10 ? __pfx___alloc_skb+0x10/0x10 netlink_sendmsg+0x6ea/0xbc0 ? __pfx_netlink_sendmsg+0x10/0x10 ? __futex_queue+0x10b/0x1f0 ____sys_sendmsg+0x7a2/0x950 ? copy_msghdr_from_user+0x26b/0x430 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ___sys_sendmsg+0xf8/0x180 ? __pfx____sys_sendmsg+0x10/0x10 ? __pfx_futex_wait+0x10/0x10 ? fdget+0x2e4/0x4a0 __sys_sendmsg+0x11f/0x1c0 ? __pfx___sys_sendmsg+0x10/0x10 do_syscall_64+0xe2/0x570 ? exc_page_fault+0x66/0xb0 entry_SYSCALL_64_after_hwframe+0x77/0x7f This fix may be combined with another one in the ethtool subsystem: https://lore.kernel.org/all/20260322075917.254874-1-alex.popov@linux.com/T/#u", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2024-56584", "url": "https://ubuntu.com/security/CVE-2024-56584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/tctx: work around xa_store() allocation error issue syzbot triggered the following WARN_ON: WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51 which is the WARN_ON_ONCE(!xa_empty(&tctx->xa)); sanity check in __io_uring_free() when a io_uring_task is going through its final put. The syzbot test case includes injecting memory allocation failures, and it very much looks like xa_store() can fail one of its memory allocations and end up with ->head being non-NULL even though no entries exist in the xarray. Until this issue gets sorted out, work around it by attempting to iterate entries in our xarray, and WARN_ON_ONCE() if one is found.", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2026-31720", "url": "https://ubuntu.com/security/CVE-2026-31720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: validate control request size f_audio_complete() copies req->length bytes into a 4-byte stack variable: u32 data = 0; memcpy(&data, req->buf, req->length); req->length is derived from the host-controlled USB request path, which can lead to a stack out-of-bounds write. Validate req->actual against the expected payload size for the supported control selectors and decode only the expected amount of data. This avoids copying a host-influenced length into a fixed-size stack object.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43342", "url": "https://ubuntu.com/security/CVE-2026-43342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Protect RNDIS options with mutex The class/subclass/protocol options are suspectible to race conditions as they can be accessed concurrently through configfs. Use existing mutex to protect these options. This issue was identified during code inspection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43343", "url": "https://ubuntu.com/security/CVE-2026-43343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_subset: Fix unbalanced refcnt in geth_free geth_alloc() increments the reference count, but geth_free() fails to decrement it. This prevents the configuration of attributes via configfs after unlinking the function. Decrement the reference count in geth_free() to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-68256", "url": "https://ubuntu.com/security/CVE-2025-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser The Information Element (IE) parser rtw_get_ie() trusted the length byte of each IE without validating that the IE body (len bytes after the 2-byte header) fits inside the remaining frame buffer. A malformed frame can advertise an IE length larger than the available data, causing the parser to increment its pointer beyond the buffer end. This results in out-of-bounds reads or, depending on the pattern, an infinite loop. Fix by validating that (offset + 2 + len) does not exceed the limit before accepting the IE or advancing to the next element. This prevents OOB reads and ensures the parser terminates safely on malformed frames.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40103", "url": "https://ubuntu.com/security/CVE-2025-40103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix refcount leak for cifs_sb_tlink Fix three refcount inconsistency issues related to `cifs_sb_tlink`. Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be called after successful calls to `cifs_sb_tlink()`. Three calls fail to update refcount accordingly, leading to possible resource leaks.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-38006", "url": "https://ubuntu.com/security/CVE-2025-38006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: Don't access ifa_index when missing In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but only when the struct ifaddrmsg is provided. Otherwise it will be comparing to uninitialised memory - reproducible in the syzkaller case from dhcpd, or busybox \"ip addr show\". The kernel MCTP implementation has always filtered by ifa_index, so existing userspace programs expecting to dump MCTP addresses must already be passing a valid ifa_index value (either 0 or a real index). BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40323", "url": "https://ubuntu.com/security/CVE-2025-40323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Set fb_display[i]->mode to NULL when the mode is released Recently, we discovered the following issue through syzkaller: BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0. Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2026-23031", "url": "https://ubuntu.com/security/CVE-2026-23031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak In gs_can_open(), the URBs for USB-in transfers are allocated, added to the parent->rx_submitted anchor and submitted. In the complete callback gs_usb_receive_bulk_callback(), the URB is processed and resubmitted. In gs_can_close() the URBs are freed by calling usb_kill_anchored_urbs(parent->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in gs_can_close(). Fix the memory leak by anchoring the URB in the gs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-43324", "url": "https://ubuntu.com/security/CVE-2026-43324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix interrupt synchronization error This fixes an error in synchronization in the dummy-hcd driver. The error has a somewhat involved history. The synchronization mechanism was introduced by commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), which added an emulated \"interrupts enabled\" flag together with code emulating synchronize_irq() (it waits until all current handler callbacks have returned). But the emulated interrupt-disable occurred too late, after the driver containing the handler callback routines had been told that it was unbound and no more callbacks would occur. Commit 4a5d797a9f9c (\"usb: gadget: dummy_hcd: fix gpf in gadget_setup\") tried to fix this by moving the synchronize_irq() emulation code from dummy_stop() to dummy_pullup(), which runs before the unbind callback. There still were races, though, because the emulated interrupt-disable still occurred too late. It couldn't be moved to dummy_pullup(), because that routine can be called for reasons other than an impending unbind. Therefore commits 7dc0c55e9f30 (\"USB: UDC core: Add udc_async_callbacks gadget op\") and 04145a03db9d (\"USB: UDC: Implement udc_async_callbacks in dummy-hcd\") added an API allowing the UDC core to tell dummy-hcd exactly when emulated interrupts and their callbacks should be disabled. That brings us to the current state of things, which is still wrong because the emulated synchronize_irq() occurs before the emulated interrupt-disable! That's no good, beause it means that more emulated interrupts can occur after the synchronize_irq() emulation has run, leading to the possibility that a callback handler may be running when the gadget driver is unbound. To fix this, we have to move the synchronize_irq() emulation code yet again, to the dummy_udc_async_callbacks() routine, which takes care of enabling and disabling emulated interrupt requests. The synchronization will now run immediately after emulated interrupts are disabled, which is where it belongs.", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43327", "url": "https://ubuntu.com/security/CVE-2026-43327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix locking/synchronization error Syzbot testing was able to provoke an addressing exception and crash in the usb_gadget_udc_reset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second (\"driver\") argument of NULL. The bad caller was set_link_state() in dummy_hcd.c, and the problem arose because of a race between a USB reset and driver unbind. These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first. The error responsible for the syzbot crash occurred because the stop_activity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stop_activity() occurs in set_link_state() when handling an emulated USB reset, after the test of dum->ints_enabled and before the increment of dum->callback_usage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->ints_enabled and dum->driver. Normally this other thread would have to wait for dum->callback_usage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callback_usage had not yet been incremented. The fix is to increment dum->callback_usage _before_ calling stop_activity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usb_gadget_udc_reset() safely returns and dum->callback_usage has been decremented again.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31737", "url": "https://ubuntu.com/security/CVE-2026-31737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ftgmac100: fix ring allocation unwind on open failure ftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, and rx_scratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function. Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31738", "url": "https://ubuntu.com/security/CVE-2026-31738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: validate ND option lengths in vxlan_na_create vxlan_na_create() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31747", "url": "https://ubuntu.com/security/CVE-2026-31747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me4000: Fix potential overrun of firmware buffer `me4000_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`. Note: The firmware loading was totally broken before commit ac584af59945 (\"staging: comedi: me4000: fix firmware downloading\"), but that is the most sensible target for this fix.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31748", "url": "https://ubuntu.com/security/CVE-2026-31748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me_daq: Fix potential overrun of firmware buffer `me2600_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Although it checks that the supplied firmware is at least 16 bytes long, it does not check that it is long enough to contain the data stream. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31749", "url": "https://ubuntu.com/security/CVE-2026-31749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: ni_atmio16d: Fix invalid clean-up after failed attach If the driver's COMEDI \"attach\" handler function (`atmio16d_attach()`) returns an error, the COMEDI core will call the driver's \"detach\" handler function (`atmio16d_detach()`) to clean up. This calls `reset_atmio16d()` unconditionally, but depending on where the error occurred in the attach handler, the device may not have been sufficiently initialized to call `reset_atmio16d()`. It uses `dev->iobase` as the I/O port base address and `dev->private` as the pointer to the COMEDI device's private data structure. `dev->iobase` may still be set to its initial value of 0, which would result in undesired writes to low I/O port addresses. `dev->private` may still be `NULL`, which would result in null pointer dereferences. Fix `atmio16d_detach()` by checking that `dev->private` is valid (non-null) before calling `reset_atmio16d()`. This implies that `dev->iobase` was set correctly since that is set up before `dev->private`.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43340", "url": "https://ubuntu.com/security/CVE-2026-43340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Reinit dev->spinlock between attachments to low-level drivers `struct comedi_device` is the main controlling structure for a COMEDI device created by the COMEDI subsystem. It contains a member `spinlock` containing a spin-lock that is initialized by the COMEDI subsystem, but is reserved for use by a low-level driver attached to the COMEDI device (at least since commit 25436dc9d84f (\"Staging: comedi: remove RT code\")). Some COMEDI devices (those created on initialization of the COMEDI subsystem when the \"comedi.comedi_num_legacy_minors\" parameter is non-zero) can be attached to different low-level drivers over their lifetime using the `COMEDI_DEVCONFIG` ioctl command. This can result in inconsistent lock states being reported when there is a mismatch in the spin-lock locking levels used by each low-level driver to which the COMEDI device has been attached. Fix it by reinitializing `dev->spinlock` before calling the low-level driver's `attach` function pointer if `CONFIG_LOCKDEP` is enabled.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31751", "url": "https://ubuntu.com/security/CVE-2026-31751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: dt2815: add hardware detection to prevent crash The dt2815 driver crashes when attached to I/O ports without actual hardware present. This occurs because syzkaller or users can attach the driver to arbitrary I/O addresses via COMEDI_DEVCONFIG ioctl. When no hardware exists at the specified port, inb() operations return 0xff (floating bus), but outb() operations can trigger page faults due to undefined behavior, especially under race conditions: BUG: unable to handle page fault for address: 000000007fffff90 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:dt2815_attach+0x6e0/0x1110 Add hardware detection by reading the status register before attempting any write operations. If the read returns 0xff, assume no hardware is present and fail the attach with -ENODEV. This prevents crashes from outb() operations on non-existent hardware.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31752", "url": "https://ubuntu.com/security/CVE-2026-31752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: validate ND option lengths br_nd_send() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31754", "url": "https://ubuntu.com/security/CVE-2026-31754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix state inconsistency on gadget init failure When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency. When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error, so cdns_role_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles. This leads to a synchronous external abort in xhci_gen_setup() when setting up the host controller: [ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408 [ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switch Fix by calling cdns_drd_gadget_off() in the error path to properly clean up the DRD gadget state.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31755", "url": "https://ubuntu.com/security/CVE-2026-31755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix NULL pointer dereference in ep_queue When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when __cdns3_gadget_ep_queue() is called, causing a kernel crash. Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints. This prevents potential crashes when ep_queue is called on endpoints that are not ready.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31756", "url": "https://ubuntu.com/security/CVE-2026-31756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop() dwc2_gadget_exit_clock_gating() internally calls call_gadget() macro, which expects hsotg->lock to be held since it does spin_unlock/spin_lock around the gadget driver callback invocation. However, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating() without holding the lock. This leads to: - spin_unlock on a lock that is not held (undefined behavior) - The lock remaining held after dwc2_gadget_exit_clock_gating() returns, causing a deadlock when spin_lock_irqsave() is called later in the same function. Fix this by acquiring hsotg->lock before calling dwc2_gadget_exit_clock_gating() and releasing it afterwards, which satisfies the locking requirement of the call_gadget() macro.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31758", "url": "https://ubuntu.com/security/CVE-2026-31758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbtmc: Flush anchored URBs in usbtmc_release When calling usbtmc_release, pending anchored URBs must be flushed or killed to prevent use-after-free errors (e.g. in the HCD giveback path). Call usbtmc_draw_down() to allow anchored URBs to be completed.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31759", "url": "https://ubuntu.com/security/CVE-2026-31759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: fix double free in ulpi_register_interface() error path When device_register() fails, ulpi_register() calls put_device() on ulpi->dev. The device release callback ulpi_dev_release() drops the OF node reference and frees ulpi, but the current error path in ulpi_register_interface() then calls kfree(ulpi) again, causing a double free. Let put_device() handle the cleanup through ulpi_dev_release() and avoid freeing ulpi again in ulpi_register_interface().", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31761", "url": "https://ubuntu.com/security/CVE-2026-31761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Move iio_device_register() to correct location iio_device_register() should be at the end of the probe function to prevent race conditions. Place iio_device_register() at the end of the probe function and place iio_device_unregister() accordingly.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31762", "url": "https://ubuntu.com/security/CVE-2026-31762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix irq resource leak The interrupt handler is setup but only a few lines down if iio_trigger_register() fails the function returns without properly releasing the handler. Add cleanup goto to resolve resource leak. Detected by Smatch: drivers/iio/gyro/mpu3050-core.c:1128 mpu3050_trigger_probe() warn: 'irq' from request_threaded_irq() not released on lines: 1124.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31763", "url": "https://ubuntu.com/security/CVE-2026-31763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix incorrect free_irq() variable The handler for the IRQ part of this driver is mpu3050->trig but, in the teardown free_irq() is called with handler mpu3050. Use correct IRQ handler when calling free_irq().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31770", "url": "https://ubuntu.com/security/CVE-2026-31770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) Fix division by zero in occ_show_power_1() In occ_show_power_1() case 1, the accumulator is divided by update_tag without checking for zero. If no samples have been collected yet (e.g. during early boot when the sensor block is included but hasn't been updated), update_tag is zero, causing a kernel divide-by-zero crash. The 2019 fix in commit 211186cae14d (\"hwmon: (occ) Fix division by zero issue\") only addressed occ_get_powr_avg() used by occ_show_power_2() and occ_show_power_a0(). This separate code path in occ_show_power_1() was missed. Fix this by reusing the existing occ_get_powr_avg() helper, which already handles the zero-sample case and uses mul_u64_u32_div() to multiply before dividing for better precision. Move the helper above occ_show_power_1() so it is visible at the call site. [groeck: Fix alignment problems reported by checkpatch]", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43334", "url": "https://ubuntu.com/security/CVE-2026-43334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: force responder MITM requirements before building the pairing response smp_cmd_pairing_req() currently builds the pairing response from the initiator auth_req before enforcing the local BT_SECURITY_HIGH requirement. If the initiator omits SMP_AUTH_MITM, the response can also omit it even though the local side still requires MITM. tk_request() then sees an auth value without SMP_AUTH_MITM and may select JUST_CFM, making method selection inconsistent with the pairing policy the responder already enforces. When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMP_AUTH_MITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31773", "url": "https://ubuntu.com/security/CVE-2026-31773", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: derive legacy responder STK authentication from MITM state The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved. For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result. This also keeps the legacy path aligned with the Secure Connections code, which already treats JUST_WORKS/JUST_CFM as unauthenticated.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31776", "url": "https://ubuntu.com/security/CVE-2026-31776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix missing SPDIFI1 index handling SPDIF1 DAIO type isn't properly handled in daio_device_index() for hw20k2, and it returned -EINVAL, which ended up with the out-of-bounds array access. Follow the hw20k1 pattern and return the proper index for this type, too.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31778", "url": "https://ubuntu.com/security/CVE-2026-31778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix stack out-of-bounds read in init_card The loop creates a whitespace-stripped copy of the card shortname where `len < sizeof(card->id)` is used for the bounds check. Since sizeof(card->id) is 16 and the local id buffer is also 16 bytes, writing 16 non-space characters fills the entire buffer, overwriting the terminating nullbyte. When this non-null-terminated string is later passed to snd_card_set_id() -> copy_valid_id_string(), the function scans forward with `while (*nid && ...)` and reads past the end of the stack buffer, reading the contents of the stack. A USB device with a product name containing many non-ASCII, non-space characters (e.g. multibyte UTF-8) will reliably trigger this as follows: BUG: KASAN: stack-out-of-bounds in copy_valid_id_string sound/core/init.c:696 [inline] BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c sound/core/init.c:718 The off-by-one has been present since commit bafeee5b1f8d (\"ALSA: snd_usb_caiaq: give better shortname\") from June 2009 (v2.6.31-rc1), which first introduced this whitespace-stripping loop. The original code never accounted for the null terminator when bounding the copy. Fix this by changing the loop bound to `sizeof(card->id) - 1`, ensuring at least one byte remains as the null terminator.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31780", "url": "https://ubuntu.com/security/CVE-2026-31780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation The variable valuesize is declared as u8 but accumulates the total length of all SSIDs to scan. Each SSID contributes up to 33 bytes (IEEE80211_MAX_SSID_LEN + 1), and with WILC_MAX_NUM_PROBED_SSID (10) SSIDs the total can reach 330, which wraps around to 74 when stored in a u8. This causes kmalloc to allocate only 75 bytes while the subsequent memcpy writes up to 331 bytes into the buffer, resulting in a 256-byte heap buffer overflow. Widen valuesize from u8 to u32 to accommodate the full range.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31781", "url": "https://ubuntu.com/security/CVE-2026-31781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ioc32: stop speculation on the drm_compat_ioctl path The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling array_index_nospec() on the index to the function pointer list.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43333", "url": "https://ubuntu.com/security/CVE-2026-43333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject direct access to nullable PTR_TO_BUF pointers check_mem_access() matches PTR_TO_BUF via base_type() which strips PTR_MAYBE_NULL, allowing direct dereference without a null check. Map iterator ctx->key and ctx->value are PTR_TO_BUF | PTR_MAYBE_NULL. On stop callbacks these are NULL, causing a kernel NULL dereference. Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching the existing PTR_TO_BTF_ID pattern.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31415", "url": "https://ubuntu.com/security/CVE-2026-31415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid overflows in ip6_datagram_send_ctl() Yiming Qian reported : I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via `skb_under_panic()` (local DoS). The core issue is a mismatch between: - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type `__u16`) and - a pointer to the *last* provided destination-options header (`opt->dst1opt`) when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided. - `include/net/ipv6.h`: - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible). (lines 291-307, especially 298) - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`: - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen` without rejecting duplicates. (lines 909-933) - `net/ipv6/ip6_output.c:__ip6_append_data()`: - Uses `opt->opt_flen + opt->opt_nflen` to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - `net/ipv6/ip6_output.c:__ip6_make_skb()`: - Calls `ipv6_push_frag_opts()` if `opt->opt_flen` is non-zero. (lines 1930-1934) - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`: - Push size comes from `ipv6_optlen(opt->dst1opt)` (based on the pointed-to header). (lines 1179-1185 and 1206-1211) 1. `opt_flen` is a 16-bit accumulator: - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`. 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs and increments `opt_flen` each time: - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`: - It computes `len = ((hdr->hdrlen + 1) << 3);` - It checks `CAP_NET_RAW` using `ns_capable(net->user_ns, CAP_NET_RAW)`. (line 922) - Then it does: - `opt->opt_flen += len;` (line 927) - `opt->dst1opt = hdr;` (line 928) There is no duplicate rejection here (unlike the legacy `IPV6_2292DSTOPTS` path which rejects duplicates at `net/ipv6/datagram.c:901-904`). If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps while `dst1opt` still points to a large (2048-byte) destination-options header. In the attached PoC (`poc.c`): - 32 cmsgs with `hdrlen=255` => `len = (255+1)*8 = 2048` - 1 cmsg with `hdrlen=0` => `len = 8` - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8` - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header. 3. The transmit path sizes headers using the wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1463-1465`: - `headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;` With wrapped `opt_flen`, `headersize`/headroom decisions underestimate what will be pushed later. 4. When building the final skb, the actual push length comes from `dst1opt` and is not limited by wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1930-1934`: - `if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);` - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes `dst1opt` via `ipv6_push_exthdr()`. - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does: - `skb_push(skb, ipv6_optlen(opt));` - `memcpy(h, opt, ipv6_optlen(opt));` With insufficient headroom, `skb_push()` underflows and triggers `skb_under_panic()` -> `BUG()`: - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`) - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`) - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target netns user namespace (`ns_capable(net->user_ns, CAP_NET_RAW)`). - Root (or any task with `CAP_NET_RAW`) can trigger this without user namespaces. - An unprivileged `uid=1000` user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced `CAP_NET_RAW` (the attached PoC does this). - Local denial of service: kernel BUG/panic (system crash). - ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31422", "url": "https://ubuntu.com/security/CVE-2026-31422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_flow: fix NULL pointer dereference on shared blocks flow_change() calls tcf_block_q() and dereferences q->handle to derive a default baseclass. Shared blocks leave block->q NULL, causing a NULL deref when a flow filter without a fully qualified baseclass is created on a shared block. Check tcf_block_shared() before accessing block->q and return -EINVAL for shared blocks. This avoids the null-deref shown below: ======================================================================= KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:flow_change (net/sched/cls_flow.c:508) Call Trace: tc_new_tfilter (net/sched/cls_api.c:2432) rtnetlink_rcv_msg (net/core/rtnetlink.c:6980) [...] =======================================================================", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31421", "url": "https://ubuntu.com/security/CVE-2026-31421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL pointer dereference on shared blocks The old-method path in fw_classify() calls tcf_block_q() and dereferences q->handle. Shared blocks leave block->q NULL, causing a NULL deref when an empty cls_fw filter is attached to a shared block and a packet with a nonzero major skb mark is classified. Reject the configuration in fw_change() when the old method (no TCA_OPTIONS) is used on a shared block, since fw_classify()'s old-method path needs block->q which is NULL for shared blocks. The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fw_classify (net/sched/cls_fw.c:81) Call Trace: tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860) tc_run (net/core/dev.c:4401) __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31417", "url": "https://ubuntu.com/security/CVE-2026-31417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix overflow when accumulating packets Add a check to ensure that `x25_sock.fraglen` does not overflow. The `fraglen` also needs to be resetted when purging `fragment_queue` in `x25_clear_queues()`.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43014", "url": "https://ubuntu.com/security/CVE-2026-43014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: properly unregister fixed rate clocks The additional resources allocated with clk_register_fixed_rate() need to be released with clk_unregister_fixed_rate(), otherwise they are lost.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43015", "url": "https://ubuntu.com/security/CVE-2026-43015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix clk handling on PCI glue driver removal platform_device_unregister() may still want to use the registered clks during runtime resume callback. Note that there is a commit d82d5303c4c5 (\"net: macb: fix use after free on rmmod\") that addressed the similar problem of clk vs platform device unregistration but just moved the bug to another place. Save the pointers to clks into local variables for reuse after platform device is unregistered. BUG: KASAN: use-after-free in clk_prepare+0x5a/0x60 Read of size 8 at addr ffff888104f85e00 by task modprobe/597 CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x8d/0xba print_report+0x17f/0x496 kasan_report+0xd9/0x180 clk_prepare+0x5a/0x60 macb_runtime_resume+0x13d/0x410 [macb] pm_generic_runtime_resume+0x97/0xd0 __rpm_callback+0xc8/0x4d0 rpm_callback+0xf6/0x230 rpm_resume+0xeeb/0x1a70 __pm_runtime_resume+0xb4/0x170 bus_remove_device+0x2e3/0x4b0 device_del+0x5b3/0xdc0 platform_device_del+0x4e/0x280 platform_device_unregister+0x11/0x50 pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 519: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x8e/0x90 __clk_register+0x458/0x2890 clk_hw_register+0x1a/0x60 __clk_hw_register_fixed_rate+0x255/0x410 clk_register_fixed_rate+0x3c/0xa0 macb_probe+0x1d8/0x42e [macb_pci] local_pci_probe+0xd7/0x190 pci_device_probe+0x252/0x600 really_probe+0x255/0x7f0 __driver_probe_device+0x1ee/0x330 driver_probe_device+0x4c/0x1f0 __driver_attach+0x1df/0x4e0 bus_for_each_dev+0x15d/0x1f0 bus_add_driver+0x486/0x5e0 driver_register+0x23a/0x3d0 do_one_initcall+0xfd/0x4d0 do_init_module+0x18b/0x5a0 load_module+0x5663/0x7950 __do_sys_finit_module+0x101/0x180 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 597: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x180 __kmem_cache_free+0xbc/0x320 clk_unregister+0x6de/0x8d0 macb_remove+0x73/0xc0 [macb_pci] pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31425", "url": "https://ubuntu.com/security/CVE-2026-31425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: ib: reject FRMR registration before IB connection is established rds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_data and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with i_cm_id = NULL because the connection worker has not yet called rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses the control message before any connection establishment, allowing rds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash the kernel. The existing guard in rds_ib_reg_frmr() only checks for !ic (added in commit 9e630bcb7701), which does not catch this case since ic is allocated early and is always non-NULL once the connection object exists. KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920 Call Trace: rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167) rds_ib_map_frmr (net/rds/ib_frmr.c:252) rds_ib_reg_frmr (net/rds/ib_frmr.c:430) rds_ib_get_mr (net/rds/ib_rdma.c:615) __rds_rdma_map (net/rds/rdma.c:295) rds_cmsg_rdma_map (net/rds/rdma.c:860) rds_sendmsg (net/rds/send.c:1363) ____sys_sendmsg do_syscall_64 Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all non-NULL before proceeding with FRMR registration, mirroring the guard already present in rds_ib_post_inv(). Return -ENODEV when the connection is not ready, which the existing error handling in rds_cmsg_send() converts to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to start the connection worker.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43020", "url": "https://ubuntu.com/security/CVE-2026-43020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate LTK enc_size on load Load Long Term Keys stores the user-provided enc_size and later uses it to size fixed-size stack operations when replying to LE LTK requests. An enc_size larger than the 16-byte key buffer can therefore overflow the reply stack buffer. Reject oversized enc_size values while validating the management LTK record so invalid keys never reach the stored key state.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43024", "url": "https://ubuntu.com/security/CVE-2026-43024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject immediate NF_QUEUE verdict nft_queue is always used from userspace nftables to deliver the NF_QUEUE verdict. Immediately emitting an NF_QUEUE verdict is never used by the userspace nft tools, so reject immediate NF_QUEUE verdicts. The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NF_QUEUE immediate verdicts to address this issue.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31424", "url": "https://ubuntu.com/security/CVE-2026-31424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP Weiming Shi says: xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_* constants. This is only correct for families whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING). ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports: - arpt_CLASSIFY - arpt_mangle - arpt_MARK that provide explicit NFPROTO_ARP match/target declarations.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43026", "url": "https://ubuntu.com/security/CVE-2026-43026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT. The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields. Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled. Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43027", "url": "https://ubuntu.com/security/CVE-2026-43027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_helper: pass helper to expect cleanup nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expect_iter_me() never matches any expectation and all of them survive the cleanup. After unregister returns, nfnl_cthelper_del() frees the helper object immediately. Subsequent expectation dumps or packet-driven init_conntrack() calls then dereference the freed exp->helper, causing a use-after-free. Pass the actual helper pointer so expectations referencing it are properly destroyed before the helper object is freed. BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43028", "url": "https://ubuntu.com/security/CVE-2026-43028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: ensure names are nul-terminated Reject names that lack a \\0 character before feeding them to functions that expect c-strings. Fixes tag is the most recent commit that needs this change.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31416", "url": "https://ubuntu.com/security/CVE-2026-31416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: account for netlink header size This is a followup to an old bug fix: NLMSG_DONE needs to account for the netlink header size, not just the attribute size. This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43329", "url": "https://ubuntu.com/security/CVE-2026-43329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: strictly check for maximum number of actions The maximum number of flowtable hardware offload actions in IPv6 is: * ethernet mangling (4 payload actions, 2 for each ethernet address) * SNAT (4 payload actions) * DNAT (4 payload actions) * Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. * Redirect (1 action) Which makes 17, while the maximum is 16. But act_ct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions. Update flow_action_entry_next() calls to check for the maximum number of supported actions. While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31680", "url": "https://ubuntu.com/security/CVE-2026-31680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: flowlabel: defer exclusive option free until RCU teardown `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file RCU read-side lock and prints `fl->opt->opt_nflen` when an option block is present. Exclusive flowlabels currently free `fl->opt` as soon as `fl->users` drops to zero in `fl_release()`. However, the surrounding `struct ip6_flowlabel` remains visible in the global hash table until later garbage collection removes it and `fl_free_rcu()` finally tears it down. A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that early `kfree()` and dereference freed option state, triggering a crash in `ip6fl_seq_show()`. Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43030", "url": "https://ubuntu.com/security/CVE-2026-43030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix regsafe() for pointers to packet In case rold->reg->range == BEYOND_PKT_END && rcur->reg->range == N regsafe() may return true which may lead to current state with valid packet range not being explored. Fix the bug.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43032", "url": "https://ubuntu.com/security/CVE-2026-43032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: pn533: bound the UART receive buffer pn532_receive_buf() appends every incoming byte to dev->recv_skb and only resets the buffer after pn532_uart_rx_is_frame() recognizes a complete frame. A continuous stream of bytes without a valid PN532 frame header therefore keeps growing the skb until skb_put_u8() hits the tail limit. Drop the accumulated partial frame once the fixed receive buffer is full so malformed UART traffic cannot grow the skb past PN532_UART_SKB_BUFF_LEN.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43035", "url": "https://ubuntu.com/security/CVE-2026-43035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to zero to prevent an info-leak When building netlink messages, tc_chain_fill_node() never initializes the tcm_info field of struct tcmsg. Since the allocation is not zeroed, kernel heap memory is leaked to userspace through this 4-byte field. The fix simply zeroes tcm_info alongside the other fields that are already initialized.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43339", "url": "https://ubuntu.com/security/CVE-2026-43339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible UaF in addrconf_permanent_addr() The mentioned helper try to warn the user about an exceptional condition, but the message is delivered too late, accessing the ipv6 after its possible deletion. Reorder the statement to avoid the possible UaF; while at it, place the warning outside the idev->lock as it needs no protection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31423", "url": "https://ubuntu.com/security/CVE-2026-31423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: fix divide-by-zero in rtsc_min() m2sm() converts a u32 slope to a u64 scaled value. For large inputs (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores the difference of two such u64 values in a u32 variable `dsm` and uses it as a divisor. When the difference is exactly 2^32 the truncation yields zero, causing a divide-by-zero oops in the concave-curve intersection path: Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...] Widen `dsm` to u64 and replace do_div() with div64_u64() so the full difference is preserved.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43040", "url": "https://ubuntu.com/security/CVE-2026-43040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak When processing Router Advertisements with user options the kernel builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data The fix is simple, just zeroes the padding fields.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43041", "url": "https://ubuntu.com/security/CVE-2026-43041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak __radix_tree_create() allocates and links intermediate nodes into the tree one by one. If a subsequent allocation fails, the already-linked nodes remain in the tree with no corresponding leaf entry. These orphaned internal nodes are never reclaimed because radix_tree_for_each_slot() only visits slots containing leaf values. The radix_tree API is deprecated in favor of xarray. As suggested by Matthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray instead of fixing the radix_tree itself [1]. xarray properly handles cleanup of internal nodes — xa_destroy() frees all internal xarray nodes when the qrtr_node is released, preventing the leak. [1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43043", "url": "https://ubuntu.com/security/CVE-2026-43043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af-alg - fix NULL pointer dereference in scatterwalk The AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL) when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL exactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent sendmsg() allocates a new SGL and chains it, but fails to clear the end marker on the previous SGL's last data entry. This causes the crypto scatterwalk to hit a premature end, returning NULL on sg_next() and leading to a kernel panic during dereference. Fix this by explicitly unmarking the end of the previous SGL when performing sg_chain() in af_alg_alloc_tsgl().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43046", "url": "https://ubuntu.com/security/CVE-2026-43046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject root items with drop_progress and zero drop_level [BUG] When recovering relocation at mount time, merge_reloc_root() and btrfs_drop_snapshot() both use BUG_ON(level == 0) to guard against an impossible state: a non-zero drop_progress combined with a zero drop_level in a root_item, which can be triggered: ------------[ cut here ]------------ kernel BUG at fs/btrfs/relocation.c:1545! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2 RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545 Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000 Call Trace: merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861 btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195 btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130 open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640 btrfs_fill_super fs/btrfs/super.c:987 [inline] btrfs_get_tree_super fs/btrfs/super.c:1951 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline] btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ... RIP: 0033:0x7f969c9a8fde Code: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f ---[ end trace 0000000000000000 ]--- The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamic metadata fuzzing tool that corrupts btrfs metadata at runtime. [CAUSE] A non-zero drop_progress.objectid means an interrupted btrfs_drop_snapshot() left a resume point on disk, and in that case drop_level must be greater than 0 because the checkpoint is only saved at internal node levels. Although this invariant is enforced when the kernel writes the root item, it is not validated when the root item is read back from disk. That allows on-disk corruption to provide an invalid state with drop_progress.objectid != 0 and drop_level == 0. When relocation recovery later processes such a root item, merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). The same invalid metadata can also trigger the corresponding BUG_ON() in btrfs_drop_snapshot(). [FIX] Fix this by validating the root_item invariant in tree-checker when reading root items from disk: if drop_progress.objectid is non-zero, drop_level must also be non-zero. Reject such malformed metadata with -EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot() and triggers the BUG_ON. After the fix, the same corruption is correctly rejected by tree-checker and the BUG_ON is no longer triggered.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43047", "url": "https://ubuntu.com/security/CVE-2026-43047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Check to ensure report responses match the request It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes. Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43050", "url": "https://ubuntu.com/security/CVE-2026-43050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix use-after-free in sock_def_readable() A race condition exists between lec_atm_close() setting priv->lecd to NULL and concurrent access to priv->lecd in send_to_lecd(), lec_handle_bridge(), and lec_atm_send(). When the socket is freed via RCU while another thread is still using it, a use-after-free occurs in sock_def_readable() when accessing the socket's wait queue. The root cause is that lec_atm_close() clears priv->lecd without any synchronization, while callers dereference priv->lecd without any protection against concurrent teardown. Fix this by converting priv->lecd to an RCU-protected pointer: - Mark priv->lecd as __rcu in lec.h - Use rcu_assign_pointer() in lec_atm_close() and lecd_attach() for safe pointer assignment - Use rcu_access_pointer() for NULL checks that do not dereference the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and lecd_attach() - Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(), lec_handle_bridge() and lec_atm_send() to safely access lecd - Use rcu_assign_pointer() followed by synchronize_rcu() in lec_atm_close() to ensure all readers have completed before proceeding. This is safe since lec_atm_close() is called from vcc_release() which holds lock_sock(), a sleeping lock. - Remove the manual sk_receive_queue drain from lec_atm_close() since vcc_destroy_socket() already drains it after lec_atm_close() returns. v2: Switch from spinlock + sock_hold/put approach to RCU to properly fix the race. The v1 spinlock approach had two issues pointed out by Eric Dumazet: 1. priv->lecd was still accessed directly after releasing the lock instead of using a local copy. 2. The spinlock did not prevent packets being queued after lec_atm_close() drains sk_receive_queue since timer and workqueue paths bypass netif_stop_queue(). Note: Syzbot patch testing was attempted but the test VM terminated unexpectedly with \"Connection to localhost closed by remote host\", likely due to a QEMU AHCI emulation issue unrelated to this fix. Compile testing with \"make W=1 net/atm/lec.o\" passes cleanly.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43051", "url": "https://ubuntu.com/security/CVE-2026-43051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq The wacom_intuos_bt_irq() function processes Bluetooth HID reports without sufficient bounds checking. A maliciously crafted short report can trigger an out-of-bounds read when copying data into the wacom structure. Specifically, report 0x03 requires at least 22 bytes to safely read the processed data and battery status, while report 0x04 (which falls through to 0x03) requires 32 bytes. Add explicit length checks for these report IDs and log a warning if a short report is received.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31555", "url": "https://ubuntu.com/security/CVE-2026-31555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Clear stale exiting pointer in futex_lock_pi() retry path Fuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524 When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'. After wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0\t\t\t CPU1\t\t CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; \t\t\t futex_lock_pi(uaddr) \t\t\t futex_lock_pi_atomic() \t\t\t\t attach_to_pi_owner() \t\t\t\t // observes EXITING \t\t\t\t *exiting = owner; // takes ref \t\t\t\t return -EBUSY \t\t\t wait_for_owner_exiting(-EBUSY, owner) \t\t\t\t put_task_struct(); // drops ref \t\t\t // exiting still points to owner \t\t\t goto retry; \t\t\t futex_lock_pi_atomic() \t\t\t\t lock_pi_update_atomic() \t\t\t\t cmpxchg(uaddr) \t\t\t\t\t*uaddr ^= WAITERS // whatever \t\t\t\t // value changed \t\t\t\t return -EAGAIN; \t\t\t wait_for_owner_exiting(-EAGAIN, exiting) // stale \t\t\t\t WARN_ON_ONCE(exiting) Fix this by resetting upon retry, essentially aligning it with requeue_pi.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43065", "url": "https://ubuntu.com/security/CVE-2026-43065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: always drain queued discard work in ext4_mb_release() While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]: > If the filesystem is initially mounted with the discard option, > deleting files will populate sbi->s_discard_list and queue > s_discard_work. If it is then remounted with nodiscard, the > EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is > neither cancelled nor flushed. [1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing. In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own. Fix it because it's a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-43066", "url": "https://ubuntu.com/security/CVE-2026-43066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths During code review, Joseph found that ext4_fc_replay_inode() calls ext4_get_fc_inode_loc() to get the inode location, which holds a reference to iloc.bh that must be released via brelse(). However, several error paths jump to the 'out' label without releasing iloc.bh: - ext4_handle_dirty_metadata() failure - sync_dirty_buffer() failure - ext4_mark_inode_used() failure - ext4_iget() failure Fix this by introducing an 'out_brelse' label placed just before the existing 'out' label to ensure iloc.bh is always released. Additionally, make ext4_fc_replay_inode() propagate errors properly instead of always returning 0.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31447", "url": "https://ubuntu.com/security/CVE-2026-31447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: reject mount if bigalloc with s_first_data_block != 0 bigalloc with s_first_data_block != 0 is not supported, reject mounting it.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43068", "url": "https://ubuntu.com/security/CVE-2026-43068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal() There's issue as follows: ... EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): error count since last fsck: 1 EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760 EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760 ... According to the log analysis, blocks are always requested from the corrupted block group. This may happen as follows: ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return error ext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out; After commit 9008a58e5dce (\"ext4: make the bitmap read routines return real error codes\") merged, Commit 163a203ddb36 (\"ext4: mark block group as corrupt on block bitmap error\") is no real solution for allocating blocks from corrupted block groups. This is because if 'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then 'ext4_mb_load_buddy()' may return an error. This means that the block allocation will fail. Therefore, check block group if corrupted when ext4_mb_load_buddy() returns error.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31452", "url": "https://ubuntu.com/security/CVE-2026-31452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: convert inline data to extents when truncate exceeds inline size Add a check in ext4_setattr() to convert files from inline data storage to extent-based storage when truncate() grows the file size beyond the inline capacity. This prevents the filesystem from entering an inconsistent state where the inline data flag is set but the file size exceeds what can be stored inline. Without this fix, the following sequence causes a kernel BUG_ON(): 1. Mount filesystem with inode that has inline flag set and small size 2. truncate(file, 50MB) - grows size but inline flag remains set 3. sendfile() attempts to write data 4. ext4_write_inline_data() hits BUG_ON(write_size > inline_capacity) The crash occurs because ext4_write_inline_data() expects inline storage to accommodate the write, but the actual inline capacity (~60 bytes for i_block + ~96 bytes for xattrs) is far smaller than the file size and write request. The fix checks if the new size from setattr exceeds the inode's actual inline capacity (EXT4_I(inode)->i_inline_size) and converts the file to extent-based storage before proceeding with the size change. This addresses the root cause by ensuring the inline data flag and file size remain consistent during truncate operations.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31455", "url": "https://ubuntu.com/security/CVE-2026-31455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: stop reclaim before pushing AIL during unmount The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while background reclaim and inodegc are still running. This is broken independently of any use-after-free issues - background reclaim and inodegc should not be running while the AIL is being pushed during unmount, as inodegc can dirty and insert inodes into the AIL during the flush, and background reclaim can race to abort and free dirty inodes. Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel background reclaim before pushing the AIL. Stop inodegc before cancelling m_reclaim_work because the inodegc worker can re-queue m_reclaim_work via xfs_inodegc_set_reclaimable.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31464", "url": "https://ubuntu.com/security/CVE-2026-31464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done() A malicious or compromised VIO server can return a num_written value in the discover targets MAD response that exceeds max_targets. This value is stored directly in vhost->num_targets without validation, and is then used as the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], which is only allocated for max_targets entries. Indices at or beyond max_targets access kernel memory outside the DMA-coherent allocation. The out-of-bounds data is subsequently embedded in Implicit Logout and PLOGI MADs that are sent back to the VIO server, leaking kernel memory. Fix by clamping num_written to max_targets before storing it.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31467", "url": "https://ubuntu.com/security/CVE-2026-31467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: add GFP_NOIO in the bio completion if needed The bio completion path in the process context (e.g. dm-verity) will directly call into decompression rather than trigger another workqueue context for minimal scheduling latencies, which can then call vm_map_ram() with GFP_KERNEL. Due to insufficient memory, vm_map_ram() may generate memory swapping I/O, which can cause submit_bio_wait to deadlock in some scenarios. Trimmed down the call stack, as follows: f2fs_submit_read_io submit_bio //bio_list is initialized. mmc_blk_mq_recovery z_erofs_endio vm_map_ram __pte_alloc_kernel __alloc_pages_direct_reclaim shrink_folio_list __swap_writepage submit_bio_wait //bio_list is non-NULL, hang!!! Use memalloc_noio_{save,restore}() to wrap up this path.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31469", "url": "https://ubuntu.com/security/CVE-2026-31469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false A UAF issue occurs when the virtio_net driver is configured with napi_tx=N and the device's IFF_XMIT_DST_RELEASE flag is cleared (e.g., during the configuration of tc route filter rules). When IFF_XMIT_DST_RELEASE is removed from the net_device, the network stack expects the driver to hold the reference to skb->dst until the packet is fully transmitted and freed. In virtio_net with napi_tx=N, skbs may remain in the virtio transmit ring for an extended period. If the network namespace is destroyed while these skbs are still pending, the corresponding dst_ops structure has freed. When a subsequent packet is transmitted, free_old_xmit() is triggered to clean up old skbs. It then calls dst_release() on the skb associated with the stale dst_entry. Since the dst_ops (referenced by the dst_entry) has already been freed, a UAF kernel paging request occurs. fix it by adds skb_dst_drop(skb) in start_xmit to explicitly release the dst reference before the skb is queued in virtio_net. Call Trace: Unable to handle kernel paging request at virtual address ffff80007e150000 CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT ... percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P) dst_release+0xe0/0x110 net/core/dst.c:177 skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177 sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255 dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469 napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527 __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net] free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net] start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net] ... Reproduction Steps: NETDEV=\"enp3s0\" config_qdisc_route_filter() { tc qdisc del dev $NETDEV root tc qdisc add dev $NETDEV root handle 1: prio tc filter add dev $NETDEV parent 1:0 \\ \tprotocol ip prio 100 route to 100 flowid 1:1 ip route add 192.168.1.100/32 dev $NETDEV realm 100 } test_ns() { ip netns add testns ip link set $NETDEV netns testns ip netns exec testns ifconfig $NETDEV 10.0.32.46/24 ip netns exec testns ping -c 1 10.0.32.1 ip netns del testns } config_qdisc_route_filter test_ns sleep 2 test_ns", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31473", "url": "https://ubuntu.com/security/CVE-2026-31473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex MEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0) queue teardown paths. This can race request object cleanup against vb2 queue cancellation and lead to use-after-free reports. We already serialize request queueing against STREAMON/OFF with req_queue_mutex. Extend that serialization to REQBUFS, and also take the same mutex in media_request_ioctl_reinit() so REINIT is in the same exclusion domain. This keeps request cleanup and queue cancellation from running in parallel for request-capable devices.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31570", "url": "https://ubuntu.com/security/CVE-2026-31570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gw: fix OOB heap access in cgw_csum_crc8_rel() cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx(): int from = calc_idx(crc8->from_idx, cf->len); int to = calc_idx(crc8->to_idx, cf->len); int res = calc_idx(crc8->result_idx, cf->len); if (from < 0 || to < 0 || res < 0) return; However, the loop and the result write then use the raw s8 fields directly instead of the computed variables: for (i = crc8->from_idx; ...) /* BUG: raw negative index */ cf->data[crc8->result_idx] = ...; /* BUG: raw negative index */ With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame, calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf->data[-64], and the write goes to cf->data[-64]. This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before the start of the canfd_frame on the heap. The companion function cgw_csum_xor_rel() uses `from`/`to`/`res` correctly throughout; fix cgw_csum_crc8_rel() to match. Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62 To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31483", "url": "https://ubuntu.com/security/CVE-2026-31483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/syscalls: Add spectre boundary for syscall dispatch table The s390 syscall number is directly controlled by userspace, but does not have an array_index_nospec() boundary to prevent access past the syscall function pointer tables.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31485", "url": "https://ubuntu.com/security/CVE-2026-31485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-lpspi: fix teardown order issue (UAF) There is a teardown order issue in the driver. The SPI controller is registered using devm_spi_register_controller(), which delays unregistration of the SPI controller until after the fsl_lpspi_remove() function returns. As the fsl_lpspi_remove() function synchronously tears down the DMA channels, a running SPI transfer triggers the following NULL pointer dereference due to use after free: | fsl_lpspi 42550000.spi: I/O Error in DMA RX | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] | Call trace: | fsl_lpspi_dma_transfer+0x260/0x340 [spi_fsl_lpspi] | fsl_lpspi_transfer_one+0x198/0x448 [spi_fsl_lpspi] | spi_transfer_one_message+0x49c/0x7c8 | __spi_pump_transfer_message+0x120/0x420 | __spi_sync+0x2c4/0x520 | spi_sync+0x34/0x60 | spidev_message+0x20c/0x378 [spidev] | spidev_ioctl+0x398/0x750 [spidev] [...] Switch from devm_spi_register_controller() to spi_register_controller() in fsl_lpspi_probe() and add the corresponding spi_unregister_controller() in fsl_lpspi_remove().", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31565", "url": "https://ubuntu.com/security/CVE-2026-31565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix deadlock during netdev reset with active connections Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering device_delete and subsequent client removal. During client removal, uverbs_client waits for QP reference count to reach zero while cma_client holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31494", "url": "https://ubuntu.com/security/CVE-2026-31494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: use the current queue number for stats There's a potential mismatch between the memory reserved for statistics and the amount of memory written. gem_get_sset_count() correctly computes the number of stats based on the active queues, whereas gem_get_ethtool_stats() indiscriminately copies data using the maximum number of queues, and in the case the number of active queues is less than MACB_MAX_QUEUES, this results in a OOB write as observed in the KASAN splat. ================================================================== BUG: KASAN: vmalloc-out-of-bounds in gem_get_ethtool_stats+0x54/0x78 [macb] Write of size 760 at addr ffff80008080b000 by task ethtool/1027 CPU: [...] Tainted: [E]=UNSIGNED_MODULE Hardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 print_report+0x384/0x5e0 kasan_report+0xa0/0xf0 kasan_check_range+0xe8/0x190 __asan_memcpy+0x54/0x98 gem_get_ethtool_stats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] dev_ethtool+0x1220/0x38c0 dev_ioctl+0x4ac/0xca8 sock_do_ioctl+0x170/0x1d8 sock_ioctl+0x484/0x5d8 __arm64_sys_ioctl+0x12c/0x1b8 invoke_syscall+0xd4/0x258 el0_svc_common.constprop.0+0xb4/0x240 do_el0_svc+0x48/0x68 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 The buggy address belongs to a 1-page vmalloc region starting at 0xffff80008080b000 allocated at dev_ethtool+0x11f0/0x38c0 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff00000a333000 pfn:0xa333 flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff) raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== Fix it by making sure the copied size only considers the active number of queues.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31495", "url": "https://ubuntu.com/security/CVE-2026-31495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: use netlink policy range checks Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors. - CTA_PROTOINFO_TCP_STATE: reject values > TCP_CONNTRACK_SYN_SENT2 at policy level, removing the manual >= TCP_CONNTRACK_MAX check. - CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values > TCP_MAX_WSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count. - CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with CTA_FILTER_F_ALL, removing the manual mask checks. - CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding a new mask define grouping all valid expect flags. Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31427", "url": "https://ubuntu.com/security/CVE-2026-31427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp process_sdp() declares union nf_inet_addr rtp_addr on the stack and passes it to the nf_nat_sip sdp_session hook after walking the SDP media descriptions. However rtp_addr is only initialized inside the media loop when a recognized media type with a non-zero port is found. If the SDP body contains no m= lines, only inactive media sections (m=audio 0 ...) or only unrecognized media types, rtp_addr is never assigned. Despite that, the function still calls hooks->sdp_session() with &rtp_addr, causing nf_nat_sdp_session() to format the stale stack value as an IP address and rewrite the SDP session owner and connection lines with it. With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this results in the session-level o= and c= addresses being rewritten to 0.0.0.0 for inactive SDP sessions. Without stack auto-init the rewritten address is whatever happened to be on the stack. Fix this by pre-initializing rtp_addr from the session-level connection address (caddr) when available, and tracking via a have_rtp_addr flag whether any valid address was established. Skip the sdp_session hook entirely when no valid address exists.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31674", "url": "https://ubuntu.com/security/CVE-2026-31674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check() Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS. rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[]. Validate addrnr during rule installation so malformed rules are rejected before the match logic can use an out-of-range value.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31428", "url": "https://ubuntu.com/security/CVE-2026-31428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD __build_packet_message() manually constructs the NFULA_PAYLOAD netlink attribute using skb_put() and skb_copy_bits(), bypassing the standard nla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes are allocated (including NLA alignment padding), only data_len bytes of actual packet data are copied. The trailing nla_padlen(data_len) bytes (1-3 when data_len is not 4-byte aligned) are never initialized, leaking stale heap contents to userspace via the NFLOG netlink socket. Replace the manual attribute construction with nla_reserve(), which handles the tailroom check, header setup, and padding zeroing via __nla_reserve(). The subsequent skb_copy_bits() fills in the payload data on top of the properly initialized attribute.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31497", "url": "https://ubuntu.com/security/CVE-2026-31497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: clamp SCO altsetting table indices btusb_work() maps the number of active SCO links to USB alternate settings through a three-entry lookup table when CVSD traffic uses transparent voice settings. The lookup currently indexes alts[] with data->sco_num - 1 without first constraining sco_num to the number of available table entries. While the table only defines alternate settings for up to three SCO links, data->sco_num comes from hci_conn_num() and is used directly. Cap the lookup to the last table entry before indexing it so the driver keeps selecting the highest supported alternate setting without reading past alts[].", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31498", "url": "https://ubuntu.com/security/CVE-2026-31498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop l2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTED state to support L2CAP reconfiguration (e.g. MTU changes). However, since both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set from the initial configuration, the reconfiguration path falls through to l2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, and retrans_list without freeing the previous allocations and sets chan->sdu to NULL without freeing the existing skb. This leaks all previously allocated ERTM resources. Additionally, l2cap_parse_conf_req() does not validate the minimum value of remote_mps derived from the RFC max_pdu_size option. A zero value propagates to l2cap_segment_sdu() where pdu_len becomes zero, causing the while loop to never terminate since len is never decremented, exhausting all available memory. Fix the double-init by skipping l2cap_ertm_init() and l2cap_chan_ready() when the channel is already in BT_CONNECTED state, while still allowing the reconfiguration parameters to be updated through l2cap_parse_conf_req(). Also add a pdu_len zero check in l2cap_segment_sdu() as a safeguard.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31507", "url": "https://ubuntu.com/security/CVE-2026-31507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffer smc_rx_splice() allocates one smc_spd_priv per pipe_buffer and stores the pointer in pipe_buffer.private. The pipe_buf_operations for these buffers used .get = generic_pipe_buf_get, which only increments the page reference count when tee(2) duplicates a pipe buffer. The smc_spd_priv pointer itself was not handled, so after tee() both the original and the cloned pipe_buffer share the same smc_spd_priv *. When both pipes are subsequently released, smc_rx_pipe_buf_release() is called twice against the same object: 1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct] 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF] KASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), which then escalates to a NULL-pointer dereference and kernel panic via smc_rx_update_consumer() when it chases the freed priv->smc pointer: BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x650 kasan_report+0xc6/0x100 smc_rx_pipe_buf_release+0x78/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smc_rx_update_consumer+0x8d/0x350 Call Trace: smc_rx_pipe_buf_release+0x121/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception Beyond the memory-safety problem, duplicating an SMC splice buffer is semantically questionable: smc_rx_update_cons() would advance the consumer cursor twice for the same data, corrupting receive-window accounting. A refcount on smc_spd_priv could fix the double-free, but the cursor-accounting issue would still need to be addressed separately. The .get callback is invoked by both tee(2) and splice_pipe_to_pipe() for partial transfers; both will now return -EFAULT. Users who need to duplicate SMC socket data must use a copy-based read path.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31679", "url": "https://ubuntu.com/security/CVE-2026-31679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: validate MPLS set/set_masked payload length validate_set() accepted OVS_KEY_ATTR_MPLS as variable-sized payload for SET/SET_MASKED actions. In action handling, OVS expects fixed-size MPLS key data (struct ovs_key_mpls). Use the already normalized key_len (masked case included) and reject non-matching MPLS action key sizes. Reject invalid MPLS action payload lengths early.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31508", "url": "https://ubuntu.com/security/CVE-2026-31508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Avoid releasing netdev before teardown completes The patch cited in the Fixes tag below changed the teardown code for OVS ports to no longer unconditionally take the RTNL. After this change, the netdev_destroy() callback can proceed immediately to the call_rcu() invocation if the IFF_OVS_DATAPATH flag is already cleared on the netdev. The ovs_netdev_detach_dev() function clears the flag before completing the unregistration, and if it gets preempted after clearing the flag (as can happen on an -rt kernel), netdev_destroy() can complete and the device can be freed before the unregistration completes. This leads to a splat like: [ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025 [ 998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0 [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90 [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246 [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000 [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0 [ 998.393944] PKRU: 55555554 [ 998.393946] Call Trace: [ 998.393949] [ 998.393952] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393961] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393975] ? dp_device_event+0x41/0x80 [openvswitch] [ 998.394009] ? __die_body.cold+0x8/0x12 [ 998.394016] ? die_addr+0x3c/0x60 [ 998.394027] ? exc_general_protection+0x16d/0x390 [ 998.394042] ? asm_exc_general_protection+0x26/0x30 [ 998.394058] ? dev_set_promiscuity+0x8d/0xa0 [ 998.394066] ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch] [ 998.394092] dp_device_event+0x41/0x80 [openvswitch] [ 998.394102] notifier_call_chain+0x5a/0xd0 [ 998.394106] unregister_netdevice_many_notify+0x51b/0xa60 [ 998.394110] rtnl_dellink+0x169/0x3e0 [ 998.394121] ? rt_mutex_slowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlink_rcv_msg+0x142/0x3f0 [ 998.394128] ? avc_has_perm_noaudit+0x69/0xf0 [ 998.394130] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 998.394132] netlink_rcv_skb+0x50/0x100 [ 998.394138] netlink_unicast+0x292/0x3f0 [ 998.394141] netlink_sendmsg+0x21b/0x470 [ 998.394145] ____sys_sendmsg+0x39d/0x3d0 [ 998.394149] ___sys_sendmsg+0x9a/0xe0 [ 998.394156] __sys_sendmsg+0x7a/0xd0 [ 998.394160] do_syscall_64+0x7f/0x170 [ 998.394162] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 998.394165] RIP: 0033:0x7fad61bf4724 [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724 [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003 [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2 ---truncated---", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31509", "url": "https://ubuntu.com/security/CVE-2026-31509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix circular locking dependency in nci_close_device nci_close_device() flushes rx_wq and tx_wq while holding req_lock. This causes a circular locking dependency because nci_rx_work() running on rx_wq can end up taking req_lock too: nci_rx_work -> nci_rx_data_packet -> nci_data_exchange_complete -> __sk_destruct -> rawsock_destruct -> nfc_deactivate_target -> nci_deactivate_target -> nci_request -> mutex_lock(&ndev->req_lock) Move the flush of rx_wq after req_lock has been released. This should safe (I think) because NCI_UP has already been cleared and the transport is closed, so the work will see it and return -ENETDOWN. NIPA has been hitting this running the nci selftest with a debug kernel on roughly 4% of the runs.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31510", "url": "https://ubuntu.com/security/CVE-2026-31510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb Before using sk pointer, check if it is null. Fix the following: KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267] CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025 Workqueue: events l2cap_info_timeout RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce veth0_macvtap: entered promiscuous mode RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: __kasan_check_byte+0x12/0x40 lock_acquire+0x79/0x2e0 lock_sock_nested+0x48/0x100 ? l2cap_sock_ready_cb+0x46/0x160 l2cap_sock_ready_cb+0x46/0x160 l2cap_conn_start+0x779/0xff0 ? __pfx_l2cap_conn_start+0x10/0x10 ? l2cap_info_timeout+0x60/0xa0 ? __pfx___mutex_lock+0x10/0x10 l2cap_info_timeout+0x68/0xa0 ? process_scheduled_works+0xa8d/0x18c0 process_scheduled_works+0xb6e/0x18c0 ? __pfx_process_scheduled_works+0x10/0x10 ? assign_work+0x3d5/0x5e0 worker_thread+0xa53/0xfc0 kthread+0x388/0x470 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x51e/0xb90 ? __pfx_ret_from_fork+0x10/0x10 veth1_macvtap: entered promiscuous mode ? __switch_to+0xc7d/0x1450 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- batman_adv: batadv0: Interface activated: batadv_slave_0 batman_adv: batadv0: Interface activated: batadv_slave_1 netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce ieee80211 phy39: Selected rate control algorithm 'minstrel_ht' RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43069", "url": "https://ubuntu.com/security/CVE-2026-43069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_ll: Fix firmware leak on error path Smatch reports: drivers/bluetooth/hci_ll.c:587 download_firmware() warn: 'fw' from request_firmware() not released on lines: 544. In download_firmware(), if request_firmware() succeeds but the returned firmware content is invalid (no data or zero size), the function returns without releasing the firmware, resulting in a resource leak. Fix this by calling release_firmware() before returning when request_firmware() succeeded but the firmware content is invalid.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31408", "url": "https://ubuntu.com/security/CVE-2026-31408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold sco_recv_frame() reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold a reference under the lock. Fix by using sco_sock_hold() to take a reference before releasing the lock, and adding sock_put() on all exit paths.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-31512", "url": "https://ubuntu.com/security/CVE-2026-31512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv() l2cap_ecred_data_rcv() reads the SDU length field from skb->data using get_unaligned_le16() without first verifying that skb contains at least L2CAP_SDULEN_SIZE (2) bytes. When skb->len is less than 2, this reads past the valid data in the skb. The ERTM reassembly path correctly calls pskb_may_pull() before reading the SDU length (l2cap_reassemble_sdu, L2CAP_SAR_START case). Apply the same validation to the Enhanced Credit Based Flow Control data path.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31515", "url": "https://ubuntu.com/security/CVE-2026-31515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_key: validate families in pfkey_send_migrate() syzbot was able to trigger a crash in skb_put() [1] Issue is that pfkey_send_migrate() does not check old/new families, and that set_ipsecrequest() @family argument was truncated, thus possibly overfilling the skb. Validate families early, do not wait set_ipsecrequest(). [1] skbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev: kernel BUG at net/core/skbuff.c:214 ! Call Trace: skb_over_panic net/core/skbuff.c:219 [inline] skb_put+0x159/0x210 net/core/skbuff.c:2655 skb_put_zero include/linux/skbuff.h:2788 [inline] set_ipsecrequest net/key/af_key.c:3532 [inline] pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636 km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848 xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705 xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31518", "url": "https://ubuntu.com/security/CVE-2026-31518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: esp: fix skb leak with espintcp and async crypto When the TX queue for espintcp is full, esp_output_tail_tcp will return an error and not free the skb, because with synchronous crypto, the common xfrm output code will drop the packet for us. With async crypto (esp_output_done), we need to drop the skb when esp_output_tail_tcp returns an error.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31521", "url": "https://ubuntu.com/security/CVE-2026-31521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: module: Fix kernel panic when a symbol st_shndx is out of bounds The module loader doesn't check for bounds of the ELF section index in simplify_symbols(): for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) { \t\tconst char *name = info->strtab + sym[i].st_name; \t\tswitch (sym[i].st_shndx) { \t\tcase SHN_COMMON: \t\t[...] \t\tdefault: \t\t\t/* Divert to percpu allocation if a percpu var. */ \t\t\tif (sym[i].st_shndx == info->index.pcpu) \t\t\t\tsecbase = (unsigned long)mod_percpu(mod); \t\t\telse /** HERE --> **/\t\tsecbase = info->sechdrs[sym[i].st_shndx].sh_addr; \t\t\tsym[i].st_value += secbase; \t\t\tbreak; \t\t} \t} A symbol with an out-of-bounds st_shndx value, for example 0xffff (known as SHN_XINDEX or SHN_HIRESERVE), may cause a kernel panic: BUG: unable to handle page fault for address: ... RIP: 0010:simplify_symbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exception This can happen when module ELF is legitimately using SHN_XINDEX or when it is corrupted. Add a bounds check in simplify_symbols() to validate that st_shndx is within the valid range before using it. This issue was discovered due to a bug in llvm-objcopy, see relevant discussion for details [1]. [1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31522", "url": "https://ubuntu.com/security/CVE-2026-31522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: avoid memory leak in magicmouse_report_fixup() The magicmouse_report_fixup() function was returning a newly kmemdup()-allocated buffer, but never freeing it. The caller of report_fixup() does not take ownership of the returned pointer, but it *is* permitted to return a sub-portion of the input rdesc, whose lifetime is managed by the caller.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31523", "url": "https://ubuntu.com/security/CVE-2026-31523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-pci: ensure we're polling a polled queue A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31524", "url": "https://ubuntu.com/security/CVE-2026-31524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: asus: avoid memory leak in asus_report_fixup() The asus_report_fixup() function was returning a newly allocated kmemdup()-allocated buffer, but never freeing it. Switch to devm_kzalloc() to ensure the memory is managed and freed automatically when the device is removed. The caller of report_fixup() does not take ownership of the returned pointer, but it is permitted to return a pointer whose lifetime is at least that of the input buffer. Also fix a harmless out-of-bounds read by copying only the original descriptor size.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31788", "url": "https://ubuntu.com/security/CVE-2026-31788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: restrict usage in unprivileged domU The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains. In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature. The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest. Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today. The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot. This is XSA-482 --- V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich)", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31540", "url": "https://ubuntu.com/security/CVE-2026-31540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Check set_default_submission() before deferencing When the i915 driver firmware binaries are not present, the set_default_submission pointer is not set. This pointer is dereferenced during suspend anyways. Add a check to make sure it is set before dereferencing. [ 23.289926] PM: suspend entry (deep) [ 23.293558] Filesystems sync: 0.000 seconds [ 23.298010] Freezing user space processes [ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds) [ 23.309766] OOM killer disabled. [ 23.313027] Freezing remaining freezable tasks [ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 23.342038] serial 00:05: disabled [ 23.345719] serial 00:02: disabled [ 23.349342] serial 00:01: disabled [ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 23.361635] ata1.00: Entering standby power mode [ 23.368863] ata2.00: Entering standby power mode [ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 23.452194] #PF: supervisor instruction fetch in kernel mode [ 23.457896] #PF: error_code(0x0010) - not-present page [ 23.463065] PGD 0 P4D 0 [ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI [ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary) [ 23.482512] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 23.496511] Workqueue: async async_run_entry_fn [ 23.501087] RIP: 0010:0x0 [ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246 [ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f [ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000 [ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff [ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8 [ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68 [ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000 [ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0 [ 23.572539] PKRU: 55555554 [ 23.575281] Call Trace: [ 23.577770] [ 23.579905] intel_engines_reset_default_submission+0x42/0x60 [ 23.585695] __intel_gt_unset_wedged+0x191/0x200 [ 23.590360] intel_gt_unset_wedged+0x20/0x40 [ 23.594675] gt_sanitize+0x15e/0x170 [ 23.598290] i915_gem_suspend_late+0x6b/0x180 [ 23.602692] i915_drm_suspend_late+0x35/0xf0 [ 23.607008] ? __pfx_pci_pm_suspend_late+0x10/0x10 [ 23.611843] dpm_run_callback+0x78/0x1c0 [ 23.615817] device_suspend_late+0xde/0x2e0 [ 23.620037] async_suspend_late+0x18/0x30 [ 23.624082] async_run_entry_fn+0x25/0xa0 [ 23.628129] process_one_work+0x15b/0x380 [ 23.632182] worker_thread+0x2a5/0x3c0 [ 23.635973] ? __pfx_worker_thread+0x10/0x10 [ 23.640279] kthread+0xf6/0x1f0 [ 23.643464] ? __pfx_kthread+0x10/0x10 [ 23.647263] ? __pfx_kthread+0x10/0x10 [ 23.651045] ret_from_fork+0x131/0x190 [ 23.654837] ? __pfx_kthread+0x10/0x10 [ 23.658634] ret_from_fork_asm+0x1a/0x30 [ 23.662597] [ 23.664826] Modules linked in: [ 23.667914] CR2: 0000000000000000 [ 23.671271] ------------[ cut here ]------------ (cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad)", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23434", "url": "https://ubuntu.com/security/CVE-2026-23434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: serialize lock/unlock against other NAND operations nand_lock() and nand_unlock() call into chip->ops.lock_area/unlock_area without holding the NAND device lock. On controllers that implement SET_FEATURES via multiple low-level PIO commands, these can race with concurrent UBI/UBIFS background erase/write operations that hold the device lock, resulting in cmd_pending conflicts on the NAND controller. Add nand_get_device()/nand_release_device() around the lock/unlock operations to serialize them against all other NAND controller access.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23398", "url": "https://ubuntu.com/security/CVE-2026-23398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: fix NULL pointer dereference in icmp_tag_validation() icmp_tag_validation() unconditionally dereferences the result of rcu_dereference(inet_protos[proto]) without checking for NULL. The inet_protos[] array is sparse -- only about 15 of 256 protocol numbers have registered handlers. When ip_no_pmtu_disc is set to 3 (hardened PMTU mode) and the kernel receives an ICMP Fragmentation Needed error with a quoted inner IP header containing an unregistered protocol number, the NULL dereference causes a kernel panic in softirq context. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) Add a NULL check before accessing icmp_strict_tag_validation. If the protocol has no registered handler, return false since it cannot perform strict tag validation.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-23438", "url": "https://ubuntu.com/security/CVE-2026-23438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: guard flow control update with global_tx_fc in buffer switching mvpp2_bm_switch_buffers() unconditionally calls mvpp2_bm_pool_update_priv_fc() when switching between per-cpu and shared buffer pool modes. This function programs CM3 flow control registers via mvpp2_cm3_read()/mvpp2_cm3_write(), which dereference priv->cm3_base without any NULL check. When the CM3 SRAM resource is not present in the device tree (the third reg entry added by commit 60523583b07c (\"dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree\")), priv->cm3_base remains NULL and priv->global_tx_fc is false. Any operation that triggers mvpp2_bm_switch_buffers(), for example an MTU change that crosses the jumbo frame threshold, will crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2_cm3_read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2_bm_pool_update_fc+0x40/0x12c mvpp2_bm_pool_update_priv_fc+0x94/0xd8 mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0 mvpp2_change_mtu+0x140/0x380 __dev_set_mtu+0x1c/0x38 dev_set_mtu_ext+0x78/0x118 dev_set_mtu+0x48/0xa8 dev_ifsioc+0x21c/0x43c dev_ioctl+0x2d8/0x42c sock_ioctl+0x314/0x378 Every other flow control call site in the driver already guards hardware access with either priv->global_tx_fc or port->tx_fc. mvpp2_bm_switch_buffers() is the only place that omits this check. Add the missing priv->global_tx_fc guard to both the disable and re-enable calls in mvpp2_bm_switch_buffers(), consistent with the rest of the driver.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23397", "url": "https://ubuntu.com/security/CVE-2026-23397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfnetlink_osf: validate individual option lengths in fingerprints nfnl_osf_add_callback() validates opt_num bounds and string NUL-termination but does not check individual option length fields. A zero-length option causes nf_osf_match_one() to enter the option matching loop even when foptsize sums to zero, which matches packets with no TCP options where ctx->optp is NULL: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:227) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:293) nf_hook_slow (net/netfilter/core.c:623) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) Additionally, an MSS option (kind=2) with length < 4 causes out-of-bounds reads when nf_osf_match_one() unconditionally accesses optp[2] and optp[3] for MSS value extraction. While RFC 9293 section 3.2 specifies that the MSS option is always exactly 4 bytes (Kind=2, Length=4), the check uses \"< 4\" rather than \"!= 4\" because lengths greater than 4 do not cause memory safety issues -- the buffer is guaranteed to be at least foptsize bytes by the ctx->optsize == foptsize check. Reject fingerprints where any option has zero length, or where an MSS option has length less than 4, at add time rather than trusting these values in the packet matching hot path.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-31546", "url": "https://ubuntu.com/security/CVE-2026-31546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL deref in bond_debug_rlb_hash_show rlb_clear_slave intentionally keeps RLB hash-table entries on the rx_hashtbl_used_head list with slave set to NULL when no replacement slave is available. However, bond_debug_rlb_hash_show visites client_info->slave without checking if it's NULL. Other used-list iterators in bond_alb.c already handle this NULL-slave state safely: - rlb_update_client returns early on !client_info->slave - rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalance compare slave values before visiting - lb_req_update_subnet_clients continues if slave is NULL The following NULL deref crash can be trigger in bond_debug_rlb_hash_show: [ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seq_read_iter (fs/seq_file.c:231) [ 1.296341] seq_read (fs/seq_file.c:164) [ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfs_read (fs/read_write.c:572) [ 1.296981] ksys_read (fs/read_write.c:717) [ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) [ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add a NULL check and print \"(none)\" for entries with no assigned slave.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23439", "url": "https://ubuntu.com/security/CVE-2026-23439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n When CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0 (success) without actually creating a socket. Callers such as fou_create() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference. The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764) [...] Call Trace: genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130) This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23396", "url": "https://ubuntu.com/security/CVE-2026-23396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix NULL deref in mesh_matches_local() mesh_matches_local() unconditionally dereferences ie->mesh_config to compare mesh configuration parameters. When called from mesh_rx_csa_frame(), the parsed action-frame elements may not contain a Mesh Configuration IE, leaving ie->mesh_config NULL and triggering a kernel NULL pointer dereference. The other two callers are already safe: - ieee80211_mesh_rx_bcn_presp() checks !elems->mesh_config before calling mesh_matches_local() - mesh_plink_get_event() is only reached through mesh_process_plink_frame(), which checks !elems->mesh_config, too mesh_rx_csa_frame() is the only caller that passes raw parsed elements to mesh_matches_local() without guarding mesh_config. An adjacent attacker can exploit this by sending a crafted CSA action frame that includes a valid Mesh ID IE but omits the Mesh Configuration IE, crashing the kernel. The captured crash log: Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events_unbound cfg80211_wiphy_work [...] Call Trace: ? __pfx_mesh_matches_local (net/mac80211/mesh.c:65) ieee80211_mesh_rx_queued_mgmt (net/mac80211/mesh.c:1686) [...] ieee80211_iface_work (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802) [...] cfg80211_wiphy_work (net/wireless/core.c:426) process_one_work (net/kernel/workqueue.c:3280) ? assign_work (net/kernel/workqueue.c:1219) worker_thread (net/kernel/workqueue.c:3352) ? __pfx_worker_thread (net/kernel/workqueue.c:3385) kthread (net/kernel/kthread.c:436) [...] ret_from_fork_asm (net/arch/x86/entry/entry_64.S:255) This patch adds a NULL check for ie->mesh_config at the top of mesh_matches_local() to return false early when the Mesh Configuration IE is absent.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-23446", "url": "https://ubuntu.com/security/CVE-2026-23446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: Do not perform PM inside suspend callback syzbot reports \"task hung in rpm_resume\" This is caused by aqc111_suspend calling the PM variant of its write_cmd routine. The simplified call trace looks like this: rpm_suspend() usb_suspend_both() - here udev->dev.power.runtime_status == RPM_SUSPENDING aqc111_suspend() - called for the usb device interface aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() - here we call rpm_resume() on our parent rpm_resume() - Here we wait for a status change that will never happen. At this point we block another task which holds rtnl_lock and locks up the whole networking stack. Fix this by replacing the write_cmd calls with their _nopm variants", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23452", "url": "https://ubuntu.com/security/CVE-2026-23452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM: runtime: Fix a race condition related to device removal The following code in pm_runtime_work() may dereference the dev->parent pointer after the parent device has been freed: \t/* Maybe the parent is now able to suspend. */ \tif (parent && !parent->power.ignore_children) { \t\tspin_unlock(&dev->power.lock); \t\tspin_lock(&parent->power.lock); \t\trpm_idle(parent, RPM_ASYNC); \t\tspin_unlock(&parent->power.lock); \t\tspin_lock(&dev->power.lock); \t} Fix this by inserting a flush_work() call in pm_runtime_remove(). Without this patch blktest block/001 triggers the following complaint sporadically: BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160 Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081 Workqueue: pm pm_runtime_work Call Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0 __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160 _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 Allocated by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50 __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23454", "url": "https://ubuntu.com/security/CVE-2026-23454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: fix use-after-free in mana_hwc_destroy_channel() by reordering teardown A potential race condition exists in mana_hwc_destroy_channel() where hwc->caller_ctx is freed before the HWC's Completion Queue (CQ) and Event Queue (EQ) are destroyed. This allows an in-flight CQ interrupt handler to dereference freed memory, leading to a use-after-free or NULL pointer dereference in mana_hwc_handle_resp(). mana_smc_teardown_hwc() signals the hardware to stop but does not synchronize against IRQ handlers already executing on other CPUs. The IRQ synchronization only happens in mana_hwc_destroy_cq() via mana_gd_destroy_eq() -> mana_gd_deregister_irq(). Since this runs after kfree(hwc->caller_ctx), a concurrent mana_hwc_rx_event_handler() can dereference freed caller_ctx (and rxq->msg_buf) in mana_hwc_handle_resp(). Fix this by reordering teardown to reverse-of-creation order: destroy the TX/RX work queues and CQ/EQ before freeing hwc->caller_ctx. This ensures all in-flight interrupt handlers complete before the memory they access is freed.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23391", "url": "https://ubuntu.com/security/CVE-2026-23391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_CT: drop pending enqueued packets on template removal Templates refer to objects that can go away while packets are sitting in nfqueue refer to: - helper, this can be an issue on module removal. - timeout policy, nfnetlink_cttimeout might remove it. The use of templates with zone and event cache filter are safe, since this just copies values. Flush these enqueued packets in case the template rule gets removed.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43060", "url": "https://ubuntu.com/security/CVE-2026-43060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: drop pending enqueued packets on removal Packets sitting in nfqueue might hold a reference to: - templates that specify the conntrack zone, because a percpu area is used and module removal is possible. - conntrack timeout policies and helper, where object removal leave a stale reference. Since these objects can just go away, drop enqueued packets to avoid stale reference to them. If there is a need for finer grain removal, this logic can be revisited to make selective packet drop upon dependencies.", "cve_priority": "high", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2025-68206", "url": "https://ubuntu.com/security/CVE-2025-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: add seqadj extension for natted connections Sequence adjustment may be required for FTP traffic with PASV/EPSV modes. due to need to re-write packet payload (IP, port) on the ftp control connection. This can require changes to the TCP length and expected seq / ack_seq. The easiest way to reproduce this issue is with PASV mode. Example ruleset: table inet ftp_nat { ct helper ftp_helper { type \"ftp\" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set \"ftp_helper\" } } table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { \t\t\t192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { \t\t\t192.168.13.2 : 192.168.100.1/32 } } } Note that the ftp helper gets assigned *after* the dnat setup. The inverse (nat after helper assign) is handled by an existing check in nf_nat_setup_info() and will not show the problem. Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ ftp nat changes do not work as expected in this case: Connected to 192.168.100.1. [..] ftp> epsv EPSV/EPRT on IPv4 off. ftp> ls 227 Entering passive mode (192,168,100,1,209,129). 421 Service not available, remote server has closed connection. Kernel logs: Missing nfct_seqadj_ext_add() setup call WARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41 [..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 .. Fix this by adding the required extension when a conntrack helper is assigned to a connection that has a nat binding.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-23456", "url": "https://ubuntu.com/security/CVE-2026-23456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case In decode_int(), the CONS case calls get_bits(bs, 2) to read a length value, then calls get_uint(bs, len) without checking that len bytes remain in the buffer. The existing boundary check only validates the 2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint() reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte slab-out-of-bounds read. Add a boundary check for len bytes after get_bits() and before get_uint().", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23457", "url": "https://ubuntu.com/security/CVE-2026-23457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp() sip_help_tcp() parses the SIP Content-Length header with simple_strtoul(), which returns unsigned long, but stores the result in unsigned int clen. On 64-bit systems, values exceeding UINT_MAX are silently truncated before computing the SIP message boundary. For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32, causing the parser to miscalculate where the current message ends. The loop then treats trailing data in the TCP segment as a second SIP message and processes it through the SDP parser. Fix this by changing clen to unsigned long to match the return type of simple_strtoul(), and reject Content-Length values that exceed the remaining TCP payload length.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23458", "url": "https://ubuntu.com/security/CVE-2026-23458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct() ctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for the netlink dump callback ctnetlink_exp_ct_dump_table(), but drops the conntrack reference immediately after netlink_dump_start(). When the dump spans multiple rounds, the second recvmsg() triggers the dump callback which dereferences the now-freed conntrack via nfct_help(ct), leading to a use-after-free on ct->ext. The bug is that the netlink_dump_control has no .start or .done callbacks to manage the conntrack reference across dump rounds. Other dump functions in the same file (e.g. ctnetlink_get_conntrack) properly use .start/.done callbacks for this purpose. Fix this by adding .start and .done callbacks that hold and release the conntrack reference for the duration of the dump, and move the nfct_help() call after the cb->args[0] early-return check in the dump callback to avoid dereferencing ct->ext unnecessarily. BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133 CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 ? aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0 Allocated by task 133: kmem_cache_alloc_noprof+0x134/0x440 __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180 Freed by task 0: slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2025-39764", "url": "https://ubuntu.com/security/CVE-2025-39764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: remove refcounting in expectation dumpers Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption. AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcount_inc_not_zero(&exp->use)) to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2026-23460", "url": "https://ubuntu.com/security/CVE-2026-23460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect syzkaller reported a bug [1], and the reproducer is available at [2]. ROSE sockets use four sk->sk_state values: TCP_CLOSE, TCP_LISTEN, TCP_SYN_SENT, and TCP_ESTABLISHED. rose_connect() already rejects calls for TCP_ESTABLISHED (-EISCONN) and TCP_CLOSE with SS_CONNECTING (-ECONNREFUSED), but lacks a check for TCP_SYN_SENT. When rose_connect() is called a second time while the first connection attempt is still in progress (TCP_SYN_SENT), it overwrites rose->neighbour via rose_get_neigh(). If that returns NULL, the socket is left with rose->state == ROSE_STATE_1 but rose->neighbour == NULL. When the socket is subsequently closed, rose_release() sees ROSE_STATE_1 and calls rose_write_internal() -> rose_transmit_link(skb, NULL), causing a NULL pointer dereference. Per connect(2), a second connect() while a connection is already in progress should return -EALREADY. Add this missing check for TCP_SYN_SENT to complete the state validation in rose_connect(). [1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271 [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23462", "url": "https://ubuntu.com/security/CVE-2026-23462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: Fix possible UAF This fixes the following trace caused by not dropping l2cap_conn reference when user->remove callback is called: [ 97.809249] l2cap_conn_free: freeing conn ffff88810a171c00 [ 97.809907] CPU: 1 UID: 0 PID: 1419 Comm: repro_standalon Not tainted 7.0.0-rc1-dirty #14 PREEMPT(lazy) [ 97.809935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 97.809947] Call Trace: [ 97.809954] [ 97.809961] dump_stack_lvl (lib/dump_stack.c:122) [ 97.809990] l2cap_conn_free (net/bluetooth/l2cap_core.c:1808) [ 97.810017] l2cap_conn_del (./include/linux/kref.h:66 net/bluetooth/l2cap_core.c:1821 net/bluetooth/l2cap_core.c:1798) [ 97.810055] l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7347 (discriminator 1) net/bluetooth/l2cap_core.c:7340 (discriminator 1)) [ 97.810086] ? __pfx_l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7341) [ 97.810117] hci_conn_hash_flush (./include/net/bluetooth/hci_core.h:2152 (discriminator 2) net/bluetooth/hci_conn.c:2644 (discriminator 2)) [ 97.810148] hci_dev_close_sync (net/bluetooth/hci_sync.c:5360) [ 97.810180] ? __pfx_hci_dev_close_sync (net/bluetooth/hci_sync.c:5285) [ 97.810212] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810242] ? up_write (./arch/x86/include/asm/atomic64_64.h:87 (discriminator 5) ./include/linux/atomic/atomic-arch-fallback.h:2852 (discriminator 5) ./include/linux/atomic/atomic-long.h:268 (discriminator 5) ./include/linux/atomic/atomic-instrumented.h:3391 (discriminator 5) kernel/locking/rwsem.c:1385 (discriminator 5) kernel/locking/rwsem.c:1643 (discriminator 5)) [ 97.810267] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810290] ? rcu_is_watching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/context_tracking.h:128 kernel/rcu/tree.c:752) [ 97.810320] hci_unregister_dev (net/bluetooth/hci_core.c:504 net/bluetooth/hci_core.c:2716) [ 97.810346] vhci_release (drivers/bluetooth/hci_vhci.c:691) [ 97.810375] ? __pfx_vhci_release (drivers/bluetooth/hci_vhci.c:678) [ 97.810404] __fput (fs/file_table.c:470) [ 97.810430] task_work_run (kernel/task_work.c:235) [ 97.810451] ? __pfx_task_work_run (kernel/task_work.c:201) [ 97.810472] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810495] ? do_raw_spin_unlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlock_debug.c:142 (discriminator 5)) [ 97.810527] do_exit (kernel/exit.c:972) [ 97.810547] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810574] ? __pfx_do_exit (kernel/exit.c:897) [ 97.810594] ? lock_acquire (kernel/locking/lockdep.c:470 (discriminator 6) kernel/locking/lockdep.c:5870 (discriminator 6) kernel/locking/lockdep.c:5825 (discriminator 6)) [ 97.810616] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810639] ? do_raw_spin_lock (kernel/locking/spinlock_debug.c:95 (discriminator 4) kernel/locking/spinlock_debug.c:118 (discriminator 4)) [ 97.810664] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810688] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1)) [ 97.810721] do_group_exit (kernel/exit.c:1093) [ 97.810745] get_signal (kernel/signal.c:3007 (discriminator 1)) [ 97.810772] ? security_file_permission (./arch/x86/include/asm/jump_label.h:37 security/security.c:2366) [ 97.810803] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810826] ? vfs_read (fs/read_write.c:555) [ 97.810854] ? __pfx_get_signal (kernel/signal.c:2800) [ 97.810880] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810905] ? __pfx_vfs_read (fs/read_write.c:555) [ 97.810932] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810960] arch_do_signal_or_restart (arch/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31551", "url": "https://ubuntu.com/security/CVE-2026-31551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Fix static_branch_dec() underflow for aql_disable. syzbot reported static_branch_dec() underflow in aql_enable_write(). [0] The problem is that aql_enable_write() does not serialise concurrent write()s to the debugfs. aql_enable_write() checks static_key_false(&aql_disable.key) and later calls static_branch_inc() or static_branch_dec(), but the state may change between the two calls. aql_disable does not need to track inc/dec. Let's use static_branch_enable() and static_branch_disable(). [0]: val == 0 WARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288 Modules linked in: CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full) Tainted: [U]=USER, [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311 Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 <0f> 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00 RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4 RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a R13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98 FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0 Call Trace: __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline] __static_key_slow_dec kernel/jump_label.c:321 [inline] static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336 aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343 short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383 vfs_write+0x2aa/0x1070 fs/read_write.c:684 ksys_pwrite64 fs/read_write.c:793 [inline] __do_sys_pwrite64 fs/read_write.c:801 [inline] __se_sys_pwrite64 fs/read_write.c:798 [inline] __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f530cf9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012 RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010 RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000 R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978 ", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23463", "url": "https://ubuntu.com/security/CVE-2026-23463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: fix race condition in qman_destroy_fq When QMAN_FQ_FLAG_DYNAMIC_FQID is set, there's a race condition between fq_table[fq->idx] state and freeing/allocating from the pool and WARN_ON(fq_table[fq->idx]) in qman_create_fq() gets triggered. Indeed, we can have: Thread A Thread B qman_destroy_fq() qman_create_fq() qman_release_fqid() qman_shutdown_fq() gen_pool_free() -- At this point, the fqid is available again -- qman_alloc_fqid() -- so, we can get the just-freed fqid in thread B -- fq->fqid = fqid; fq->idx = fqid * 2; WARN_ON(fq_table[fq->idx]); fq_table[fq->idx] = fq; fq_table[fq->idx] = NULL; And adding some logs between qman_release_fqid() and fq_table[fq->idx] = NULL makes the WARN_ON() trigger a lot more. To prevent that, ensure that fq_table[fq->idx] is set to NULL before gen_pool_free() is called by using smp_wmb().", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31683", "url": "https://ubuntu.com/security/CVE-2026-31683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: avoid OGM aggregation when skb tailroom is insufficient When OGM aggregation state is toggled at runtime, an existing forwarded packet may have been allocated with only packet_len bytes, while a later packet can still be selected for aggregation. Appending in this case can hit skb_put overflow conditions. Reject aggregation when the target skb tailroom cannot accommodate the new packet. The caller then falls back to creating a new forward packet instead of appending.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31550", "url": "https://ubuntu.com/security/CVE-2026-31550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: bcm: bcm2835-power: Increase ASB control timeout The bcm2835_asb_control() function uses a tight polling loop to wait for the ASB bridge to acknowledge a request. During intensive workloads, this handshake intermittently fails for V3D's master ASB on BCM2711, resulting in \"Failed to disable ASB master for v3d\" errors during runtime PM suspend. As a consequence, the failed power-off leaves V3D in a broken state, leading to bus faults or system hangs on later accesses. As the timeout is insufficient in some scenarios, increase the polling timeout from 1us to 5us, which is still negligible in the context of a power domain transition. Also, replace the open-coded ktime_get_ns()/ cpu_relax() polling loop with readl_poll_timeout_atomic().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23368", "url": "https://ubuntu.com/security/CVE-2026-23368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: register phy led_triggers during probe to avoid AB-BA deadlock There is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and LED_TRIGGER_PHY are enabled: [ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc <-- Trying to get lock \"triggers_list_lock\" via down_write(&triggers_list_lock); [ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234 [ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c [ 1362.065489] [<80651fc4>] phylink_fwnode_phy_connect+0x15c/0x23c [ 1362.071480] [<8066ee18>] mtk_open+0x7c/0xba0 [ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0 [ 1362.080384] [<806d7668>] __dev_change_flags+0x244/0x24c [ 1362.085598] [<806d7698>] dev_change_flags+0x28/0x78 [ 1362.090528] [<807150e4>] dev_ioctl+0x4c0/0x654 <-- Hold lock \"rtnl_mutex\" by calling rtnl_lock(); [ 1362.094985] [<80694360>] sock_ioctl+0x2f4/0x4e0 [ 1362.099567] [<802e9c4c>] sys_ioctl+0x32c/0xd8c [ 1362.104022] [<80014504>] syscall_common+0x34/0x58 Here LED_TRIGGER_PHY is registering LED triggers during phy_attach while holding RTNL and then taking triggers_list_lock. [ 1362.191101] [<806c2640>] register_netdevice_notifier+0x60/0x168 <-- Trying to get lock \"rtnl_mutex\" via rtnl_lock(); [ 1362.197073] [<805504ac>] netdev_trig_activate+0x194/0x1e4 [ 1362.202490] [<8054e28c>] led_trigger_set+0x1d4/0x360 <-- Hold lock \"triggers_list_lock\" by down_read(&triggers_list_lock); [ 1362.207511] [<8054eb38>] led_trigger_write+0xd8/0x14c [ 1362.212566] [<80381d98>] sysfs_kf_bin_write+0x80/0xbc [ 1362.217688] [<8037fcd8>] kernfs_fop_write_iter+0x17c/0x28c [ 1362.223174] [<802cbd70>] vfs_write+0x21c/0x3c4 [ 1362.227712] [<802cc0c4>] ksys_write+0x78/0x12c [ 1362.232164] [<80014504>] syscall_common+0x34/0x58 Here LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takes triggers_list_lock and then RTNL. A classical AB-BA deadlock. phy_led_triggers_registers() does not require the RTNL, it does not make any calls into the network stack which require protection. There is also no requirement the PHY has been attached to a MAC, the triggers only make use of phydev state. This allows the call to phy_led_triggers_registers() to be placed elsewhere. PHY probe() and release() don't hold RTNL, so solving the AB-BA deadlock.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23303", "url": "https://ubuntu.com/security/CVE-2026-23303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Don't log plaintext credentials in cifs_set_cifscreds When debug logging is enabled, cifs_set_cifscreds() logs the key payload and exposes the plaintext username and password. Remove the debug log to avoid exposing credentials.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23335", "url": "https://ubuntu.com/security/CVE-2026-23335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah() struct irdma_create_ah_resp { // 8 bytes, no padding __u32 ah_id; // offset 0 - SET (uresp.ah_id = ah->sc_ah.ah_info.ah_idx) __u8 rsvd[4]; // offset 4 - NEVER SET <- LEAK }; rsvd[4]: 4 bytes of stack memory leaked unconditionally. Only ah_id is assigned before ib_respond_udata(). The reserved members of the structure were not zeroed.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23336", "url": "https://ubuntu.com/security/CVE-2026-23336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel rfkill_block work in wiphy_unregister() There is a use-after-free error in cfg80211_shutdown_all_interfaces found by syzkaller: BUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220 Read of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326 CPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events cfg80211_rfkill_block_work Call Trace: dump_stack_lvl+0x116/0x1f0 print_report+0xcd/0x630 kasan_report+0xe0/0x110 cfg80211_shutdown_all_interfaces+0x213/0x220 cfg80211_rfkill_block_work+0x1e/0x30 process_one_work+0x9cf/0x1b70 worker_thread+0x6c8/0xf10 kthread+0x3c5/0x780 ret_from_fork+0x56d/0x700 ret_from_fork_asm+0x1a/0x30 The problem arises due to the rfkill_block work is not cancelled when wiphy is being unregistered. In order to fix the issue cancel the corresponding work in wiphy_unregister(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23281", "url": "https://ubuntu.com/security/CVE-2026-23281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix use-after-free in lbs_free_adapter() The lbs_free_adapter() function uses timer_delete() (non-synchronous) for both command_timer and tx_lockup_timer before the structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If a timer callback is executing when lbs_free_adapter() is called, the callback will access freed memory since lbs_cfg_free() frees the containing structure immediately after lbs_free_adapter() returns. Both timer callbacks (lbs_cmd_timeout_handler and lbs_tx_lockup_handler) access priv->driver_lock, priv->cur_cmd, priv->dev, and other fields, which would all be use-after-free violations. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning. This bug was introduced in commit 8f641d93c38a (\"libertas: detect TX lockups and reset hardware\") where del_timer() was used instead of del_timer_sync() in the cleanup path. The command_timer has had the same issue since the driver was first written.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-38562", "url": "https://ubuntu.com/security/CVE-2025-38562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference error in generate_encryptionkey If client send two session setups with krb5 authenticate to ksmbd, null pointer dereference error in generate_encryptionkey could happen. sess->Preauth_HashValue is set to NULL if session is valid. So this patch skip generate encryption key if session is valid.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2026-45920", "url": "https://ubuntu.com/security/CVE-2026-45920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix dirtyclusters double decrement on fs shutdown fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count: WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4] Tracing the failure shows that the warning fires due to an s_dirtyclusters_counter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4_mb_mark_diskspace_used() and the caller ext4_mb_new_blocks(). First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4_handle_dirty_metadata() call(s) made from ext4_mb_mark_context(). The changed value is non-zero at this point, so ext4_mb_mark_diskspace_used() does not exit after the error bubbles up from ext4_mb_mark_context(). Instead, the former decrements both cluster counters and returns the error up to ext4_mb_new_blocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency. To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4_mb_new_blocks() is responsible for acquiring cluster reservation (via ext4_claim_free_clusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45899", "url": "https://ubuntu.com/security/CVE-2026-45899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop extent cache when splitting extent fails When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45985", "url": "https://ubuntu.com/security/CVE-2026-45985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues. Assume we have an unwritten extent, and then DIO writes the second half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set. Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree. [0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone. Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45924", "url": "https://ubuntu.com/security/CVE-2026-45924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths There are two places where ksmbd_vfs_kern_path_end_removing() needs to be called in order to balance what the corresponding successful call to ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and put the taken references. Otherwise there might be potential deadlocks and unbalanced locks which are caught like: BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work 2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660 CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30 Found by Linux Verification Center (linuxtesting.org).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23227", "url": "https://ubuntu.com/security/CVE-2026-23227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/free Exynos Virtual Display driver performs memory alloc/free operations without lock protection, which easily causes concurrency problem. For example, use-after-free can occur in race scenario like this: ``` \tCPU0\t\t\t\tCPU1\t\t\t\tCPU2 \t----\t\t\t\t----\t\t\t\t---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... \t\t\t\t\t\t\t\tdrm_mode_getconnector() \t\t\t\t\t\t\t\t drm_helper_probe_single_connector_modes() \t\t\t\t\t\t\t\t vidi_get_modes() \t\t\t\t\t\t\t\t if (ctx->raw_edid) // true \t\t\t\t\t\t\t\t drm_edid_dup(ctx->raw_edid); \t\t\t\t\t\t\t\t if (!drm_edid) // false \t\t\t\t\t\t\t\t ... \t\t\t\tvidi_connection_ioctl() \t\t\t\t if (vidi->connection) // false \t\t\t\t drm_edid_free(ctx->raw_edid); // free drm_edid \t\t\t\t ... \t\t\t\t\t\t\t\t drm_edid_alloc(drm_edid->edid) \t\t\t\t\t\t\t\t kmemdup(edid); // UAF!! \t\t\t\t\t\t\t\t ... ``` To prevent these vulns, at least in vidi_context, member variables related to memory alloc/free should be protected with ctx->lock.", "cve_priority": "high", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-45958", "url": "https://ubuntu.com/security/CVE-2026-45958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: fix to avoid directly dereferencing user pointer In vidi_connection_ioctl(), vidi->edid(user pointer) is directly dereferenced in the kernel. This allows arbitrary kernel memory access from the user space, so instead of directly accessing the user pointer in the kernel, we should modify it to copy edid to kernel memory using copy_from_user() and use it.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45956", "url": "https://ubuntu.com/security/CVE-2026-45956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl() vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to obtain a struct vidi_context pointer. However, drm_dev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device. This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more. To resolve this issue, we need to store/delete the vidi device pointer in exynos_drm_private->vidi_dev during bind/unbind, and then read this exynos_drm_private->vidi_dev within ioctl() to obtain the correct struct vidi_context pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23100", "url": "https://ubuntu.com/security/CVE-2026-23100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb_pmd_shared() Patch series \"mm/hugetlb: fixes for PMD table sharing (incl. using mmu_gather)\", v3. One functional fix, one performance regression fix, and two related comment fixes. I cleaned up my prototype I recently shared [1] for the performance fix, deferring most of the cleanups I had in the prototype to a later point. While doing that I identified the other things. The goal of this patch set is to be backported to stable trees \"fairly\" easily. At least patch #1 and #4. Patch #1 fixes hugetlb_pmd_shared() not detecting any sharing Patch #2 + #3 are simple comment fixes that patch #4 interacts with. Patch #4 is a fix for the reported performance regression due to excessive IPI broadcasts during fork()+exit(). The last patch is all about TLB flushes, IPIs and mmu_gather. Read: complicated There are plenty of cleanups in the future to be had + one reasonable optimization on x86. But that's all out of scope for this series. Runtime tested, with a focus on fixing the performance regression using the original reproducer [2] on x86. This patch (of 4): We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->pt_share_count to identify sharing. We didn't convert hugetlb_pmd_shared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table. Page migration, like mbind() or migrate_pages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as \"private\" although they are \"shared\", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the pagemap interface. Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-43061", "url": "https://ubuntu.com/security/CVE-2026-43061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Fix TX deadlock when using DMA `dmaengine_terminate_async` does not guarantee that the `__dma_tx_complete` callback will run. The callback is currently the only place where `dma->tx_running` gets cleared. If the transaction is canceled and the callback never runs, then `dma->tx_running` will never get cleared and we will never schedule new TX DMA transactions again. This change makes it so we clear `dma->tx_running` after we terminate the DMA transaction. This is \"safe\" because `serial8250_tx_dma_flush` is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to `dma->tx_running` is serialized.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-23474", "url": "https://ubuntu.com/security/CVE-2026-23474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: Avoid boot crash in RedBoot partition table parser Given CONFIG_FORTIFY_SOURCE=y and a recent compiler, commit 439a1bcac648 (\"fortify: Use __builtin_dynamic_object_size() when available\") produces the warning below and an oops. Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000 ------------[ cut here ]------------ WARNING: lib/string_helpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1 memcmp: detected buffer overflow: 15 byte read of buffer size 14 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONE As Kees said, \"'names' is pointing to the final 'namelen' many bytes of the allocation ... 'namelen' could be basically any length at all. This fortify warning looks legit to me -- this code used to be reading beyond the end of the allocation.\" Since the size of the dynamic allocation is calculated with strlen() we can use strcmp() instead of memcmp() and remain within bounds.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31393", "url": "https://ubuntu.com/security/CVE-2026-31393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present: - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8). - L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5). A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data. Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43062", "url": "https://ubuntu.com/security/CVE-2026-43062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp() l2cap_ecred_reconf_rsp() casts the incoming data to struct l2cap_ecred_conn_rsp (the ECRED *connection* response, 8 bytes with result at offset 6) instead of struct l2cap_ecred_reconf_rsp (2 bytes with result at offset 0). This causes two problems: - The sizeof(*rsp) length check requires 8 bytes instead of the correct 2, so valid L2CAP_ECRED_RECONF_RSP packets are rejected with -EPROTO. - rsp->result reads from offset 6 instead of offset 0, returning wrong data when the packet is large enough to pass the check. Fix by using the correct type. Also pass the already byte-swapped result variable to BT_DBG instead of the raw __le16 field.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31396", "url": "https://ubuntu.com/security/CVE-2026-31396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix use-after-free access to PTP clock PTP clock is registered on every opening of the interface and destroyed on every closing. However it may be accessed via get_ts_info ethtool call which is possible while the interface is just present in the kernel. BUG: KASAN: use-after-free in ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 Read of size 4 at addr ffff8880194345cc by task syz.0.6/948 CPU: 1 PID: 948 Comm: syz.0.6 Not tainted 6.1.164+ #109 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x17f/0x496 mm/kasan/report.c:420 kasan_report+0xd9/0x180 mm/kasan/report.c:524 ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 gem_get_ts_info+0x138/0x1e0 drivers/net/ethernet/cadence/macb_main.c:3349 macb_get_ts_info+0x68/0xb0 drivers/net/ethernet/cadence/macb_main.c:3371 __ethtool_get_ts_info+0x17c/0x260 net/ethtool/common.c:558 ethtool_get_ts_info net/ethtool/ioctl.c:2367 [inline] __dev_ethtool net/ethtool/ioctl.c:3017 [inline] dev_ethtool+0x2b05/0x6290 net/ethtool/ioctl.c:3095 dev_ioctl+0x637/0x1070 net/core/dev_ioctl.c:510 sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215 sock_ioctl+0x577/0x6d0 net/socket.c:1320 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 457: kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:699 [inline] ptp_clock_register+0x144/0x10e0 drivers/ptp/ptp_clock.c:235 gem_ptp_init+0x46f/0x930 drivers/net/ethernet/cadence/macb_ptp.c:375 macb_open+0x901/0xd10 drivers/net/ethernet/cadence/macb_main.c:2920 __dev_open+0x2ce/0x500 net/core/dev.c:1501 __dev_change_flags+0x56a/0x740 net/core/dev.c:8651 dev_change_flags+0x92/0x170 net/core/dev.c:8722 do_setlink+0xaf8/0x3a80 net/core/rtnetlink.c:2833 __rtnl_newlink+0xbf4/0x1940 net/core/rtnetlink.c:3608 rtnl_newlink+0x63/0xa0 net/core/rtnetlink.c:3655 rtnetlink_rcv_msg+0x3c6/0xed0 net/core/rtnetlink.c:6150 netlink_rcv_skb+0x15d/0x430 net/netlink/af_netlink.c:2511 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x6d7/0xa30 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x97e/0xeb0 net/netlink/af_netlink.c:1872 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x14b/0x180 net/socket.c:730 __sys_sendto+0x320/0x3b0 net/socket.c:2152 __do_sys_sendto net/socket.c:2164 [inline] __se_sys_sendto net/socket.c:2160 [inline] __x64_sys_sendto+0xdc/0x1b0 net/socket.c:2160 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 938: kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1729 [inline] slab_free_freelist_hook mm/slub.c:1755 [inline] slab_free mm/slub.c:3687 [inline] __kmem_cache_free+0xbc/0x320 mm/slub.c:3700 device_release+0xa0/0x240 drivers/base/core.c:2507 kobject_cleanup lib/kobject.c:681 [inline] kobject_release lib/kobject.c:712 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1cd/0x350 lib/kobject.c:729 put_device+0x1b/0x30 drivers/base/core.c:3805 ptp_clock_unregister+0x171/0x270 drivers/ptp/ptp_clock.c:391 gem_ptp_remove+0x4e/0x1f0 drivers/net/ethernet/cadence/macb_ptp.c:404 macb_close+0x1c8/0x270 drivers/net/ethernet/cadence/macb_main.c:2966 __dev_close_many+0x1b9/0x310 net/core/dev.c:1585 __dev_close net/core/dev.c:1597 [inline] __dev_change_flags+0x2bb/0x740 net/core/dev.c:8649 dev_change_fl ---truncated---", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31545", "url": "https://ubuntu.com/security/CVE-2026-31545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: nxp-nci: allow GPIOs to sleep Allow the firmware and enable GPIOs to sleep. This fixes a `WARN_ON' and allows the driver to operate GPIOs which are connected to I2C GPIO expanders. -- >8 -- kernel: WARNING: CPU: 3 PID: 2636 at drivers/gpio/gpiolib.c:3880 gpiod_set_value+0x88/0x98 -- >8 --", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31399", "url": "https://ubuntu.com/security/CVE-2026-31399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/bus: Fix potential use after free in asynchronous initialization Dingisoul with KASAN reports a use after free if device_add() fails in nd_async_device_register(). Commit b6eae0f61db2 (\"libnvdimm: Hold reference on parent while scheduling async init\") correctly added a reference on the parent device to be held until asynchronous initialization was complete. However, if device_add() results in an allocation failure the ref count of the device drops to 0 prior to the parent pointer being accessed. Thus resulting in use after free. The bug bot AI correctly identified the fix. Save a reference to the parent pointer to be used to drop the parent reference regardless of the outcome of device_add().", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31400", "url": "https://ubuntu.com/security/CVE-2026-31400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix cache_request leak in cache_release When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request. In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup. The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up. Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, dequeue and free the cache_request.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2024-46715", "url": "https://ubuntu.com/security/CVE-2024-46715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver: iio: add missing checks on iio_info's callback access Some callbacks from iio_info structure are accessed without any check, so if a driver doesn't implement them trying to access the corresponding sysfs entries produce a kernel oops such as: [ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute [...] [ 2203.783416] Call trace: [ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48 [ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120 [ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4 [ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0 [ 2203.802236] vfs_read from ksys_read+0xa4/0xd4 [ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54 [ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0) [ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000 [ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000 [ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0 [ 2203.830363] Code: bad PC value [ 2203.832695] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-09-18 07:15:00 UTC" }, { "cve": "CVE-2026-23113", "url": "https://ubuntu.com/security/CVE-2026-23113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't support ->read_iter(), loop_rw_iter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path: INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000 Call Trace: context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98 There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2025-39748", "url": "https://ubuntu.com/security/CVE-2025-39748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Forget ranges when refining tnum after JSET Syzbot reported a kernel warning due to a range invariant violation on the following BPF program. 0: call bpf_get_netns_cookie 1: if r0 == 0 goto 2: if r0 & Oxffffffff goto The issue is on the path where we fall through both jumps. That path is unreachable at runtime: after insn 1, we know r0 != 0, but with the sign extension on the jset, we would only fallthrough insn 2 if r0 == 0. Unfortunately, is_branch_taken() isn't currently able to figure this out, so the verifier walks all branches. The verifier then refines the register bounds using the second condition and we end up with inconsistent bounds on this unreachable path: 1: if r0 == 0 goto r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2: if r0 & 0xffffffff goto r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0) r0 after reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0) Improving the range refinement for JSET to cover all cases is tricky. We also don't expect many users to rely on JSET given LLVM doesn't generate those instructions. So instead of improving the range refinement for JSETs, Eduard suggested we forget the ranges whenever we're narrowing tnums after a JSET. This patch implements that approach.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2026-43357", "url": "https://ubuntu.com/security/CVE-2026-43357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050-core: fix pm_runtime error handling The return value of pm_runtime_get_sync() is not checked, allowing the driver to access hardware that may fail to resume. The device usage count is also unconditionally incremented. Use pm_runtime_resume_and_get() which propagates errors and avoids incrementing the usage count on failure. In preenable, add pm_runtime_put_autosuspend() on set_8khz_samplerate() failure since postdisable does not run when preenable fails.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43476", "url": "https://ubuntu.com/security/CVE-2026-43476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas() sizeof(num) evaluates to sizeof(size_t) (8 bytes on 64-bit) instead of the intended __be32 element size (4 bytes). Use sizeof(*meas) to correctly match the buffer element type.", "cve_priority": "medium", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43363", "url": "https://ubuntu.com/security/CVE-2026-43363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/apic: Disable x2apic on resume if the kernel expects so When resuming from s2ram, firmware may re-enable x2apic mode, which may have been disabled by the kernel during boot either because it doesn't support IRQ remapping or for other reasons. This causes the kernel to continue using the xapic interface, while the hardware is in x2apic mode, which causes hangs. This happens on defconfig + bare metal + s2ram. Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be disabled, i.e. when x2apic_mode = 0. The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the pre-sleep configuration or initial boot configuration for each CPU, including MSR state: When executing from the power-on reset vector as a result of waking from an S2 or S3 sleep state, the platform firmware performs only the hardware initialization required to restore the system to either the state the platform was in prior to the initial operating system boot, or to the pre-sleep configuration state. In multiprocessor systems, non-boot processors should be placed in the same state as prior to the initial operating system boot. (further ahead) If this is an S2 or S3 wake, then the platform runtime firmware restores minimum context of the system before jumping to the waking vector. This includes: \tCPU configuration. Platform runtime firmware restores the pre-sleep \tconfiguration or initial boot configuration of each CPU (MSR, MTRR, \tfirmware update, SMBase, and so on). Interrupts must be disabled (for \tIA-32 processors, disabled by CLI instruction). \t(and other things) So at least as per the spec, re-enablement of x2apic by the firmware is allowed if \"x2apic on\" is a part of the initial boot configuration. [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization [ bp: Massage. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43365", "url": "https://ubuntu.com/security/CVE-2026-43365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix undersized l_iclog_roundoff values If the superblock doesn't list a log stripe unit, we set the incore log roundoff value to 512. This leads to corrupt logs and unmountable filesystems in generic/617 on a disk with 4k physical sectors... XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197. XFS (sda1): failed to locate log tail XFS (sda1): log mount/recovery failed: error -74 XFS (sda1): log mount failed XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Ending clean mount ...on the current xfsprogs for-next which has a broken mkfs. xfs_info shows this... meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1 data = bsize=4096 blocks=2579968, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=4096 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=268435456 extents = zoned=0 start=0 reserved=0 ...observe that the log section has sectsz=4096 sunit=0, which means that the roundoff factor is 512, not 4096 as you'd expect. We should fix mkfs not to generate broken filesystems, but anyone can fuzz the ondisk superblock so we should be more cautious. I think the inadequate logic predates commit a6a65fef5ef8d0, but that's clearly going to require a different backport.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43370", "url": "https://ubuntu.com/security/CVE-2026-43370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix use-after-free race in VM acquire Replace non-atomic vm->process_info assignment with cmpxchg() to prevent race when parent/child processes sharing a drm_file both try to acquire the same VM after fork(). (cherry picked from commit c7c573275ec20db05be769288a3e3bb2250ec618)", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43373", "url": "https://ubuntu.com/security/CVE-2026-43373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ncsi: fix skb leak in error paths Early return paths in NCSI RX and AEN handlers fail to release the received skb, resulting in a memory leak. Specifically, ncsi_aen_handler() returns on invalid AEN packets without consuming the skb. Similarly, ncsi_rcv_rsp() exits early when failing to resolve the NCSI device, response handler, or request, leaving the skb unfreed.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43380", "url": "https://ubuntu.com/security/CVE-2026-43380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read The q54sj108a2_debugfs_read function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes 'data' as the destination and 'data_char' as the source. Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since 'data' is only 34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the end of the buffer onto the stack. Additionally, the arguments were swapped: it was reading from the zero-initialized 'data_char' and writing to 'data', resulting in all-zero output regardless of the actual I2C read. Fix this by: 1. Expanding 'data_char' to 66 bytes to safely hold the hex output. 2. Correcting the bin2hex() argument order and using the actual read count. 3. Using a pointer to select the correct output buffer for the final simple_read_from_buffer call.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43381", "url": "https://ubuntu.com/security/CVE-2026-43381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dpcd: return EBUSY for aux xfer if the device is asleep If we have runtime suspended, and userspace wants to use /dev/drm_dp_* then just tell it the device is busy instead of crashing in the GSP code. WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy) Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024 RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them awake while fw updates are happening.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43382", "url": "https://ubuntu.com/security/CVE-2026-43382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid double-rtnl_lock ELP metric worker batadv_v_elp_get_throughput() might be called when the RTNL lock is already held. This could be problematic when the work queue item is cancelled via cancel_delayed_work_sync() in batadv_v_elp_iface_disable(). In this case, an rtnl_lock() would cause a deadlock. To avoid this, rtnl_trylock() was used in this function to skip the retrieval of the ethtool information in case the RTNL lock was already held. But for cfg80211 interfaces, batadv_get_real_netdev() was called - which also uses rtnl_lock(). The approach for __ethtool_get_link_ksettings() must also be used instead and the lockless version __batadv_get_real_netdev() has to be called.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-31405", "url": "https://ubuntu.com/security/CVE-2026-31405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-net: fix OOB access in ULE extension header tables The ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables in handle_one_ule_extension() are declared with 255 elements (valid indices 0-254), but the index htype is derived from network-controlled data as (ule_sndu_type & 0x00FF), giving a range of 0-255. When htype equals 255, an out-of-bounds read occurs on the function pointer table, and the OOB value may be called as a function pointer. Add a bounds check on htype against the array size before either table is accessed. Out-of-range values now cause the SNDU to be discarded.", "cve_priority": "high", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-43387", "url": "https://ubuntu.com/security/CVE-2026-43387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: properly validate the data in rtw_get_ie_ex() Just like in commit 154828bf9559 (\"staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser\"), we don't trust the data in the frame so we should check the length better before acting on it", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43386", "url": "https://ubuntu.com/security/CVE-2026-43386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie The current code checks 'i + 5 < in_len' at the end of the if statement. However, it accesses 'in_ie[i + 5]' before that check, which can lead to an out-of-bounds read. Move the length check to the beginning of the conditional to ensure the index is within bounds before accessing the array.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43420", "url": "https://ubuntu.com/security/CVE-2026-43420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix i_nlink underrun during async unlink During async unlink, we drop the `i_nlink` counter before we receive the completion (that will eventually update the `i_nlink`) because \"we assume that the unlink will succeed\". That is not a bad idea, but it races against deletions by other clients (or against the completion of our own unlink) and can lead to an underrun which emits a WARNING like this one: WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68 Modules linked in: CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drop_nlink+0x50/0x68 lr : ceph_unlink+0x6c4/0x720 sp : ffff80012173bc90 x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680 x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647 x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203 x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365 x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74 x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94 x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002 x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8 Call trace: drop_nlink+0x50/0x68 (P) vfs_unlink+0xb0/0x2e8 do_unlinkat+0x204/0x288 __arm64_sys_unlinkat+0x3c/0x80 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0xa4/0xc8 el0_svc+0x18/0x58 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x154/0x158 In ceph_unlink(), a call to ceph_mdsc_submit_request() submits the CEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion. Meanwhile, between this call and the following drop_nlink() call, a worker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT or just a CEPH_MSG_CLIENT_REPLY (the latter of which could be our own completion). These will lead to a set_nlink() call, updating the `i_nlink` counter to the value received from the MDS. If that new `i_nlink` value happens to be zero, it is illegal to decrement it further. But that is exactly what ceph_unlink() will do then. The WARNING can be reproduced this way: 1. Force async unlink; only the async code path is affected. Having no real clue about Ceph internals, I was unable to find out why the MDS wouldn't give me the \"Fxr\" capabilities, so I patched get_caps_for_async_unlink() to always succeed. (Note that the WARNING dump above was found on an unpatched kernel, without this kludge - this is not a theoretical bug.) 2. Add a sleep call after ceph_mdsc_submit_request() so the unlink completion gets handled by a worker thread before drop_nlink() is called. This guarantees that the `i_nlink` is already zero before drop_nlink() runs. The solution is to skip the counter decrement when it is already zero, but doing so without a lock is still racy (TOCTOU). Since ceph_fill_inode() and handle_cap_grant() both hold the `ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, this seems like the proper lock to protect the `i_nlink` updates. I found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using `afs_vnode.cb_lock`). All three have the zero check as well.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43405", "url": "https://ubuntu.com/security/CVE-2026-43405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Use u32 for non-negative values in ceph_monmap_decode() This patch fixes unnecessary implicit conversions that change signedness of blob_len and num_mon in ceph_monmap_decode(). Currently blob_len and num_mon are (signed) int variables. They are used to hold values that are always non-negative and get assigned in ceph_decode_32_safe(), which is meant to assign u32 values. Both variables are subsequently used as unsigned values, and the value of num_mon is further assigned to monmap->num_mon, which is of type u32. Therefore, both variables should be of type u32. This is especially relevant for num_mon. If the value read from the incoming message is very large, it is interpreted as a negative value, and the check for num_mon > CEPH_MAX_MON does not catch it. This leads to the attempt to allocate a very large chunk of memory for monmap, which will most likely fail. In this case, an unnecessary attempt to allocate memory is performed, and -ENOMEM is returned instead of -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43411", "url": "https://ubuntu.com/security/CVE-2026-43411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix divide-by-zero in tipc_sk_filter_connect() A user can set conn_timeout to any value via setsockopt(TIPC_CONN_TIMEOUT), including values less than 4. When a SYN is rejected with TIPC_ERR_OVERLOAD and the retry path in tipc_sk_filter_connect() executes: delay %= (tsk->conn_timeout / 4); If conn_timeout is in the range [0, 3], the integer division yields 0, and the modulo operation triggers a divide-by-zero exception, causing a kernel oops/panic. Fix this by clamping conn_timeout to a minimum of 4 at the point of use in tipc_sk_filter_connect(). Oops: divide error: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+ RIP: 0010:tipc_sk_filter_rcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362) Call Trace: tipc_sk_backlog_rcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406) __release_sock (include/net/sock.h:1185 net/core/sock.c:3213) release_sock (net/core/sock.c:3797) tipc_connect (net/tipc/socket.c:2570) __sys_connect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098)", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43484", "url": "https://ubuntu.com/security/CVE-2026-43484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: core: Avoid bitfield RMW for claim/retune flags Move claimed and retune control flags out of the bitfield word to avoid unrelated RMW side effects in asynchronous contexts. The host->claimed bit shared a word with retune flags. Writes to claimed in __mmc_claim_host() or retune_now in mmc_mq_queue_rq() can overwrite other bits when concurrent updates happen in other contexts, triggering spurious WARN_ON(!host->claimed). Convert claimed, can_retune, retune_now and retune_paused to bool to remove shared-word coupling.", "cve_priority": "low", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43425", "url": "https://ubuntu.com/security/CVE-2026-43425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: kill download URB on timeout mdc800_device_read() submits download_urb and waits for completion. If the timeout fires and the device has not responded, the function returns without killing the URB, leaving it active. A subsequent read() resubmits the same URB while it is still in-flight, triggering the WARN in usb_submit_urb(): \"URB submitted while active\" Check the return value of wait_event_timeout() and kill the URB if it indicates timeout, ensuring the URB is complete before its status is inspected or the URB is resubmitted. Similar to - commit 372c93131998 (\"USB: yurex: fix control-URB timeout handling\") - commit b98d5000c505 (\"media: rc: iguanair: handle timeouts\")", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43426", "url": "https://ubuntu.com/security/CVE-2026-43426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: fix use-after-free in ISR during device removal In usbhs_remove(), the driver frees resources (including the pipe array) while the interrupt handler (usbhs_interrupt) is still registered. If an interrupt fires after usbhs_pipe_remove() but before the driver is fully unbound, the ISR may access freed memory, causing a use-after-free. Fix this by calling devm_free_irq() before freeing resources. This ensures the interrupt handler is both disabled and synchronized (waits for any running ISR to complete) before usbhs_pipe_remove() is called.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43427", "url": "https://ubuntu.com/security/CVE-2026-43427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: class: cdc-wdm: fix reordering issue in read code path Quoting the bug report: Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdm_read() can see the new length and call copy_to_user() on uninitialized memory. This also violates LKMM data race rules [1]. Fix it by using WRITE_ONCE and memory barriers.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43428", "url": "https://ubuntu.com/security/CVE-2026-43428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: core: Limit the length of unkillable synchronous timeouts The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device. To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector. In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43429", "url": "https://ubuntu.com/security/CVE-2026-43429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: Use usb_bulk_msg_killable() with user-specified timeouts The usbtmc driver accepts timeout values specified by the user in an ioctl command, and uses these timeouts for some usb_bulk_msg() calls. Since the user can specify arbitrarily long timeouts and usb_bulk_msg() uses unkillable waits, call usb_bulk_msg_killable() instead to avoid the possibility of the user hanging a kernel thread indefinitely.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43430", "url": "https://ubuntu.com/security/CVE-2026-43430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: yurex: fix race in probe The bbu member of the descriptor must be set to the value standing for uninitialized values before the URB whose completion handler sets bbu is submitted. Otherwise there is a window during which probing can overwrite already retrieved data.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43432", "url": "https://ubuntu.com/security/CVE-2026-43432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix memory leak in xhci_disable_slot() xhci_alloc_command() allocates a command structure and, when the second argument is true, also allocates a completion structure. Currently, the error handling path in xhci_disable_slot() only frees the command structure using kfree(), causing the completion structure to leak. Use xhci_free_command() instead of kfree(). xhci_free_command() correctly frees both the command structure and the associated completion structure. Since the command structure is allocated with zero-initialization, command->in_ctx is NULL and will not be erroneously freed by xhci_free_command(). This bug was found using an experimental static analysis tool we are developing. The tool is based on the LLVM framework and is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available, but we plan to open-source it after our research is published. The bug was originally detected on v6.13-rc1 using our static analysis tool, and we have verified that the issue persists in the latest mainline kernel. We performed build testing on x86_64 with allyesconfig using GCC=11.4.0. Since triggering these error paths in xhci_disable_slot() requires specific hardware conditions or abnormal state, we were unable to construct a test case to reliably trigger these specific error paths at runtime.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43439", "url": "https://ubuntu.com/security/CVE-2026-43439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup: fix race between task migration and iteration When a task is migrated out of a css_set, cgroup_migrate_add_task() first moves it from cset->tasks to cset->mg_tasks via: list_move_tail(&task->cg_list, &cset->mg_tasks); If a css_task_iter currently has it->task_pos pointing to this task, css_set_move_task() calls css_task_iter_skip() to keep the iterator valid. However, since the task has already been moved to ->mg_tasks, the iterator is advanced relative to the mg_tasks list instead of the original tasks list. As a result, remaining tasks on cset->tasks, as well as tasks queued on cset->mg_tasks, can be skipped by iteration. Fix this by calling css_set_skip_task_iters() before unlinking task->cg_list from cset->tasks. This advances all active iterators to the next task on cset->tasks, so iteration continues correctly even when a task is concurrently being migrated. This race is hard to hit in practice without instrumentation, but it can be reproduced by artificially slowing down cgroup_procs_show(). For example, on an Android device a temporary /sys/kernel/cgroup/cgroup_test knob can be added to inject a delay into cgroup_procs_show(), and then: 1) Spawn three long-running tasks (PIDs 101, 102, 103). 2) Create a test cgroup and move the tasks into it. 3) Enable a large delay via /sys/kernel/cgroup/cgroup_test. 4) In one shell, read cgroup.procs from the test cgroup. 5) Within the delay window, in another shell migrate PID 102 by writing it to a different cgroup.procs file. Under this setup, cgroup.procs can intermittently show only PID 101 while skipping PID 103. Once the migration completes, reading the file again shows all tasks as expected. Note that this change does not allow removing the existing css_set_skip_task_iters() call in css_set_move_task(). The new call in cgroup_migrate_add_task() only handles iterators that are racing with migration while the task is still on cset->tasks. Iterators may also start after the task has been moved to cset->mg_tasks. If we dropped css_set_skip_task_iters() from css_set_move_task(), such iterators could keep task_pos pointing to a migrating task, causing css_task_iter_advance() to malfunction on the destination css_set, up to and including crashes or infinite loops. The race window between migration and iteration is very small, and css_task_iter is not on a hot path. In the worst case, when an iterator is positioned on the first thread of the migrating process, cgroup_migrate_add_task() may have to skip multiple tasks via css_set_skip_task_iters(). However, this only happens when migration and iteration actually race, so the performance impact is negligible compared to the correctness fix provided here.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43480", "url": "https://ubuntu.com/security/CVE-2026-43480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisition The acp3x_5682_init() function did not check the return value of clk_get(), which could lead to dereferencing error pointers in rt5682_clk_enable(). Fix this by: 1. Changing clk_get() to the device-managed devm_clk_get(). 2. Adding proper IS_ERR() checks for both clock acquisitions.", "cve_priority": "low", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43445", "url": "https://ubuntu.com/security/CVE-2026-43445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: e1000/e1000e: Fix leak in 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 after a successful 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 would leak. In these commits, a faulty while condition caused an infinite loop in dma_error: Commit 03b1320dfcee (\"e1000e: remove use of skb_dma_map from e1000e driver\") Commit 602c0554d7b0 (\"e1000: remove use of skb_dma_map from e1000 driver\") Commit c1fa347f20f1 (\"e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()\") fixed the infinite loop, but introduced the off-by-one error. This issue may still exist in the igbvf driver, but I did not address it in this patch.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43449", "url": "https://ubuntu.com/security/CVE-2026-43449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_set dev->online_queues is a count incremented in nvme_init_queue. Thus, valid indices are 0 through dev->online_queues − 1. This patch fixes the loop condition to ensure the index stays within the valid range. Index 0 is excluded because it is the admin queue. KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74 CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: nvme-reset-wq nvme_reset_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xea/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xce/0x5d0 mm/kasan/report.c:482 kasan_report+0xdc/0x110 mm/kasan/report.c:595 __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c:379 nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c:3252 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 34 on cpu 1 at 4.241550s: kasan_save_stack+0x2c/0x60 mm/kasan/common.c:57 kasan_save_track+0x1c/0x70 mm/kasan/common.c:78 kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c:570 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5657 [inline] __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c:5663 kmalloc_array_node_noprof include/linux/slab.h:1075 [inline] nvme_pci_alloc_dev drivers/nvme/host/pci.c:3479 [inline] nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534 local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c:324 pci_call_probe drivers/pci/pci-driver.c:392 [inline] __pci_device_probe drivers/pci/pci-driver.c:417 [inline] pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c:451 call_driver_probe drivers/base/dd.c:583 [inline] really_probe+0x29b/0xb70 drivers/base/dd.c:661 __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c:803 driver_probe_device+0x56/0x1f0 drivers/base/dd.c:833 __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c:1159 async_run_entry_fn+0xa6/0x4b0 kernel/async.c:129 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 The buggy address belongs to the object at ffff88800592a000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 244 bytes to the right of allocated 1152-byte region [ffff88800592a000, ffff88800592a480) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff) page_type: f5(slab) raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000 head: 000fffffc0000040 ffff888001042000 00000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43450", "url": "https://ubuntu.com/security/CVE-2026-43450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table() nfnl_cthelper_dump_table() has a 'goto restart' that jumps to a label inside the for loop body. When the \"last\" helper saved in cb->args[1] is deleted between dump rounds, every entry fails the (cur != last) check, so cb->args[1] is never cleared. The for loop finishes with cb->args[0] == nf_ct_helper_hsize, and the 'goto restart' jumps back into the loop body bypassing the bounds check, causing an 8-byte out-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize]. The 'goto restart' block was meant to re-traverse the current bucket when \"last\" is no longer found, but it was placed after the for loop instead of inside it. Move the block into the for loop body so that the restart only occurs while cb->args[0] is still within bounds. BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131 Call Trace: nfnl_cthelper_dump_table+0x9f/0x1b0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 sock_recvmsg+0xde/0xf0 __sys_recvfrom+0x150/0x200 __x64_sys_recvfrom+0x76/0x90 do_syscall_64+0xc3/0x6e0 Allocated by task 1: __kvmalloc_node_noprof+0x21b/0x700 nf_ct_alloc_hashtable+0x65/0xd0 nf_conntrack_helper_init+0x21/0x60 nf_conntrack_init_start+0x18d/0x300 nf_conntrack_standalone_init+0x12/0xc0", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43451", "url": "https://ubuntu.com/security/CVE-2026-43451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: fix entry leak in bridge verdict error path nfqnl_recv_verdict() calls find_dequeue_entry() to remove the queue entry from the queue data structures, taking ownership of the entry. For PF_BRIDGE packets, it then calls nfqa_parse_bridge() to parse VLAN attributes. If nfqa_parse_bridge() returns an error (e.g. NFQA_VLAN present but NFQA_VLAN_TCI missing), the function returns immediately without freeing the dequeued entry or its sk_buff. This leaks the nf_queue_entry, its associated sk_buff, and all held references (net_device refcounts, struct net refcount). Repeated triggering exhausts kernel memory. Fix this by dropping the entry via nfqnl_reinject() with NF_DROP verdict on the error path, consistent with other error handling in this file.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43452", "url": "https://ubuntu.com/security/CVE-2026-43452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: guard option walkers against 1-byte tail reads When the last byte of options is a non-single-byte option kind, walkers that advance with i += op[i + 1] ? : 1 can read op[i + 1] past the end of the option area. Add an explicit i == optlen - 1 check before dereferencing op[i + 1] in xt_tcpudp and xt_dccp option walkers.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43453", "url": "https://ubuntu.com/security/CVE-2026-43453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop() pipapo_drop() passes rulemap[i + 1].n to pipapo_unmap() as the to_offset argument on every iteration, including the last one where i == m->field_count - 1. This reads one element past the end of the stack-allocated rulemap array (declared as rulemap[NFT_PIPAPO_MAX_FIELDS] with NFT_PIPAPO_MAX_FIELDS == 16). Although pipapo_unmap() returns early when is_last is true without using the to_offset value, the argument is evaluated at the call site before the function body executes, making this a genuine out-of-bounds stack read confirmed by KASAN: BUG: KASAN: stack-out-of-bounds in pipapo_drop+0x50c/0x57c [nf_tables] Read of size 4 at addr ffff8000810e71a4 This frame has 1 object: [32, 160) 'rulemap' The buggy address is at offset 164 -- exactly 4 bytes past the end of the rulemap array. Pass 0 instead of rulemap[i + 1].n on the last iteration to avoid the out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43458", "url": "https://ubuntu.com/security/CVE-2026-43458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: caif: hold tty->link reference in ldisc_open and ser_release A reproducer triggers a KASAN slab-use-after-free in pty_write_room() when caif_serial's TX path calls tty_write_room(). The faulting access is on tty->link->port. Hold an extra kref on tty->link for the lifetime of the caif_serial line discipline: get it in ldisc_open() and drop it in ser_release(), and also drop it on the ldisc_open() error path. With this change applied, the reproducer no longer triggers the UAF in my testing.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43459", "url": "https://ubuntu.com/security/CVE-2026-43459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-core: flush delayed work before removing DAIs and widgets When a sound card is unbound while a PCM stream is open, a use-after-free can occur in snd_soc_dapm_stream_event(), called from the close_delayed_work workqueue handler. During unbind, snd_soc_unbind_card() flushes delayed work and then calls soc_cleanup_card_resources(). Inside cleanup, snd_card_disconnect_sync() releases all PCM file descriptors, and the resulting PCM close path can call snd_soc_dapm_stream_stop() which schedules new delayed work with a pmdown_time timer delay. Since this happens after the flush in snd_soc_unbind_card(), the new work is not caught. soc_remove_link_components() then frees DAPM widgets before this work fires, leading to the use-after-free. The existing flush in soc_free_pcm_runtime() also cannot help as it runs after soc_remove_link_components() has already freed the widgets. Add a flush in soc_cleanup_card_resources() after snd_card_disconnect_sync() (after which no new PCM closes can schedule further delayed work) and before soc_remove_link_dais() and soc_remove_link_components() (which tear down the structures the delayed work accesses).", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-23277", "url": "https://ubuntu.com/security/CVE-2026-23277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit teql_master_xmit() calls netdev_start_xmit(skb, slave) to transmit through slave devices, but does not update skb->dev to the slave device beforehand. When a gretap tunnel is a TEQL slave, the transmit path reaches iptunnel_xmit() which saves dev = skb->dev (still pointing to teql0 master) and later calls iptunnel_xmit_stats(dev, pkt_len). This function does: get_cpu_ptr(dev->tstats) Since teql_master_setup() does not set dev->pcpu_stat_type to NETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstats for teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computes NULL + __per_cpu_offset[cpu], resulting in a page fault. BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206) Fix this by setting skb->dev = slave before calling netdev_start_xmit(), so that tunnel xmit functions see the correct slave device with properly allocated tstats.", "cve_priority": "medium", "cve_public_date": "2026-03-20 09:16:00 UTC" }, { "cve": "CVE-2026-43466", "url": "https://ubuntu.com/security/CVE-2026-43466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery In case of a TX error CQE, a recovery flow is triggered, mlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc, desyncing the DMA FIFO producer and consumer. After recovery, the producer pushes new DMA entries at the old dma_fifo_pc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery. The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dma_fifo_cc is already equal to dma_fifo_pc. There is no need to reset either counter, similar to how skb_fifo pc/cc are untouched. Remove the 'dma_fifo_cc = 0' reset. This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90 Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: ? __warn+0x7d/0x110 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0x16d/0x180 ? handle_bug+0x4f/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 ? iommu_dma_unmap_page+0x2e/0x90 dma_unmap_page_attrs+0x10d/0x1b0 mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core] mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core] mlx5e_napi_poll+0x8b/0xac0 [mlx5_core] __napi_poll+0x24/0x190 net_rx_action+0x32a/0x3b0 ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core] ? notifier_call_chain+0x35/0xa0 handle_softirqs+0xc9/0x270 irq_exit_rcu+0x71/0xd0 common_interrupt+0x7f/0xa0 asm_common_interrupt+0x22/0x40", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43469", "url": "https://ubuntu.com/security/CVE-2026-43469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decrement re_receiving on the early exit paths In the event that rpcrdma_post_recvs() fails to create a work request (due to memory allocation failure, say) or otherwise exits early, we should decrement ep->re_receiving before returning. Otherwise we will hang in rpcrdma_xprt_drain() as re_receiving will never reach zero and the completion will never be triggered. On a system with high memory pressure, this can appear as the following hung task: INFO: task kworker/u385:17:8393 blocked for more than 122 seconds. Tainted: G S E 6.19.0 #3 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u385:17 state:D stack:0 pid:8393 tgid:8393 ppid:2 task_flags:0x4248060 flags:0x00080000 Workqueue: xprtiod xprt_autoclose [sunrpc] Call Trace: __schedule+0x48b/0x18b0 ? ib_post_send_mad+0x247/0xae0 [ib_core] schedule+0x27/0xf0 schedule_timeout+0x104/0x110 __wait_for_common+0x98/0x180 ? __pfx_schedule_timeout+0x10/0x10 wait_for_completion+0x24/0x40 rpcrdma_xprt_disconnect+0x444/0x460 [rpcrdma] xprt_rdma_close+0x12/0x40 [rpcrdma] xprt_autoclose+0x5f/0x120 [sunrpc] process_one_work+0x191/0x3e0 worker_thread+0x2e3/0x420 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x273/0x2b0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2025-54505", "url": "https://ubuntu.com/security/CVE-2025-54505", "cve_description": "A transient execution vulnerability within AMD CPUs may allow a local user-privileged attacker to leak data via the floating point divisor unit, potentially resulting in loss of confidentiality.", "cve_priority": "medium", "cve_public_date": "2026-04-27 16:16:00 UTC" }, { "cve": "CVE-2026-31628", "url": "https://ubuntu.com/security/CVE-2026-31628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU: Fix FPDSS on Zen1 Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43472", "url": "https://ubuntu.com/security/CVE-2026-43472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: unshare: fix unshare_fs() handling There's an unpleasant corner case in unshare(2), when we have a CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that case copy_mnt_ns() gets passed current->fs instead of a private copy, which causes interesting warts in proof of correctness] > I guess if private means fs->users == 1, the condition could still be true. Unfortunately, it's worse than just a convoluted proof of correctness. Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS (and current->fs->users == 1). We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and flips current->fs->{pwd,root} to corresponding locations in the new namespace. Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM). We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's destroyed and its mount tree is dissolved, but... current->fs->root and current->fs->pwd are both left pointing to now detached mounts. They are pinning those, so it's not a UAF, but it leaves the calling process with unshare(2) failing with -ENOMEM _and_ leaving it with pwd and root on detached isolated mounts. The last part is clearly a bug. There is other fun related to that mess (races with pivot_root(), including the one between pivot_root() and fork(), of all things), but this one is easy to isolate and fix - treat CLONE_NEWNS as \"allocate a new fs_struct even if it hadn't been shared in the first place\". Sure, we could go for something like \"if both CLONE_NEWNS *and* one of the things that might end up failing after copy_mnt_ns() call in create_new_namespaces() are set, force allocation of new fs_struct\", but let's keep it simple - the cost of copy_fs_struct() is trivial. Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets a freshly allocated fs_struct, yet to be attached to anything. That seriously simplifies the analysis... FWIW, that bug had been there since the introduction of unshare(2) ;-/", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-43473", "url": "https://ubuntu.com/security/CVE-2026-43473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Add NULL checks when resetting request and reply queues The driver encountered a crash during resource cleanup when the reply and request queues were NULL due to freed memory. This issue occurred when the creation of reply or request queues failed, and the driver freed the memory first, but attempted to mem set the content of the freed memory, leading to a system crash. Add NULL pointer checks for reply and request queues before accessing the reply/request memory during cleanup", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-43475", "url": "https://ubuntu.com/security/CVE-2026-43475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT This resolves the follow splat and lock-up when running with PREEMPT_RT enabled on Hyper-V: [ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002 [ 415.140822] INFO: lockdep is turned off. [ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common [ 415.140846] Preemption disabled at: [ 415.140847] [] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)} [ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024 [ 415.140857] Call Trace: [ 415.140861] [ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140863] dump_stack_lvl+0x91/0xb0 [ 415.140870] __schedule_bug+0x9c/0xc0 [ 415.140875] __schedule+0xdf6/0x1300 [ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980 [ 415.140879] ? rcu_is_watching+0x12/0x60 [ 415.140883] schedule_rtlock+0x21/0x40 [ 415.140885] rtlock_slowlock_locked+0x502/0x1980 [ 415.140891] rt_spin_lock+0x89/0x1e0 [ 415.140893] hv_ringbuffer_write+0x87/0x2a0 [ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0 [ 415.140900] ? rcu_is_watching+0x12/0x60 [ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc] [ 415.140904] ? HARDIRQ_verbose+0x10/0x10 [ 415.140908] ? __rq_qos_issue+0x28/0x40 [ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod] [ 415.140926] __blk_mq_issue_directly+0x4a/0xc0 [ 415.140928] blk_mq_issue_direct+0x87/0x2b0 [ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440 [ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0 [ 415.140935] __blk_flush_plug+0xf4/0x150 [ 415.140940] __submit_bio+0x2b2/0x5c0 [ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360 [ 415.140946] submit_bio_noacct_nocheck+0x272/0x360 [ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4] [ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4] [ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4] [ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4] [ 415.141060] generic_perform_write+0x14e/0x2c0 [ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4] [ 415.141083] vfs_write+0x2ca/0x570 [ 415.141087] ksys_write+0x76/0xf0 [ 415.141089] do_syscall_64+0x99/0x1490 [ 415.141093] ? rcu_is_watching+0x12/0x60 [ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0 [ 415.141097] ? rcu_is_watching+0x12/0x60 [ 415.141098] ? lock_release+0x1f0/0x2a0 [ 415.141100] ? rcu_is_watching+0x12/0x60 [ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0 [ 415.141103] ? rcu_is_watching+0x12/0x60 [ 415.141104] ? __schedule+0xb34/0x1300 [ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170 [ 415.141109] ? do_nanosleep+0x8b/0x160 [ 415.141111] ? hrtimer_nanosleep+0x89/0x100 [ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10 [ 415.141116] ? xfd_validate_state+0x26/0x90 [ 415.141118] ? rcu_is_watching+0x12/0x60 [ 415.141120] ? do_syscall_64+0x1e0/0x1490 [ 415.141121] ? do_syscall_64+0x1e0/0x1490 [ 415.141123] ? rcu_is_watching+0x12/0x60 [ 415.141124] ? do_syscall_64+0x1e0/0x1490 [ 415.141125] ? do_syscall_64+0x1e0/0x1490 [ 415.141127] ? irqentry_exit+0x140/0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-23270", "url": "https://ubuntu.com/security/CVE-2026-23270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocks As Paolo said earlier [1]: \"Since the blamed commit below, classify can return TC_ACT_CONSUMED while the current skb being held by the defragmentation engine. As reported by GangMin Kim, if such packet is that may cause a UaF when the defrag engine later on tries to tuch again such packet.\" act_ct was never meant to be used in the egress path, however some users are attaching it to egress today [2]. Attempting to reach a middle ground, we noticed that, while most qdiscs are not handling TC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, we address the issue by only allowing act_ct to bind to clsact/ingress qdiscs and shared blocks. That way it's still possible to attach act_ct to egress (albeit only with clsact). [1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/ [2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23300", "url": "https://ubuntu.com/security/CVE-2026-23300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop When a standalone IPv6 nexthop object is created with a loopback device (e.g., \"ip -6 nexthop add id 100 dev lo\"), fib6_nh_init() misclassifies it as a reject route. This is because nexthop objects have no destination prefix (fc_dst=::), causing fib6_is_reject() to match any loopback nexthop. The reject path skips fib_nh_common_init(), leaving nhc_pcpu_rth_output unallocated. If an IPv4 route later references this nexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and panics. Simplify the check in fib6_nh_init() to only match explicit reject routes (RTF_REJECT) instead of using fib6_is_reject(). The loopback promotion heuristic in fib6_is_reject() is handled separately by ip6_route_info_create_nh(). After this change, the three cases behave as follows: 1. Explicit reject route (\"ip -6 route add unreachable 2001:db8::/64\"): RTF_REJECT is set, enters reject path, skips fib_nh_common_init(). No behavior change. 2. Implicit loopback reject route (\"ip -6 route add 2001:db8::/32 dev lo\"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. ip6_route_info_create_nh() still promotes it to reject afterward. nhc_pcpu_rth_output is allocated but unused, which is harmless. 3. Standalone nexthop object (\"ip -6 nexthop add id 100 dev lo\"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. nhc_pcpu_rth_output is properly allocated, fixing the crash when IPv4 routes reference this nexthop.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23293", "url": "https://ubuntu.com/security/CVE-2026-23293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. If an IPv6 packet is injected into the interface, route_shortcircuit() is called and a NULL pointer dereference happens on neigh_lookup(). BUG: kernel NULL pointer dereference, address: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neigh_lookup+0x20/0x270 [...] Call Trace: vxlan_xmit+0x638/0x1ef0 [vxlan] dev_hard_start_xmit+0x9e/0x2e0 __dev_queue_xmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x12f/0x1590 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix this by adding an early check on route_shortcircuit() when protocol is ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here because VXLAN can be built-in even when IPv6 is built as a module.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23381", "url": "https://ubuntu.com/security/CVE-2026-23381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. Then, if neigh_suppress is enabled and an ICMPv6 Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() will dereference ipv6_stub->nd_tbl which is NULL, passing it to neigh_lookup(). This causes a kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neigh_lookup+0x16/0xe0 [...] Call Trace: ? neigh_lookup+0x16/0xe0 br_do_suppress_nd+0x160/0x290 [bridge] br_handle_frame_finish+0x500/0x620 [bridge] br_handle_frame+0x353/0x440 [bridge] __netif_receive_skb_core.constprop.0+0x298/0x1110 __netif_receive_skb_one_core+0x3d/0xa0 process_backlog+0xa0/0x140 __napi_poll+0x2c/0x170 net_rx_action+0x2c4/0x3a0 handle_softirqs+0xd0/0x270 do_softirq+0x3f/0x60 Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() in the callers. This is in essence disabling NS/NA suppression when IPv6 is disabled.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23372", "url": "https://ubuntu.com/security/CVE-2026-23372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: rawsock: cancel tx_work before socket teardown In rawsock_release(), cancel any pending tx_work and purge the write queue before orphaning the socket. rawsock_tx_work runs on the system workqueue and calls nfc_data_exchange which dereferences the NCI device. Without synchronization, tx_work can race with socket and device teardown when a process is killed (e.g. by SIGKILL), leading to use-after-free or leaked references. Set SEND_SHUTDOWN first so that if tx_work is already running it will see the flag and skip transmitting, then use cancel_work_sync to wait for any in-progress execution to finish, and finally purge any remaining queued skbs.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23339", "url": "https://ubuntu.com/security/CVE-2026-23339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: free skb on nci_transceive early error paths nci_transceive() takes ownership of the skb passed by the caller, but the -EPROTO, -EINVAL, and -EBUSY error paths return without freeing it. Due to issues clearing NCI_DATA_EXCHANGE fixed by subsequent changes the nci/nci_dev selftest hits the error path occasionally in NIPA, and kmemleak detects leaks: unreferenced object 0xff11000015ce6a40 (size 640): comm \"nci_dev\", pid 3954, jiffies 4295441246 hex dump (first 32 bytes): 6b 6b 6b 6b 00 a4 00 0c 02 e1 03 6b 6b 6b 6b 6b kkkk.......kkkkk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk backtrace (crc 7c40cc2a): kmem_cache_alloc_node_noprof+0x492/0x630 __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xc6/0x8f0 sock_alloc_send_pskb+0x326/0x3f0 nfc_alloc_send_skb+0x94/0x1d0 rawsock_sendmsg+0x162/0x4c0 do_syscall_64+0x117/0xfc0", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23340", "url": "https://ubuntu.com/security/CVE-2026-23340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs When shrinking the number of real tx queues, netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush qdiscs for queues which will no longer be used. qdisc_reset_all_tx_gt() currently serializes qdisc_reset() with qdisc_lock(). However, for lockless qdiscs, the dequeue path is serialized by qdisc_run_begin/end() using qdisc->seqlock instead, so qdisc_reset() can run concurrently with __qdisc_run() and free skbs while they are still being dequeued, leading to UAF. This can easily be reproduced on e.g. virtio-net by imposing heavy traffic while frequently changing the number of queue pairs: iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 done With KASAN enabled, this leads to reports like: BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: ... __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 udp_sendmsg+0x13c9/0x1fc0 ... Allocated by task 1270 on cpu 5 at 44.558414s: ... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg+0x13a6/0x1fc0 ... Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a/0x890 ... Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path by taking qdisc->seqlock for TCQ_F_NOLOCK qdiscs, matching the serialization model already used by dev_reset_queue(). Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state reflects an empty queue, avoiding needless re-scheduling.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23304", "url": "https://ubuntu.com/security/CVE-2026-23304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu() l3mdev_master_dev_rcu() can return NULL when the slave device is being un-slaved from a VRF. All other callers deal with this, but we lost the fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu() with commit 4832c30d5458 (\"net: ipv6: put host and anycast routes on device with address\"). KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418) Call Trace: ip6_pol_route (net/ipv6/route.c:2318) fib6_rule_lookup (net/ipv6/fib6_rules.c:115) ip6_route_output_flags (net/ipv6/route.c:2607) vrf_process_v6_outbound (drivers/net/vrf.c:437) I was tempted to rework the un-slaving code to clear the flag first and insert synchronize_rcu() before we remove the upper. But looks like the explicit fallback to loopback_dev is an established pattern. And I guess avoiding the synchronize_rcu() is nice, too.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23420", "url": "https://ubuntu.com/security/CVE-2026-23420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: Fix a locking bug Make sure that wl->mutex is locked before it is unlocked. This has been detected by the Clang thread-safety analyzer.", "cve_priority": "medium", "cve_public_date": "2026-04-03 14:16:00 UTC" }, { "cve": "CVE-2026-23357", "url": "https://ubuntu.com/security/CVE-2026-23357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix deadlock in error path of mcp251x_open The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish. This issue is similar to the one fixed in commit 7dd9c26bd6cf (\"can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\") but for the error path. To solve this issue move the call to free_irq() after the lock is released. Setting `priv->force_quit = 1` beforehand ensure that the IRQ handler will exit right away once it acquired the lock.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23362", "url": "https://ubuntu.com/security/CVE-2026-23362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix locking for bcm_op runtime updates Commit c2aba69d0c36 (\"can: bcm: add locking for bcm_op runtime updates\") added a locking for some variables that can be modified at runtime when updating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup(). Usually the RX_SETUP only handles and filters incoming traffic with one exception: When the RX_RTR_FRAME flag is set a predefined CAN frame is sent when a specific RTR frame is received. Therefore the rx bcm_op uses bcm_can_tx() which uses the bcm_tx_lock that was only initialized in bcm_tx_setup(). Add the missing spin_lock_init() when allocating the bcm_op in bcm_rx_setup() to handle the RTR case properly.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23286", "url": "https://ubuntu.com/security/CVE-2026-23286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix null-ptr-deref in lec_arp_clear_vccs syzkaller reported a null-ptr-deref in lec_arp_clear_vccs(). This issue can be easily reproduced using the syzkaller reproducer. In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared by multiple lec_arp_table entries (e.g., via entry->vcc or entry->recv_vcc). When the underlying VCC is closed, lec_vcc_close() iterates over all ARP entries and calls lec_arp_clear_vccs() for each matched entry. For example, when lec_vcc_close() iterates through the hlists in priv->lec_arp_empty_ones or other ARP tables: 1. In the first iteration, for the first matched ARP entry sharing the VCC, lec_arp_clear_vccs() frees the associated vpriv (which is vcc->user_back) and sets vcc->user_back to NULL. 2. In the second iteration, for the next matched ARP entry sharing the same VCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv from vcc->user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference it via `vcc->pop = vpriv->old_pop`, leading to a null-ptr-deref crash. Fix this by adding a null check for vpriv before dereferencing it. If vpriv is already NULL, it means the VCC has been cleared by a previous call, so we can safely skip the cleanup and just clear the entry's vcc/recv_vcc pointers. The entire cleanup block (including vcc_release_async()) is placed inside the vpriv guard because a NULL vpriv indicates the VCC has already been fully released by a prior iteration — repeating the teardown would redundantly set flags and trigger callbacks on an already-closing socket. The Fixes tag points to the initial commit because the entry->vcc path has been vulnerable since the original code. The entry->recv_vcc path was later added by commit 8d9f73c0ad2f (\"atm: fix a memory leak of vcc->user_back\") with the same pattern, and both paths are fixed here.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23296", "url": "https://ubuntu.com/security/CVE-2026-23296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix refcount leak for tagset_refcnt This leak will cause a hang when tearing down the SCSI host. For example, iscsid hangs with the following call trace: [130120.652718] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured PID: 2528 TASK: ffff9d0408974e00 CPU: 3 COMMAND: \"iscsid\" #0 [ffffb5b9c134b9e0] __schedule at ffffffff860657d4 #1 [ffffb5b9c134ba28] schedule at ffffffff86065c6f #2 [ffffb5b9c134ba40] schedule_timeout at ffffffff86069fb0 #3 [ffffb5b9c134bab0] __wait_for_common at ffffffff8606674f #4 [ffffb5b9c134bb10] scsi_remove_host at ffffffff85bfe84b #5 [ffffb5b9c134bb30] iscsi_sw_tcp_session_destroy at ffffffffc03031c4 [iscsi_tcp] #6 [ffffb5b9c134bb48] iscsi_if_recv_msg at ffffffffc0292692 [scsi_transport_iscsi] #7 [ffffb5b9c134bb98] iscsi_if_rx at ffffffffc02929c2 [scsi_transport_iscsi] #8 [ffffb5b9c134bbf0] netlink_unicast at ffffffff85e551d6 #9 [ffffb5b9c134bc38] netlink_sendmsg at ffffffff85e554ef", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23356", "url": "https://ubuntu.com/security/CVE-2026-23356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: fix \"LOGIC BUG\" in drbd_al_begin_io_nonblock() Even though we check that we \"should\" be able to do lc_get_cumulative() while holding the device->al_lock spinlock, it may still fail, if some other code path decided to do lc_try_lock() with bad timing. If that happened, we logged \"LOGIC BUG for enr=...\", but still did not return an error. The rest of the code now assumed that this request has references for the relevant activity log extents. The implcations are that during an active resync, mutual exclusivity of resync versus application IO is not guaranteed. And a potential crash at this point may not realizs that these extents could have been target of in-flight IO and would need to be resynced just in case. Also, once the request completes, it will give up activity log references it does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put(). Fix: Do not crash the kernel for a condition that is harmless during normal operation: also catch \"e->refcnt == 0\", not only \"e == NULL\" when being noisy about \"al_complete_io() called on inactive extent %u\\n\". And do not try to be smart and \"guess\" whether something will work, then be surprised when it does not. Deal with the fact that it may or may not work. If it does not, remember a possible \"partially in activity log\" state (only possible for requests that cross extent boundaries), and return an error code from drbd_al_begin_io_nonblock(). A latter call for the same request will then resume from where we left off.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23388", "url": "https://ubuntu.com/security/CVE-2026-23388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check metadata block offset is within range Syzkaller reports a \"general protection fault in squashfs_copy_data\" This is ultimately caused by a corrupted index look-up table, which produces a negative metadata block offset. This is subsequently passed to squashfs_copy_data (via squashfs_read_metadata) where the negative offset causes an out of bounds access. The fix is to check that the offset is within range in squashfs_read_metadata. This will trap this and other cases.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23379", "url": "https://ubuntu.com/security/CVE-2026-23379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: fix divide by zero in the offload path Offloading ETS requires computing each class' WRR weight: this is done by averaging over the sums of quanta as 'q_sum' and 'q_psum'. Using unsigned int, the same integer size as the individual DRR quanta, can overflow and even cause division by zero, like it happened in the following splat: Oops: divide error: 0000 [#1] SMP PTI CPU: 13 UID: 0 PID: 487 Comm: tc Tainted: G E 6.19.0-virtme #45 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Call Trace: ets_qdisc_change+0x870/0xf40 [sch_ets] qdisc_create+0x12b/0x540 tc_modify_qdisc+0x6d7/0xbd0 rtnetlink_rcv_msg+0x168/0x6b0 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x1d6/0x2b0 netlink_sendmsg+0x22e/0x470 ____sys_sendmsg+0x38a/0x3c0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x111/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f440b81c77e Code: 4d 89 d8 e8 d4 bc 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff951e4c10 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000481820 RCX: 00007f440b81c77e RDX: 0000000000000000 RSI: 00007fff951e4cd0 RDI: 0000000000000003 RBP: 00007fff951e4c20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff951f4fa8 R13: 00000000699ddede R14: 00007f440bb01000 R15: 0000000000486980 Modules linked in: sch_ets(E) netdevsim(E) ---[ end trace 0000000000000000 ]--- RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]--- Fix this using 64-bit integers for 'q_sum' and 'q_psum'.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23289", "url": "https://ubuntu.com/security/CVE-2026-23289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq() Fix a user triggerable leak on the system call failure path.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23279", "url": "https://ubuntu.com/security/CVE-2026-23279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix NULL pointer dereference in mesh_rx_csa_frame() In mesh_rx_csa_frame(), elems->mesh_chansw_params_ie is dereferenced at lines 1638 and 1642 without a prior NULL check: ifmsh->chsw_ttl = elems->mesh_chansw_params_ie->mesh_ttl; ... pre_value = le16_to_cpu(elems->mesh_chansw_params_ie->mesh_pre_value); The mesh_matches_local() check above only validates the Mesh ID, Mesh Configuration, and Supported Rates IEs. It does not verify the presence of the Mesh Channel Switch Parameters IE (element ID 118). When a received CSA action frame omits that IE, ieee802_11_parse_elems() leaves elems->mesh_chansw_params_ie as NULL, and the unconditional dereference causes a kernel NULL pointer dereference. A remote mesh peer with an established peer link (PLINK_ESTAB) can trigger this by sending a crafted SPECTRUM_MGMT/CHL_SWITCH action frame that includes a matching Mesh ID and Mesh Configuration IE but omits the Mesh Channel Switch Parameters IE. No authentication beyond the default open mesh peering is required. Crash confirmed on kernel 6.17.0-5-generic via mac80211_hwsim: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:ieee80211_mesh_rx_queued_mgmt+0x143/0x2a0 [mac80211] CR2: 0000000000000000 Fix by adding a NULL check for mesh_chansw_params_ie after mesh_matches_local() returns, consistent with how other optional IEs are guarded throughout the mesh code. The bug has been present since v3.13 (released 2014-01-19).", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23367", "url": "https://ubuntu.com/security/CVE-2026-23367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: radiotap: reject radiotap with unknown bits The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator->_next_ns_data isn't initialized (it's only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value. Fix this by moving the rejection of unknown radiotap fields down to after the in-namespace lookup, so it will really use iterator->_next_ns_data only for vendor namespaces, even in case undefined fields are present.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23318", "url": "https://ubuntu.com/security/CVE-2026-23318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Use correct version for UAC3 header validation The entry of the validators table for UAC3 AC header descriptor is defined with the wrong protocol version UAC_VERSION_2, while it should have been UAC_VERSION_3. This results in the validator never matching for actual UAC3 devices (protocol == UAC_VERSION_3), causing their header descriptors to bypass validation entirely. A malicious USB device presenting a truncated UAC3 header could exploit this to cause out-of-bounds reads when the driver later accesses unvalidated descriptor fields. The bug was introduced in the same commit as the recently fixed UAC3 feature unit sub-type typo, and appears to be from the same copy-paste error when the UAC3 section was created from the UAC2 section.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23370", "url": "https://ubuntu.com/security/CVE-2026-23370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data set_new_password() hex dumps the entire buffer, which contains plaintext password data, including current and new passwords. Remove the hex dump to avoid leaking credentials.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23352", "url": "https://ubuntu.com/security/CVE-2026-23352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/efi: defer freeing of boot services memory efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late(). There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area(). More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete. Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM. If the freed memory resides in the areas that memory map for them is still uninitialized, they won't be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages. Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map. Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that's undesirable late in boot when there is concurrency. More robust approach is to only defer freeing of the EFI boot services memory. Split efi_free_boot_services() in two. First efi_unmap_boot_services() collects ranges that should be freed into an array then efi_free_boot_services() later frees them after deferred init is complete.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23382", "url": "https://ubuntu.com/security/CVE-2026-23382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them In commit 2ff5baa9b527 (\"HID: appleir: Fix potential NULL dereference at raw event handle\"), we handle the fact that raw event callbacks can happen even for a HID device that has not been \"claimed\" causing a crash if a broken device were attempted to be connected to the system. Fix up the remaining in-tree HID drivers that forgot to add this same check to resolve the same issue.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23324", "url": "https://ubuntu.com/security/CVE-2026-23324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: usb: etas_es58x: correctly anchor the urb in the read bulk callback When submitting an urb, that is using the anchor pattern, it needs to be anchored before submitting it otherwise it could be leaked if usb_kill_anchored_urbs() is called. This logic is correctly done elsewhere in the driver, except in the read bulk callback so do that here also.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23298", "url": "https://ubuntu.com/security/CVE-2026-23298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ucan: Fix infinite loop from zero-length messages If a broken ucan device gets a message with the message length field set to 0, then the driver will loop for forever in ucan_read_bulk_callback(), hanging the system. If the length is 0, just skip the message and go on to the next one. This has been fixed in the kvaser_usb driver in the past in commit 0c73772cd2b8 (\"can: kvaser_usb: leaf: Fix potential infinite loop in command parsers\"), so there must be some broken devices out there like this somewhere.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23307", "url": "https://ubuntu.com/security/CVE-2026-23307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a message When looking at the data in a USB urb, the actual_length is the size of the buffer passed to the driver, not the transfer_buffer_length which is set by the driver as the max size of the buffer. When parsing the messages in ems_usb_read_bulk_callback() properly check the size both at the beginning of parsing the message to make sure it is big enough for the expected structure, and at the end of the message to make sure we don't overflow past the end of the buffer for the next message.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23290", "url": "https://ubuntu.com/security/CVE-2026-23290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: validate USB endpoints The pegasus driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23365", "url": "https://ubuntu.com/security/CVE-2026-23365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kalmia: validate USB endpoints The kalmia driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23312", "url": "https://ubuntu.com/security/CVE-2026-23312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: validate USB endpoints The kaweth driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23291", "url": "https://ubuntu.com/security/CVE-2026-23291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: properly drop the usb interface reference on disconnect When the device is disconnected from the driver, there is a \"dangling\" reference count on the usb interface that was grabbed in the probe callback. Fix this up by properly dropping the reference after we are done with it.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23253", "url": "https://ubuntu.com/security/CVE-2026-23253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: fix wrong reinitialization of ringbuffer on reopen dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock.", "cve_priority": "high", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-43123", "url": "https://ubuntu.com/security/CVE-2026-43123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: check return value of con2fb_acquire_newinfo() If fbcon_open() fails when called from con2fb_acquire_newinfo() then info->fbcon_par pointer remains NULL which is later dereferenced. Add check for return value of the function con2fb_acquire_newinfo() to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23220", "url": "https://ubuntu.com/security/CVE-2026-23220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error paths The problem occurs when a signed request fails smb2 signature verification check. In __process_request(), if check_sign_req() returns an error, set_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called. set_smb2_rsp_status() set work->next_smb2_rcv_hdr_off as zero. By resetting next_smb2_rcv_hdr_off to zero, the pointer to the next command in the chain is lost. Consequently, is_chained_smb2_message() continues to point to the same request header instead of advancing. If the header's NextCommand field is non-zero, the function returns true, causing __handle_ksmbd_work() to repeatedly process the same failed request in an infinite loop. This results in the kernel log being flooded with \"bad smb2 signature\" messages and high CPU usage. This patch fixes the issue by changing the return value from SERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures that the processing loop terminates immediately rather than attempting to continue from an invalidated offset.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-45911", "url": "https://ubuntu.com/security/CVE-2026-45911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix role switching during resume If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference. The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped. So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usb_hcd_is_primary_hcd+0x0/0x1c lr : cdns_host_resume+0x24/0x5c ... Call trace: usb_hcd_is_primary_hcd+0x0/0x1c (P) cdns_resume+0x6c/0xbc cdns3_controller_resume.isra.0+0xe8/0x17c cdns3_plat_resume+0x18/0x24 platform_pm_resume+0x2c/0x68 dpm_run_callback+0x90/0x248 device_resume+0x100/0x24c dpm_resume+0x190/0x2ec dpm_resume_end+0x18/0x34 suspend_devices_and_enter+0x2b0/0xa44 pm_suspend+0x16c/0x5fc state_store+0x80/0xec kobj_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x130/0x1dc vfs_write+0x240/0x370 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0x108 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-71287", "url": "https://ubuntu.com/security/CVE-2025-71287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memory: mtk-smi: fix device leak on larb probe Make sure to drop the reference taken when looking up the SMI device during larb probe on late probe failure (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23359", "url": "https://ubuntu.com/security/CVE-2026-23359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stack-out-of-bounds write in devmap get_upper_ifindexes() iterates over all upper devices and writes their indices into an array without checking bounds. Also the callers assume that the max number of upper devices is MAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack, but that assumption is not correct and the number of upper devices could be larger than MAX_NEST_DEV (e.g., many macvlans), causing a stack-out-of-bounds write. Add a max parameter to get_upper_ifindexes() to avoid the issue. When there are too many upper devices, return -EOVERFLOW and abort the redirect. To reproduce, create more than MAX_NEST_DEV(8) macvlans on a device with an XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS. Then send a packet to the device to trigger the XDP redirect path.", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43291", "url": "https://ubuntu.com/security/CVE-2026-43291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: nfc: nci: Fix parameter validation for packet data Since commit 9c328f54741b (\"net: nfc: nci: Add parameter validation for packet data\") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct).", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43283", "url": "https://ubuntu.com/security/CVE-2026-43283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle dma_free_coherent() in error path takes priv->rx_buf.alloc_len as the dma handle. This would lead to improper unmapping of the buffer. Change the dma handle to priv->rx_buf.alloc_phys.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43264", "url": "https://ubuntu.com/security/CVE-2026-43264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: of: display_timing: fix refcount leak in of_get_display_timings() of_parse_phandle() returns a device_node with refcount incremented, which is stored in 'entry' and then copied to 'native_mode'. When the error paths at lines 184 or 192 jump to 'entryfail', native_mode's refcount is not decremented, causing a refcount leak. Fix this by changing the goto target from 'entryfail' to 'timingfail', which properly calls of_node_put(native_mode) before cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43202", "url": "https://ubuntu.com/security/CVE-2026-43202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: vt8500lcdfb: fix missing dma_free_coherent() fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not freed if the error path is reached.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43203", "url": "https://ubuntu.com/security/CVE-2026-43203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: fore200e: fix use-after-free in tasklets during device removal When the PCA-200E or SBA-200E adapter is being detached, the fore200e is deallocated. However, the tx_tasklet or rx_tasklet may still be running or pending, leading to use-after-free bug when the already freed fore200e is accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet(). One of the race conditions can occur as follows: CPU 0 (cleanup) | CPU 1 (tasklet) fore200e_pca_remove_one() | fore200e_interrupt() fore200e_shutdown() | tasklet_schedule() kfree(fore200e) | fore200e_tx_tasklet() | fore200e-> // UAF Fix this by ensuring tx_tasklet or rx_tasklet is properly canceled before the fore200e is released. Add tasklet_kill() in fore200e_shutdown() to synchronize with any pending or running tasklets. Moreover, since fore200e_reset() could prevent further interrupts or data transfers, the tasklet_kill() should be placed after fore200e_reset() to prevent the tasklet from being rescheduled in fore200e_interrupt(). Finally, it only needs to do tasklet_kill() when the fore200e state is greater than or equal to FORE200E_STATE_IRQ, since tasklets are uninitialized in earlier states. In a word, the tasklet_kill() should be placed in the FORE200E_STATE_IRQ branch within the switch...case structure. This bug was identified through static analysis.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43149", "url": "https://ubuntu.com/security/CVE-2026-43149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean() The priv->rx_buffer and priv->tx_buffer are alloc'd together as contiguous buffers in uhdlc_init() but freed as two buffers in uhdlc_memclean(). Change the cleanup to only call dma_free_coherent() once on the whole buffer.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43273", "url": "https://ubuntu.com/security/CVE-2026-43273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: supply snapshot context in ceph_zero_partial_object() The ceph_zero_partial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.conf dd if=/dev/urandom of=/mnt/mycephfs/foo bs=64K count=1 mkdir /mnt/mycephfs/.snap/snap1 md5sum /mnt/mycephfs/.snap/snap1/foo fallocate -p -o 0 -l 4096 /mnt/mycephfs/foo echo 3 > /proc/sys/vm/drop/caches md5sum /mnt/mycephfs/.snap/snap1/foo # get different md5sum!!", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43159", "url": "https://ubuntu.com/security/CVE-2026-43159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix null dereference in find_network The variable pwlan has the possibility of being NULL when passed into rtw_free_network_nolock() which would later dereference the variable.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43211", "url": "https://ubuntu.com/security/CVE-2026-43211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: Fix pci_slot_trylock() error handling Commit a4e772898f8b (\"PCI: Add missing bridge lock to pci_bus_lock()\") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails. Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } } After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug. This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread. Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path. [Same patch later posted by Keith at https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com]", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43206", "url": "https://ubuntu.com/security/CVE-2026-43206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8 bytes via memset without checking the buffer size parameter. This allows unprivileged userspace to trigger an out-of bounds kernel memory write by passing a small buffer, leading to potential privilege escalation.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43275", "url": "https://ubuntu.com/security/CVE-2026-43275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Flush exception handling work when RPM level is zero Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0. When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race condition where the driver could attempt to access the host controller to handle an exception after the system had already entered a deep power-down state, resulting in a system crash. Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete and prevents illegal hardware access during the power-down sequence.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43145", "url": "https://ubuntu.com/security/CVE-2026-43145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_rproc: Fix invalid loaded resource table detection imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded resource table even when the current firmware does not provide one. When the device tree contains a \"rsc-table\" entry, priv->rsc_table is non-NULL and denotes where a resource table would be located if one is present in memory. However, when the current firmware has no resource table, rproc->table_ptr is NULL. The function still returns priv->rsc_table, and the remoteproc core interprets this as a valid loaded resource table. Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when there is no resource table for the current firmware (i.e. when rproc->table_ptr is NULL). This aligns the function's semantics with the remoteproc core: a loaded resource table is only reported when a valid table_ptr exists. With this change, starting firmware without a resource table no longer triggers a crash.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43147", "url": "https://ubuntu.com/security/CVE-2026-43147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV\" This reverts commit 05703271c3cd (\"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV\"), which causes a deadlock by recursively taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of pci_stop_and_remove_bus_device(). For example with the following sequence of commands: $ echo > /sys/bus/pci/devices//sriov_numvfs $ echo 1 > /sys/bus/pci/devices//remove A trimmed trace of the deadlock on a mlx5 device is as below: zsh/5715 is trying to acquire lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140 but task is already holding lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110 [<00000259779c844e>] print_deadlock_bug+0x31e/0x330 [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0 [<00000259779bffac>] lock_acquire+0x14c/0x350 [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520 [<000002597896413c>] mutex_lock_nested+0x3c/0x50 [<00000259784a07e4>] sriov_disable+0x34/0x140 [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core] [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core] [<00000259784857fc>] pci_device_remove+0x3c/0xa0 [<000002597851012e>] device_release_driver_internal+0x18e/0x280 [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0 [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80 [<00000259784972c2>] remove_store+0x72/0x90 [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200 [<0000025977d7241c>] vfs_write+0x24c/0x300 [<0000025977d72696>] ksys_write+0x86/0x110 [<000002597895b61c>] __do_syscall+0x14c/0x400 [<000002597896e0ee>] system_call+0x6e/0x90 This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43289", "url": "https://ubuntu.com/security/CVE-2026-43289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kexec: derive purgatory entry from symbol kexec_load_purgatory() derives image->start by locating e_entry inside an SHF_EXECINSTR section. If the purgatory object contains multiple executable sections with overlapping sh_addr, the entrypoint check can match more than once and trigger a WARN. Derive the entry section from the purgatory_start symbol when present and compute image->start from its final placement. Keep the existing e_entry fallback for purgatories that do not expose the symbol. WARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784 Call Trace: bzImage64_load+0x133/0xa00 __do_sys_kexec_file_load+0x2b3/0x5c0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e [me@linux.beauty: move helper to avoid forward declaration, per Baoquan]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43168", "url": "https://ubuntu.com/security/CVE-2026-43168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix reflink preserve cleanup issue commit c06c303832ec (\"ocfs2: fix xattr array entry __counted_by error\") doesn't handle all cases and the cleanup job for preserved xattr entries still has bug: - the 'last' pointer should be shifted by one unit after cleanup an array entry. - current code logic doesn't cleanup the first entry when xh_count is 1. Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43295", "url": "https://ubuntu.com/security/CVE-2026-43295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net() When idtab allocation fails, net is not registered with rio_add_net() yet, so kfree(net) is sufficient to release the memory. Set mport->net to NULL to avoid dangling pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43148", "url": "https://ubuntu.com/security/CVE-2026-43148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/smp: Add check for kcalloc() failure in parse_thread_groups() As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing it to of_property_read_u32_array().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43163", "url": "https://ubuntu.com/security/CVE-2026-43163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/bitmap: fix GPF in write_page caused by resize race A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod] This is a use-after-free race between bitmap_daemon_work() and __bitmap_resize(). The daemon iterates over `bitmap->storage.filemap` without locking, while the resize path frees that storage via md_bitmap_file_unmap(). `quiesce()` does not stop the md thread, allowing concurrent access to freed pages. Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43200", "url": "https://ubuntu.com/security/CVE-2026-43200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functions struct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target); While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specify the parameters in the correct order, pci_primary_epc_epf_unlink() and pci_secondary_epc_epf_unlink() specify the parameters in the wrong order, leading to the below kernel crash when using the unlink command in configfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0 [mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43158", "url": "https://ubuntu.com/security/CVE-2026-43158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix freemap adjustments when adding xattrs to leaf blocks xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) \t\t\t\t\t+ xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where \"rhs\" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 (\"xfs: fix attr leaf header freemap.size underflow\") and the previous patch that resets zero length freemap entries to have base = 0.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43187", "url": "https://ubuntu.com/security/CVE-2026-43187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: delete attr leaf freemap entries when empty Back in commit 2a2b5932db6758 (\"xfs: fix attr leaf header freemap.size underflow\"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the \"pushed-up\" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43130", "url": "https://ubuntu.com/security/CVE-2026-43130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode Commit 4fc82cd907ac (\"iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected\") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system. For example, if a VM fails to connect to the PCIe device, \"virsh destroy\" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd. Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput Although pci_device_is_present() is slower than pci_dev_is_disconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase. Besides, devtlb_invalidation_with_pasid() is called only in the paths below, which are far less frequent than memory map/unmap. 1. mm-struct release 2. {attach,release}_dev 3. set/remove PASID 4. dirty-tracking setup The gain in system stability far outweighs the negligible cost of using pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43133", "url": "https://ubuntu.com/security/CVE-2026-43133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation Commit cc3ed80ae69f (\"KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state\") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01. As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43196", "url": "https://ubuntu.com/security/CVE-2026-43196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: ti: pruss: Fix double free in pruss_clk_mux_setup() In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectly calls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np) on the error path. However, after the devm_add_action_or_reset() returns, the of_node_put(clk_mux_np) is called again, causing a double free. Fix by returning directly, to avoid the duplicate of_node_put().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43242", "url": "https://ubuntu.com/security/CVE-2026-43242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: ti: k3-socinfo: Fix regmap leak on probe failure The mmio regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43278", "url": "https://ubuntu.com/security/CVE-2026-43278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: clear cloned request bio pointer when last clone bio completes Stale rq->bio values have been observed to cause double-initialization of cloned bios in request-based device-mapper targets, leading to use-after-free and double-free scenarios. One such case occurs when using dm-multipath on top of a PCIe NVMe namespace, where cloned request bios are freed during blk_complete_request(), but rq->bio is left intact. Subsequent clone teardown then attempts to free the same bios again via blk_rq_unprep_clone(). The resulting double-free path looks like: nvme_pci_complete_batch() nvme_complete_batch() blk_mq_end_request_batch() blk_complete_request() // called on a DM clone request bio_endio() // first free of all clone bios ... rq->end_io() // end_clone_request() dm_complete_request(tio->orig) dm_softirq_done() dm_done() dm_end_request() blk_rq_unprep_clone() // second free of clone bios Fix this by clearing the clone request's bio pointer when the last cloned bio completes, ensuring that later teardown paths do not attempt to free already-released bios.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43312", "url": "https://ubuntu.com/security/CVE-2026-43312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov5647: Initialize subdev before controls In ov5647_init_controls() we call v4l2_get_subdevdata, but it is initialized by v4l2_i2c_subdev_init() in the probe, which currently happens after init_controls(). This can result in a segfault if the error condition is hit, and we try to access i2c_client, so fix the order.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43182", "url": "https://ubuntu.com/security/CVE-2026-43182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ccs: Avoid possible division by zero Calculating maximum M for scaler configuration involves dividing by MIN_X_OUTPUT_SIZE limit register's value. Albeit the value is presumably non-zero, the driver was missing the check it in fact was. Fix this.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43246", "url": "https://ubuntu.com/security/CVE-2026-43246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c/tw9906: Fix potential memory leak in tw9906_probe() In one of the error paths in tw9906_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43218", "url": "https://ubuntu.com/security/CVE-2026-43218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c/tw9903: Fix potential memory leak in tw9903_probe() In one of the error paths in tw9903_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43135", "url": "https://ubuntu.com/security/CVE-2026-43135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: Add missing unmap in snd_cx23885_hw_params() In error path, add cx23885_alsa_dma_unmap() to release the resource acquired by cx23885_alsa_dma_map().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43257", "url": "https://ubuntu.com/security/CVE-2026-43257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx88: Add missing unmap in snd_cx88_hw_params() In error path, add cx88_alsa_dma_unmap() to release resource acquired by cx88_alsa_dma_map().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43231", "url": "https://ubuntu.com/security/CVE-2026-43231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-keene: fix memory leak in error path Fix a memory leak in usb_keene_probe(). The v4l2 control handler is initialized and controls are added, but if v4l2_device_register() or video_register_device() fails afterward, the handler was never freed, leaking memory. Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensure the control handler is properly freed for all error paths after it is initialized.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43136", "url": "https://ubuntu.com/security/CVE-2026-43136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Check maxfield in hidpp_get_report_length() Do not crash when a report has no fields. Fake USB gadgets can send their own HID report descriptors and can define report structures without valid fields. This can be used to crash the kernel over USB.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43251", "url": "https://ubuntu.com/security/CVE-2026-43251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: prodikeys: Check presence of pm->input_ep82 Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, pm->input_ep82 stays NULL, which leads to a crash later. This does not happen with the real device, but can be provoked by imposing as one.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43140", "url": "https://ubuntu.com/security/CVE-2026-43140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: Do not crash on missing msc->input Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, msc->input stays NULL, leading to a crash at a later time. Detect this condition in the input_configured() hook and reject the device. This is not supposed to happen with actual magic mouse devices, but can be provoked by imposing as a magic mouse USB device.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43152", "url": "https://ubuntu.com/security/CVE-2026-43152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hid-pl: handle probe errors Errors in init must be reported back or we'll follow a NULL pointer the first time FF is used.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43315", "url": "https://ubuntu.com/security/CVE-2026-43315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeeding Drop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failing as it is trivially easy to trigger from userspace by modifying CPUID after loading CR3. E.g. modifying the state restoration selftest like so: --- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main(int argc, char *argv[]) /* Restore state in a new VM. */ vcpu = vm_recreate_with_one_vcpu(vm); - vcpu_load_state(vcpu, state); + + if (stage == 4) { + state->sregs.cr3 = BIT(44); + vcpu_load_state(vcpu, state); + + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36); + __vcpu_nested_state_set(vcpu, &state->nested); + } else { + vcpu_load_state(vcpu, state); + } /* * Restore XSAVE state in a dummy vCPU, first without doing generates: WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd] Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm] CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd] Call Trace: kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm] kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Simply delete the WARN instead of trying to prevent userspace from shoving \"illegal\" state into CR3. For better or worse, KVM's ABI allows userspace to set CPUID after SREGS, and vice versa, and KVM is very permissive when it comes to guest CPUID. I.e. attempting to enforce the virtual CPU model when setting CPUID could break userspace. Given that the WARN doesn't provide any meaningful protection for KVM or benefit for userspace, simply drop it even though the odds of breaking userspace are minuscule. Opportunistically delete a spurious newline.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43270", "url": "https://ubuntu.com/security/CVE-2026-43270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove() In mtk_mdp_probe(), vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43207", "url": "https://ubuntu.com/security/CVE-2026-43207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix error handling in probe function Add mtk_mdp_unregister_m2m_device() on the error handling path to prevent resource leak. Add check for the return value of vpu_get_plat_device() to prevent null pointer dereference. And vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43132", "url": "https://ubuntu.com/security/CVE-2026-43132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: correctly handle dm_bufio_client_create() failure If either of the calls to dm_bufio_client_create() in verity_fec_ctr() fails, then dm_bufio_client_destroy() is later called with an ERR_PTR() argument. That causes a crash. Fix this.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2025-71274", "url": "https://ubuntu.com/security/CVE-2025-71274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: core: fix race in driver_override_show() and use core helper The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string_attr macro with explicit show and store functions. The new driver_override_store uses the standard driver_set_override helper. Since the introduction of driver_set_override, the comments in include/linux/rpmsg.h have stated that this helper must be used to set or clear driver_override, but the implementation was not updated until now. Because driver_set_override modifies and frees the string while holding the device_lock, the new driver_override_show now correctly holds the device_lock during the read operation to prevent the race. Additionally, since rpmsg_string_attr has only ever been used for driver_override, removing the macro simplifies the code.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43233", "url": "https://ubuntu.com/security/CVE-2026-43233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: fix OOB read in decode_choice() In decode_choice(), the boundary check before get_len() uses the variable `len`, which is still 0 from its initialization at the top of the function: unsigned int type, ext, len = 0; ... if (ext || (son->attr & OPEN)) { BYTE_ALIGN(bs); if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */ return H323_ERROR_BOUND; len = get_len(bs); /* OOB read */ When the bitstream is exactly consumed (bs->cur == bs->end), the check nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent get_len() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well. This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nf_conntrack_h323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer. Fix this by checking for 2 bytes (the maximum that get_len() may read) instead of the uninitialized `len`. This matches the pattern used at every other get_len() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43205", "url": "https://ubuntu.com/security/CVE-2026-43205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: validate num_ifs to prevent out-of-bounds write The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes() but never validates it against DPSW_MAX_IF (64). This value controls iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices into the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reports num_ifs >= 64, the loop can write past the array bounds. Add a bound check for num_ifs in dpaa2_switch_init(). dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all ports match the flood filter, the loop fills all 64 slots and the control interface write overflows by one entry. The check uses >= because num_ifs == DPSW_MAX_IF is also functionally broken. build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ...", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43194", "url": "https://ubuntu.com/security/CVE-2026-43194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: consume xmit errors of GSO frames udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min. These tests use veth to simulate GRO. They attach a trivial (\"return XDP_PASS;\") XDP program to the veth to force TSO off and NAPI on. Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]). In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck. The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok | ok ok ok \\\\ \t\t\t snd_nxt \"x\" means packet lost by veth, and \"ok\" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent. So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above). Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely. We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-\"networks\" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix? Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link).", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43156", "url": "https://ubuntu.com/security/CVE-2026-43156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: enable basic endpoint checking pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors: - usb_rcvbulkpipe(dev, 1) for RX data - usb_sndbulkpipe(dev, 2) for TX data - usb_rcvintpipe(dev, 3) for status interrupts A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes. Add a pegasus_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion. Similar fix to - commit 90b7f2961798 (\"net: usb: rtl8150: enable basic endpoint checking\") - commit 9e7021d2aeae (\"net: usb: catc: enable basic endpoint checking\")", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43232", "url": "https://ubuntu.com/security/CVE-2026-43232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets When the FarSync T-series card is being detached, the fst_card_info is deallocated in fst_remove_one(). However, the fst_tx_task or fst_int_task may still be running or pending, leading to use-after-free bugs when the already freed fst_card_info is accessed in fst_process_tx_work_q() or fst_process_int_work_q(). A typical race condition is depicted below: CPU 0 (cleanup) | CPU 1 (tasklet) | fst_start_xmit() fst_remove_one() | tasklet_schedule() unregister_hdlc_device()| | fst_process_tx_work_q() //handler kfree(card) //free | do_bottom_half_tx() | card-> //use The following KASAN trace was captured: ================================================================== BUG: KASAN: slab-use-after-free in do_bottom_half_tx+0xb88/0xd00 Read of size 4 at addr ffff88800aad101c by task ksoftirqd/3/32 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcb/0x5d0 ? do_bottom_half_tx+0xb88/0xd00 kasan_report+0xb8/0xf0 ? do_bottom_half_tx+0xb88/0xd00 do_bottom_half_tx+0xb88/0xd00 ? _raw_spin_lock_irqsave+0x85/0xe0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx___hrtimer_run_queues+0x10/0x10 fst_process_tx_work_q+0x67/0x90 tasklet_action_common+0x1fa/0x720 ? hrtimer_interrupt+0x31f/0x780 handle_softirqs+0x176/0x530 __irq_exit_rcu+0xab/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 41 on cpu 3 at 72.330843s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 __kasan_kmalloc+0x7f/0x90 fst_add_one+0x1a5/0x1cd0 local_pci_probe+0xdd/0x190 pci_device_probe+0x341/0x480 really_probe+0x1c6/0x6a0 __driver_probe_device+0x248/0x310 driver_probe_device+0x48/0x210 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x101/0x190 __device_attach+0x198/0x3a0 device_initial_probe+0x78/0xa0 pci_bus_add_device+0x81/0xc0 pci_bus_add_devices+0x7e/0x190 enable_slot+0x9b9/0x1130 acpiphp_check_bridge.part.0+0x2e1/0x460 acpiphp_hotplug_notify+0x36c/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... Freed by task 41 on cpu 1 at 75.138639s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x135/0x410 fst_remove_one+0x2ca/0x540 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0x364/0x530 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device+0xd/0x20 disable_slot+0x116/0x260 acpiphp_disable_and_eject_slot+0x4b/0x190 acpiphp_hotplug_notify+0x230/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... The buggy address belongs to the object at ffff88800aad1000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 28 bytes inside of freed 1024-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xaad0 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x100000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000003 ffffea00002ab401 00000000ffffffff 00000000ffffffff head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88800aad0f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800aad0f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800aad1000: fa fb ---truncated---", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43134", "url": "https://ubuntu.com/security/CVE-2026-43134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ This adds a check for encryption key size upon receiving L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAP_CR_LE_BAD_KEY_SIZE.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43180", "url": "https://ubuntu.com/security/CVE-2026-43180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls netif_stop_queue() and netif_wake_queue(). These are TX queue flow control functions unrelated to RX multicast configuration. The premature netif_wake_queue() can re-enable TX while tx_urb is still in-flight, leading to a double usb_submit_urb() on the same URB: kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); } kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done } kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active } This triggers the WARN in usb_submit_urb(): \"URB submitted while active\" This is a similar class of bug fixed in rtl8150 by - commit 958baf5eaee3 (\"net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast\"). Also kaweth_set_rx_mode() is already functionally broken, the real set_rx_mode action is performed by kaweth_async_set_rx_mode(), which in turn is not a no-op only at ndo_open() time.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43139", "url": "https://ubuntu.com/security/CVE-2026-43139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix uninitialized saddr in xfrm6_get_saddr() xfrm6_get_saddr() does not check the return value of ipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6_get_saddr() still returns 0 (success). This causes the caller xfrm_tmpl_resolve_one() to use the uninitialized address in xfrm_state_find(), triggering KMSAN warning: ===================================================== BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940 xfrm_state_find+0x2424/0xa940 xfrm_resolve_and_create_bundle+0x906/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 xfrm_lookup_route+0x63/0x2b0 ip_route_output_flow+0x1ce/0x270 udp_sendmsg+0x2ce1/0x3400 inet_sendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64_sys_sendto+0x130/0x200 x64_sys_call+0x332b/0x3e70 do_syscall_64+0xd3/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable tmp.i.i created at: xfrm_resolve_and_create_bundle+0x3e3/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 ===================================================== Fix by checking the return value of ipv6_dev_get_saddr() and propagating the error.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43141", "url": "https://ubuntu.com/security/CVE-2026-43141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut Number of MW LUTs depends on NTB configuration and can be set to zero, in such scenario rounddown_pow_of_two will cause undefined behaviour and should not be performed. This patch ensures that rounddown_pow_of_two is called on valid value.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43241", "url": "https://ubuntu.com/security/CVE-2026-43241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access Number of MW LUTs depends on NTB configuration and can be set to MAX_MWS, This patch protects against invalid index out of bounds access to mw_sizes When invalid access print message to user that configuration is not valid.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43279", "url": "https://ubuntu.com/security/CVE-2026-43279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Add sanity check for OOB writes at silencing At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2025-71267", "url": "https://ubuntu.com/security/CVE-2025-71267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an ATTR_LIST attribute indicates a zero data size while the driver allocates memory for it. When ntfs_load_attr_list() processes a resident ATTR_LIST with data_size set to zero, it still allocates memory because of al_aligned(0). This creates an inconsistent state where ni->attr_list.size is zero, but ni->attr_list.le is non-null. This causes ni_enum_attr_ex to incorrectly assume that no attribute list exists and enumerates only the primary MFT record. When it finds ATTR_LIST, the code reloads it and restarts the enumeration, repeating indefinitely. The mount operation never completes, hanging the kernel thread. This patch adds validation to ensure that data_size is non-zero before memory allocation. When a zero-sized ATTR_LIST is detected, the function returns -EINVAL, preventing a DoS vulnerability.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2025-71265", "url": "https://ubuntu.com/security/CVE-2025-71265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an attribute header indicates an empty run list, while directory entries reference it as containing actual data. In NTFS, setting evcn=-1 with svcn=0 is a valid way to represent an empty run list, and run_unpack() correctly handles this by checking if evcn + 1 equals svcn and returning early without parsing any run data. However, this creates a problem when there is metadata inconsistency, where the attribute header claims to be empty (evcn=-1) but the caller expects to read actual data. When run_unpack() immediately returns success upon seeing this condition, it leaves the runs_tree uninitialized with run->runs as a NULL. The calling function attr_load_runs_range() assumes that a successful return means that the runs were loaded and sets clen to 0, expecting the next run_lookup_entry() call to succeed. Because runs_tree remains uninitialized, run_lookup_entry() continues to fail, and the loop increments vcn by zero (vcn += 0), leading to an infinite loop. This patch adds a retry counter to detect when run_lookup_entry() fails consecutively after attr_load_runs_vcn(). If the run is still not found on the second attempt, it indicates corrupted metadata and returns -EINVAL, preventing the Denial-of-Service (DoS) vulnerability.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2025-71266", "url": "https://ubuntu.com/security/CVE-2025-71266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: check return value of indx_find to avoid infinite loop We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed dentry in the ntfs3 filesystem can cause the kernel to hang during the lookup operations. By setting the HAS_SUB_NODE flag in an INDEX_ENTRY within a directory's INDEX_ALLOCATION block and manipulating the VCN pointer, an attacker can cause the indx_find() function to repeatedly read the same block, allocating 4 KB of memory each time. The kernel lacks VCN loop detection and depth limits, causing memory exhaustion and an OOM crash. This patch adds a return value check for fnd_push() to prevent a memory exhaustion vulnerability caused by infinite loops. When the index exceeds the size of the fnd->nodes array, fnd_push() returns -EINVAL. The indx_find() function checks this return value and stops processing, preventing further memory allocation.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-43225", "url": "https://ubuntu.com/security/CVE-2026-43225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix memory leak on failure path cfg80211_inform_bss_frame() may return NULL on failure. In that case, the allocated buffer 'buf' is not freed and the function returns early, leading to potential memory leak. Fix this by ensuring that 'buf' is freed on both success and failure paths.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43230", "url": "https://ubuntu.com/security/CVE-2026-43230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: Clear reconnect pending bit When canceling the reconnect worker, care must be taken to reset the reconnect-pending bit. If the reconnect worker has not yet been scheduled before it is canceled, the reconnect-pending bit will stay on forever.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43296", "url": "https://ubuntu.com/security/CVE-2026-43296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Workaround SQM/PSE stalls by disabling sticky NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated. work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21) These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43226", "url": "https://ubuntu.com/security/CVE-2026-43226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: No shortcut out of RDS_CONN_ERROR RDS connections carry a state \"rds_conn_path::cp_state\" and transitions from one state to another and are conditional upon an expected state: \"rds_conn_path_transition.\" There is one exception to this conditionality, which is \"RDS_CONN_ERROR\" that can be enforced by \"rds_conn_path_drop\" regardless of what state the condition is currently in. But as soon as a connection enters state \"RDS_CONN_ERROR\", the connection handling code expects it to go through the shutdown-path. The RDS/TCP multipath changes added a shortcut out of \"RDS_CONN_ERROR\" straight back to \"RDS_CONN_CONNECTING\" via \"rds_tcp_accept_one_path\" (e.g. after \"rds_tcp_state_change\"). A subsequent \"rds_tcp_reset_callbacks\" can then transition the state to \"RDS_CONN_RESETTING\" with a shutdown-worker queued. That'll trip up \"rds_conn_init_shutdown\", which was never adjusted to handle \"RDS_CONN_RESETTING\" and subsequently drops the connection with the dreaded \"DR_INV_CONN_STATE\", which leaves \"RDS_SHUTDOWN_WORK_QUEUED\" on forever. So we do two things here: a) Don't shortcut \"RDS_CONN_ERROR\", but take the longer path through the shutdown code. b) Add \"RDS_CONN_RESETTING\" to the expected states in \"rds_conn_init_shutdown\" so that we won't error out and get stuck, if we ever hit weird state transitions like this again.\"", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43190", "url": "https://ubuntu.com/security/CVE-2026-43190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_tcpmss: check remaining length before reading optlen Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload).", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43255", "url": "https://ubuntu.com/security/CVE-2026-43255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix WARNING in usb_tx_block The function usb_tx_block() submits cardp->tx_urb without ensuring that any previous transmission on this URB has completed. If a second call occurs while the URB is still active (e.g. during rapid firmware loading), usb_submit_urb() detects the active state and triggers a warning: 'URB submitted while active'. Fix this by enforcing serialization: call usb_kill_urb() before submitting the new request. This ensures the URB is idle and safe to reuse.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43314", "url": "https://ubuntu.com/security/CVE-2026-43314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: remove fake timeout to avoid leak request Since commit 15f73f5b3e59 (\"blk-mq: move failure injection out of blk_mq_complete_request\"), drivers are responsible for calling blk_should_fake_timeout() at appropriate code paths and opportunities. However, the dm driver does not implement its own timeout handler and relies on the timeout handling of its slave devices. If an io-timeout-fail error is injected to a dm device, the request will be leaked and never completed, causing tasks to hang indefinitely. Reproduce: 1. prepare dm which has iscsi slave device 2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times 3. read/write dm 4. iscsiadm -m node -u Result: hang task like below [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds. [ 862.244133] Tainted: G E 6.19.0-rc1+ #51 [ 862.244337] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000 [ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi] [ 862.245264] Call Trace: [ 862.245587] [ 862.245814] __schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120 [ 862.247688] elevator_change+0x16d/0x460 [ 862.247893] elevator_set_none+0x87/0xf0 [ 862.248798] blk_unregister_queue+0x12e/0x2a0 [ 862.248995] __del_gendisk+0x231/0x7e0 [ 862.250143] del_gendisk+0x12f/0x1d0 [ 862.250339] sd_remove+0x85/0x130 [sd_mod] [ 862.250650] device_release_driver_internal+0x36d/0x530 [ 862.250849] bus_remove_device+0x1dd/0x3f0 [ 862.251042] device_del+0x38a/0x930 [ 862.252095] __scsi_remove_device+0x293/0x360 [ 862.252291] scsi_remove_target+0x486/0x760 [ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi] [ 862.252886] process_one_work+0x633/0xe50 [ 862.253101] worker_thread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] ret_from_fork+0x2a6/0x470 [ 862.255852] ret_from_fork_asm+0x1a/0x30 [ 862.256037] Remove the blk_should_fake_timeout() check from dm, as dm has no native timeout handling and should not attempt to fake timeouts.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-71292", "url": "https://ubuntu.com/security/CVE-2025-71292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: nlink overflow in jfs_rename If nlink is maximal for a directory (-1) and inside that directory you perform a rename for some child directory (not moving from the parent), then the nlink of the first directory is first incremented and later decremented. Normally this is fine, but when nlink = -1 this causes a wrap around to 0, and then drop_nlink issues a warning. After applying the patch syzbot no longer issues any warnings. I also ran some basic fs tests to look for any regressions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43236", "url": "https://ubuntu.com/security/CVE-2026-43236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying the atmel_hlcdc_plane state structure without properly duplicating the drm_plane_state. In particular, state->commit remained set to the old state commit, which can lead to a use-after-free in the next drm_atomic_commit() call. Fix this by calling __drm_atomic_helper_duplicate_plane_state(), which correctly clones the base drm_plane_state (including the ->commit pointer). It has been seen when closing and re-opening the device node while another DRM client (e.g. fbdev) is still attached: ============================================================================= BUG kmalloc-64 (Not tainted): Poison overwritten ----------------------------------------------------------------------------- 0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0 pid=29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28 Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0 pid=169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0 flags=0x200(workingset|zone=0) Object 0xc611b340 @offset=832 fp=0xc611b7c0", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43269", "url": "https://ubuntu.com/security/CVE-2026-43269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback After several commits, the slab memory increases. Some drm_crtc_commit objects are not freed. The atomic_destroy_state callback only put the framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function to put all the objects that are no longer needed. It has been seen after hours of usage of a graphics application or using kmemleak: unreferenced object 0xc63a6580 (size 64): comm \"egt_basic\", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleak_alloc+0x34/0x3c __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43287", "url": "https://ubuntu.com/security/CVE-2026-43287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Account property blob allocations to memcg DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory. Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM. Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43183", "url": "https://ubuntu.com/security/CVE-2026-43183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx25821: Fix a resource leak in cx25821_dev_setup() Add release_mem_region() if ioremap() fails to release the memory region obtained by cx25821_get_resources().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43316", "url": "https://ubuntu.com/security/CVE-2026-43316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: solo6x10: Check for out of bounds chip_id Clang with CONFIG_UBSAN_SHIFT=y noticed a condition where a signed type (literal \"1\" is an \"int\") could end up being shifted beyond 32 bits, so instrumentation was added (and due to the double is_tw286x() call seen via inlining), Clang decides the second one must now be undefined behavior and elides the rest of the function[1]. This is a known problem with Clang (that is still being worked on), but we can avoid the entire problem by actually checking the existing max chip ID, and now there is no runtime instrumentation added at all since everything is known to be within bounds. Additionally use an unsigned value for the shift to remove the instrumentation even without the explicit bounds checking. [hverkuil: fix checkpatch warning for is_tw286x]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43223", "url": "https://ubuntu.com/security/CVE-2026-43223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix URB leak in pvr2_send_request_ex When pvr2_send_request_ex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2_send_request_ex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usb_submit_urb(). Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43302", "url": "https://ubuntu.com/security/CVE-2026-43302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Set DMA segment size to avoid debug warnings When using V3D rendering with CONFIG_DMA_API_DEBUG enabled, the kernel occasionally reports a segment size mismatch. This is because 'max_seg_size' is not set. The kernel defaults to 64K. setting 'max_seg_size' to the maximum will prevent 'debug_dma_map_sg()' from complaining about the over-mapping of the V3D segment length. DMA-API: v3d 1002000000.v3d: mapping sg segment longer than device claims to support [len=8290304] [max=65536] WARNING: CPU: 0 PID: 493 at kernel/dma/debug.c:1179 debug_dma_map_sg+0x330/0x388 CPU: 0 UID: 0 PID: 493 Comm: Xorg Not tainted 6.12.53-yocto-standard #1 Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_dma_map_sg+0x330/0x388 lr : debug_dma_map_sg+0x330/0x388 sp : ffff8000829a3ac0 x29: ffff8000829a3ac0 x28: 0000000000000001 x27: ffff8000813fe000 x26: ffffc1ffc0000000 x25: ffff00010fdeb760 x24: 0000000000000000 x23: ffff8000816a9bf0 x22: 0000000000000001 x21: 0000000000000002 x20: 0000000000000002 x19: ffff00010185e810 x18: ffffffffffffffff x17: 69766564206e6168 x16: 74207265676e6f6c x15: 20746e656d676573 x14: 20677320676e6970 x13: 5d34303334393134 x12: 0000000000000000 x11: 00000000000000c0 x10: 00000000000009c0 x9 : ffff8000800e0b7c x8 : ffff00010a315ca0 x7 : ffff8000816a5110 x6 : 0000000000000001 x5 : 000000000000002b x4 : 0000000000000002 x3 : 0000000000000008 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00010a315280 Call trace: debug_dma_map_sg+0x330/0x388 __dma_map_sg_attrs+0xc0/0x278 dma_map_sgtable+0x30/0x58 drm_gem_shmem_get_pages_sgt+0xb4/0x140 v3d_bo_create_finish+0x28/0x130 [v3d] v3d_create_bo_ioctl+0x54/0x180 [v3d] drm_ioctl_kernel+0xc8/0x140 drm_ioctl+0x2d4/0x4d8", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43124", "url": "https://ubuntu.com/security/CVE-2026-43124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore: ram_core: fix incorrect success return when vmap() fails In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43227", "url": "https://ubuntu.com/security/CVE-2026-43227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/sh_tmu: Always leave device running after probe The TMU device can be used as both a clocksource and a clockevent provider. The driver tries to be smart and power itself on and off, as well as enabling and disabling its clock when it's not in operation. This behavior is slightly altered if the TMU is used as an early platform device in which case the device is left powered on after probe, but the clock is still enabled and disabled at runtime. This has worked for a long time, but recent improvements in PREEMPT_RT and PROVE_LOCKING have highlighted an issue. As the TMU registers itself as a clockevent provider, clockevents_register_device(), it needs to use raw spinlocks internally as this is the context of which the clockevent framework interacts with the TMU driver. However in the context of holding a raw spinlock the TMU driver can't really manage its power state or clock with calls to pm_runtime_*() and clk_*() as these calls end up in other platform drivers using regular spinlocks to control power and clocks. This mix of spinlock contexts trips a lockdep warning. ============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90 For non-PREEMPT_RT builds this is not really an issue, but for PREEMPT_RT builds where normal spinlocks can sleep this might be an issue. Be cautious and always leave the power and clock running after probe.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43313", "url": "https://ubuntu.com/security/CVE-2026-43313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4() In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDE device and then reassigned an ISA device: dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...); dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...); If the first lookup succeeds but the second fails, dev becomes NULL. This leads to a potential null-pointer dereference when dev_dbg() is called: if (errata.piix4.bmisx) dev_dbg(&dev->dev, ...); To prevent this, use two temporary pointers and retrieve each device independently, avoiding overwriting dev with a possible NULL value. [ rjw: Subject adjustment, added an empty code line ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43266", "url": "https://ubuntu.com/security/CVE-2026-43266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EFI/CPER: don't go past the ARM processor CPER record buffer There's a logic inside GHES/CPER to detect if the section_length is too small, but it doesn't detect if it is too big. Currently, if the firmware receives an ARM processor CPER record stating that a section length is big, kernel will blindly trust section_length, producing a very long dump. For instance, a 67 bytes record with ERR_INFO_NUM set 46198 and section length set to 854918320 would dump a lot of data going a way past the firmware memory-mapped area. Fix it by adding a logic to prevent it to go past the buffer if ERR_INFO_NUM is too big, making it report instead: \t[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 \t[Hardware Error]: event severity: recoverable \t[Hardware Error]: Error 0, type: recoverable \t[Hardware Error]: section_type: ARM processor error \t[Hardware Error]: MIDR: 0xff304b2f8476870a \t[Hardware Error]: section length: 854918320, CPER size: 67 \t[Hardware Error]: section length is too big \t[Hardware Error]: firmware-generated error record is incorrect \t[Hardware Error]: ERR_INFO_NUM is 46198 [ rjw: Subject and changelog tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43277", "url": "https://ubuntu.com/security/CVE-2026-43277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: APEI/GHES: ensure that won't go past CPER allocated record The logic at ghes_new() prevents allocating too large records, by checking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB). Yet, the allocation is done with the actual number of pages from the CPER bios table location, which can be smaller. Yet, a bad firmware could send data with a different size, which might be bigger than the allocated memory, causing an OOPS: Unable to handle kernel paging request at virtual address fff00000f9b40000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000 [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 Workqueue: kacpi_notify acpi_os_execute_deferred pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : hex_dump_to_buffer+0x30c/0x4a0 lr : hex_dump_to_buffer+0x328/0x4a0 sp : ffff800080e13880 x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083 x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004 x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083 x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010 x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008 x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020 x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000 x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008 Call trace: hex_dump_to_buffer+0x30c/0x4a0 (P) print_hex_dump+0xac/0x170 cper_estatus_print_section+0x90c/0x968 cper_estatus_print+0xf0/0x158 __ghes_print_estatus+0xa0/0x148 ghes_proc+0x1bc/0x220 ghes_notify_hed+0x5c/0xb8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x80 acpi_hed_notify+0x28/0x40 acpi_ev_notify_dispatch+0x50/0x80 acpi_os_execute_deferred+0x24/0x48 process_one_work+0x15c/0x3b0 worker_thread+0x2d0/0x400 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44) ---[ end trace 0000000000000000 ]--- Prevent that by taking the actual allocated are into account when checking for CPER length. [ rjw: Subject tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43171", "url": "https://ubuntu.com/security/CVE-2026-43171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EFI/CPER: don't dump the entire memory region The current logic at cper_print_fw_err() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory. The end result can be: - the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region. Fix it by checking if the section length is too small before doing a hex dump. [ rjw: Subject tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43184", "url": "https://ubuntu.com/security/CVE-2026-43184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rnbd-srv: Zero the rsp buffer before using it Before using the data buffer to send back the response message, zero it completely. This prevents any stray bytes to be picked up by the client side when there the message is exchanged between different protocol versions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43261", "url": "https://ubuntu.com/security/CVE-2026-43261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Add support for TSV110 Spectre-BHB mitigation The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43262", "url": "https://ubuntu.com/security/CVE-2026-43262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fiemap page fault fix In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault. Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary. Fixes xfstest generic/742.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43209", "url": "https://ubuntu.com/security/CVE-2026-43209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: minix: Add required sanity checking to minix_check_superblock() The fs/minix implementation of the minix filesystem does not currently support any other value for s_log_zone_size than 0. This is also the only value supported in util-linux; see mkfs.minix.c line 511. In addition, this patch adds some sanity checking for the other minix superblock fields, and moves the minix_blocks_needed() checks for the zmap and imap also to minix_check_super_block(). This also closes a related syzbot bug report.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43268", "url": "https://ubuntu.com/security/CVE-2026-43268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: pretend special inodes as regular files Since commit af153bb63a33 (\"vfs: catch invalid modes in may_open()\") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23241", "url": "https://ubuntu.com/security/CVE-2026-23241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: add missing syscalls to read class The \"at\" variant of getxattr() and listxattr() are missing from the audit read class. Calling getxattrat() or listxattrat() on a file to read its extended attributes will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds missing syscalls to the audit read class.", "cve_priority": "medium", "cve_public_date": "2026-03-17 10:16:00 UTC" }, { "cve": "CVE-2025-71239", "url": "https://ubuntu.com/security/CVE-2025-71239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: add fchmodat2() to change attributes class fchmodat2(), introduced in version 6.6 is currently not in the change attribute class of audit. Calling fchmodat2() to change a file attribute in the same fashion than chmod() or fchmodat() will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds fchmodat2() to the change attributes class.", "cve_priority": "medium", "cve_public_date": "2026-03-17 10:15:00 UTC" }, { "cve": "CVE-2026-45964", "url": "https://ubuntu.com/security/CVE-2026-45964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path Commit 5940d1cf9f42 (\"SUNRPC: Rebalance a kref in auth_gss.c\") added a kref_get(&gss_auth->kref) call to balance the gss_put_auth() done in gss_release_msg(), but forgot to add a corresponding kref_put() on the error path when kstrdup_const() fails. If service_name is non-NULL and kstrdup_const() fails, the function jumps to err_put_pipe_version which calls put_pipe_version() and kfree(gss_msg), but never releases the gss_auth reference. This leads to a kref leak where the gss_auth structure is never freed. Add a forward declaration for gss_free_callback() and call kref_put() in the err_put_pipe_version error path to properly release the reference taken earlier.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45870", "url": "https://ubuntu.com/security/CVE-2026-45870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: auth_gss: fix memory leaks in XDR decoding error paths The gssx_dec_ctx(), gssx_dec_status(), and gssx_dec_name() functions allocate memory via gssx_dec_buffer(), which calls kmemdup(). When a subsequent decode operation fails, these functions return immediately without freeing previously allocated buffers, causing memory leaks. The leak in gssx_dec_ctx() is particularly relevant because the caller (gssp_accept_sec_context_upcall) initializes several buffer length fields to non-zero values, resulting in memory allocation: struct gssx_ctx rctxh = { .exported_context_token.len = GSSX_max_output_handle_sz, .mech.len = GSS_OID_MAX_LEN, .src_name.display_name.len = GSSX_max_princ_sz, .targ_name.display_name.len = GSSX_max_princ_sz }; If, for example, gssx_dec_name() succeeds for src_name but fails for targ_name, the memory allocated for exported_context_token, mech, and src_name.display_name remains unreferenced and cannot be reclaimed. Add error handling with goto-based cleanup to free any previously allocated buffers before returning an error.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45948", "url": "https://ubuntu.com/security/CVE-2026-45948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leak in ext4_ext_shift_extents() In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4_find_extent(), leading to a memory leak. Fix this by jumping to the out label to ensure the path is properly released.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45912", "url": "https://ubuntu.com/security/CVE-2026-45912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't cache extent during splitting extent Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful. Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, when ext4_split_extent_at() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4_find_extent() and ext4_cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting. In adition, if the unwritten extent cache is not shrunk during the splitting, ext4_cache_extents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46250", "url": "https://ubuntu.com/security/CVE-2026-46250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: MIPS: Work around LLVM bug when gp is used as global register variable On MIPS, __current_thread_info is defined as global register variable locating in $gp, and is simply assigned with new address during kernel relocation. This however is broken with LLVM, which always restores $gp if it finds $gp is clobbered in any form, including when intentionally through a global register variable. This is against GCC's documentation[1], which requires a callee-saved register used as global register variable not to be restored if it's clobbered. As a result, $gp will continue to point to the unrelocated kernel after the epilog of relocate_kernel(), leading to an early crash in init_idle, [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY [ 0.000000] Tainted: [W]=WARN [ 0.000000] Hardware name: loongson,loongson64v-4core-virtio [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240 [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001 [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002 [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80 [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80 [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90 [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90 [ 0.000000] Hi : 0000000000000000 [ 0.000000] Lo : 0000000000000000 [ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270 [ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270 [ 0.000000] Status: 540000e2\tKX SX UX KERNEL EXL [ 0.000000] Cause : 00000008 (ExcCode 02) [ 0.000000] BadVA : 0000000000000000 [ 0.000000] PrId : 00006305 (ICT Loongson-3) [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000) [ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528 [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000 [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258 [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98 [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [] init_idle+0x130/0x270 [ 0.000000] [] sched_init+0x5c8/0x6c0 [ 0.000000] [] start_kernel+0x27c/0x7a8 This bug has been reported to LLVM[2] and affects version from (at least) 18 to 21. Let's work around this by using inline assembly to assign $gp before a fix is widely available.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45974", "url": "https://ubuntu.com/security/CVE-2026-45974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not found If btrfs_search_slot_for_read() returns 1, it means we did not find any key greater than or equals to the key we asked for, meaning we have reached the end of the tree and therefore the path is not valid. If this happens we need to break out of the loop and stop, instead of continuing and accessing an invalid path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45965", "url": "https://ubuntu.com/security/CVE-2026-45965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix invalid deref of rawdata when export_binary is unset If the export_binary parameter is disabled on runtime, profiles that were loaded before that will still have their rawdata stored in apparmorfs, with a symbolic link to the rawdata on the policy directory. When one of those profiles are replaced, the rawdata is set to NULL, but when trying to resolve the symbolic links to rawdata for that profile, it will try to dereference profile->rawdata->name when profile->rawdata is now NULL causing an oops. Fix it by checking if rawdata is set. [ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088 [ 168.657420] #PF: supervisor read access in kernel mode [ 168.660619] #PF: error_code(0x0000) - not-present page [ 168.663613] PGD 0 P4D 0 [ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI [ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary) [ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330 [ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8 [ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282 [ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158 [ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80 [ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000 [ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80 [ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0 [ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000 [ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0 [ 168.701696] Call Trace: [ 168.702325] [ 168.702995] rawdata_get_link_data+0x1c/0x30 [ 168.704145] vfs_readlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64_sys_readlink+0x1e/0x30 [ 168.708653] x64_sys_call+0x1d77/0x26b0 [ 168.709525] do_syscall_64+0x81/0x500 [ 168.710348] ? do_statx+0x72/0xb0 [ 168.711109] ? putname+0x3e/0x80 [ 168.711845] ? __x64_sys_statx+0xb7/0x100 [ 168.712711] ? x64_sys_call+0x10fc/0x26b0 [ 168.713577] ? do_syscall_64+0xbf/0x500 [ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0 [ 168.715404] ? irqentry_exit+0xb2/0x740 [ 168.716359] ? exc_page_fault+0x90/0x1b0 [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45848", "url": "https://ubuntu.com/security/CVE-2026-45848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix NULL sock in aa_sock_file_perm Deal with the potential that sock and sock-sk can be NULL during socket setup or teardown. This could lead to an oops. The fix for NULL pointer dereference in __unix_needs_revalidation shows this is at least possible for af_unix sockets. While the fix for af_unix sockets applies for newer mediation this is still the fall back path for older af_unix mediation and other sockets, so ensure it is covered.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45970", "url": "https://ubuntu.com/security/CVE-2026-45970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: alb: fix UAF in rlb_arp_recv during bond up/down The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN. However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag. [ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? __pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry. Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45847", "url": "https://ubuntu.com/security/CVE-2026-45847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: remove WARN_ON_ONCE when accessing forward path array Although unlikely, recent support for IPIP tunnels increases chances of reaching this WARN_ON_ONCE if userspace manages to build a sufficiently long forward path. Remove it.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45890", "url": "https://ubuntu.com/security/CVE-2026-45890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen-netback: reject zero-queue configuration from guest A malicious or buggy Xen guest can write \"0\" to the xenbus key \"multi-queue-num-queues\". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range(). On systems with panic_on_warn=1, this allows a guest-to-host denial of service. The Xen network interface specification requires the queue count to be \"greater than zero\". Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45968", "url": "https://ubuntu.com/security/CVE-2026-45968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuidle: Skip governor when only one idle state is available On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash. [ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668 Fix this by adding a bail-out in cpuidle_select() that returns state 0 directly when state_count <= 1, bypassing the governor and keeping the tick running.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45935", "url": "https://ubuntu.com/security/CVE-2026-45935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot In the 'DeleteIndexEntryRoot' case of the 'do_action' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking. Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize); It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to size_t for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow. This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45864", "url": "https://ubuntu.com/security/CVE-2026-45864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent infinite loops caused by the next valid being the same When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1]. Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this. [1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45868", "url": "https://ubuntu.com/security/CVE-2026-45868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix refcount leak in pcs_add_gpio_func() of_parse_phandle_with_args() returns a device_node pointer with refcount incremented in gpiospec.np. The loop iterates through all phandles but never releases the reference, causing a refcount leak on each iteration. Add of_node_put() calls to release the reference after extracting the needed arguments and on the error path when devm_kzalloc() fails. This bug was detected by our static analysis tool and verified by my code review.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45883", "url": "https://ubuntu.com/security/CVE-2026-45883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: sca3000: Fix a resource leak in sca3000_probe() spi->irq from request_threaded_irq() not released when iio_device_register() fails. Add an return value check and jump to a common error handler when iio_device_register() fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45875", "url": "https://ubuntu.com/security/CVE-2026-45875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: arizona: Fix regulator resource leak on wm5102_clear_write_sequencer() failure The wm5102_clear_write_sequencer() helper may return an error and just return, bypassing the cleanup sequence and causing regulators to remain enabled, leading to a resource leak. Change the direct return to jump to the err_reset label to properly free the resources.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45978", "url": "https://ubuntu.com/security/CVE-2026-45978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: greybus: lights: avoid NULL deref gb_lights_light_config() stores channel_count before allocating the channels array. If kcalloc() fails, gb_lights_release() iterates the non-zero count and dereferences light->channels, which is NULL. Allocate channels first and only then publish channels_count so the cleanup path can't walk a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45954", "url": "https://ubuntu.com/security/CVE-2026-45954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe() In au1200fb_drv_probe(), when platform_get_irq fails(), it directly returns from the function with an error code, which causes a memory leak. Replace it with a goto label to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45857", "url": "https://ubuntu.com/security/CVE-2026-45857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: csiostor: Fix dereference of null pointer rn The error exit path when rn is NULL ends up deferencing the null pointer rn via the use of the macro CSIO_INC_STATS. Fix this by adding a new error return path label after the use of the macro to avoid the deference.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45856", "url": "https://ubuntu.com/security/CVE-2026-45856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45852", "url": "https://ubuntu.com/security/CVE-2026-45852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45869", "url": "https://ubuntu.com/security/CVE-2026-45869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: wm97xx: Fix NULL pointer dereference in power_supply_changed() In `probe()`, `request_irq()` is called before allocating/registering a `power_supply` handle. If an interrupt is fired between the call to `request_irq()` and `power_supply_register()`, the `power_supply` handle will be used uninitialized in `power_supply_changed()` in `wm97xx_bat_update()` (triggered from the interrupt handler). This will lead to a `NULL` pointer dereference since Fix this racy `NULL` pointer dereference by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Since the IRQ is the last thing requests in the `probe()` now, remove the error path for freeing it. Instead add one for unregistering the `power_supply` handle when IRQ request fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45916", "url": "https://ubuntu.com/security/CVE-2026-45916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sbs-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Keep the old behavior of just printing a warning in case of any failures during the IRQ request and finishing the probe successfully.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46270", "url": "https://ubuntu.com/security/CVE-2026-46270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: rt9455: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45936", "url": "https://ubuntu.com/security/CVE-2026-45936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: goldfish: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45885", "url": "https://ubuntu.com/security/CVE-2026-45885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cpcap-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45879", "url": "https://ubuntu.com/security/CVE-2026-45879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq25980: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45902", "url": "https://ubuntu.com/security/CVE-2026-45902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45867", "url": "https://ubuntu.com/security/CVE-2026-45867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: act8945a: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45946", "url": "https://ubuntu.com/security/CVE-2026-45946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Commit 1c1f13a006ed (\"power: supply: ab8500: Move to componentized binding\") introduced this issue during a refactorization. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45866", "url": "https://ubuntu.com/security/CVE-2026-45866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: caif: fix use-after-free in caif_serial ldisc_close() There is a use-after-free bug in caif_serial where handle_tx() may access ser->tty after the tty has been freed. The race condition occurs between ldisc_close() and packet transmission: CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldisc_close() tty_kref_put(ser->tty) [tty may be freed here] <-- race window --> caif_xmit() handle_tx() tty = ser->tty // dangling ptr tty->ops->write() // UAF! schedule_work() ser_release() unregister_netdevice() The root cause is that tty_kref_put() is called in ldisc_close() while the network device is still active and can receive packets. Since ser and tty have a 1:1 binding relationship with consistent lifecycles (ser is allocated in ldisc_open and freed in ser_release via unregister_netdevice, and each ser binds exactly one tty), we can safely defer the tty reference release to ser_release() where the network device is unregistered. Fix this by moving tty_kref_put() from ldisc_close() to ser_release(), after unregister_netdevice(). This ensures the tty reference is held as long as the network device exists, preventing the UAF. Note: We save ser->tty before unregister_netdevice() because ser is embedded in netdev's private data and will be freed along with netdev (needs_free_netdev = true). How to reproduce: Add mdelay(500) at the beginning of ldisc_close() to widen the race window, then run the reproducer program [1]. Note: There is a separate deadloop issue in handle_tx() when using PORT_UNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper serial backend). This deadloop exists even without this patch, and is likely caused by inconsistency between uart_write_room() and uart_write() in serial core. It has been addressed in a separate patch [2]. KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in handle_tx+0x5d1/0x620 Read of size 1 at addr ffff8881131e1490 by task caif_uaf_trigge/9929 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xd0/0x630 kasan_report+0xe4/0x120 handle_tx+0x5d1/0x620 dev_hard_start_xmit+0x9d/0x6c0 __dev_queue_xmit+0x6e2/0x4410 packet_xmit+0x243/0x360 packet_sendmsg+0x26cf/0x5500 __sys_sendto+0x4a3/0x520 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0xc9/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f615df2c0d7 Allocated by task 9930: Freed by task 64: Last potentially related work creation: The buggy address belongs to the object at ffff8881131e1000 which belongs to the cache kmalloc-cg-2k of size 2048 The buggy address is located 1168 bytes inside of freed 2048-byte region [ffff8881131e1000, ffff8881131e1800) The buggy address belongs to the physical page: page_owner tracks the page as allocated page last free pid 9778 tgid 9778 stack trace: Memory state around the buggy address: ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-31411", "url": "https://ubuntu.com/security/CVE-2026-31411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: fix crash due to unvalidated vcc pointer in sigd_send() Reproducer available at [1]. The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values. Fix this by introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found. Since struct atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock_hold/sock_put is sufficient to keep the vcc alive while it is being used. Note that there may be a race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety. [1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3", "cve_priority": "medium", "cve_public_date": "2026-04-08 14:16:00 UTC" }, { "cve": "CVE-2026-46259", "url": "https://ubuntu.com/security/CVE-2026-46259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent.", "cve_priority": "high", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45891", "url": "https://ubuntu.com/security/CVE-2026-45891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix double free issue for tx spare buffer In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory. Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory. The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer. Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new `tx_spare` fails. This ensures the error cleanup path only frees genuinely newly allocated buffers.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45873", "url": "https://ubuntu.com/security/CVE-2026-45873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets Userspace provides an optimized representation in case intervals are adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous set checks on start elements for this reason. However, it is possible to add intervals that overlap to this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end \tA B start end A C Restore the check on overlapping start elements to report an overlap.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46267", "url": "https://ubuntu.com/security/CVE-2026-46267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: hci: shdlc: Stop timers and work before freeing context llc_shdlc_deinit() purges SHDLC skb queues and frees the llc_shdlc structure while its timers and state machine work may still be active. Timer callbacks can schedule sm_work, and sm_work accesses SHDLC state and the skb queues. If teardown happens in parallel with a queued/running work item, it can lead to UAF and other shutdown races. Stop all SHDLC timers and cancel sm_work synchronously before purging the queues and freeing the context. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-46249", "url": "https://ubuntu.com/security/CVE-2026-46249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix PF driver crash with kexec kernel booting During a kexec reboot the hardware is not power-cycled, so AF state from the old kernel can persist into the new kernel. When AF and PF drivers are built as modules, the PF driver may probe before AF reinitializes the hardware. The PF driver treats the RVUM block revision as an indication that AF initialization is complete. If this value is left uncleared at shutdown, PF may incorrectly assume AF is ready and access stale hardware state, leading to a crash. Clear the RVUM block revision during AF shutdown to avoid PF mis-detecting AF readiness after kexec.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45915", "url": "https://ubuntu.com/security/CVE-2026-45915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: avoid parent link count underflow in rmdir Corrupted FAT images can leave a directory inode with an incorrect i_nlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls drop_nlink(dir) and can drive i_nlink to 0, triggering the WARN_ON in drop_nlink(). Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45983", "url": "https://ubuntu.com/security/CVE-2026-45983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: never defer requests during idmap lookup During v4 request compound arg decoding, some ops (e.g. SETATTR) can trigger idmap lookup upcalls. When those upcall responses get delayed beyond the allowed time limit, cache_check() will mark the request for deferral and cause it to be dropped. This prevents nfs4svc_encode_compoundres from being executed, and thus the session slot flag NFSD4_SLOT_INUSE never gets cleared. Subsequent client requests will fail with NFSERR_JUKEBOX, given that the slot will be marked as in-use, making the SEQUENCE op fail. Fix this by making sure that the RQ_USEDEFERRAL flag is always clear during nfs4svc_decode_compoundargs(), since no v4 request should ever be deferred.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45862", "url": "https://ubuntu.com/security/CVE-2026-45862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush cache for PASID table before using it When writing the address of a freshly allocated zero-initialized PASID table to a PASID directory entry, do that after the CPU cache flush for this PASID table, not before it, to avoid the time window when this PASID table may be already used by non-coherent IOMMU hardware while its contents in RAM is still some random old data, not zero-initialized.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45860", "url": "https://ubuntu.com/security/CVE-2026-45860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: increase the connection clean up limit to 64 After the optimization to only perform one GC per jiffy, a new problem was introduced. If more than 8 new connections are tracked per jiffy the list won't be cleaned up fast enough possibly reaching the limit wrongly. In order to prevent this issue, only skip the GC if it was already triggered during the same jiffy and the increment is lower than the clean up limit. In addition, increase the clean up limit to 64 connections to avoid triggering GC too often and do more effective GCs. This has been tested using a HTTP server and several performance tools while having nft_connlimit/xt_connlimit or OVS limit configured. Output of slowhttptest + OVS limit at 52000 connections: slow HTTP test status on 340th second: initializing: 0 pending: 432 connected: 51998 error: 0 closed: 0 service available: YES", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45969", "url": "https://ubuntu.com/security/CVE-2026-45969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: playstation: Add missing check for input_ff_create_memless The ps_gamepad_create() function calls input_ff_create_memless() without verifying its return value, which can lead to incorrect behavior or potential crashes when FF effects are triggered. Add a check for the return value of input_ff_create_memless().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-71304", "url": "https://ubuntu.com/security/CVE-2025-71304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: /smack/doi: accept previously used values Writing to /smack/doi a value that has ever been written there in the past disables networking for non-ambient labels. E.g. # cat /smack/doi 3 # netlabelctl -p cipso list Configured CIPSO mappings (1) DOI value : 3 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (3) domain: \"_\" (IPv4) protocol: UNLABELED domain: DEFAULT (IPv4) protocol: CIPSO, DOI = 3 domain: DEFAULT (IPv6) protocol: UNLABELED # cat /smack/ambient _ # cat /proc/$$/attr/smack/current _ # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.964 ms # echo foo >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.956 ms unknown option 86 # echo 4 >/smack/doi # echo 3 >/smack/doi !> [ 214.050395] smk_cipso_doi:691 cipso add rc = -17 # echo 3 >/smack/doi !> [ 249.402261] smk_cipso_doi:678 remove rc = -2 !> [ 249.402261] smk_cipso_doi:691 cipso add rc = -17 # ping -c1 10.1.95.12 !!> ping: 10.1.95.12: Address family for hostname not supported # echo _ >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.617 ms This happens because Smack keeps decommissioned DOIs, fails to re-add them, and consequently refuses to add the “default” domain map: # netlabelctl -p cipso list Configured CIPSO mappings (2) DOI value : 3 mapping type : PASS_THROUGH DOI value : 4 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (2) domain: \"_\" (IPv4) protocol: UNLABELED !> (no ipv4 map for default domain here) domain: DEFAULT (IPv6) protocol: UNLABELED Fix by clearing decommissioned DOI definitions and serializing concurrent DOI updates with a new lock. Also: - allow /smack/doi to live unconfigured, since adding a map (netlbl_cfg_cipsov4_map_add) may fail. CIPSO_V4_DOI_UNKNOWN(0) indicates the unconfigured DOI - add new DOI before removing the old default map, so the old map remains if the add fails (2008-02-04, Casey Schaufler)", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45904", "url": "https://ubuntu.com/security/CVE-2026-45904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling The recent commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug safe\") restructured the EEH driver to improve synchronization with the PCI hotplug layer. However, it inadvertently moved pci_lock_rescan_remove() outside its intended scope in eeh_handle_normal_event(), leading to broken PCI error reporting and improper EEH event triggering. Specifically, eeh_handle_normal_event() acquired pci_lock_rescan_remove() before calling eeh_pe_bus_get(), but eeh_pe_bus_get() itself attempts to acquire the same lock internally, causing nested locking and disrupting normal EEH event handling paths. This patch adds a boolean parameter do_lock to _eeh_pe_bus_get(), with two public wrappers: eeh_pe_bus_get() with locking enabled. eeh_pe_bus_get_nolock() that skips locking. Callers that already hold pci_lock_rescan_remove() now use eeh_pe_bus_get_nolock() to avoid recursive lock acquisition. Additionally, pci_lock_rescan_remove() calls are restored to the correct position—after eeh_pe_bus_get() and immediately before iterating affected PEs and devices. This ensures EEH-triggered PCI removes occur under proper bus rescan locking without recursive lock contention. The eeh_pe_loc_get() function has been split into two functions: eeh_pe_loc_get(struct eeh_pe *pe) which retrieves the loc for given PE. eeh_pe_loc_get_bus(struct pci_bus *bus) which retrieves the location code for given bus. This resolves lockdep warnings such as: [ 84.964298] [ T928] ============================================ [ 84.964304] [ T928] WARNING: possible recursive locking detected [ 84.964311] [ T928] 6.18.0-rc3 #51 Not tainted [ 84.964315] [ T928] -------------------------------------------- [ 84.964320] [ T928] eehd/928 is trying to acquire lock: [ 84.964324] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964342] [ T928] but task is already holding lock: [ 84.964347] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964357] [ T928] other info that might help us debug this: [ 84.964363] [ T928] Possible unsafe locking scenario: [ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928] lock(pci_rescan_remove_lock); [ 84.964378] [ T928] lock(pci_rescan_remove_lock); [ 84.964383] [ T928] *** DEADLOCK *** [ 84.964388] [ T928] May be due to missing lock nesting notation [ 84.964393] [ T928] 1 lock held by eehd/928: [ 84.964397] [ T928] #0: c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964408] [ T928] stack backtrace: [ 84.964414] [ T928] CPU: 2 UID: 0 PID: 928 Comm: eehd Not tainted 6.18.0-rc3 #51 VOLUNTARY [ 84.964417] [ T928] Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_022) hv:phyp pSeries [ 84.964419] [ T928] Call Trace: [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130 (unreliable) [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [ 84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c00000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46253", "url": "https://ubuntu.com/security/CVE-2026-46253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore/ram: fix buffer overflow in persistent_ram_save_old() persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz->old_log when it is NULL, but it unconditionally updates prz->old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1) 9. ramoops_get_next_prz() → persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45919", "url": "https://ubuntu.com/security/CVE-2026-45919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/rt: Skip currently executing CPU in rto_next_cpu() CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts. The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45871", "url": "https://ubuntu.com/security/CVE-2026-45871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Fix missing cleanup on get_burstcount() error get_burstcount() can return -EBUSY on timeout. When this happens, st33zp24_send() returns directly without releasing the locality acquired earlier. Use goto out_err to ensure proper cleanup when get_burstcount() fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45941", "url": "https://ubuntu.com/security/CVE-2026-45941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_infineon: Fix locality leak on get_burstcount() failure get_burstcount() can return -EBUSY on timeout. When this happens, the function returns directly without releasing the locality that was acquired at the beginning of tpm_tis_i2c_send(). Use goto out_err to ensure proper cleanup when get_burstcount() fails.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45984", "url": "https://ubuntu.com/security/CVE-2026-45984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix use-after-free in iomap inline data write path The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45960", "url": "https://ubuntu.com/security/CVE-2026-45960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: return error when node already exists in hfs_bnode_create When hfs_bnode_create() finds that a node is already hashed (which should not happen in normal operation), it currently returns the existing node without incrementing its reference count. This causes a reference count inconsistency that leads to a kernel panic when the node is later freed in hfs_bnode_put(): kernel BUG at fs/hfsplus/bnode.c:676! BUG_ON(!atomic_read(&node->refcnt)) This scenario can occur when hfs_bmap_alloc() attempts to allocate a node that is already in use (e.g., when node 0's bitmap bit is incorrectly unset), or due to filesystem corruption. Returning an existing node from a create path is not normal operation. Fix this by returning ERR_PTR(-EEXIST) instead of the node when it's already hashed. This properly signals the error condition to callers, which already check for IS_ERR() return values.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23243", "url": "https://ubuntu.com/security/CVE-2026-23243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umad: Reject negative data_len in ib_umad_write ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-23242", "url": "https://ubuntu.com/security/CVE-2026-23242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix potential NULL pointer dereference in header processing If siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(), qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data() dereferences qp->rx_fpdu->more_ddp_segs without checking, which may lead to a NULL pointer deref. Only check more_ddp_segs when rx_fpdu is present. KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-23235", "url": "https://ubuntu.com/security/CVE-2026-23235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix out-of-bounds access in sysfs attribute read/write Some f2fs sysfs attributes suffer from out-of-bounds memory access and incorrect handling of integer values whose size is not 4 bytes. For example: vm:~# echo 65537 > /sys/fs/f2fs/vde/carve_out vm:~# cat /sys/fs/f2fs/vde/carve_out 65537 vm:~# echo 4294967297 > /sys/fs/f2fs/vde/atgc_age_threshold vm:~# cat /sys/fs/f2fs/vde/atgc_age_threshold 1 carve_out maps to {struct f2fs_sb_info}->carve_out, which is a 8-bit integer. However, the sysfs interface allows setting it to a value larger than 255, resulting in an out-of-range update. atgc_age_threshold maps to {struct atgc_management}->age_threshold, which is a 64-bit integer, but its sysfs interface cannot correctly set values larger than UINT_MAX. The root causes are: 1. __sbi_store() treats all default values as unsigned int, which prevents updating integers larger than 4 bytes and causes out-of-bounds writes for integers smaller than 4 bytes. 2. f2fs_sbi_show() also assumes all default values are unsigned int, leading to out-of-bounds reads and incorrect access to integers larger than 4 bytes. This patch introduces {struct f2fs_attr}->size to record the actual size of the integer associated with each sysfs attribute. With this information, sysfs read and write operations can correctly access and update values according to their real data size, avoiding memory corruption and truncation.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23234", "url": "https://ubuntu.com/security/CVE-2026-23234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid UAF in f2fs_write_end_io() As syzbot reported an use-after-free issue in f2fs_write_end_io(). It is caused by below race condition: loop device\t\t\t\tumount - worker_thread - loop_process_work - do_req_filebacked - lo_rw_aio - lo_rw_aio_complete - blk_mq_end_request - blk_update_request - f2fs_write_end_io - dec_page_count - folio_end_writeback \t\t\t\t\t- kill_f2fs_super \t\t\t\t\t - kill_block_super \t\t\t\t\t - f2fs_put_super \t\t\t\t\t : free(sbi) : get_pages(, F2FS_WB_CP_DATA) accessed sbi which is freed In kill_f2fs_super(), we will drop all page caches of f2fs inodes before call free(sbi), it guarantee that all folios should end its writeback, so it should be safe to access sbi before last folio_end_writeback(). Let's relocate ckpt thread wakeup flow before folio_end_writeback() to resolve this issue.", "cve_priority": "low", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23236", "url": "https://ubuntu.com/security/CVE-2026-23236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: smscufx: properly copy ioctl memory to kernelspace The UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data from userspace to kernelspace, and instead directly references the memory, which can cause problems if invalid data is passed from userspace. Fix this all up by correctly copying the memory before accessing it within the kernel.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23266", "url": "https://ubuntu.com/security/CVE-2026-23266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: rivafb: fix divide error in nv3_arb() A userspace program can trigger the RIVA NV3 arbitration code by calling the FBIOPUT_VSCREENINFO ioctl on /dev/fb*. When doing so, the driver recomputes FIFO arbitration parameters in nv3_arb(), using state->mclk_khz (derived from the PRAMDAC MCLK PLL) as a divisor without validating it first. In a normal setup, state->mclk_khz is provided by the real hardware and is non-zero. However, an attacker can construct a malicious or misconfigured device (e.g. a crafted/emulated PCI device) that exposes a bogus PLL configuration, causing state->mclk_khz to become zero. Once nv3_get_param() calls nv3_arb(), the division by state->mclk_khz in the gns calculation causes a divide error and crashes the kernel. Fix this by checking whether state->mclk_khz is zero and bailing out before doing the division. The following log reveals it: rivafb: setting virtual Y resolution to 2184 divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 2187 Comm: syz-executor.0 Not tainted 5.18.0-rc1+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:nv3_arb drivers/video/fbdev/riva/riva_hw.c:439 [inline] RIP: 0010:nv3_get_param+0x3ab/0x13b0 drivers/video/fbdev/riva/riva_hw.c:546 Call Trace: nv3CalcArbitration.constprop.0+0x255/0x460 drivers/video/fbdev/riva/riva_hw.c:603 nv3UpdateArbitrationSettings drivers/video/fbdev/riva/riva_hw.c:637 [inline] CalcStateExt+0x447/0x1b90 drivers/video/fbdev/riva/riva_hw.c:1246 riva_load_video_mode+0x8a9/0xea0 drivers/video/fbdev/riva/fbdev.c:779 rivafb_set_par+0xc0/0x5f0 drivers/video/fbdev/riva/fbdev.c:1196 fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1033 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1109 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1188 __x64_sys_ioctl+0x122/0x190 fs/ioctl.c:856", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2025-71233", "url": "https://ubuntu.com/security/CVE-2025-71233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Avoid creating sub-groups asynchronously The asynchronous creation of sub-groups by a delayed work could lead to a NULL pointer dereference when the driver directory is removed before the work completes. The crash can be easily reproduced with the following commands: # cd /sys/kernel/config/pci_ep/functions/pci_epf_test # for i in {1..20}; do mkdir test && rmdir test; done BUG: kernel NULL pointer dereference, address: 0000000000000088 ... Call Trace: configfs_register_group+0x3d/0x190 pci_epf_cfs_work+0x41/0x110 process_one_work+0x18f/0x350 worker_thread+0x25a/0x3a0 Fix this issue by using configfs_add_default_group() API which does not have the deadlock problem as configfs_register_group() and does not require the delayed work handler. [mani: slightly reworded the description and added stable list]", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71232", "url": "https://ubuntu.com/security/CVE-2025-71232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Free sp in error path to fix system crash System crash seen during load/unload test in a loop, [61110.449331] qla2xxx [0000:27:00.0]-0042:0: Disabled MSI-X. [61110.467494] ============================================================================= [61110.467498] BUG qla2xxx_srbs (Tainted: G OE -------- --- ): Objects remaining in qla2xxx_srbs on __kmem_cache_shutdown() [61110.467501] ----------------------------------------------------------------------------- [61110.467502] Slab 0x000000000ffc8162 objects=51 used=1 fp=0x00000000e25d3d85 flags=0x57ffffc0010200(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [61110.467509] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1 [61110.467513] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023 [61110.467515] Call Trace: [61110.467516] [61110.467519] dump_stack_lvl+0x34/0x48 [61110.467526] slab_err.cold+0x53/0x67 [61110.467534] __kmem_cache_shutdown+0x16e/0x320 [61110.467540] kmem_cache_destroy+0x51/0x160 [61110.467544] qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467607] ? __do_sys_delete_module.constprop.0+0x178/0x280 [61110.467613] ? syscall_trace_enter.constprop.0+0x145/0x1d0 [61110.467616] ? do_syscall_64+0x5c/0x90 [61110.467619] ? exc_page_fault+0x62/0x150 [61110.467622] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [61110.467626] [61110.467627] Disabling lock debugging due to kernel taint [61110.467635] Object 0x0000000026f7e6e6 @offset=16000 [61110.467639] ------------[ cut here ]------------ [61110.467639] kmem_cache_destroy qla2xxx_srbs: Slab cache still has objects when called from qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467659] WARNING: CPU: 53 PID: 455206 at mm/slab_common.c:520 kmem_cache_destroy+0x14d/0x160 [61110.467718] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G B OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1 [61110.467720] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023 [61110.467721] RIP: 0010:kmem_cache_destroy+0x14d/0x160 [61110.467724] Code: 99 7d 07 00 48 89 ef e8 e1 6a 07 00 eb b3 48 8b 55 60 48 8b 4c 24 20 48 c7 c6 70 fc 66 90 48 c7 c7 f8 ef a1 90 e8 e1 ed 7c 00 <0f> 0b eb 93 c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 [61110.467725] RSP: 0018:ffffa304e489fe80 EFLAGS: 00010282 [61110.467727] RAX: 0000000000000000 RBX: ffffffffc0d9a860 RCX: 0000000000000027 [61110.467729] RDX: ffff8fd5ff9598a8 RSI: 0000000000000001 RDI: ffff8fd5ff9598a0 [61110.467730] RBP: ffff8fb6aaf78700 R08: 0000000000000000 R09: 0000000100d863b7 [61110.467731] R10: ffffa304e489fd20 R11: ffffffff913bef48 R12: 0000000040002000 [61110.467731] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [61110.467733] FS: 00007f64c89fb740(0000) GS:ffff8fd5ff940000(0000) knlGS:0000000000000000 [61110.467734] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [61110.467735] CR2: 00007f0f02bfe000 CR3: 00000020ad6dc005 CR4: 0000000000770ee0 [61110.467736] PKRU: 55555554 [61110.467737] Call Trace: [61110.467738] [61110.467739] qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467755] ? __do_sys_delete_module.constprop.0+0x178/0x280 Free sp in the error path to fix the crash.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71238", "url": "https://ubuntu.com/security/CVE-2025-71238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix bsg_done() causing double free Kernel panic observed on system, [5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000 [5353358.825194] #PF: supervisor write access in kernel mode [5353358.825195] #PF: error_code(0x0002) - not-present page [5353358.825196] PGD 100006067 P4D 0 [5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI [5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el9_5.x86_64 #1 [5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025 [5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10 [5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246 [5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000 [5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000 [5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000 [5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090 [5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000 [5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000 [5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0 [5353358.825221] PKRU: 55555554 [5353358.825222] Call Trace: [5353358.825223] [5353358.825224] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825229] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825232] ? sg_copy_buffer+0xc8/0x110 [5353358.825236] ? __die_body.cold+0x8/0xd [5353358.825238] ? page_fault_oops+0x134/0x170 [5353358.825242] ? kernelmode_fixup_or_oops+0x84/0x110 [5353358.825244] ? exc_page_fault+0xa8/0x150 [5353358.825247] ? asm_exc_page_fault+0x22/0x30 [5353358.825252] ? memcpy_erms+0x6/0x10 [5353358.825253] sg_copy_buffer+0xc8/0x110 [5353358.825259] qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx] [5353358.825317] qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx] Most routines in qla_bsg.c call bsg_done() only for success cases. However a few invoke it for failure case as well leading to a double free. Validate before calling bsg_done().", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23221", "url": "https://ubuntu.com/security/CVE-2026-23221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: fix use-after-free in driver_override_show() The driver_override_show() function reads the driver_override string without holding the device_lock. However, driver_override_store() uses driver_set_override(), which modifies and frees the string while holding the device_lock. This can result in a concurrent use-after-free if the string is freed by the store function while being read by the show function. Fix this by holding the device_lock around the read operation.", "cve_priority": "low", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23228", "url": "https://ubuntu.com/security/CVE-2026-23228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection() On kthread_run() failure in ksmbd_tcp_new_connection(), the transport is freed via free_transport(), which does not decrement active_num_conn, leaking this counter. Replace free_transport() with ksmbd_tcp_disconnect().", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23169", "url": "https://ubuntu.com/security/CVE-2026-23169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race in mptcp_pm_nl_flush_addrs_doit() syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id() and/or mptcp_pm_nl_is_backup() Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit() which is not RCU ready. list_splice_init_rcu() can not be called here while holding pernet->lock spinlock. Many thanks to Eulgyu Kim for providing a repro and testing our patches.", "cve_priority": "high", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-37786", "url": "https://ubuntu.com/security/CVE-2025-37786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: free routing table on probe failure If complete = true in dsa_tree_setup(), it means that we are the last switch of the tree which is successfully probing, and we should be setting up all switches from our probe path. After \"complete\" becomes true, dsa_tree_setup_cpu_ports() or any subsequent function may fail. If that happens, the entire tree setup is in limbo: the first N-1 switches have successfully finished probing (doing nothing but having allocated persistent memory in the tree's dst->ports, and maybe dst->rtable), and switch N failed to probe, ending the tree setup process before anything is tangible from the user's PoV. If switch N fails to probe, its memory (ports) will be freed and removed from dst->ports. However, the dst->rtable elements pointing to its ports, as created by dsa_link_touch(), will remain there, and will lead to use-after-free if dereferenced. If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirely possible because that is where ds->ops->setup() is, we get a kasan report like this: ================================================================== BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568 Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42 Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 The simplest way to fix the bug is to delete the routing table in its entirety. dsa_tree_setup_routing_table() has no problem in regenerating it even if we deleted links between ports other than those of switch N, because dsa_link_touch() first checks whether the port pair already exists in dst->rtable, allocating if not. The deletion of the routing table in its entirety already exists in dsa_tree_teardown(), so refactor that into a function that can also be called from the tree setup error path. In my analysis of the commit to blame, it is the one which added dsa_link elements to dst->rtable. Prior to that, each switch had its own ds->rtable which is freed when the switch fails to probe. But the tree is potentially persistent memory.", "cve_priority": "low", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2026-23237", "url": "https://ubuntu.com/security/CVE-2026-23237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: classmate-laptop: Add missing NULL pointer checks In a few places in the Classmate laptop driver, code using the accel object may run before that object's address is stored in the driver data of the input device using it. For example, cmpc_accel_sensitivity_store_v4() is the \"show\" method of cmpc_accel_sensitivity_attr_v4 which is added in cmpc_accel_add_v4(), before calling dev_set_drvdata() for inputdev->dev. If the sysfs attribute is accessed prematurely, the dev_get_drvdata(&inputdev->dev) call in in cmpc_accel_sensitivity_store_v4() returns NULL which leads to a NULL pointer dereference going forward. Moreover, sysfs attributes using the input device are added before initializing that device by cmpc_add_acpi_notify_device() and if one of them is accessed before running that function, a NULL pointer dereference will occur. For example, cmpc_accel_sensitivity_attr_v4 is added before calling cmpc_add_acpi_notify_device() and if it is read prematurely, the dev_get_drvdata(&acpi->dev) call in cmpc_accel_sensitivity_show_v4() returns NULL which leads to a NULL pointer dereference going forward. Fix this by adding NULL pointer checks in all of the relevant places.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23238", "url": "https://ubuntu.com/security/CVE-2026-23238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: romfs: check sb_set_blocksize() return value romfs_fill_super() ignores the return value of sb_set_blocksize(), which can fail if the requested block size is incompatible with the block device's configuration. This can be triggered by setting a loop device's block size larger than PAGE_SIZE using ioctl(LOOP_SET_BLOCK_SIZE, 32768), then mounting a romfs filesystem on that device. When sb_set_blocksize(sb, ROMBSIZE) is called with ROMBSIZE=4096 but the device has logical_block_size=32768, bdev_validate_blocksize() fails because the requested size is smaller than the device's logical block size. sb_set_blocksize() returns 0 (failure), but romfs ignores this and continues mounting. The superblock's block size remains at the device's logical block size (32768). Later, when sb_bread() attempts I/O with this oversized block size, it triggers a kernel BUG in folio_set_bh(): kernel BUG at fs/buffer.c:1582! BUG_ON(size > PAGE_SIZE); Fix by checking the return value of sb_set_blocksize() and failing the mount with -EINVAL if it returns 0.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-31687", "url": "https://ubuntu.com/security/CVE-2026-31687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: omap: do not register driver in probe() Commit 11a78b794496 (\"ARM: OMAP: MPUIO wake updates\") registers the omap_mpuio_driver from omap_mpuio_init(), which is called from omap_gpio_probe(). However, it neither makes sense to register drivers from probe() callbacks of other drivers, nor does the driver core allow registering drivers with a device lock already being held. The latter was revealed by commit dc23806a7c47 (\"driver core: enforce device_lock for driver_match_device()\") leading to a potential deadlock condition described in [1]. Additionally, the omap_mpuio_driver is never unregistered from the driver core, even if the module is unloaded. Hence, register the omap_mpuio_driver from the module initcall and unregister it in module_exit().", "cve_priority": "medium", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2025-71235", "url": "https://ubuntu.com/security/CVE-2025-71235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Delay module unload while fabric scan in progress System crash seen during load/unload test in a loop. [105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086 [105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0 [105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000 [105954.384923] FS: 0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000 [105954.384925] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0 [105954.384928] PKRU: 55555554 [105954.384929] Call Trace: [105954.384931] [105954.384934] qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx] [105954.384962] ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx] [105954.384980] ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx] [105954.384999] ? __wake_up_common+0x80/0x190 [105954.385004] ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx] [105954.385023] ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx] [105954.385040] ? __handle_irq_event_percpu+0x3d/0x190 [105954.385044] ? handle_irq_event+0x58/0xb0 [105954.385046] ? handle_edge_irq+0x93/0x240 [105954.385050] ? __common_interrupt+0x41/0xa0 [105954.385055] ? common_interrupt+0x3e/0xa0 [105954.385060] ? asm_common_interrupt+0x22/0x40 The root cause of this was that there was a free (dma_free_attrs) in the interrupt context. There was a device discovery/fabric scan in progress. A module unload was issued which set the UNLOADING flag. As part of the discovery, after receiving an interrupt a work queue was scheduled (which involved a work to be queued). Since the UNLOADING flag is set, the work item was not allocated and the mapped memory had to be freed. The free occurred in interrupt context leading to system crash. Delay the driver unload until the fabric scan is complete to avoid the crash.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71236", "url": "https://ubuntu.com/security/CVE-2025-71236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Validate sp before freeing associated memory System crash with the following signature [154563.214890] nvme nvme2: NVME-FC{1}: controller connect complete [154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Set ZIO exchange threshold to 3. [154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: SET ZIO Activity exchange threshold to 5. [154565.539974] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 0080 0000. [154565.545744] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 00a0 0000. [154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate). [154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate). [154565.553079] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [154565.553080] #PF: supervisor read access in kernel mode [154565.553082] #PF: error_code(0x0000) - not-present page [154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0 [154565.553089] Oops: 0000 1 PREEMPT SMP PTI [154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: loaded Tainted: G OE ------- --- 5.14.0-503.11.1.el9_5.x86_64 #1 [154565.553096] Hardware name: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 09/30/2024 [154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553141] Code: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 <4c> 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b [154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286 [154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002 [154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47 [154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a [154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0 [154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000 [154565.553152] FS: 0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000 [154565.553154] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0 [154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [154565.553159] PKRU: 55555554 [154565.553160] Call Trace: [154565.553162] [154565.553165] ? show_trace_log_lvl+0x1c4/0x2df [154565.553172] ? show_trace_log_lvl+0x1c4/0x2df [154565.553177] ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553215] ? __die_body.cold+0x8/0xd [154565.553218] ? page_fault_oops+0x134/0x170 [154565.553223] ? snprintf+0x49/0x70 [154565.553229] ? exc_page_fault+0x62/0x150 [154565.553238] ? asm_exc_page_fault+0x22/0x30 Check for sp being non NULL before freeing any associated memory", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71237", "url": "https://ubuntu.com/security/CVE-2025-71237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: Fix potential block overflow that cause system hang When a user executes the FITRIM command, an underflow can occur when calculating nblocks if end_block is too small. Since nblocks is of type sector_t, which is u64, a negative nblocks value will become a very large positive integer. This ultimately leads to the block layer function __blkdev_issue_discard() taking an excessively long time to process the bio chain, and the ns_segctor_sem lock remains held for a long period. This prevents other tasks from acquiring the ns_segctor_sem lock, resulting in the hang reported by syzbot in [1]. If the ending block is too small, typically if it is smaller than 4KiB range, depending on the usage of the segment 0, it may be possible to attempt a discard request beyond the device size causing the hang. Exiting successfully and assign the discarded size (0 in this case) to range->len. Although the start and len values in the user input range are too small, a conservative strategy is adopted here to safely ignore them, which is equivalent to a no-op; it will not perform any trimming and will not throw an error. [1] task:segctord state:D stack:28968 pid:6093 tgid:6093 ppid:2 task_flags:0x200040 flags:0x00080000 Call Trace: rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272 nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline] nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684 [ryusuke: corrected part of the commit message about the consequences]", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23229", "url": "https://ubuntu.com/security/CVE-2026-23229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add spinlock protection with virtqueue notification When VM boots with one virtio-crypto PCI device and builtin backend, run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head! It seems that the data virtqueue need protection when it is handled for virtio done notification. If the spinlock protection is added in virtcrypto_done_task(), openssl benchmark with multiple processes works well.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23222", "url": "https://ubuntu.com/security/CVE-2026-23222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly The existing allocation of scatterlists in omap_crypto_copy_sg_lists() was allocating an array of scatterlist pointers, not scatterlist objects, resulting in a 4x too small allocation. Use sizeof(*new_sg) to get the correct object size.", "cve_priority": "high", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23392", "url": "https://ubuntu.com/security/CVE-2026-23392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-45988", "url": "https://ubuntu.com/security/CVE-2026-45988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix re-decryption of RESPONSE packets If a RESPONSE packet gets a temporary failure during processing, it may end up in a partially decrypted state - and then get requeued for a retry. Fix this by just discarding the packet; we will send another CHALLENGE packet and thereby elicit a further response. Similarly, discard an incoming CHALLENGE packet if we get an error whilst generating a RESPONSE; the server will send another CHALLENGE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46195", "url": "https://ubuntu.com/security/CVE-2026-46195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46135", "url": "https://ubuntu.com/security/CVE-2026-46135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.", "cve_priority": "critical", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31402", "url": "https://ubuntu.com/security/CVE-2026-31402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.", "cve_priority": "critical", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43071", "url": "https://ubuntu.com/security/CVE-2026-43071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dcache: Limit the minimal number of bucket to two There is an OOB read problem on dentry_hashtable when user sets 'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260 There will be only one bucket in dentry_hashtable when dhash_entries is set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then, following process will access more than one buckets(which memory region is not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB! Fix it by limiting the minimal number of dentry_hashtable bucket to two, so that 'd_hash_shift' won't exceeds the bit width of type u32.", "cve_priority": "low", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-46119", "url": "https://ubuntu.com/security/CVE-2026-46119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix slab-out-of-bounds access in auth message processing If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY contains a positive value in its result field, it is treated as an error code by ceph_handle_auth_reply() and returned to handle_auth_reply(). Thereafter, an attempt is made to send the preallocated message of type CEPH_MSG_AUTH, where the returned value is interpreted as the size of the front segment to send. If the result value in the message is greater than the size of the memory buffer allocated for the front segment, an out-of-bounds access occurs, and the content of the memory region beyond this buffer is sent out. This patch fixes the issue by treating only negative values in the result field as errors. Positive values are therefore treated as success in the same way as a zero value. Additionally, a BUG_ON is added to __send_prepared_auth_request() comparing the len parameter to front_alloc_len to prevent sending the message if it exceeds the bounds of the allocation and to make it easier to catch any logic flaws leading to this.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-43501", "url": "https://ubuntu.com/security/CVE-2026-43501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: \tskb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards.", "cve_priority": "critical", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46043", "url": "https://ubuntu.com/security/CVE-2026-46043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43493", "url": "https://ubuntu.com/security/CVE-2026-43493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications.", "cve_priority": "high", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-31637", "url": "https://ubuntu.com/security/CVE-2026-31637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: reject undecryptable rxkad response tickets rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether crypto_skcipher_decrypt() succeeded. A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes. Check the decrypt result and abort the connection with RXKADBADTICKET when ticket decryption fails.", "cve_priority": "critical", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31657", "url": "https://ubuntu.com/security/CVE-2026-31657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: hold claim backbone gateways by reference batadv_bla_add_claim() can replace claim->backbone_gw and drop the old gateway's last reference while readers still follow the pointer. The netlink claim dump path dereferences claim->backbone_gw->orig and takes claim->backbone_gw->crc_lock without pinning the underlying backbone gateway. batadv_bla_check_claim() still has the same naked pointer access pattern. Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate on a stable gateway reference until the read-side work is complete. This keeps the dump and claim-check paths aligned with the lifetime rules introduced for the other BLA claim readers.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31685", "url": "https://ubuntu.com/security/CVE-2026-31685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_eui64: reject invalid MAC header for all packets `eui64_mt6()` derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address. The existing guard only rejects an invalid MAC header when `par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()` can still reach `eth_hdr(skb)` even when the MAC header is not valid. Fix this by removing the `par->fragoff != 0` condition so that packets with an invalid MAC header are rejected before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43117", "url": "https://ubuntu.com/security/CVE-2026-43117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() If overlay is used on top of btrfs, dentry->d_sb translates to overlay's super block and fsid assignment will lead to a crash. Use file_inode(file)->i_sb to always get btrfs_sb.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43114", "url": "https://ubuntu.com/security/CVE-2026-43114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry New test case fails unexpectedly when avx2 matching functions are used. The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo. This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f - This is expected to work, because its the same set after all and it was already loaded once. But with avx2, this fails: nft reports a clashing element. The reported clash is of following form: We successfully re-inserted a . b c . d Then we try to insert a . d avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next. Due to incorrect masking, the skip-step finds the next matching element *only considering the first field*, i.e. we return the already reinserted \"a . b\", even though the last field is different and the entry should not have been matched. No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback. Bisection points to 7711f4bb4b36 (\"netfilter: nft_set_pipapo: fix range overlap detection\") but that fix merely uncovers this bug. Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate. The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31478", "url": "https://ubuntu.com/security/CVE-2026-31478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len() After this commit (e2b76ab8b5c9 \"ksmbd: add support for read compound\"), response buffer management was changed to use dynamic iov array. In the new design, smb2_calc_max_out_buf_len() expects the second argument (hdr2_len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31668", "url": "https://ubuntu.com/security/CVE-2026-31668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: separate dst_cache for input and output paths in seg6 lwtunnel The seg6 lwtunnel uses a single dst_cache per encap route, shared between seg6_input_core() and seg6_output_core(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup. Fix this by splitting the cache into cache_input and cache_output, so each path maintains its own cached dst independently.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31659", "url": "https://ubuntu.com/security/CVE-2026-31659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject oversized global TT response buffers batadv_tt_prepare_tvlv_global_data() builds the allocation length for a global TT response in 16-bit temporaries. When a remote originator advertises a large enough global TT, the TT payload length plus the VLAN header offset can exceed 65535 and wrap before kmalloc(). The full-table response path still uses the original TT payload length when it fills tt_change, so the wrapped allocation is too small and batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object before the later packet-size check runs. Fix this by rejecting TT responses whose TVLV value length cannot fit in the 16-bit TVLV payload length field.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31649", "url": "https://ubuntu.com/security/CVE-2026-31649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix integer underflow in chain mode The jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb->len (total length including page fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc); When a packet has a small linear portion (nopaged_len <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax * i pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware. Fix this by introducing a buf_len local variable clamped to min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmac_xmit() handles page fragments afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31669", "url": "https://ubuntu.com/security/CVE-2026-31669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix slab-use-after-free in __inet_lookup_established The ehash table lookups are lockless and rely on SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability during RCU read-side critical sections. Both tcp_prot and tcpv6_prot have their slab caches created with this flag via proto_register(). However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into tcpv6_prot_override during inet_init() (fs_initcall, level 5), before inet6_init() (module_init/device_initcall, level 6) has called proto_register(&tcpv6_prot). At that point, tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab remains NULL permanently. This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so when these sockets are freed without SOCK_RCU_FREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcu_read_lock can then access freed memory, triggering a slab-use-after-free in __inet_lookup_established. Fix this by splitting the IPv6-specific initialization out of mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called from mptcp_proto_v6_init() before protocol registration. This ensures tcpv6_prot_override.slab correctly inherits the SLAB_TYPESAFE_BY_RCU slab cache.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43011", "url": "https://ubuntu.com/security/CVE-2026-43011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix potential double free of skb When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain: x25_queue_rx_frame returns 1 | v x25_state3_machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25_process_rx_frame returns queued=0 | v x25_backlog_rcv at line 452 sees queued=0 and calls kfree_skb(skb) again This would free the same skb twice. Looking at x25_backlog_rcv: net/x25/x25_in.c:x25_backlog_rcv() { ... queued = x25_process_rx_frame(sk, skb); ... if (!queued) kfree_skb(skb); }", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43037", "url": "https://ubuntu.com/security/CVE-2026-43037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip4ip6_err() Oskar Kjos reported the following problem. ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr value. __ip_options_echo() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->__data, a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE). To fix this we clear skb2->cb[], as suggested by Oskar Kjos. Also add minimal IPv4 header validation (version == 4, ihl >= 5).", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43038", "url": "https://ubuntu.com/security/CVE-2026-43038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31682", "url": "https://ubuntu.com/security/CVE-2026-31682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: linearize skb before parsing ND options br_nd_send() parses neighbour discovery options from ns->opt[] and assumes that these options are in the linear part of request. Its callers only guarantee that the ICMPv6 header and target address are available, so the option area can still be non-linear. Parsing ns->opt[] in that case can access data past the linear buffer. Linearize request before option parsing and derive ns from the linear network header.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-23450", "url": "https://ubuntu.com/security/CVE-2026-23450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1]. smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release(). This leads to two issues: 1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed. The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race): CPU A (softirq) CPU B (process ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* No lock on listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash! Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed. Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight. - Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock(). - Use rcu_read_lock() to protect reading sk_user_data. - Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely. Note: smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected. Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied. [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23428", "url": "https://ubuntu.com/security/CVE-2026-23428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of share_conf in compound request smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without validating tcon->t_state. ksmbd_tree_conn_lookup() checks t_state == TREE_CONNECTED on the initial lookup path, but the compound reuse path bypasses this check entirely. If a prior command in the compound (SMB2_TREE_DISCONNECT) sets t_state to TREE_DISCONNECTED and frees share_conf via ksmbd_share_config_put(), subsequent commands dereference the freed share_conf through work->tcon->share_conf. KASAN report: [ 4.144653] ================================================================== [ 4.145059] BUG: KASAN: slab-use-after-free in smb2_write+0xc74/0xe70 [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44 [ 4.145772] [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY [ 4.145871] 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 [ 4.145875] Workqueue: ksmbd-io handle_ksmbd_work [ 4.145888] Call Trace: [ 4.145892] [ 4.145894] dump_stack_lvl+0x64/0x80 [ 4.145910] print_report+0xce/0x660 [ 4.145919] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 4.145928] ? smb2_write+0xc74/0xe70 [ 4.145931] kasan_report+0xce/0x100 [ 4.145934] ? smb2_write+0xc74/0xe70 [ 4.145937] smb2_write+0xc74/0xe70 [ 4.145939] ? __pfx_smb2_write+0x10/0x10 [ 4.145942] ? _raw_spin_unlock+0xe/0x30 [ 4.145945] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 4.145948] ? smb2_tree_disconnect+0x31c/0x480 [ 4.145951] handle_ksmbd_work+0x40f/0x1080 [ 4.145953] process_one_work+0x5fa/0xef0 [ 4.145962] ? assign_work+0x122/0x3e0 [ 4.145964] worker_thread+0x54b/0xf70 [ 4.145967] ? __pfx_worker_thread+0x10/0x10 [ 4.145970] kthread+0x346/0x470 [ 4.145976] ? recalc_sigpending+0x19b/0x230 [ 4.145980] ? __pfx_kthread+0x10/0x10 [ 4.145984] ret_from_fork+0x4fb/0x6c0 [ 4.145992] ? __pfx_ret_from_fork+0x10/0x10 [ 4.145995] ? __switch_to+0x36c/0xbe0 [ 4.145999] ? __pfx_kthread+0x10/0x10 [ 4.146003] ret_from_fork_asm+0x1a/0x30 [ 4.146013] [ 4.146014] [ 4.149858] Allocated by task 44: [ 4.149953] kasan_save_stack+0x33/0x60 [ 4.150061] kasan_save_track+0x14/0x30 [ 4.150169] __kasan_kmalloc+0x8f/0xa0 [ 4.150274] ksmbd_share_config_get+0x1dd/0xdd0 [ 4.150401] ksmbd_tree_conn_connect+0x7e/0x600 [ 4.150529] smb2_tree_connect+0x2e6/0x1000 [ 4.150645] handle_ksmbd_work+0x40f/0x1080 [ 4.150761] process_one_work+0x5fa/0xef0 [ 4.150873] worker_thread+0x54b/0xf70 [ 4.150978] kthread+0x346/0x470 [ 4.151071] ret_from_fork+0x4fb/0x6c0 [ 4.151176] ret_from_fork_asm+0x1a/0x30 [ 4.151286] [ 4.151332] Freed by task 44: [ 4.151418] kasan_save_stack+0x33/0x60 [ 4.151526] kasan_save_track+0x14/0x30 [ 4.151634] kasan_save_free_info+0x3b/0x60 [ 4.151751] __kasan_slab_free+0x43/0x70 [ 4.151861] kfree+0x1ca/0x430 [ 4.151952] __ksmbd_tree_conn_disconnect+0xc8/0x190 [ 4.152088] smb2_tree_disconnect+0x1cd/0x480 [ 4.152211] handle_ksmbd_work+0x40f/0x1080 [ 4.152326] process_one_work+0x5fa/0xef0 [ 4.152438] worker_thread+0x54b/0xf70 [ 4.152545] kthread+0x346/0x470 [ 4.152638] ret_from_fork+0x4fb/0x6c0 [ 4.152743] ret_from_fork_asm+0x1a/0x30 [ 4.152853] [ 4.152900] The buggy address belongs to the object at ffff88810430c180 [ 4.152900] which belongs to the cache kmalloc-96 of size 96 [ 4.153226] The buggy address is located 20 bytes inside of [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0) [ 4.153549] [ 4.153596] The buggy address belongs to the physical page: [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c [ 4.154000] flags: 0x ---truncated---", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23455", "url": "https://ubuntu.com/security/CVE-2026-23455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read. Add a check to ensure len is positive after the decrement.", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43186", "url": "https://ubuntu.com/security/CVE-2026-43186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43185", "url": "https://ubuntu.com/security/CVE-2026-43185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix signededness bug in smb_direct_prepare_negotiation() smb_direct_prepare_negotiation() casts an unsigned __u32 value from sp->max_recv_size and req->preferred_send_size to a signed int before computing min_t(int, ...). A maliciously provided preferred_send_size of 0x80000000 will return as smaller than max_recv_size, and then be used to set the maximum allowed alowed receive size for the next message. By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow. This fix replaces min_t(int, ...) with min_t(u32)", "cve_priority": "critical", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43341", "url": "https://ubuntu.com/security/CVE-2026-43341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31607", "url": "https://ubuntu.com/security/CVE-2026-31607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: validate number_of_packets in usbip_pack_ret_submit() When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the *original* number_of_packets from the CMD_SUBMIT. A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region. KASAN confirmed this with kernel 7.0.0-rc5: BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69 The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40) The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 (\"usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input\") and b78d830f0049 (\"usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input\"). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets. This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size. Kelvin Mbogo's series (\"usb: usbip: fix integer overflow in usbip_recv_iso()\", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit. Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43383", "url": "https://ubuntu.com/security/CVE-2026-43383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-md5: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2025-68263", "url": "https://ubuntu.com/security/CVE-2025-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: ipc: fix use-after-free in ipc_msg_send_request ipc_msg_send_request() waits for a generic netlink reply using an ipc_msg_table_entry on the stack. The generic netlink handler (handle_generic_event()/handle_response()) fills entry->response under ipc_msg_table_lock, but ipc_msg_send_request() used to validate and free entry->response without holding the same lock. Under high concurrency this allows a race where handle_response() is copying data into entry->response while ipc_msg_send_request() has just freed it, leading to a slab-use-after-free reported by KASAN in handle_generic_event(): BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd] Write of size 12 at addr ffff888198ee6e20 by task pool/109349 ... Freed by task: kvfree ipc_msg_send_request [ksmbd] ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd] Fix by: - Taking ipc_msg_table_lock in ipc_msg_send_request() while validating entry->response, freeing it when invalid, and removing the entry from ipc_msg_table. - Returning the final entry->response pointer to the caller only after the hash entry is removed under the lock. - Returning NULL in the error path, preserving the original API semantics. This makes all accesses to entry->response consistent with handle_response(), which already updates and fills the response buffer under ipc_msg_table_lock, and closes the race that allowed the UAF.", "cve_priority": "critical", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2026-46243", "url": "https://ubuntu.com/security/CVE-2026-46243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key.", "cve_priority": "medium", "cve_public_date": "2026-06-01 17:17:00 UTC" }, { "cve": "CVE-2026-43414", "url": "https://ubuntu.com/security/CVE-2026-43414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Completely fix fcport double free In qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free(). When an error happens, this function is called by qla2x00_sp_release(), when kref_put() releases the first and the last reference. qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport(). Doing it one more time after kref_put() is a bad idea.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43407", "url": "https://ubuntu.com/security/CVE-2026-43407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply() This patch fixes an out-of-bounds access in ceph_handle_auth_reply() that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In ceph_handle_auth_reply(), the value of the payload_len field of such a message is stored in a variable of type int. A value greater than INT_MAX leads to an integer overflow and is interpreted as a negative value. This leads to decrementing the pointer address by this value and subsequently accessing it because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. This patch fixes the issue by changing the data type of payload_len to u32. Additionally, the data type of result_msg_len is changed to u32, as it is also a variable holding a non-negative length. Also, an additional layer of sanity checks is introduced, ensuring that directly after reading it from the message, payload_len and result_msg_len are not greater than the overall segment length. BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph] Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262 CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ceph-msgr ceph_con_workfn [libceph] Call Trace: dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x620 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x72/0x210 kasan_report+0xe7/0x130 ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] __asan_report_load_n_noabort+0xf/0x20 ceph_handle_auth_reply+0x642/0x7a0 [libceph] mon_dispatch+0x973/0x23d0 [libceph] ? apparmor_socket_recvmsg+0x6b/0xa0 ? __pfx_mon_dispatch+0x10/0x10 [libceph] ? __kasan_check_write+0x14/0x30i ? mutex_unlock+0x7f/0xd0 ? __pfx_mutex_unlock+0x10/0x10 ? __pfx_do_recvmsg+0x10/0x10 [libceph] ceph_con_process_message+0x1f1/0x650 [libceph] process_message+0x1e/0x450 [libceph] ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] ? save_fpregs_to_fpstate+0xb0/0x230 ? raw_spin_rq_unlock+0x17/0xa0 ? finish_task_switch.isra.0+0x13b/0x760 ? __switch_to+0x385/0xda0 ? __kasan_check_write+0x14/0x30 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 ceph_con_workfn+0x248/0x10c0 [libceph] process_one_work+0x629/0xf80 ? __kasan_check_write+0x14/0x30 worker_thread+0x87f/0x1570 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_try_to_wake_up+0x10/0x10 ? kasan_print_address_stack_frame+0x1f7/0x280 ? __pfx_worker_thread+0x10/0x10 kthread+0x396/0x830 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? __pfx_kthread+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? recalc_sigpending+0x180/0x210 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3f7/0x610 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x385/0xda0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 [ idryomov: replace if statements with ceph_decode_need() for payload_len and result_msg_len ]", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43406", "url": "https://ubuntu.com/security/CVE-2026-43406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in process_message_header() If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in process_message_header(). Perform an explicit bounds check before decoding the message header.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43304", "url": "https://ubuntu.com/security/CVE-2026-43304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.", "cve_priority": "critical", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-37924", "url": "https://ubuntu.com/security/CVE-2025-37924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in kerberos authentication Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbd_free_user but before sess->user is set to NULL.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37778", "url": "https://ubuntu.com/security/CVE-2025-37778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix dangling pointer in krb_authenticate krb_authenticate frees sess->user and does not set the pointer to NULL. It calls ksmbd_krb5_authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2_sess_setup, which calls krb_authenticate, will be accessing free'd memory when it later uses sess->user.", "cve_priority": "high", "cve_public_date": "2025-05-01 14:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2157390, 1786013, 2157405, 2154194, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156629, 2156629, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198 ], "changes": [ { "cves": [ { "cve": "CVE-2026-46137", "url": "https://ubuntu.com/security/CVE-2026-46137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: fix potential data-race This mptcp_pm_add_timer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bh_lock_sock(). If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46275", "url": "https://ubuntu.com/security/CVE-2026-46275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart. The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the `hu` struct. When the scheduled work executes later, it blindly dereferences the freed `hu` struct. Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently. Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities.", "cve_priority": "high", "cve_public_date": "2026-06-08 16:16:00 UTC" }, { "cve": "CVE-2025-23141", "url": "https://ubuntu.com/security/CVE-2025-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where \"accepting\" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit can access guest memory. The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triple_fault_event_test selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario. ============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted ----------------------------- include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2026-43052", "url": "https://ubuntu.com/security/CVE-2026-43052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check tdls flag in ieee80211_tdls_oper When NL80211_TDLS_ENABLE_LINK is called, the code only checks if the station exists but not whether it is actually a TDLS station. This allows the operation to proceed for non-TDLS stations, causing unintended side effects like modifying channel context and HT protection before failing. Add a check for sta->sta.tdls early in the ENABLE_LINK case, before any side effects occur, to ensure the operation is only allowed for actual TDLS peers.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2025-22107", "url": "https://ubuntu.com/security/CVE-2025-22107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry() There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-21863", "url": "https://ubuntu.com/security/CVE-2025-21863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: prevent opcode speculation sqe->opcode is used for different tables, make sure we santitise it against speculations.", "cve_priority": "low", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2026-46274", "url": "https://ubuntu.com/security/CVE-2026-46274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io-wq: check that the predecessor is hashed in io_wq_remove_pending() io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0]. Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory. Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot.", "cve_priority": "high", "cve_public_date": "2026-06-08 16:16:00 UTC" }, { "cve": "CVE-2026-45846", "url": "https://ubuntu.com/security/CVE-2026-45846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst() bareudp_fill_metadata_dst() passes bareudp->sock to udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check. The socket is only created in bareudp_open() and NULLed in bareudp_stop(), so calling this function while the device is down triggers a NULL dereference via sock->sk. BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160) Call Trace: bareudp_fill_metadata_dst (drivers/net/bareudp.c:532) do_execute_actions (net/openvswitch/actions.c:901) ovs_execute_actions (net/openvswitch/actions.c:1589) ovs_packet_cmd_execute (net/openvswitch/datapath.c:700) genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1209) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths in the same driver.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45844", "url": "https://ubuntu.com/security/CVE-2026-45844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: arp_tables: fix IEEE1394 ARP payload parsing Weiming Shi says: \"arp_packet_match() unconditionally parses the ARP payload assuming two hardware addresses are present (source and target). However, IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address field, and arp_hdr_len() already accounts for this by returning a shorter length for ARPHRD_IEEE1394 devices. As a result, on IEEE1394 interfaces arp_packet_match() advances past a nonexistent target hardware address and reads the wrong bytes for both the target device address comparison and the target IP address. This causes arptables rules to match against garbage data, leading to incorrect filtering decisions: packets that should be accepted may be dropped and vice versa. The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already handles this correctly by skipping the target hardware address for ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match().\" Mangle the original patch to always return 0 (no match) in case user matches on the target hardware address which is never present in IEEE1394. Note that this returns 0 (no match) for either normal and inverse match because matching in the target hardware address in ARPHRD_IEEE1394 has never been supported by arptables. This is intentional, matching on the target hardware address should never evaluate true for ARPHRD_IEEE1394. Moreover, adjust arpt_mangle to drop the packet too as AI suggests: In arpt_mangle, the logic assumes a standard ARP layout. Because IEEE1394 (FireWire) omits the target hardware address, the linear pointer arithmetic miscalculates the offset for the target IP address. This causes mangling operations to write to the wrong location, leading to packet corruption. To ensure safety, this patch drops packets (NF_DROP) when mangling is requested for these fields on IEEE1394 devices, as the current implementation cannot correctly map the FireWire ARP payload. This omits both mangling target hardware and IP address. Even if IP address mangling should be possible in IEEE1394, this would require to adjust arpt_mangle offset calculation, which has never been supported. Based on patch from Weiming Shi .", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45843", "url": "https://ubuntu.com/security/CVE-2026-45843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: bound decode() reads against the compressed packet length slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code. A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets. Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45842", "url": "https://ubuntu.com/security/CVE-2026-45842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: reject VJ receive packets on instances with no rstate array slhc_init() accepts rslots == 0 as a valid configuration, with the documented meaning of 'no receive compression'. In that case the allocation loop in slhc_init() is skipped, so comp->rstate stays NULL and comp->rslot_limit stays 0 (from the kzalloc of struct slcompress). The receive helpers do not defend against that configuration. slhc_uncompress() dereferences comp->rstate[x] when the VJ header carries an explicit connection ID, and slhc_remember() later assigns cs = &comp->rstate[...] after only comparing the packet's slot number to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the range check, and the code dereferences a NULL rstate. The configuration is reachable in-tree through PPP. PPPIOCSMAXCID stores its argument in a signed int, and (val >> 16) uses arithmetic shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1 is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because /dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path is reachable from an unprivileged user namespace. Once the malformed VJ state is installed, any inbound VJ-compressed or VJ-uncompressed frame that selects slot 0 crashes the kernel in softirq context: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519) Call Trace: ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466) ppp_input (drivers/net/ppp/ppp_generic.c:2359) ppp_async_process (drivers/net/ppp/ppp_async.c:492) tasklet_action_common (kernel/softirq.c:926) handle_softirqs (kernel/softirq.c:623) run_ksoftirqd (kernel/softirq.c:1055) smpboot_thread_fn (kernel/smpboot.c:160) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) Reject the receive side on such instances instead of touching rstate. slhc_uncompress() falls through to its existing 'bad' label, which bumps sls_i_error and enters the toss state. slhc_remember() mirrors that with an explicit sls_i_error increment followed by slhc_toss(); the sls_i_runt counter is not used here because a missing rstate is an internal configuration state, not a runt packet. The transmit path is unaffected: the only in-tree caller that picks rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and slip.c always calls slhc_init(16, 16), so comp->tstate remains valid and slhc_compress() continues to work.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45841", "url": "https://ubuntu.com/security/CVE-2026-45841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO nf_osf_match_one() computes ctx->window % f->wss.val in the OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a subsequent matching TCP SYN divides by zero and panics the kernel. Reject the bogus fingerprint in nfnl_osf_add_callback() above the per-option for-loop. f->wss is per-fingerprint, not per-option, so the check must run regardless of f->opt_num (including 0). Also reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that as \"should not happen\". Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:220) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:348) nf_hook_slow (net/netfilter/core.c:622) ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv (include/linux/skbuff.h:1162) __netif_receive_skb_one_core (net/core/dev.c:6181) process_backlog (net/core/dev.c:6642) __napi_poll (net/core/dev.c:7710) net_rx_action (net/core/dev.c:7945) handle_softirqs (kernel/softirq.c:622)", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45840", "url": "https://ubuntu.com/security/CVE-2026-45840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: cap upcall PID array size and pre-size vport replies The vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENL_UNS_ADMIN_PERM. kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Kernel panic - not syncing: Fatal exception Reject attempts to set more PIDs than nr_cpu_ids in ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply size in ovs_vport_cmd_msg_size() based on that bound, similar to the existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the two sides stay consistent.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46319", "url": "https://ubuntu.com/security/CVE-2026-46319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: Only release RCU read lock after ct_ft When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero() is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft object. This vulnerability can lead to privilege escalation. Analysis from zdi-disclosures@trendmicro.com: When initializing act_ct, tcf_ct_init() is called, which internally triggers tcf_ct_flow_table_get(). static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params) { struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ... } static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params) { void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj; } At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft from zones_ht . The lookup is performed within an RCU read critical section through rcu_read_lock() / rcu_read_unlock(), which prevents the object from being freed. However, at the point of function return, rcu_read_unlock() has already been called, and there is nothing preventing ct_ft from being freed before reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomes the race window, during which ct_ft can be freed. Free Process: tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put(). static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft) { if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); } } At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work static void tcf_ct_flow_table_cleanup_work(struct work_struct *work) { struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE); } tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes between [1] and [2], UAF occurs. This race condition has a very short race window, making it generally difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was inserted after[1]", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-45839", "url": "https://ubuntu.com/security/CVE-2026-45839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec() CO-RE accessor strings are colon-separated indices that describe a path from a root BTF type to a target field, e.g. \"0:1:2\" walks through nested struct members. bpf_core_parse_spec() parses each component with sscanf(\"%d\"), so negative values like -1 are silently accepted. The subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the upper bound and always pass for negative values because C integer promotion converts the __u16 btf_vlen result to int, making the comparison (int)(-1) >= (int)(N) false for any positive N. When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff, producing an out-of-bounds read far past the members array. A crafted BPF program with a negative CO-RE accessor on any struct that exists in vmlinux BTF (e.g. task_struct) crashes the kernel deterministically during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y (default on major distributions). The bug is reachable with CAP_BPF: BUG: unable to handle page fault for address: ffffed11818b6626 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full) RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354) RAX: 00000000ffffffff Call Trace: bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321) bpf_core_apply (kernel/bpf/btf.c:9507) check_core_relo (kernel/bpf/verifier.c:19475) bpf_check (kernel/bpf/verifier.c:26031) bpf_prog_load (kernel/bpf/syscall.c:3089) __sys_bpf (kernel/bpf/syscall.c:6228) CO-RE accessor indices are inherently non-negative (struct member index, array element index, or enumerator index), so reject them immediately after parsing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45838", "url": "https://ubuntu.com/security/CVE-2026-45838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix end-of-list detection in cgroup_storage_get_next_key() list_next_entry() never returns NULL -- when the current element is the last entry it wraps to the list head via container_of(). The subsequent NULL check is therefore dead code and get_next_key() never returns -ENOENT for the last element, instead reading storage->key from a bogus pointer that aliases internal map fields and copying the result to userspace. Replace it with list_entry_is_head() so the function correctly returns -ENOENT when there are no more entries.", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46214", "url": "https://ubuntu.com/security/CVE-2026-46214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix accept queue count leak on transport mismatch virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listener to reject all new connections. Fix by moving sk_acceptq_added() to after the transport validation, matching the pattern used by vmci_transport and hyperv_transport.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46234", "url": "https://ubuntu.com/security/CVE-2026-46234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: fix buffer size clamping order In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint. This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size. Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45836", "url": "https://ubuntu.com/security/CVE-2026-45836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46231", "url": "https://ubuntu.com/security/CVE-2026-46231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: put backbone reference on failed claim hash insert When batadv_bla_add_claim() fails to insert a new claim into the hash, it leaked a reference to the backbone_gw for which the claim was intended. Call batadv_backbone_gw_put() on the error path to release the reference and avoid leaking the backbone_gw object.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46233", "url": "https://ubuntu.com/security/CVE-2026-46233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: only purge non-released claims When batadv_bla_purge_claims() goes through the list of claims, it is only traversing the hash list with an rcu_read_lock(). Due to a potential parallel batadv_claim_put(), it can happen that it encounters a claim which was actually in the process of being released+freed by batadv_claim_release(). In this case, backbone_gw is set to NULL before the delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is then no longer allowed because it would cause a NULL-ptr derefence. To avoid this, only claims with a valid reference counter must be purged. All others are already taken care of.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46212", "url": "https://ubuntu.com/security/CVE-2026-46212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: prevent use-after-free when deleting claims When batadv_bla_del_backbone_claims() removes all claims for a backbone, it does this by dropping the link entry in the hash list. This list entry itself was one of the references which need to be dropped at the same time via batadv_claim_put(). But the batadv_claim_put() must not be done before the last access to the claim object in this function. Otherwise the claim might be freed already by the batadv_claim_release() function before the list entry was dropped.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46238", "url": "https://ubuntu.com/security/CVE-2026-46238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop caching unowned originator pointers in BAT IV BAT IV keeps the last-hop neighbor address in each neigh_node, but some paths also cache an originator pointer derived from a temporary lookup. That pointer is not owned by the neigh_node and may no longer refer to a live originator entry after purge handling runs. Stop storing the auxiliary originator pointer in the BAT IV neighbor state. When BAT IV needs the neighbor originator data, resolve it from the stored neighbor address and drop the reference again after use. [sven: avoid bonding logic for outgoing OGM]", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46206", "url": "https://ubuntu.com/security/CVE-2026-46206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject new tp_meter sessions during teardown Prevent tp_meter from starting new sender or receiver sessions after mesh_state has left BATADV_MESH_ACTIVE.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46198", "url": "https://ubuntu.com/security/CVE-2026-46198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix integer overflow on buff_pos Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size check is done using the int type in batadv_iv_ogm_aggr_packet whereas the buff_pos variable uses the s16 type. This could lead to an out-of-bound read.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46227", "url": "https://ubuntu.com/security/CVE-2026-46227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the \"sk != asoc->base.sk\" and \"asoc->base.dead\" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 (\"sctp: walk the list of asoc safely\") was added for.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46220", "url": "https://ubuntu.com/security/CVE-2026-46220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission sdma_v4_0_ring_emit_fence() contains two BUG_ON(addr & 0x3) assertions that verify fence writeback addresses are dword-aligned. These assertions can be reached from unprivileged userspace via crafted DRM_IOCTL_AMDGPU_CS submissions, causing a fatal kernel panic in a scheduler worker thread. Replace both BUG_ON() calls with WARN_ON() to log the condition without crashing the kernel. A misaligned fence address at this point indicates a driver bug, but crashing the kernel is never the correct response when the assertion is reachable from userspace. The CS IOCTL path is the correct place to filter invalid submissions; the ring emission callback is too late to do anything about it. (cherry picked from commit b90250bd933afd1ba94d86d6b13821997b22b18e)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46197", "url": "https://ubuntu.com/security/CVE-2026-46197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: validate SVM ioctl nattr against buffer size Validate nattr field against the buffer size, preventing out-of-bounds buffer access via user-controlled attribute count. (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46209", "url": "https://ubuntu.com/security/CVE-2026-46209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1); However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value. A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46230", "url": "https://ubuntu.com/security/CVE-2026-46230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg Check bounds against the end of the BO whenever we access the msg.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46219", "url": "https://ubuntu.com/security/CVE-2026-46219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix use-after-free on unbind The state machine work is scheduled by the interrupt handler and therefore needs to be cancelled after disabling interrupts to avoid a potential use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46236", "url": "https://ubuntu.com/security/CVE-2026-46236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: xbox_remote: heed DMA restrictions The buffer for IO must not be part of the device structure because that violates the DMA coherency rules.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46205", "url": "https://ubuntu.com/security/CVE-2026-46205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: media: atomisp: Disallow all private IOCTLs Disallow all private IOCTLs. These aren't quite as safe as one could assume of IOCTL handlers; disable them for now. Instead of removing the code, return in the beginning of the function if cmd is non-zero in order to keep static checkers happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46168", "url": "https://ubuntu.com/security/CVE-2026-46168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix scheduling with atomic in timestamp sockopt Using lock_sock_fast() (atomic context) around sock_set_timestamp() and sock_set_timestamping() is unsafe, as both helpers can sleep. Replace lock_sock_fast() with sleepable lock_sock()/release_sock() to avoid scheduling while atomic panic.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46189", "url": "https://ubuntu.com/security/CVE-2026-46189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path Sashiko points out that pvrdma_uar_free() is already called within pvrdma_dealloc_ucontext(), so calling it before triggers a double free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46133", "url": "https://ubuntu.com/security/CVE-2026-46133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject unknown opcodes before ICRC processing Even after applying commit 7244491dab34 (\"RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv\"), a single unauthenticated UDP packet can still trigger panic. That patch handled payload_size() underflow only for valid opcodes with short packets, not for packets carrying an unknown opcode. The unknown-opcode OOB read described below predates that commit and reaches back to the initial Soft RoCE driver. The check added there reads pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The rxe_opcode[] array has 256 entries but is only populated for defined IB opcodes; any other entry (for example opcode 0xff) is zero-initialized, so length == 0 and the check degenerates to pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES which underflows when length == 0 and passes a huge value to rxe_crc32(), causing an out-of-bounds read of the skb payload. Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma link add rxe0 type rxe netdev eth0 A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and QPN=IB_MULTICAST_QPN triggers: BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170 Read of size 1 at addr ... The buggy address is located 0 bytes to the right of allocated 704-byte region Call Trace: crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 Subsequent packets with the same shape fault on unmapped memory and panic the kernel. The trigger requires only module load and \"rdma link add\"; no QP, no connection, and no authentication. Fix this by rejecting packets whose opcode has no rxe_opcode[] entry, detected via the zero mask or zero length, before any length arithmetic runs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46127", "url": "https://ubuntu.com/security/CVE-2026-46127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp() Sashiko points out that pd->uctx isn't initialized until late in the function so all these error flow references are NULL and will crash. Use the uctx that isn't NULL.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46178", "url": "https://ubuntu.com/security/CVE-2026-46178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq() Sashiko points out that mlx4_srq_alloc() was not undone during error unwind, add the missing call to mlx4_srq_free().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46112", "url": "https://ubuntu.com/security/CVE-2026-46112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix unlocked call to hns_roce_qp_remove() Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory. Grab the same locks the other two callers use.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46304", "url": "https://ubuntu.com/security/CVE-2026-46304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the final controller reference through nvmet_cq_put(). If that triggers nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on the same nvmet-wq. Call chain: nvmet_tcp_schedule_release_queue() kref_put(&queue->kref, nvmet_tcp_release_queue) nvmet_tcp_release_queue() queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq process_one_work() nvmet_tcp_release_queue_work() nvmet_cq_put(&queue->nvme_cq) nvmet_cq_destroy() nvmet_ctrl_put(cq->ctrl) nvmet_ctrl_free() flush_work(&ctrl->async_event_work) <--- nvmet_wq Previously Scheduled by :- \t\t nvmet_add_async_event \t\t queue_work(nvmet_wq, &ctrl->async_event_work); This trips lockdep with a possible recursive locking warning. [ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55 [ 5223.061801] loop0: detected capacity change from 0 to 2097152 [ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 [ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420) [ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349. [ 5223.128453] nvme nvme1: new ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349 [ 5233.199447] nvme nvme1: Removing ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\" [ 5233.227718] ============================================ [ 5233.231283] WARNING: possible recursive locking detected [ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N [ 5233.238434] -------------------------------------------- [ 5233.241852] kworker/u192:6/2413 is trying to acquire lock: [ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 [ 5233.251438] but task is already holding lock: [ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.261125] other info that might help us debug this: [ 5233.265333] Possible unsafe locking scenario: [ 5233.269217] CPU0 [ 5233.270795] ---- [ 5233.272436] lock((wq_completion)nvmet-wq); [ 5233.275241] lock((wq_completion)nvmet-wq); [ 5233.278020] *** DEADLOCK *** [ 5233.281793] May be due to missing lock nesting notation [ 5233.286195] 3 locks held by kworker/u192:6/2413: [ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0 [ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 [ 5233.304290] stack backtrace: [ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full) [ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST [ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp] [ 5233.306532] Call Trace: [ 5233.306534] [ 5233.306536] dump_stack_lvl+0x73/0xb0 [ 5233.306552] print_deadlock_bug+0x225/0x2f0 [ 5233.306556] __lock_acquire+0x13f0/0x2290 [ 5233.306563] lock_acquire+0xd0/0x300 [ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306571] ? __flush_work+0x20b/0x530 [ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306577] touch_wq_lockdep_map+0x3b/0x90 [ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90 [ 52 ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46161", "url": "https://ubuntu.com/security/CVE-2026-46161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix divide-by-zero in setup_geo() with zero far_copies setup_geo() extracts near_copies (nc) and far_copies (fc) from the user-provided layout parameter without checking for zero. When fc=0 with the \"improved\" far set layout selected, 'geo->far_set_size = disks / fc' triggers a divide-by-zero. Validate nc and fc immediately after extraction, returning -1 if either is zero.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46124", "url": "https://ubuntu.com/security/CVE-2026-46124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate block number from NFS file handle in isofs_export_iget isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker- controlled block number (ifid->block or ifid->parent_block) from the NFS file handle to isofs_export_iget(), which only rejects block == 0 before calling isofs_iget() and ultimately sb_bread(). A crafted file handle with fh_len sufficient to pass the check added by commit 0405d4b63d08 (\"isofs: Prevent the use of too small fid\") can still drive the server to read any in-range block on the backing device as if it were an iso_directory_record. That earlier fix was assigned CVE-2025-37780. sb_bread() on an out-of-range block returns NULL cleanly via the EIO path, so there is no memory-safety violation. For in-range reads of adjacent-partition data on the same block device, the unrelated bytes end up in iso_inode_info fields that reach the NFS client as dentry metadata. The deployment surface (isofs exported over NFS from loop-mounted images) is narrow and requires an authenticated NFS peer, but the malformed-file-handle class is reportable as hardening next to the existing CVE-2025-37780 fix. Reject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent() call sites with a single line.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46303", "url": "https://ubuntu.com/security/CVE-2026-46303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b (\"[PATCH] rock.c: handle corrupted directories\") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 (\"isofs: Fix infinite looping over CE entries\") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.", "cve_priority": "medium", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46294", "url": "https://ubuntu.com/security/CVE-2026-46294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a buffer overflow in ioctl processing Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the \"outptr\" variable to the next 8-byte boundary: \toutptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The \"for\" loop is iterated again, it executes: \tremaining = len - (outptr - outbuf); 5. If \"outptr\" points past \"outbuf + len\", the arithmetics wraps around and the variable \"remaining\" contains unusually high number 6. With \"remaining\" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, \"outptr = align_ptr(outptr)\" can't overshoot the input buffer and the bug can't happen accidentally", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46107", "url": "https://ubuntu.com/security/CVE-2026-46107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-thin: fix metadata refcount underflow There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count. If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in \"device mapper: space map common: unable to decrement block\" errors. Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46301", "url": "https://ubuntu.com/security/CVE-2026-46301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: topcliff-pch: fix use-after-free on unbind Give the driver a chance to flush its queue before releasing the DMA buffers on driver unbind", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46273", "url": "https://ubuntu.com/security/CVE-2026-46273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmveth: Disable GSO for packets with small MSS Some physical adapters on Power systems do not support segmentation offload when the MSS is less than 224 bytes. Attempting to send such packets causes the adapter to freeze, stopping all traffic until manually reset. Implement ndo_features_check to disable GSO for packets with small MSS values. The network stack will perform software segmentation instead. The 224-byte minimum matches ibmvnic commit (\"ibmvnic: Enforce stronger sanity checks on GSO packets\") which uses the same physical adapters in SEA configurations. The issue occurs specifically when the hardware attempts to perform segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets (gso_segs == 1) do not trigger the problematic LSO code path and are transmitted normally without segmentation. Add an ndo_features_check callback to disable GSO when MSS < 224 bytes. Also call vlan_features_check() to ensure proper handling of VLAN packets, particularly QinQ (802.1ad) configurations where the hardware parser may not support certain offload features. Validated using iptables to force small MSS values. Without the fix, the adapter freezes. With the fix, packets are segmented in software and transmission succeeds. Comprehensive regression testing completedd (MSS tests, performance, stability).", "cve_priority": "high", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-43502", "url": "https://ubuntu.com/security/CVE-2026-43502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: handle zerocopy send cleanup before the message is queued A zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket. The purge path currently infers zerocopy state from rm->m_rs, so an unqueued message can be cleaned up as if it owned normal payload pages. However, zerocopy ownership is really determined by the presence of op_mmp_znotifier, regardless of whether the message has reached the socket queue. Capture op_mmp_znotifier up front in rds_message_purge() and use it as the cleanup discriminator. If the message is already associated with a socket, keep the existing completion path. Otherwise, drop the pinned page accounting directly and release the notifier before putting the payload pages. This keeps early send failure cleanup consistent with the zerocopy lifetime rules without changing the normal queued completion path.", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46120", "url": "https://ubuntu.com/security/CVE-2026-46120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: Use cached t->net in ip6erspan_changelink(). After commit 5e72ce3e3980 (\"net: ipv6: Use link netns in newlink() of rtnl_link_ops\"), ip6erspan_newlink() correctly resolves the per-netns ip6gre hash via link_net. ip6erspan_changelink() was not converted in that series and still uses dev_net(dev), which diverges from the device's creation netns after IFLA_NET_NS_FD migration. This re-inserts the tunnel into the wrong per-netns hash. The original netns keeps a stale entry. When that netns is later destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a slab-use-after-free reported by KASAN, followed by a kernel BUG at net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify(). Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). ip6gre_changelink() earlier in the same file already uses the cached t->net; only ip6erspan_changelink() has the wrong shape.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46184", "url": "https://ubuntu.com/security/CVE-2026-46184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sound: ua101: fix division by zero at probe Add a missing sanity check for bNrChannels in detect_usb_format() to prevent a division by zero in playback_urb_complete() and capture_urb_complete(). USB core does not validate class-specific descriptor fields such as bNrChannels, so drivers must verify them before use. If a device provides bNrChannels = 0, frame_bytes becomes zero and is later used as a divisor in the URB completion handlers, leading to a kernel crash.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46132", "url": "https://ubuntu.com/security/CVE-2026-46132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack without initialisation: \tstruct ifla_vf_broadcast vf_broadcast; The struct contains a single fixed 32-byte field: \t/* include/uapi/linux/if_link.h */ \tstruct ifla_vf_broadcast { \t\t__u8 broadcast[32]; \t}; The function then copies dev->broadcast into it using dev->addr_len as the length: \tmemcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len); On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via: \tnla_put(skb, IFLA_VF_BROADCAST, \t\tsizeof(vf_broadcast), &vf_broadcast) leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK request, repeatable. The other vf_* structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vf_vlan_info, node_guid and port_guid a few lines above. vf_broadcast was simply missed when it was added. Reachability: any unprivileged local process can open AF_NETLINK / NETLINK_ROUTE without capabilities and send RTM_GETLINK with an IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nla_put() when reproduced. Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf_* structs in the same function.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46150", "url": "https://ubuntu.com/security/CVE-2026-46150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fanotify: fix false positive on permission events fsnotify_get_mark_safe() may return false for a mark on an unrelated group, which results in bypassing the permission check. Fix by skipping over detached marks that are not in the current group.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45834", "url": "https://ubuntu.com/security/CVE-2026-45834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-45835", "url": "https://ubuntu.com/security/CVE-2026-45835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46186", "url": "https://ubuntu.com/security/CVE-2026-46186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: validate rx pkt_type header length virtbt_rx_handle() reads the leading pkt_type byte from the RX skb and forwards the remainder to hci_recv_frame() for every event/ACL/SCO/ISO type, without checking that the remaining payload is at least the fixed HCI header for that type. After the preceding patch bounds the backend-supplied used.len to [1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches hci_recv_frame() with skb->len already pulled to 0. If the byte happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification fast-path in hci_dev_classify_pkt_type() dereferences hci_acl_hdr(skb)->handle whenever the HCI device has an active CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of uninitialized RX-buffer data. The same hazard exists for every packet type the driver accepts because none of the switch cases in virtbt_rx_handle() check skb->len against the per-type minimum HCI header size before handing the frame to the core. After stripping pkt_type, require skb->len to cover the fixed header size for the selected type (event 2, ACL 4, SCO 3, ISO 4) before calling hci_recv_frame(); drop ratelimited otherwise. Unknown pkt_type values still take the original kfree_skb() default path. Use bt_dev_err_ratelimited() because both the length and pkt_type values come from an untrusted backend that can otherwise flood the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46123", "url": "https://ubuntu.com/security/CVE-2026-46123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: clamp rx length before skb_put virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one(). Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device. The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory. Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle(). Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log. Same class of bug as commit c04db81cd028 (\"net/9p: Fix buffer overflow in USB transport layer\"), which hardened the USB 9p transport against unchecked device-reported length.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46172", "url": "https://ubuntu.com/security/CVE-2026-46172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: xfrm6: release dst on error in xfrm6_rcv_encap() xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6_route_input_lookup() returns a referenced dst entry even when the lookup resolves to an error route. If dst->error is set, xfrm6_rcv_encap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries. Release the dst before jumping to the drop path.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46146", "url": "https://ubuntu.com/security/CVE-2026-46146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3() The convert_chmap_v3() has a loop with its increment size of cs_desc->wLength, but we forgot to validate cs_desc->wLength itself, which may lead to potential endless loop by a malformed descriptor. Add a proper size check to abort the loop for plugging the hole.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46167", "url": "https://ubuntu.com/security/CVE-2026-46167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. Ideally that short command should be detected and error out, but many printers are known to send \"incorrect\" responses back so we can't just do that. statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl. usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller. Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no \"leak\" of information happening.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46151", "url": "https://ubuntu.com/security/CVE-2026-46151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix heap leak in IEEE 1284 device ID via short response usblp_ctrl_msg() collapses the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GET_DEVICE_ID control transfer short and the driver has no way to know. usblp_cache_device_id_string() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves device_id_string[2..1022] holding stale kmalloc heap. That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf(\"%s\", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device. Fix this up by just zapping the buffer with zeros before each request sent to the device.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46122", "url": "https://ubuntu.com/security/CVE-2026-46122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43: enforce bounds check on firmware key index in b43_rx() The firmware-controlled key index in b43_rx() can exceed the dev->key[] array size (58 entries). The existing B43_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read. Make the B43_WARN_ON check enforcing by dropping the frame when the firmware returns an invalid key index.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46307", "url": "https://ubuntu.com/security/CVE-2026-46307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath5k: do not access array OOB Vincent reports: > The ath5k driver seems to do an array-index-out-of-bounds access as > shown by the UBSAN kernel message: > UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20 > index 4 is out of range for type 'ieee80211_tx_rate [4]' > ... > Call Trace: > > dump_stack_lvl+0x5d/0x80 > ubsan_epilogue+0x5/0x2b > __ubsan_handle_out_of_bounds.cold+0x46/0x4b > ath5k_tasklet_tx+0x4e0/0x560 [ath5k] > tasklet_action_common+0xb5/0x1c0 It is real. 'ts->ts_final_idx' can be 3 on 5212, so: info->status.rates[ts->ts_final_idx + 1].idx = -1; with the array defined as: struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES]; while the size is: #define IEEE80211_TX_MAX_RATES 4 is indeed bogus. Set this 'idx = -1' sentinel only if the array index is less than the array size. As mac80211 will not look at rates beyond the size (IEEE80211_TX_MAX_RATES). Note: The effect of the OOB write is negligible. It just overwrites the next member of info->status, i.e. ack_signal.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46187", "url": "https://ubuntu.com/security/CVE-2026-46187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: fix kthread lifetime race between self-exit and external-stop RSI driver use both self-exit(kthread_complete_and_exit) and external-stop (kthread_stop) when killing a kthread. Generally, kthread_stop() is called first, and in this case, no particular issues occur. However, in rare instances where kthread_complete_and_exit() is called first and then kthread_stop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again. Therefore, to prevent this with minimal modification, you must remove kthread_stop() and change the code to wait until the self-exit operation is completed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46163", "url": "https://ubuntu.com/security/CVE-2026-46163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43legacy: enforce bounds check on firmware key index in RX path Same fix as b43: the firmware-controlled key index in b43legacy_rx() can exceed dev->max_nr_keys. The existing B43legacy_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read of dev->key[]. Make the check enforcing by dropping the frame for invalid indices.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46044", "url": "https://ubuntu.com/security/CVE-2026-46044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:ssif: Clean up kthread on errors If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43496", "url": "https://ubuntu.com/security/CVE-2026-43496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peeked When red qdisc has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] [ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq] [ 78.672148][ T363] ? __pfx__printk+0x10/0x10 [ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0 [ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0 [ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red] [ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf] [ 78.673566][ T363] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead.", "cve_priority": "medium", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2024-56727", "url": "https://ubuntu.com/security/CVE-2024-56727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c Adding error pointer check after calling otx2_mbox_get_rsp().", "cve_priority": "medium", "cve_public_date": "2024-12-29 12:15:00 UTC" }, { "cve": "CVE-2026-31489", "url": "https://ubuntu.com/security/CVE-2026-31489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: meson-spicc: Fix double-put in remove path meson_spicc_probe() registers the controller with devm_spi_register_controller(), so teardown already drops the controller reference via devm cleanup. Calling spi_controller_put() again in meson_spicc_remove() causes a double-put.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31476", "url": "https://ubuntu.com/security/CVE-2026-31476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: do not expire session on binding failure When a multichannel session binding request fails (e.g. wrong password), the error path unconditionally sets sess->state = SMB2_SESSION_EXPIRED. However, during binding, sess points to the target session looked up via ksmbd_session_lookup_slowpath() -- which belongs to another connection's user. This allows a remote attacker to invalidate any active session by simply sending a binding request with a wrong password (DoS). Fix this by skipping session expiration when the failed request was a binding attempt, since the session does not belong to the current connection. The reference taken by ksmbd_session_lookup_slowpath() is still correctly released via ksmbd_user_session_put().", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43497", "url": "https://ubuntu.com/security/CVE-2026-43497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages to userspace but sets no vm_ops on the VMA. This means the kernel cannot track active mmaps. When dlfb_realloc_framebuffer() replaces the backing buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated. On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages while userspace PTEs still reference them, resulting in a use-after-free: the process retains read/write access to freed kernel pages. Add vm_operations_struct with open/close callbacks that maintain an atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(), check mmap_count and return -EBUSY if the buffer is currently mapped, preventing buffer replacement while userspace holds stale PTEs. Tested with PoC using dummy_hcd + raw_gadget USB device emulation.", "cve_priority": "low", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46108", "url": "https://ubuntu.com/security/CVE-2026-46108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:si: Return state to normal if message allocation fails There were places where nothing would get started if a message allocation failed, so the driver needs to return to normal state.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46128", "url": "https://ubuntu.com/security/CVE-2026-46128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Check event message buffer response for bad data The event message buffer response data size got checked later when processing, but check it right after the response comes back. It appears some BMCs may return an empty message instead of an error when fetching events. There are apparently some new BMCs that make this error, so we need to compensate.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46177", "url": "https://ubuntu.com/security/CVE-2026-46177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Add limits to event and receive message requests The driver would just fetch events and receive messages until the BMC said it was done. To avoid issues with BMCs that never say they are done, add a limit of 10 fetches at a time. In addition, an si interface has an attn state it can return from the hardware which is supposed to cause a flag fetch to see if the driver needs to fetch events or message or a few other things. If the attn bit gets stuck, it's a similar problem. So allow messages in between flag fetches so the driver itself doesn't get stuck. This is a more general fix than the previous fix for the specific bad BMC, but should fix the more general issue of a BMC that won't stop saying it has data. This has been there from the beginning of the driver. It's not a bug per-se, but it is accounting for bugs in BMCs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46149", "url": "https://ubuntu.com/security/CVE-2026-46149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show() target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered. Commit 27e06650a5ea (\"scsi: target: target_core_configfs: Add length check to avoid buffer overflow\") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46101", "url": "https://ubuntu.com/security/CVE-2026-46101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: reject zero shift in nft_bitwise Reject zero shift operands for nft_bitwise left and right shift expressions during initialization. The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour. Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46099", "url": "https://ubuntu.com/security/CVE-2026-46099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels seg6_input_core() and rpl_input() call ip6_route_input() which sets a NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking dst_hold() unconditionally. On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpu_rt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence: ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1] rt_genid_bump_ipv6() -> bumps fib6_sernum [fib6_sernum from W to Z] ip6_route_output() -> ip6_pol_route() -> FIB lookup resolves fib6_nh [nhid=N] -> rt6_get_pcpu_route() pcpu_rt->sernum != fib6_sernum [W <> Z, stale] -> prev = xchg(rt6i_pcpu, NULL) -> dst_release(prev) [prev is pcpu_rt, refcount 1->0, dead] dst = skb_dst(skb) [dst is the dead pcpu_rt] dst_cache_set_ip6(dst) -> dst_hold() on dead dst -> WARN / use-after-free For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release the pcpu_rt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6_nh and its rt6i_pcpu entry. Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after ip6_route_input() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6_route_output() already returns a refcounted dst.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46033", "url": "https://ubuntu.com/security/CVE-2026-46033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject short ahash digests during instance creation authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46062", "url": "https://ubuntu.com/security/CVE-2026-46062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix integer overflow in run_unpack() volume boundary check The volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses raw addition which can wrap around for large lcn and len values, bypassing the validation. Use check_add_overflow() as is already done for the adjacent prev_lcn + dlcn and vcn64 + len checks added by commit 3ac37e100385 (\"ntfs3: Fix integer overflow in run_unpack()\"). Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46072", "url": "https://ubuntu.com/security/CVE-2026-46072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: add buffer boundary checks to run_unpack() run_unpack() checks `run_buf < run_last` at the top of the while loop but then reads size_size and offset_size bytes via run_unpack_s64() without verifying they fit within the remaining buffer. A crafted NTFS image with truncated run data in an MFT attribute triggers an OOB heap read of up to 15 bytes when the filesystem is mounted. Add boundary checks before each run_unpack_s64() call to ensure the declared field size does not exceed the remaining buffer. Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46023", "url": "https://ubuntu.com/security/CVE-2026-46023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm mirror: fix integer overflow in create_dirty_log() The argument count calculation in create_dirty_log() performs `*args_used = 2 + param_count` before validating against argc. When a user provides a param_count close to UINT_MAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent `argc < *args_used` check to be bypassed. The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array. Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46077", "url": "https://ubuntu.com/security/CVE-2026-46077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-tdes - fix DMA sync direction Before DMA output is consumed by the CPU, ->dma_addr_out must be synced with dma_sync_single_for_cpu() instead of dma_sync_single_for_device(). Using the wrong direction can return stale cache data on non-coherent platforms.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45986", "url": "https://ubuntu.com/security/CVE-2026-45986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccree - fix a memory leak in cc_mac_digest() Add cc_unmap_result() if cc_map_hash_request_final() fails to prevent potential memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46019", "url": "https://ubuntu.com/security/CVE-2026-46019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the first page using free_page(), leaking the remaining 3 pages. Use free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46015", "url": "https://ubuntu.com/security/CVE-2026-46015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: call sk_data_ready() after listener migration When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46040", "url": "https://ubuntu.com/security/CVE-2026-46040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails When fsnotify_add_inode_mark_locked() fails in inotify_new_watch(), the error path calls inotify_remove_from_idr() but does not call dec_inotify_watches() to undo the preceding inc_inotify_watches(). This leaks a watch count, and repeated failures can exhaust the max_user_watches limit with -ENOSPC even when no watches are active. Prior to commit 1cce1eea0aff (\"inotify: Convert to using per-namespace limits\"), the watch count was incremented after fsnotify_add_mark_locked() succeeded, so this path was not affected. The conversion moved inc_inotify_watches() before the mark insertion without adding the corresponding rollback. Add the missing dec_inotify_watches() call in the error path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46070", "url": "https://ubuntu.com/security/CVE-2026-46070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: validate payload size before accessing journal metadata r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block. A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets. Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46051", "url": "https://ubuntu.com/security/CVE-2026-46051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix soft lockup in retry_aligned_read() When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46046", "url": "https://ubuntu.com/security/CVE-2026-46046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all() The commit c8e008b60492 (\"ext4: ignore xattrs past end\") introduced a refcount leak in when block_csum is false. ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to get iloc.bh, but never releases it with brelse().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46285", "url": "https://ubuntu.com/security/CVE-2026-46285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: docg3: fix use-after-free in docg3_release() In docg3_release(), the docg3 pointer is obtained from cascade->floors[0]->priv before the loop that calls doc_release_device() on each floor. doc_release_device() frees the docg3 struct via kfree(docg3) at line 1881. After the loop, docg3->cascade->bch dereferences the already-freed pointer. Fix this by accessing cascade->bch directly, which is equivalent since docg3->cascade points back to the same cascade struct, and is already available as a local variable. This also removes the now-unused docg3 local variable.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46082", "url": "https://ubuntu.com/security/CVE-2026-46082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. [sean: tag for stable@]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45987", "url": "https://ubuntu.com/security/CVE-2026-45987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2 After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46024", "url": "https://ubuntu.com/security/CVE-2026-46024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply() If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for both protocol and result, this is currently not treated as an error. In case of ac->negotiating == true and ac->protocol > 0, this leads to setting ac->protocol = 0 and ac->ops = NULL. Thereafter, the check for ac->protocol != protocol returns false, and init_protocol() is not called. Subsequently, ac->ops->handle_reply() is called, which leads to a null pointer dereference, because ac->ops is still NULL. This patch changes the check for ac->protocol != protocol to !ac->protocol, as this also includes the case when the protocol was set to zero in the message. This causes the message to be treated as containing a bad auth protocol.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46037", "url": "https://ubuntu.com/security/CVE-2026-46037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: validate reply type before using icmp_pointers Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type. That value is outside the range covered by icmp_pointers[], which only describes the traditional ICMP types up to NR_ICMP_TYPES. Avoid consulting icmp_pointers[] for reply types outside that range, and use array_index_nospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46027", "url": "https://ubuntu.com/security/CVE-2026-46027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid early lgr access in smc_clc_wait_msg A CLC decline can be received while the handshake is still in an early stage, before the connection has been associated with a link group. The decline handling in smc_clc_wait_msg() updates link-group level sync state for first-contact declines, but that state only exists after link group setup has completed. Guard the link-group update accordingly and keep the per-socket peer diagnosis handling unchanged. This preserves the existing sync_err handling for established link-group contexts and avoids touching link-group state before it is available.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46053", "url": "https://ubuntu.com/security/CVE-2026-46053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: fix MR cleanup on copy error __rds_rdma_map() hands sg/pages ownership to the transport after get_mr() succeeds. If copying the generated cookie back to user space fails after that point, the error path must not free those resources again before dropping the MR reference. Remove the duplicate unpin/free from the put_user() failure branch so that MR teardown is handled only through the existing final cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46004", "url": "https://ubuntu.com/security/CVE-2026-46004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Handle probe errors properly The probe procedure of setup_card() in caiaq driver doesn't treat the error cases gracefully, e.g. the error from snd_card_register() calls snd_card_free() but continues. This would lead to a UAF for the further calls like snd_usb_caiaq_control_init(), as Berk suggested in another patch in the link below. However, the problem is not only that; in general, this function drops the all error handlings (as it's a void function) although its caller can propagate an error to snd_probe(), which eventually calls snd_card_free() as a proper error path. That said, we should treat each error case in setup_card(), and just return the error code promptly, which is then handled later as a fatal error in snd_probe(). This patch achieves it by changing the setup_card() to return an error code. Also, the superfluous snd_card_free() call is removed, too. Note that card->private_free can be set still safely at returning an error. All called functions in card_free() have checks of the unassigned resources or NULL checks.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46050", "url": "https://ubuntu.com/security/CVE-2026-46050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix deadlock with check operation and nowait requests When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b (\"raid10: cleanup memleak at raid10_make_request\") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case. This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0. Output of r10conf state of the array when we hit this condition: crash> struct r10conf \tbarrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0, Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier(): md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46049", "url": "https://ubuntu.com/security/CVE-2026-46049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Add fallback to default RSR for S/PDIF spdif_passthru_playback_get_resources() uses atc->pll_rate as the RSR for the MSR calculation loop. However, pll_rate is only updated in atc_pll_init() and not in hw_pll_init(), so it remains 0 after the card init. When spdif_passthru_playback_setup() skips atc_pll_init() for 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin indefinitely. Add fallback to use atc->rsr when atc->pll_rate is 0. This reflects the hardware state, since hw_card_init() already configures the PLL to the default RSR.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46002", "url": "https://ubuntu.com/security/CVE-2026-46002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext2: reject inodes with zero i_nlink and valid mode in ext2_iget() ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is zero or i_dtime is set, treating them as deleted. However, the case of i_nlink == 0 with a non-zero mode and zero dtime slips through. Since ext2 has no orphan list, such a combination can only result from filesystem corruption - a legitimate inode deletion always sets either i_dtime or clears i_mode before freeing the inode. A crafted image can exploit this gap to present such an inode to the VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via ext2_unlink(), ext2_rename() and ext2_rmdir(): WARNING: CPU: 3 PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295 vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477 do_unlinkat+0x53e/0x730 fs/namei.c:4541 __x64_sys_unlink+0xc6/0x110 fs/namei.c:4587 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 646 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rename+0x35e/0x850 fs/ext2/namei.c:374 vfs_rename+0xf2f/0x2060 fs/namei.c:5021 do_renameat2+0xbe2/0xd50 fs/namei.c:5178 __x64_sys_rename+0x7e/0xa0 fs/namei.c:5223 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 634 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311 vfs_rmdir+0x204/0x690 fs/namei.c:4348 do_rmdir+0x372/0x3e0 fs/namei.c:4407 __x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Extend the existing i_nlink == 0 check to also catch this case, reporting the corruption via ext2_error() and returning -EFSCORRUPTED. This rejects the inode at load time and prevents it from reaching any of the namei.c paths. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46047", "url": "https://ubuntu.com/security/CVE-2026-46047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Fix use-after-free in driver remove() In the remove callback, if a packet arrives after destroy_workqueue() is called, but before sock_release(), the qrtr_ns_data_ready() callback will try to queue the work, causing use-after-free issue. Fix this issue by saving the default 'sk_data_ready' callback during qrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback at the start of remove(). This ensures that even if a packet arrives after destroy_workqueue(), the work struct will not be dereferenced. Note that it is also required to ensure that the RX threads are completed before destroying the workqueue, because the threads could be using the qrtr_ns_data_ready() callback.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46009", "url": "https://ubuntu.com/security/CVE-2026-46009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to do later. This leads to an oops when .allow_link fails or when .drop_link is performed. Remove the helper. Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46102", "url": "https://ubuntu.com/security/CVE-2026-46102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: strparser: fix skb_head leak in strp_abort_strp() When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46098", "url": "https://ubuntu.com/security/CVE-2026-46098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: caif: clear client service pointer on teardown `caif_connect()` can tear down an existing client after remote shutdown by calling `caif_disconnect_client()` followed by `caif_free_client()`. `caif_free_client()` releases the service layer referenced by `adap_layer->dn`, but leaves that pointer stale. When the socket is later destroyed, `caif_sock_destructor()` calls `caif_free_client()` again and dereferences the freed service pointer. Clear the client/service links before releasing the service object so repeated teardown becomes harmless.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46088", "url": "https://ubuntu.com/security/CVE-2026-46088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names() snd_ctl_elem_init_enum_names() advances pointer p through the names buffer while decrementing buf_len. If buf_len reaches zero but items remain, the next iteration calls strnlen(p, 0). While strnlen(p, 0) returns 0 and would hit the existing name_len == 0 error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks maxlen against __builtin_dynamic_object_size(). When Clang loses track of p's object size inside the loop, this triggers a BRK exception panic before the return value is examined. Add a buf_len == 0 guard at the loop entry to prevent calling fortified strnlen() on an exhausted buffer. Found by kernel fuzz testing through Xiaomi Smartphone.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46080", "url": "https://ubuntu.com/security/CVE-2026-46080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: split transactions in dio completion to avoid credit exhaustion During ocfs2 dio operations, JBD2 may report warnings via following call trace: ocfs2_dio_end_io_write ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_split_extent ocfs2_try_to_merge_extent ocfs2_extend_rotate_transaction ocfs2_extend_trans jbd2__journal_restart start_this_handle output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449 To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to handle extents in a batch of transaction. Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode should only be removed from the orphan list after the extent tree update is complete. This ensures that if a crash occurs in the middle of extent tree updates, we won't leave stale blocks beyond EOF. This patch also changes the logic for updating the inode size and removing orphan, making it similar to ext4_dio_write_end_io(). Both operations are performed only when everything looks good. Finally, thanks to Jans and Joseph for providing the bug fix prototype and suggestions.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-21739", "url": "https://ubuntu.com/security/CVE-2025-21739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix use-after free in init error and remove paths devm_blk_crypto_profile_init() registers a cleanup handler to run when the associated (platform-) device is being released. For UFS, the crypto private data and pointers are stored as part of the ufs_hba's data structure 'struct ufs_hba::crypto_profile'. This structure is allocated as part of the underlying ufshcd and therefore Scsi_host allocation. During driver release or during error handling in ufshcd_pltfrm_init(), this structure is released as part of ufshcd_dealloc_host() before the (platform-) device associated with the crypto call above is released. Once this device is released, the crypto cleanup code will run, using the just-released 'struct ufs_hba::crypto_profile'. This causes a use-after-free situation: Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0 In other words, the initialisation code flow is: platform-device probe ufshcd_pltfrm_init() ufshcd_alloc_host() scsi_host_alloc() allocation of struct ufs_hba creation of scsi-host devices devm_blk_crypto_profile_init() devm registration of cleanup handler using platform-device and during error handling of ufshcd_pltfrm_init() or during driver removal: ufshcd_dealloc_host() scsi_host_put() put_device(scsi-host) release of struct ufs_hba put_device(platform-device) crypto cleanup handler To fix this use-after free, change ufshcd_alloc_host() to register a devres action to automatically cleanup the underlying SCSI device on ufshcd destruction, without requiring explicit calls to ufshcd_dealloc_host(). This way: * the crypto profile and all other ufs_hba-owned resources are destroyed before SCSI (as they've been registered after) * a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as it's not needed anymore * no future drivers using ufshcd_alloc_host() could ever forget adding the cleanup", "cve_priority": "low", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2026-46064", "url": "https://ubuntu.com/security/CVE-2026-46064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix heap over-read in ibmasm_send_i2o_message() The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO. Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure. Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controller's free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it. Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45994", "url": "https://ubuntu.com/security/CVE-2026-45994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix OOB reads in command_file_write due to missing size checks The command_file_write() handler allocates a kernel buffer of exactly count bytes and copies user data into it, but does not validate the buffer against the dot command protocol before passing it to get_dot_command_size() and get_dot_command_timeout(). Since both the allocation size (count) and the header fields (command_size, data_size) are independently user-controlled, an attacker can cause get_dot_command_size() to return a value exceeding the allocation, triggering OOB reads in get_dot_command_timeout() and an out-of-bounds memcpy_toio() that leaks kernel heap memory to the service processor. Fix with two guards: reject writes smaller than sizeof(struct dot_command_header) before allocation, then after copying user data reject commands where the buffer is smaller than the total size declared by the header (sizeof(header) + command_size + data_size). This ensures all subsequent header and payload field accesses stay within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46022", "url": "https://ubuntu.com/security/CVE-2026-46022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt() ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60). A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started. The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes: queue_begin + reader * sizeof(struct remote_input) with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception. Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46006", "url": "https://ubuntu.com/security/CVE-2026-46006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix u32 overflow in pushbuf reloc bounds check nouveau_gem_pushbuf_reloc_apply() validates each relocation with if (r->reloc_bo_offset + 4 > nvbo->bo.base.size) but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size. Cast to u64 so the addition happens in 64-bit arithmetic. [ Add Fixes: tag. - Danilo ]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46018", "url": "https://ubuntu.com/security/CVE-2026-46018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES parse_uac2_sample_rate_range() caps the number of enumerated rates at MAX_NR_RATES, but it only breaks out of the current rate loop. A malformed UAC2 RANGE response with additional triplets continues parsing the remaining triplets and repeatedly prints \"invalid uac2 rates\" while probe still holds register_mutex. Stop the whole parse once the cap is reached and return the number of rates collected so far.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-31696", "url": "https://ubuntu.com/security/CVE-2026-31696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing validation of ticket length in non-XDR key preparsing In rxrpc_preparse(), there are two paths for parsing key payloads: the XDR path (for large payloads) and the non-XDR path (for payloads <= 28 bytes). While the XDR path (rxrpc_preparse_xdr_rxkad()) correctly validates the ticket length against AFSTOKEN_RK_TIX_MAX, the non-XDR path fails to do so. This allows an unprivileged user to provide a very large ticket length. When this key is later read via rxrpc_read(), the total token size (toksize) calculation results in a value that exceeds AFSTOKEN_LENGTH_MAX, triggering a WARN_ON(). [ 2001.302904] WARNING: CPU: 2 PID: 2108 at net/rxrpc/key.c:778 rxrpc_read+0x109/0x5c0 [rxrpc] Fix this by adding a check in the non-XDR parsing path of rxrpc_preparse() to ensure the ticket length does not exceed AFSTOKEN_RK_TIX_MAX, bringing it into parity with the XDR parsing logic.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31697", "url": "https://ubuntu.com/security/CVE-2026-31697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388 CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31698", "url": "https://ubuntu.com/security/CVE-2026-31698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033 CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31699", "url": "https://ubuntu.com/security/CVE-2026-31699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405 CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31701", "url": "https://ubuntu.com/security/CVE-2026-31701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: take a reference on the USB device in create_card() The caiaq driver stores a pointer to the parent USB device in cdev->chip.dev but never takes a reference on it. The card's private_free callback, snd_usb_caiaq_card_free(), can run asynchronously via snd_card_free_when_closed() after the USB device has already been disconnected and freed, so any access to cdev->chip.dev in that path dereferences a freed usb_device. On top of the refcounting issue, the current card_free implementation calls usb_reset_device(cdev->chip.dev). A reset in a free callback is inappropriate: the device is going away, the call takes the device lock in a teardown context, and the reset races with the disconnect path that the callback is already cleaning up after. Take a reference on the USB device in create_card() with usb_get_dev(), drop it with usb_put_dev() in the free callback, and remove the usb_reset_device() call.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31694", "url": "https://ubuntu.com/security/CVE-2026-31694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject oversized dirents in page cache fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31716", "url": "https://ubuntu.com/security/CVE-2026-31716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate rec->used in journal-replay file record check check_file_record() validates rec->total against the record size but never validates rec->used. The do_action() journal-replay handlers read rec->used from disk and use it to compute memmove lengths: DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next)) When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall. This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay Fix this up by bounding rec->used correctly. This is much like commit b2bc7c44ed17 (\"fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\") which checked different values in this same switch statement.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31676", "url": "https://ubuntu.com/security/CVE-2026-31676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31409", "url": "https://ubuntu.com/security/CVE-2026-31409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: unset conn->binding on failed binding request When a multichannel SMB2_SESSION_SETUP request with SMB2_SESSION_REQ_FLAG_BINDING fails ksmbd sets conn->binding = true but never clears it on the error path. This leaves the connection in a binding state where all subsequent ksmbd_session_lookup_all() calls fall back to the global sessions table. This fix it by clearing conn->binding = false in the error path.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2023-53596", "url": "https://ubuntu.com/security/CVE-2023-53596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: base: Free devm resources when unregistering a device In the current code, devres_release_all() only gets called if the device has a bus and has been probed. This leads to issues when using bus-less or driver-less devices where the device might never get freed if a managed resource holds a reference to the device. This is happening in the DRM framework for example. We should thus call devres_release_all() in the device_del() function to make sure that the device-managed actions are properly executed when the device is unregistered, even if it has neither a bus nor a driver. This is effectively the same change than commit 2f8d16a996da (\"devres: release resources on device_del()\") that got reverted by commit a525a3ddeaca (\"driver core: free devres in device_release\") over memory leaks concerns. This patch effectively combines the two commits mentioned above to release the resources both on device_del() and device_release() and get the best of both worlds.", "cve_priority": "low", "cve_public_date": "2025-10-04 16:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2025-38192", "url": "https://ubuntu.com/security/CVE-2025-38192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: clear the dst when changing skb protocol A not-so-careful NAT46 BPF program can crash the kernel if it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10) The output interface has a 4->6 program attached at ingress. We try to loop the multicast skb back to the sending socket. Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr and changes skb->protocol to v6. We enter ip6_rcv_core which tries to use skb_dst(). But the dst is still an IPv4 one left after IPv4 mcast output. Clear the dst in all BPF helpers which change the protocol. Try to preserve metadata dsts, those may carry non-routing metadata.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-21712", "url": "https://ubuntu.com/security/CVE-2025-21712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime After commit ec6bb299c7c3 (\"md/md-bitmap: add 'sync_size' into struct md_bitmap_stats\"), following panic is reported: Oops: general protection fault, probably for non-canonical address RIP: 0010:bitmap_get_stats+0x2b/0xa0 Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Root cause is that bitmap_get_stats() can be called at anytime if mddev is still there, even if bitmap is destroyed, or not fully initialized. Deferenceing bitmap in this case can crash the kernel. Meanwhile, the above commit start to deferencing bitmap->storage, make the problem easier to trigger. Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2026-43328", "url": "https://ubuntu.com/security/CVE-2026-43328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error path When kobject_init_and_add() fails, cpufreq_dbs_governor_init() calls kobject_put(&dbs_data->attr_set.kobj). The kobject release callback cpufreq_dbs_data_release() calls gov->exit(dbs_data) and kfree(dbs_data), but the current error path then calls gov->exit(dbs_data) and kfree(dbs_data) again, causing a double free. Keep the direct kfree(dbs_data) for the gov->init() failure path, but after kobject_init_and_add() has been called, let kobject_put() handle the cleanup through cpufreq_dbs_data_release().", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-23066", "url": "https://ubuntu.com/security/CVE-2026-23066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recvmsg() unconditional requeue If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at the front of the recvmsg queue already has its mutex locked, it requeues the call - whether or not the call is already queued. The call may be on the queue because MSG_PEEK was also passed and so the call was not dequeued or because the I/O thread requeued it. The unconditional requeue may then corrupt the recvmsg queue, leading to things like UAFs or refcount underruns. Fix this by only requeuing the call if it isn't already on the queue - and moving it to the front if it is already queued. If we don't queue it, we have to put the ref we obtained by dequeuing it. Also, MSG_PEEK doesn't dequeue the call so shouldn't call rxrpc_notify_socket() for the call if we didn't use up all the data on the queue, so fix that also.", "cve_priority": "high", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-27407", "url": "https://ubuntu.com/security/CVE-2024-27407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fixed overflow check in mi_enum_attr()", "cve_priority": "high", "cve_public_date": "2024-05-17 12:15:00 UTC" }, { "cve": "CVE-2023-45896", "url": "https://ubuntu.com/security/CVE-2023-45896", "cve_description": "ntfs3 in the Linux kernel through 6.8.0 allows a physically proximate attacker to read kernel memory by mounting a filesystem (e.g., if a Linux distribution is configured to allow unprivileged mounts of removable media) and then leveraging local access to trigger an out-of-bounds read. A length value can be larger than the amount of memory allocated. NOTE: the supplier's perspective is that there is no vulnerability when an attack requires an attacker-modified filesystem image.", "cve_priority": "medium", "cve_public_date": "2024-08-28 05:15:00 UTC" }, { "cve": "CVE-2023-52737", "url": "https://ubuntu.com/security/CVE-2023-52737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: lock the inode in shared mode before starting fiemap Currently fiemap does not take the inode's lock (VFS lock), it only locks a file range in the inode's io tree. This however can lead to a deadlock if we have a concurrent fsync on the file and fiemap code triggers a fault when accessing the user space buffer with fiemap_fill_next_extent(). The deadlock happens on the inode's i_mmap_lock semaphore, which is taken both by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by syzbot and triggers a trace like the following: task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 wait_on_state fs/btrfs/extent-io-tree.c:707 [inline] wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751 lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742 find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488 writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863 __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174 extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091 extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211 do_writepages+0x3c3/0x680 mm/page-writeback.c:2581 filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388 __filemap_fdatawrite_range mm/filemap.c:421 [inline] filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439 btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline] start_ordered_ops fs/btrfs/file.c:1737 [inline] btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839 generic_write_sync include/linux/fs.h:2885 [inline] btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684 call_write_iter include/linux/fs.h:2189 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9 RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006 RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8 INFO: task syz-executor361:5697 blocked for more than 145 seconds. Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095 __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260 btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526 do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947 wp_page_shared+0x15e/0x380 mm/memory.c:3295 handle_pte_fault mm/memory.c:4949 [inline] __handle_mm_fault mm/memory.c:5073 [inline] handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219 do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428 handle_page_fault arch/x86/mm/fault.c:1519 [inline] exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233 Code: 74 0a 89 (...) RSP: 0018:ffffc9000570f330 EFLAGS: 000502 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-05-21 16:15:00 UTC" }, { "cve": "CVE-2025-38626", "url": "https://ubuntu.com/security/CVE-2025-38626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode w/ \"mode=lfs\" mount option, generic/299 will cause system panic as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2835! Call Trace: f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720 The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may trigger foreground gc only if it allocates any physical block, it will be a little bit later when there is multiple threads writing data w/ aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so f2fs_map_blocks() does block allocations aggressively. In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_blocks().", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2024-46770", "url": "https://ubuntu.com/security/CVE-2024-46770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Add netif_device_attach/detach into PF reset flow Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. getting coalesce settings can result in a NULL pointer dereference seen below. Reproduction steps: Once the driver is fully initialized, trigger reset: \t# echo 1 > /sys/class/net//device/reset when reset is in progress try to get coalesce settings using ethtool: \t# ethtool -c BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7 RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice] RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206 RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000 R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40 FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0 Call Trace: ice_get_coalesce+0x17/0x30 [ice] coalesce_prepare_data+0x61/0x80 ethnl_default_doit+0xde/0x340 genl_family_rcv_msg_doit+0xf2/0x150 genl_rcv_msg+0x1b3/0x2c0 netlink_rcv_skb+0x5b/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x19c/0x290 netlink_sendmsg+0x222/0x490 __sys_sendto+0x1df/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7faee60d8e27 Calling netif_device_detach() before reset makes the net core not call the driver when ethtool command is issued, the attempt to execute an ethtool command during reset will result in the following message: netlink error: No such device instead of NULL pointer dereference. Once reset is done and ice_rebuild() is executing, the netif_device_attach() is called to allow for ethtool operations to occur again in a safe manner.", "cve_priority": "medium", "cve_public_date": "2024-09-18 08:15:00 UTC" }, { "cve": "CVE-2025-38105", "url": "https://ubuntu.com/security/CVE-2025-38105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Kill timer properly at removal The USB-audio MIDI code initializes the timer, but in a rare case, the driver might be freed without the disconnect call. This leaves the timer in an active state while the assigned object is released via snd_usbmidi_free(), which ends up with a kernel warning when the debug configuration is enabled, as spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be killed properly. While we're at it, replace the existing timer_delete_sync() at the disconnect callback with timer_shutdown_sync(), too.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2024-27389", "url": "https://ubuntu.com/security/CVE-2024-27389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore: inode: Only d_invalidate() is needed Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning: WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410 Using the combo of d_drop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use d_invalidate() and update the code to not bother checking for error codes that can never happen. ---", "cve_priority": "medium", "cve_public_date": "2024-05-01 13:15:00 UTC" }, { "cve": "CVE-2023-52682", "url": "https://ubuntu.com/security/CVE-2023-52682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait on block writeback for post_read case If inode is compressed, but not encrypted, it missed to call f2fs_wait_on_block_writeback() to wait for GCed page writeback in IPU write path. Thread A\t\t\t\tGC-Thread \t\t\t\t\t- f2fs_gc \t\t\t\t\t - do_garbage_collect \t\t\t\t\t - gc_data_segment \t\t\t\t\t - move_data_block \t\t\t\t\t - f2fs_submit_page_write \t\t\t\t\t migrate normal cluster's block via \t\t\t\t\t meta_inode's page cache - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_submit_page_bio IRQ - f2fs_read_end_io \t\t\t\t\tIRQ \t\t\t\t\told data overrides new data due to \t\t\t\t\tout-of-order GC and common IO. \t\t\t\t\t- f2fs_read_end_io", "cve_priority": "medium", "cve_public_date": "2024-05-17 15:15:00 UTC" }, { "cve": "CVE-2024-56719", "url": "https://ubuntu.com/security/CVE-2024-56719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix TSO DMA API usage causing oops Commit 66600fac7a98 (\"net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data\") moved the assignment of tx_skbuff_dma[]'s members to be later in stmmac_tso_xmit(). The buf (dma cookie) and len stored in this structure are passed to dma_unmap_single() by stmmac_tx_clean(). The DMA API requires that the dma cookie passed to dma_unmap_single() is the same as the value returned from dma_map_single(). However, by moving the assignment later, this is not the case when priv->dma_cap.addr64 > 32 as \"des\" is offset by proto_hdr_len. This causes problems such as: dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed and with DMA_API_DEBUG enabled: DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes] Fix this by maintaining \"des\" as the original DMA cookie, and use tso_des to pass the offset DMA cookie to stmmac_tso_allocator(). Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/", "cve_priority": "medium", "cve_public_date": "2024-12-29 09:15:00 UTC" }, { "cve": "CVE-2024-41079", "url": "https://ubuntu.com/security/CVE-2024-41079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: always initialize cqe.result The spec doesn't mandate that the first two double words (aka results) for the command queue entry need to be set to 0 when they are not used (not specified). Though, the target implemention returns 0 for TCP and FC but not for RDMA. Let's make RDMA behave the same and thus explicitly initializing the result field. This prevents leaking any data from the stack.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2023-53545", "url": "https://ubuntu.com/security/CVE-2023-53545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: unmap and remove csa_va properly Root PD BO should be reserved before unmap and remove a bo_va from VM otherwise lockdep will complain. v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian) [14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu] [14616.937096] Call Trace: [14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu] [14616.937187] drm_file_free+0x1d6/0x300 [drm] [14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm] [14616.937220] drm_release+0x5e/0x100 [drm] [14616.937234] __fput+0x9f/0x280 [14616.937239] ____fput+0xe/0x20 [14616.937241] task_work_run+0x61/0x90 [14616.937246] exit_to_user_mode_prepare+0x215/0x220 [14616.937251] syscall_exit_to_user_mode+0x2a/0x60 [14616.937254] do_syscall_64+0x48/0x90 [14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd", "cve_priority": "medium", "cve_public_date": "2025-10-04 16:15:00 UTC" }, { "cve": "CVE-2025-68239", "url": "https://ubuntu.com/security/CVE-2025-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: restore write access before closing files opened by open_exec() bm_register_write() opens an executable file using open_exec(), which internally calls do_open_execat() and denies write access on the file to avoid modification while it is being executed. However, when an error occurs, bm_register_write() closes the file using filp_close() directly. This does not restore the write permission, which may cause subsequent write operations on the same file to fail. Fix this by calling exe_file_allow_write_access() before filp_close() to restore the write permission properly.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-38659", "url": "https://ubuntu.com/security/CVE-2025-38659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: No more self recovery When a node withdraws and it turns out that it is the only node that has the filesystem mounted, gfs2 currently tries to replay the local journal to bring the filesystem back into a consistent state. Not only is that a very bad idea, it has also never worked because gfs2_recover_func() will refuse to do anything during a withdraw. However, before even getting to this point, gfs2_recover_func() dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free before commit 04133b607a78 (\"gfs2: Prevent double iput for journal on error\") and is a NULL pointer dereference since then. Simply get rid of self recovery to fix that.", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2022-49961", "url": "https://ubuntu.com/security/CVE-2022-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg->precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored state. To show a concrete example of the problem: 0000000000000000 : 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 10: r2 = -1 0000000000000058 : 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit 00000000000000b8 : 23: w0 = 0 24: exit For the first case, the single line execution's exploration will prune the search at insn 14 for the branch insn 9's second leg as it will be verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will always be 0 so at runtime we don't get error for being greater than UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just sees reg->precise as false for both r2 registers in both states, hence considers them equal for purposes of states_equal. If we propagated precise markers using the backtracking support, we would use the precise marking to then ensure that old r2 (UINT_MAX) was within the new r2 (1) and this would never be true, so the verification would rightfully fail. The end result is that the out of bounds access at instruction 19 would be permitted without this fix. Note that reg->precise is always set to true when user does not have CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static or global functions)), hence this is only a problem when precision marks need to be explicitly propagated (i.e. privileged users with CAP_BPF). A simplified test case has been included in the next patch to prevent future regressions.", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2024-47809", "url": "https://ubuntu.com/security/CVE-2024-47809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix possible lkb_resource null dereference This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded. The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference. In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.", "cve_priority": "medium", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2025-38250", "url": "https://ubuntu.com/security/CVE-2025-38250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix use-after-free in vhci_flush() syzbot reported use-after-free in vhci_flush() without repro. [0] From the splat, a thread close()d a vhci file descriptor while its device was being used by iotcl() on another thread. Once the last fd refcnt is released, vhci_release() calls hci_unregister_dev(), hci_free_dev(), and kfree() for struct vhci_data, which is set to hci_dev->dev->driver_data. The problem is that there is no synchronisation after unlinking hdev from hci_dev_list in hci_unregister_dev(). There might be another thread still accessing the hdev which was fetched before the unlink operation. We can use SRCU for such synchronisation. Let's run hci_dev_reset() under SRCU and wait for its completion in hci_unregister_dev(). Another option would be to restore hci_dev->destruct(), which was removed in commit 587ae086f6e4 (\"Bluetooth: Remove unused hci-destruct cb\"). However, this would not be a good solution, as we should not run hci_unregister_dev() while there are in-flight ioctl() requests, which could lead to another data-race KCSAN splat. Note that other drivers seem to have the same problem, for exmaple, virtbt_remove(). [0]: BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718 CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name ---truncated---", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2026-43281", "url": "https://ubuntu.com/security/CVE-2026-43281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate() Although it is guided that `#mbox-cells` must be at least 1, there are many instances of `#mbox-cells = <0>;` in the device tree. If that is the case and the corresponding mailbox controller does not provide `fw_xlate` and of_xlate` function pointers, `fw_mbox_index_xlate()` will be used by default and out-of-bounds accesses could occur due to lack of bounds check in that function.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23157", "url": "https://ubuntu.com/security/CVE-2026-23157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not strictly require dirty metadata threshold for metadata writepages [BUG] There is an internal report that over 1000 processes are waiting at the io_schedule_timeout() of balance_dirty_pages(), causing a system hang and trigger a kernel coredump. The kernel is v6.4 kernel based, but the root problem still applies to any upstream kernel before v6.18. [CAUSE] From Jan Kara for his wisdom on the dirty page balance behavior first. This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB. Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there's dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying. When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit. So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in that cgroup. So that means the only way to reduce the dirty pages of that cgroup is to writeback the dirty pages of btrfs btree inode, and only after that those processes can exit balance_dirty_pages(). Now back to the btrfs part, btree_writepages() is responsible for writing back dirty btree inode pages. The problem here is, there is a btrfs internal threshold that if the btree inode's dirty bytes are below the 32M threshold, it will not do any writeback. This behavior is to batch as much metadata as possible so we won't write back those tree blocks and then later re-COW them again for another modification. This internal 32MiB is higher than the existing dirty page size (28MiB), meaning no writeback will happen, causing a deadlock between btrfs and cgroup: - Btrfs doesn't want to write back btree inode until more dirty pages - Cgroup/MM doesn't want more dirty pages for btrfs btree inode Thus any process touching that btree inode is put into sleep until the number of dirty pages is reduced. Thanks Jan Kara a lot for the analysis of the root cause. [ENHANCEMENT] Since kernel commit b55102826d7d (\"btrfs: set AS_KERNEL_FILE on the btree_inode\"), btrfs btree inode pages will only be charged to the root cgroup which should have a much larger limit than btrfs' 32MiB threshold. So it should not affect newer kernels. But for all current LTS kernels, they are all affected by this problem, and backporting the whole AS_KERNEL_FILE may not be a good idea. Even for newer kernels I still think it's a good idea to get rid of the internal threshold at btree_writepages(), since for most cases cgroup/MM has a better view of full system memory usage than btrfs' fixed threshold. For internal callers using btrfs_btree_balance_dirty() since that function is already doing internal threshold check, we don't need to bother them. But for external callers of btree_writepages(), just respect their requests and write back whatever they want, ignoring the internal btrfs threshold to avoid such deadlock on btree inode dirty page balancing.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23141", "url": "https://ubuntu.com/security/CVE-2026-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: check for inline extents in range_is_hole_in_parent() Before accessing the disk_bytenr field of a file extent item we need to check if we are dealing with an inline extent. This is because for inline extents their data starts at the offset of the disk_bytenr field. So accessing the disk_bytenr means we are accessing inline data or in case the inline data is less than 8 bytes we can actually cause an invalid memory access if this inline extent item is the first item in the leaf or access metadata from other items.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-40005", "url": "https://ubuntu.com/security/CVE-2025-40005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: Implement refcount to handle unbind during busy driver support indirect read and indirect write operation with assumption no force device removal(unbind) operation. However force device removal(removal) is still available to root superuser. Unbinding driver during operation causes kernel crash. This changes ensure driver able to handle such operation for indirect read and indirect write by implementing refcount to track attached devices to the controller and gracefully wait and until attached devices remove operation completed before proceed with removal operation.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2023-53629", "url": "https://ubuntu.com/security/CVE-2023-53629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: dlm: fix use after free in midcomms commit While working on processing dlm message in softirq context I experienced the following KASAN use-after-free warning: [ 151.760477] ================================================================== [ 151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347 [ 151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828 [ 151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014 [ 151.768726] Call Trace: [ 151.769277] [ 151.769748] dump_stack_lvl+0x5b/0x86 [ 151.770556] print_report+0x180/0x4c8 [ 151.771378] ? kasan_complete_mode_report_info+0x7c/0x1e0 [ 151.772241] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.773069] kasan_report+0x93/0x1a0 [ 151.773668] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.774514] __asan_load4+0x7e/0xa0 [ 151.775089] dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.775890] ? create_message.isra.29.constprop.64+0x57/0xc0 [ 151.776770] send_common+0x19f/0x1b0 [ 151.777342] ? remove_from_waiters+0x60/0x60 [ 151.778017] ? lock_downgrade+0x410/0x410 [ 151.778648] ? __this_cpu_preempt_check+0x13/0x20 [ 151.779421] ? rcu_lockdep_current_cpu_online+0x88/0xc0 [ 151.780292] _convert_lock+0x46/0x150 [ 151.780893] convert_lock+0x7b/0xc0 [ 151.781459] dlm_lock+0x3ac/0x580 [ 151.781993] ? 0xffffffffc0540000 [ 151.782522] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.783379] ? dlm_scan_rsbs+0xa70/0xa70 [ 151.784003] ? preempt_count_sub+0xd6/0x130 [ 151.784661] ? is_module_address+0x47/0x70 [ 151.785309] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.786166] ? 0xffffffffc0540000 [ 151.786693] ? lockdep_init_map_type+0xc3/0x360 [ 151.787414] ? 0xffffffffc0540000 [ 151.787947] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.789004] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.789858] ? 0xffffffffc0540000 [ 151.790392] ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture] [ 151.791347] ? delay_tsc+0x94/0xc0 [ 151.791898] torture_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.792735] ? torture_start+0x30/0x30 [dlm_locktorture] [ 151.793606] lock_torture+0x177/0x270 [dlm_locktorture] [ 151.794448] ? torture_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture] [ 151.795539] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.796476] ? do_raw_spin_lock+0x11e/0x1e0 [ 151.797152] ? mark_held_locks+0x34/0xb0 [ 151.797784] ? _raw_spin_unlock_irqrestore+0x30/0x70 [ 151.798581] ? __kthread_parkme+0x79/0x110 [ 151.799246] ? trace_preempt_on+0x2a/0xf0 [ 151.799902] ? __kthread_parkme+0x79/0x110 [ 151.800579] ? preempt_count_sub+0xd6/0x130 [ 151.801271] ? __kasan_check_read+0x11/0x20 [ 151.801963] ? __kthread_parkme+0xec/0x110 [ 151.802630] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.803569] kthread+0x192/0x1d0 [ 151.804104] ? kthread_complete_and_exit+0x30/0x30 [ 151.804881] ret_from_fork+0x1f/0x30 [ 151.805480] [ 151.806111] Allocated by task 1347: [ 151.806681] kasan_save_stack+0x26/0x50 [ 151.807308] kasan_set_track+0x25/0x30 [ 151.807920] kasan_save_alloc_info+0x1e/0x30 [ 151.808609] __kasan_slab_alloc+0x63/0x80 [ 151.809263] kmem_cache_alloc+0x1ad/0x830 [ 151.809916] dlm_allocate_mhandle+0x17/0x20 [ 151.810590] dlm_midcomms_get_mhandle+0x96/0x260 [ 151.811344] _create_message+0x95/0x180 [ 151.811994] create_message.isra.29.constprop.64+0x57/0xc0 [ 151.812880] send_common+0x129/0x1b0 [ 151.813467] _convert_lock+0x46/0x150 [ 151.814074] convert_lock+0x7b/0xc0 [ 151.814648] dlm_lock+0x3ac/0x580 [ 151.815199] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.816258] torture_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.817129] lock_t ---truncated---", "cve_priority": "high", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2025-71221", "url": "https://ubuntu.com/security/CVE-2025-71221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue() Add proper locking in mmp_pdma_residue() to prevent use-after-free when accessing descriptor list and descriptor contents. The race occurs when multiple threads call tx_status() while the tasklet on another CPU is freeing completed descriptors: CPU 0 CPU 1 ----- ----- mmp_pdma_tx_status() mmp_pdma_residue() -> NO LOCK held list_for_each_entry(sw, ..) DMA interrupt dma_do_tasklet() -> spin_lock(&desc_lock) list_move(sw->node, ...) spin_unlock(&desc_lock) | dma_pool_free(sw) <- FREED! -> access sw->desc <- UAF! This issue can be reproduced when running dmatest on the same channel with multiple threads (threads_per_chan > 1). Fix by protecting the chain_running list iteration and descriptor access with the chan->desc_lock spinlock.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23204", "url": "https://ubuntu.com/security/CVE-2026-23204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: use skb_header_pointer_careful() skb_header_pointer() does not fully validate negative @offset values. Use skb_header_pointer_careful() instead. GangMin Kim provided a report and a repro fooling u32_classify(): BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0 net/sched/cls_u32.c:221", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-71161", "url": "https://ubuntu.com/security/CVE-2025-71161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: disable recursive forward error correction There are two problems with the recursive correction: 1. It may cause denial-of-service. In fec_read_bufs, there is a loop that has 253 iterations. For each iteration, we may call verity_hash_for_block recursively. There is a limit of 4 nested recursions - that means that there may be at most 253^4 (4 billion) iterations. Red Hat QE team actually created an image that pushes dm-verity to this limit - and this image just makes the udev-worker process get stuck in the 'D' state. 2. It doesn't work. In fec_read_bufs we store data into the variable \"fio->bufs\", but fio bufs is shared between recursive invocations, if \"verity_hash_for_block\" invoked correction recursively, it would overwrite partially filled fio->bufs.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2022-50552", "url": "https://ubuntu.com/security/CVE-2022-50552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: use quiesced elevator switch when reinitializing queues The hctx's run_work may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally. nvme nvme0: resetting controller nvme nvme0: 32/0/0 default/read/poll queues BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:kyber_has_work+0x29/0x70 ... Call Trace: __blk_mq_do_dispatch_sched+0x83/0x2b0 __blk_mq_sched_dispatch_requests+0x12e/0x170 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x2b/0x50 process_one_work+0x1ef/0x380 worker_thread+0x2d/0x3e0", "cve_priority": "low", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2024-36922", "url": "https://ubuntu.com/security/CVE-2024-36922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: read txq->read_ptr under lock If we read txq->read_ptr without lock, we can read the same value twice, then obtain the lock, and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in the WARN_ONCE() a little later. Fix that by reading txq->read_ptr under lock.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2024-53221", "url": "https://ubuntu.com/security/CVE-2024-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix null-ptr-deref in f2fs_submit_page_bio() There's issue as follows when concurrently installing the f2fs.ko module and mounting the f2fs file system: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs] Call Trace: f2fs_submit_page_bio+0x126/0x8b0 [f2fs] __get_meta_page+0x1d4/0x920 [f2fs] get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs] validate_checkpoint+0xac/0x290 [f2fs] f2fs_get_valid_checkpoint+0x207/0x950 [f2fs] f2fs_fill_super+0x1007/0x39b0 [f2fs] mount_bdev+0x183/0x250 legacy_get_tree+0xf4/0x1e0 vfs_get_tree+0x88/0x340 do_new_mount+0x283/0x5e0 path_mount+0x2b2/0x15b0 __x64_sys_mount+0x1fe/0x270 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Above issue happens as the biset of the f2fs file system is not initialized before register \"f2fs_fs_type\". To address above issue just register \"f2fs_fs_type\" at the last in init_f2fs_fs(). Ensure that all f2fs file system resources are initialized.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-56657", "url": "https://ubuntu.com/security/CVE-2024-56657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Avoid WARN() for symlink errors Using WARN() for showing the error of symlink creations don't give more information than telling that something goes wrong, since the usual code path is a lregister callback from each control element creation. More badly, the use of WARN() rather confuses fuzzer as if it were serious issues. This patch downgrades the warning messages to use the normal dev_err() instead of WARN(). For making it clearer, add the function name to the prefix, too.", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2022-49803", "url": "https://ubuntu.com/security/CVE-2022-49803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Fix memory leak of nsim_dev->fa_cookie kmemleak reports this issue: unreferenced object 0xffff8881bac872d0 (size 8): comm \"sh\", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie .. nsim_drv_remove() The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To fix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove().", "cve_priority": "medium", "cve_public_date": "2025-05-01 15:16:00 UTC" }, { "cve": "CVE-2022-50116", "url": "https://ubuntu.com/security/CVE-2022-50116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix deadlock and link starvation in outgoing data path The current implementation queues up new control and user packets as needed and processes this queue down to the ldisc in the same code path. That means that the upper and the lower layer are hard coupled in the code. Due to this deadlocks can happen as seen below while transmitting data, especially during ldisc congestion. Furthermore, the data channels starve the control channel on high transmission load on the ldisc. Introduce an additional control channel data queue to prevent timeouts and link hangups during ldisc congestion. This is being processed before the user channel data queue in gsm_data_kick(), i.e. with the highest priority. Put the queue to ldisc data path into a workqueue and trigger it whenever new data has been put into the transmission queue. Change gsm_dlci_data_sweep() accordingly to fill up the transmission queue until TX_THRESH_HI. This solves the locking issue, keeps latency low and provides good performance on high data load. Note that now all packets from a DLCI are removed from the internal queue if the associated DLCI was closed. This ensures that no data is sent by the introduced write task to an already closed DLCI. BUG: spinlock recursion on CPU#0, test_v24_loop/124 lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0 CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x34/0x44 do_raw_spin_lock+0x76/0xa0 _raw_spin_lock_irqsave+0x72/0x80 uart_write_room+0x3b/0xc0 gsm_data_kick+0x14b/0x240 [n_gsm] gsmld_write_wakeup+0x35/0x70 [n_gsm] tty_wakeup+0x53/0x60 tty_port_default_wakeup+0x1b/0x30 serial8250_tx_chars+0x12f/0x220 serial8250_handle_irq.part.0+0xfe/0x150 serial8250_default_handle_irq+0x48/0x80 serial8250_interrupt+0x56/0xa0 __handle_irq_event_percpu+0x78/0x1f0 handle_irq_event+0x34/0x70 handle_fasteoi_irq+0x90/0x1e0 __common_interrupt+0x69/0x100 common_interrupt+0x48/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:__do_softirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00 RSP: 0018:ffffc90000003f98 EFLAGS: 00000286 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7 RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? __do_softirq+0x73/0x34e irq_exit_rcu+0xb5/0x100 common_interrupt+0xa4/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50 Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 3d 97 33 ff 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44 RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? _raw_spin_unlock_irqrestore+0x23/0x50 gsmtty_write+0x65/0x80 [n_gsm] n_tty_write+0x33f/0x530 ? swake_up_all+0xe0/0xe0 file_tty_write.constprop.0+0x1b1/0x320 ? n_tty_flush_buffer+0xb0/0xb0 new_sync_write+0x10c/0x190 vfs_write+0x282/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f3e5e35c15c Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2026-31586", "url": "https://ubuntu.com/security/CVE-2026-31586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: blk-cgroup: fix use-after-free in cgwb_release_workfn() cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) ** Stack based on commit 66672af7a095 (\"Add linux-next specific files for 20260410\") I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh (The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.) Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31598", "url": "https://ubuntu.com/security/CVE-2026-31598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible deadlock between unlink and dio_end_io_write ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key. Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir \t ocfs2_expand_inline_dir \t down_write(&oi->ip_alloc_sem) <- Lock B Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode) Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31642", "url": "https://ubuntu.com/security/CVE-2026-31642", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call removal to use RCU safe deletion Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop. This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by: Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that. rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31664", "url": "https://ubuntu.com/security/CVE-2026-31664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear trailing padding in build_polexpire() build_expire() clears the trailing padding bytes of struct xfrm_user_expire after setting the hard field via memset_after(), but the analogous function build_polexpire() does not do this for struct xfrm_user_polexpire. The padding bytes after the __u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners, leaking kernel heap memory contents. Add the missing memset_after() call, matching build_expire().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43075", "url": "https://ubuntu.com/security/CVE-2026-43075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix out-of-bounds write in ocfs2_write_end_inline KASAN reports a use-after-free write of 4086 bytes in ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF. The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk id_count field to determine whether a write fits in inline data. On a corrupted filesystem, id_count can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer. Call trace (crash path): vfs_copy_file_range (fs/read_write.c:1634) do_splice_direct splice_direct_to_actor iter_file_splice_write ocfs2_file_write_iter generic_perform_write ocfs2_write_end ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949) ocfs2_write_end_inline (fs/ocfs2/aops.c:1915) memcpy_from_folio <-- KASAN: write OOB So add id_count upper bound check in ocfs2_validate_inode_block() to alongside the existing i_size check to fix it.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43076", "url": "https://ubuntu.com/security/CVE-2026-43076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate inline data i_size during inode read When reading an inode from disk, ocfs2_validate_inode_block() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's i_size can exceed the actual inline data capacity (id_count). This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory. In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry() Fix by adding a validation check in ocfs2_validate_inode_block() to ensure inodes with inline data have i_size <= id_count. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-23444", "url": "https://ubuntu.com/security/CVE-2026-23444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do. Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free. Document the skb ownership guarantee in the function's kdoc.", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2025-38710", "url": "https://ubuntu.com/security/CVE-2025-38710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Validate i_depth for exhash directories A fuzzer test introduced corruption that ends up with a depth of 0 in dir_e_read(), causing an undefined shift by 32 at: index = hash >> (32 - dip->i_depth); As calculated in an open-coded way in dir_make_exhash(), the minimum depth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 is invalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time. So we can avoid the undefined behaviour by checking for depth values lower than the minimum in gfs2_dinode_in(). Values greater than the maximum are already being checked for there. Also switch the calculation in dir_make_exhash() to use ilog2() to clarify how the depth is calculated. Tested with the syzkaller repro.c and xfstests '-g quick'.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2026-23442", "url": "https://ubuntu.com/security/CVE-2026-23442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: add NULL checks for idev in SRv6 paths __in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER). Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31594", "url": "https://ubuntu.com/security/CVE-2026-31594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to perform later. This leads to an oops when .allow_link fails or when .drop_link is performed. The following is an example oops of the former case: Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pci_epc_remove_epf+0x78/0xe0 (P) pci_primary_epc_epf_link+0x88/0xa8 configfs_symlink+0x1f4/0x5a0 vfs_symlink+0x134/0x1d8 do_symlinkat+0x88/0x138 __arm64_sys_symlinkat+0x74/0xe0 [...] Remove the helper, and drop pci_epc_put(). EPC device refcounting is tied to the configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2022-50073", "url": "https://ubuntu.com/security/CVE-2022-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null Fixes a NULL pointer derefence bug triggered from tap driver. When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null (in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb) virtio_net_hdr_to_skb calls dev_parse_header_protocol which needs skb->dev field to be valid. The line that trigers the bug is in dev_parse_header_protocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->header_ops || !dev->header_ops->parse_protocol) 22e1: mov 0x10(%rbx),%rax 22e5:\t mov 0x230(%rax),%rax Setting skb->dev before the call in tap.c fixes the issue. BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tap_get_user+0x3f1/0x540 [tap] tap_sendmsg+0x56/0x362 [tap] ? get_tx_bufs+0xc2/0x1e0 [vhost_net] handle_tx_copy+0x114/0x670 [vhost_net] handle_tx+0xb0/0xe0 [vhost_net] handle_tx_kick+0x15/0x20 [vhost_net] vhost_worker+0x7b/0xc0 [vhost] ? vhost_vring_call_reset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2026-31576", "url": "https://ubuntu.com/security/CVE-2026-31576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: hackrf: fix to not free memory after the device is registered in hackrf_probe() In hackrf driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open hackrf fd \t\t\t\t\t\t.... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... \t\t\t\t\t\tsys_ioctl(fd, ...); \t\t\t\t\t\t v4l2_ioctl(); \t\t\t\t\t\t video_is_registered() // UAF!! \t\t\t\t\t\t.... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t v4l2_release() // UAF!! \t\t\t\t\t\t hackrf_video_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked. However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver's release() is invoked. Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven't been released yet. And since release() free memory too, race to use-after-free and double-free vuln occur. To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43058", "url": "https://ubuntu.com/security/CVE-2026-43058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix pass-by-value structs causing MSAN warnings vidtv_ts_null_write_into() and vidtv_ts_pcr_write_into() take their argument structs by value, causing MSAN to report uninit-value warnings. While only vidtv_ts_null_write_into() has triggered a report so far, both functions share the same issue. Fix by passing both structs by const pointer instead, avoiding the stack copy of the struct along with its MSAN shadow and origin metadata. The functions do not modify the structs, which is enforced by the const qualifier.", "cve_priority": "medium", "cve_public_date": "2026-05-02 07:16:00 UTC" }, { "cve": "CVE-2026-31577", "url": "https://ubuntu.com/security/CVE-2026-31577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map The DAT inode's btree node cache (i_assoc_inode) is initialized lazily during btree operations. However, nilfs_mdt_save_to_shadow_map() assumes i_assoc_inode is already initialized when copying dirty pages to the shadow map during GC. If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before any btree operation has occurred on the DAT inode, i_assoc_inode is NULL leading to a general protection fault. Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always initialized before any GC operation can use it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31578", "url": "https://ubuntu.com/security/CVE-2026-31578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: as102: fix to not free memory after the device is registered in as102_usb_probe() In as102_usb driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open as102 fd \t\t\t\t\t\t.... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t as102_release() // UAF!! \t\t\t\t\t\t as102_usb_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a USB character device registered with usb_register_dev() is later unregistered (via usb_deregister_dev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked. In as102, as102_usb_probe() calls usb_register_dev() and then, on an error path, does usb_deregister_dev() and frees as102_dev_t right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102_release() --> as102_usb_release() and access or free as102_dev_t again, occur a race to use-after-free and double-free vuln. The fix is to never kfree(as102_dev_t) directly once usb_register_dev() has succeeded. After deregistration, defer freeing memory to .release(). In other words, let release() perform the last kfree when the final open FD is closed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31580", "url": "https://ubuntu.com/security/CVE-2026-31580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bcache: fix cached_dev.sb_bio use-after-free and crash In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention: ``` [6888366.280350] Call Trace: [6888366.280452] blk_update_request+0x14e/0x370 [6888366.280561] blk_mq_end_request+0x1a/0x130 [6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd] [6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd] [6888366.280903] __complete_request+0x22/0x70 [libceph] [6888366.281032] osd_dispatch+0x15e/0xb40 [libceph] [6888366.281164] ? inet_recvmsg+0x5b/0xd0 [6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph] [6888366.281405] ceph_con_process_message+0x79/0x140 [libceph] [6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph] [6888366.281661] ceph_con_workfn+0x329/0x680 [libceph] ``` After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped. Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio. This patch hopes to wait for sb_write to complete in cached_dev_free. It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31581", "url": "https://ubuntu.com/security/CVE-2026-31581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: fix use-after-free on disconnect In usb6fire_chip_abort(), the chip struct is allocated as the card's private data (via snd_card_new with sizeof(struct sfire_chip)). When snd_card_free_when_closed() is called and no file handles are open, the card and embedded chip are freed synchronously. The subsequent chip->card = NULL write then hits freed slab memory. Call trace: usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline] usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953 Fix by moving the card lifecycle out of usb6fire_chip_abort() and into usb6fire_chip_disconnect(). The card pointer is saved in a local before any teardown, snd_card_disconnect() is called first to prevent new opens, URBs are aborted while chip is still valid, and snd_card_free_when_closed() is called last so chip is never accessed after the card may be freed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31583", "url": "https://ubuntu.com/security/CVE-2026-31583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free in em28xx_v4l2_open() em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock, creating a race with em28xx_v4l2_init()'s error path and em28xx_v4l2_fini(), both of which free the em28xx_v4l2 struct and set dev->v4l2 to NULL under dev->lock. This race leads to two issues: - use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler, since the video_device is embedded in the freed em28xx_v4l2 struct. - NULL pointer dereference in em28xx_resolution_set() when accessing v4l2->norm, since dev->v4l2 has been set to NULL. Fix this by moving the mutex_lock() before the dev->v4l2 read and adding a NULL check for dev->v4l2 under the lock.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31585", "url": "https://ubuntu.com/security/CVE-2026-31585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix nfeeds state corruption on start_streaming failure syzbot reported a memory leak in vidtv_psi_service_desc_init [1]. When vidtv_start_streaming() fails inside vidtv_start_feed(), the nfeeds counter is left incremented even though no feed was actually started. This corrupts the driver state: subsequent start_feed calls see nfeeds > 1 and skip starting the mux, while stop_feed calls eventually try to stop a non-existent stream. This state corruption can also lead to memory leaks, since the mux and channel resources may be partially allocated during a failed start_streaming but never cleaned up, as the stop path finds dvb->streaming == false and returns early. Fix by decrementing nfeeds back when start_streaming fails, keeping the counter in sync with the actual number of active feeds. [1] BUG: memory leak unreferenced object 0xffff888145b50820 (size 32): comm \"syz.0.17\", pid 6068, jiffies 4294944486 backtrace (crc 90a0c7d4): vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31686", "url": "https://ubuntu.com/security/CVE-2026-31686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/kasan: fix double free for kasan pXds kasan_free_pxd() assumes the page table is always struct page aligned. But that's not always the case for all architectures. E.g. In case of powerpc with 64K pagesize, PUD table (of size 4096) comes from slab cache named pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's just directly pass the start of the pxd table which is passed as the 1st argument. This fixes the below double free kasan issue seen with PMEM: radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages ================================================================== BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20 Free of addr c0000003c38e0000 by task ndctl/2164 CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeries Call Trace: dump_stack_lvl+0x88/0xc4 (unreliable) print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140 kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec ---- interrupt: 3000 at 0x7fff93b3d3f4 NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000 REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392) MSR: 800000000280f033 CR: 48888208 XER: 00000000 <...> NIP [00007fff93b3d3f4] 0x7fff93b3d3f4 LR [00007fff93b3d3f4] 0x7fff93b3d3f4 ---- interrupt: 3000 The buggy address belongs to the object at c0000003c38e0000 which belongs to the cache pgtable-2^9 of size 4096 The buggy address is located 0 bytes inside of 4096-byte region [c0000003c38e0000, c0000003c38e1000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:c0000003bfd63e01 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) page_type: f5(slab) raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected [ 138.953636] [ T2164] Memory state around the buggy address: [ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953669] [ T2164] ^ [ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953692] [ T2164] ================================================================== [ 138.953701] [ T2164] Disabling lock debugging due to kernel taint", "cve_priority": "low", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2026-31588", "url": "https://ubuntu.com/security/CVE-2026-31588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use scratch field in MMIO fragment to hold small write values When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value. This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, *and* both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable. The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by overwrite the data value with garbage. Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *al ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31630", "url": "https://ubuntu.com/security/CVE-2026-31630", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: proc: size address buffers for %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with \"%pISpc\". That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23399", "url": "https://ubuntu.com/security/CVE-2026-23399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nf_tables: nft_dynset: fix possible stateful expression memleak in error path If cloning the second stateful expression in the element via GFP_ATOMIC fails, then the first stateful expression remains in place without being released.   unreferenced object (percpu) 0x607b97e9cab8 (size 16):     comm \"softirq\", pid 0, jiffies 4294931867     hex dump (first 16 bytes on cpu 3):       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     backtrace (crc 0):       pcpu_alloc_noprof+0x453/0xd80       nft_counter_clone+0x9c/0x190 [nf_tables]       nft_expr_clone+0x8f/0x1b0 [nf_tables]       nft_dynset_new+0x2cb/0x5f0 [nf_tables]       nft_rhash_update+0x236/0x11c0 [nf_tables]       nft_dynset_eval+0x11f/0x670 [nf_tables]       nft_do_chain+0x253/0x1700 [nf_tables]       nft_do_chain_ipv4+0x18d/0x270 [nf_tables]       nf_hook_slow+0xaa/0x1e0       ip_local_deliver+0x209/0x330", "cve_priority": "medium", "cve_public_date": "2026-03-28 08:15:00 UTC" }, { "cve": "CVE-2024-35865", "url": "https://ubuntu.com/security/CVE-2024-35865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.", "cve_priority": "medium", "cve_public_date": "2024-05-19 09:15:00 UTC" }, { "cve": "CVE-2026-31590", "url": "https://ubuntu.com/security/CVE-2026-31590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION Drop the WARN in sev_pin_memory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing: struct kvm_enc_region range = { .addr = 0, .size = -1ul, }; __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range); Note, the checks in sev_mem_enc_register_region() that presumably exist to verify the incoming address+size are completely worthless, as both \"addr\" and \"size\" are u64s and SEV is 64-bit only, i.e. they _can't_ be greater than ULONG_MAX. That wart will be cleaned up in the near future. \tif (range->addr > ULONG_MAX || range->size > ULONG_MAX) \t\treturn -EINVAL; Opportunistically add a comment to explain why the code calculates the number of pages the \"hard\" way, e.g. instead of just shifting @ulen.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31596", "url": "https://ubuntu.com/security/CVE-2026-31596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle invalid dinode in ocfs2_group_extend [BUG] kernel BUG at fs/ocfs2/resize.c:308! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308 Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe Call Trace: ... ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... [CAUSE] ocfs2_group_extend() assumes that the global bitmap inode block returned from ocfs2_inode_lock() has already been validated and BUG_ONs when the signature is not a dinode. That assumption is too strong for crafted filesystems because the JBD2-managed buffer path can bypass structural validation and return an invalid dinode to the resize ioctl. [FIX] Validate the dinode explicitly in ocfs2_group_extend(). If the global bitmap buffer does not contain a valid dinode, report filesystem corruption with ocfs2_error() and fail the resize operation instead of crashing the kernel.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31597", "url": "https://ubuntu.com/security/CVE-2026-31597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY, as documented in mm/filemap.c: \"If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap().\" When this happens, a concurrent munmap() can call remove_vma() and free the vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call dereferences it -- a use-after-free. Fix this by saving ip_blkno as a plain integer before calling filemap_fault(), and removing vma from the trace event. Since ip_blkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31599", "url": "https://ubuntu.com/security/CVE-2026-31599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections syzbot reported a general protection fault in vidtv_psi_desc_assign [1]. vidtv_psi_pmt_stream_init() can return NULL on memory allocation failure, but vidtv_channel_pmt_match_sections() does not check for this. When tail is NULL, the subsequent call to vidtv_psi_desc_assign(&tail->descriptor, desc) dereferences a NULL pointer offset, causing a general protection fault. Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean up the already-allocated stream chain and return. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629 Call Trace: vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline] vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479 vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31602", "url": "https://ubuntu.com/security/CVE-2026-31602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Limit PTP to a single page Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic. ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ct_vm_map() tries to access beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count remain unchanged.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31603", "url": "https://ubuntu.com/security/CVE-2026-31603", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: sm750fb: fix division by zero in ps_to_hz() ps_to_hz() is called from hw_sm750_crtc_set_mode() without validating that pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO causes a division by zero. Fix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent with other framebuffer drivers.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31605", "url": "https://ubuntu.com/security/CVE-2026-31605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31615", "url": "https://ubuntu.com/security/CVE-2026-31615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: renesas_usb3: validate endpoint index in standard request handlers The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math. This is just like what was done in commit ee0d382feb44 (\"usb: gadget: aspeed_udc: validate endpoint index for ast udc\") for the aspeed driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31616", "url": "https://ubuntu.com/security/CVE-2026-31616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete() A broken/bored/mean USB host can overflow the skb_shared_info->frags[] array on a Linux gadget exposing a Phonet function by sending an unbounded sequence of full-page OUT transfers. pn_rx_complete() finalizes the skb only when req->actual < req->length, where req->length is set to PAGE_SIZE by the gadget. If the host always sends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never be reset and each completion will add another fragment via skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17), subsequent frag stores overwrite memory adjacent to the shinfo on the heap. Drop the skb and account a length error when the frag limit is reached, matching the fix applied in t7xx by commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\").", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31617", "url": "https://ubuntu.com/security/CVE-2026-31617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb() The block_len read from the host-supplied NTB header is checked against ntb_max but has no lower bound. When block_len is smaller than opts->ndp_size, the bounds check of: \tndp_index > (block_len - opts->ndp_size) will underflow producing a huge unsigned value that ndp_index can never exceed, defeating the check entirely. The same underflow occurs in the datagram index checks against block_len - opts->dpe_size. With those checks neutered, a malicious USB host can choose ndp_index and datagram offsets that point past the actual transfer, and the skb_put_data() copies adjacent kernel memory into the network skb. Fix this by rejecting block lengths that cannot hold at least the NTB header plus one NDP. This will make block_len - opts->ndp_size and block_len - opts->dpe_size both well-defined. Commit 8d2b1a1ec9f5 (\"CDC-NCM: avoid overflow in sanity checking\") fixed a related class of issues on the host side of NCM.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31618", "url": "https://ubuntu.com/security/CVE-2026-31618", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31619", "url": "https://ubuntu.com/security/CVE-2026-31619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: fireworks: bound device-supplied status before string array lookup The status field in an EFW response is a 32-bit value supplied by the firewire device. efr_status_names[] has 17 entries so a status value outside that range goes off into the weeds when looking at the %s value. Even worse, the status could return EFR_STATUS_INCOMPLETE which is 0x80000000, and is obviously not in that array of potential strings. Fix this up by properly bounding the index against the array size and printing \"unknown\" if it's not recognized.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31622", "url": "https://ubuntu.com/security/CVE-2026-31622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: digital: Bounds check NFC-A cascade depth in SDD response handler The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3 or 4 bytes to target->nfcid1 on each round, but the number of cascade rounds is controlled entirely by the peer device. The peer sets the cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the cascade-incomplete bit in the SEL_RES (deciding whether another round follows). ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver actually enforces this. This means a malicious peer can keep the cascade running, writing past the heap-allocated nfc_target with each round. Fix this by rejecting the response when the accumulated UID would exceed the buffer. Commit e329e71013c9 (\"NFC: nci: Bounds check struct nfc_target arrays\") fixed similar missing checks against the same field on the NCI path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31623", "url": "https://ubuntu.com/security/CVE-2026-31623", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete() A malicious USB device claiming to be a CDC Phonet modem can overflow the skb_shared_info->frags[] array by sending an unbounded sequence of full-page bulk transfers. Drop the skb and increment the length error when the frag limit is reached. This matches the same fix that commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\") did for the t7xx driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31624", "url": "https://ubuntu.com/security/CVE-2026-31624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: clamp report_size in s32ton() to avoid undefined shift s32ton() shifts by n-1 where n is the field's report_size, a value that comes directly from a HID device. The HID parser bounds report_size only to <= 256, so a broken HID device can supply a report descriptor with a wide field that triggers shift exponents up to 256 on a 32-bit type when an output report is built via hid_output_field() or hid_set_field(). Commit ec61b41918587 (\"HID: core: fix shift-out-of-bounds in hid_report_raw_event\") added the same n > 32 clamp to the function snto32(), but s32ton() was never given the same fix as I guess syzbot hadn't figured out how to fuzz a device the same way. Fix this up by just clamping the max value of n, just like snto32() does.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31625", "url": "https://ubuntu.com/security/CVE-2026-31625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: alps: fix NULL pointer dereference in alps_raw_event() Commit ecfa6f34492c (\"HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them\") attempted to fix up the HID drivers that had missed the previous fix that was done in 2ff5baa9b527 (\"HID: appleir: Fix potential NULL dereference at raw event handle\"), but the alps driver was missed. Fix this up by properly checking in the hid-alps driver that it had been claimed correctly before attempting to process the raw event.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31626", "url": "https://ubuntu.com/security/CVE-2026-31626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify() Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using uninitialized data. Smatch warns that only 6 bytes are copied to this 8-byte (u64) variable, leaving the last two bytes uninitialized: drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify() warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes) Initializing the variable at the start of the function fixes this warning and ensures predictable behavior.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31627", "url": "https://ubuntu.com/security/CVE-2026-31627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: s3c24xx: check the size of the SMBUS message before using it The first byte of an i2c SMBUS message is the size, and it should be verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX before processing it. This is the same logic that was added in commit a6e04f05ce0b (\"i2c: tegra: check msg length in SMBUS block read\") to the i2c tegra driver.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31532", "url": "https://ubuntu.com/security/CVE-2026-31532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: fix ro->uniq use-after-free in raw_rcv() raw_release() unregisters raw CAN receive filters via can_rx_unregister(), but receiver deletion is deferred with call_rcu(). This leaves a window where raw_rcv() may still be running in an RCU read-side critical section after raw_release() frees ro->uniq, leading to a use-after-free of the percpu uniq storage. Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific socket destructor. can_rx_unregister() takes an extra reference to the socket and only drops it from the RCU callback, so freeing uniq from sk_destruct ensures the percpu area is not released until the relevant callbacks have drained. [mkl: applied manually]", "cve_priority": "high", "cve_public_date": "2026-04-23 12:17:00 UTC" }, { "cve": "CVE-2026-31629", "url": "https://ubuntu.com/security/CVE-2026-31629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: add missing return after LLCP_CLOSED checks In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket state is LLCP_CLOSED, the code correctly calls release_sock() and nfc_llcp_sock_put() but fails to return. Execution falls through to the remainder of the function, which calls release_sock() and nfc_llcp_sock_put() again. This results in a double release_sock() and a refcount underflow via double nfc_llcp_sock_put(), leading to a use-after-free. Add the missing return statements after the LLCP_CLOSED branches in both functions to prevent the fall-through.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31407", "url": "https://ubuntu.com/security/CVE-2026-31407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: add missing netlink policy validations Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink. These attributes are used by the kernel without any validation. Extend the netlink policies accordingly. Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-43079", "url": "https://ubuntu.com/security/CVE-2026-43079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Skip discovery table for offline dies This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0. WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore] Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at \"pmu->boxes[die] = box\" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43080", "url": "https://ubuntu.com/security/CVE-2026-43080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: Drop large packets with UDP encap syzbot reported a WARN on my patch series [1]. The actual issue is an overflow of 16-bit UDP length field, and it exists in the upstream code. My series added a debug WARN with an overflow check that exposed the issue, that's why syzbot tripped on my patches, rather than on upstream code. syzbot's repro: r0 = socket$pppl2tp(0x18, 0x1, 0x1) r1 = socket$inet6_udp(0xa, 0x2, 0x0) connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c) connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\\x00', '\\xff\\xff', @empty}}}}, 0x32) writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)=\"ee\", 0x34000}], 0x1) It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP encapsulation, and l2tp_xmit_core doesn't check for overflows when it assigns the UDP length field. The value gets trimmed to 16 bites. Add an overflow check that drops oversized packets and avoids sending packets with trimmed UDP length to the wire. syzbot's stack trace (with my patch applied): len >= 65536u WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957 Modules linked in: CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline] RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline] RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327 Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f RSP: 0018:ffffc90003d67878 EFLAGS: 00010293 RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000 RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004 R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900 R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000 FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0 Call Trace: pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x503/0x550 net/socket.c:1195 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1 vfs_writev+0x33c/0x990 fs/read_write.c:1059 do_writev+0x154/0x2e0 fs/read_write.c:1105 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f636479c629 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629 RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31673", "url": "https://ubuntu.com/security/CVE-2026-31673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: read UNIX_DIAG_VFS data under unix_state_lock Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unix_release_sock() clears u->path under unix_state_lock() and drops the path reference after unlocking. Read the inode and device numbers for UNIX_DIAG_VFS while holding unix_state_lock(), then emit the netlink attribute after dropping the lock. This keeps the VFS data stable while the reply is being built.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31681", "url": "https://ubuntu.com/security/CVE-2026-31681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_multiport: validate range encoding in checkentry ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end. The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule. Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43085", "url": "https://ubuntu.com/security/CVE-2026-43085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator When batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send() appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSG_DONE message body. Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes the nfgenmsg payload via nfnl_fill_hdr(), consistent with how __build_packet_message() already constructs NFULNL_MSG_PACKET headers.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43089", "url": "https://ubuntu.com/security/CVE-2026-43089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_mapping() struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43093", "url": "https://ubuntu.com/security/CVE-2026-43093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: tighten UMEM headroom validation to account for tailroom and min frame The current headroom validation in xdp_umem_reg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skb_shared_info stored at the end of XSK frame would be corrupted. HW typically works with 128-aligned sizes so let us provide this value as bare minimum. Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43098", "url": "https://ubuntu.com/security/CVE-2026-43098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: s3fwrn5: allocate rx skb before consuming bytes s3fwrn82_uart_read() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already deliver a complete frame before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43099", "url": "https://ubuntu.com/security/CVE-2026-43099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: fix null-ptr-deref in icmp_build_probe() ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing this error pointer to dev_hold() will cause a kernel crash with null-ptr-deref. Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting \"No Such Interface\".", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43103", "url": "https://ubuntu.com/security/CVE-2026-43103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lapbether: handle NETDEV_PRE_TYPE_CHANGE lapbeth_data_transmit() expects the underlying device type to be ARPHRD_ETHER. Returning NOTIFY_BAD from lapbeth_device_event() makes sure bonding driver can not break this expectation.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31684", "url": "https://ubuntu.com/security/CVE-2026-31684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_csum: validate nested VLAN headers tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43074", "url": "https://ubuntu.com/security/CVE-2026-43074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: defer struct eventpoll free to RCU grace period In certain situations, ep_free() in eventpoll.c will kfree the epi->ep eventpoll struct while it still being used by another concurrent thread. Defer the kfree() to an RCU callback to prevent UAF.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43104", "url": "https://ubuntu.com/security/CVE-2026-43104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix a memory leak in hang state error path When vc4_save_hang_state() encounters an early return condition, it returns without freeing the previously allocated `kernel_state`, leaking memory. Add the missing kfree() calls by consolidating the early return paths into a single place.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43105", "url": "https://ubuntu.com/security/CVE-2026-43105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix memory leak of BO array in hang state The hang state's BO array is allocated separately with kzalloc() in vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the missing kfree() for the BO array before freeing the hang state struct.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43110", "url": "https://ubuntu.com/security/CVE-2026-43110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: validate bsscfg indices in IF events brcmf_fweh_handle_if_event() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check. Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array. [add missing wifi prefix]", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43111", "url": "https://ubuntu.com/security/CVE-2026-43111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: fix use-after-free in roccat_report_event roccat_report_event() iterates over the device->readers list without holding the readers_lock. This allows a concurrent roccat_release() to remove and free a reader while it's still being accessed, leading to a use-after-free. Protect the readers list traversal with the readers_lock mutex.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43112", "url": "https://ubuntu.com/security/CVE-2026-43112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath When cifs_sanitize_prepath is called with an empty string or a string containing only delimiters (e.g., \"/\"), the current logic attempts to check *(cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read. This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL. The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.", "cve_priority": "low", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43113", "url": "https://ubuntu.com/security/CVE-2026-43113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wl1251: validate packet IDs before indexing tx_frames wl1251_tx_packet_cb() uses the firmware completion ID directly to index the fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it. Reject completion IDs that fall outside wl->tx_frames[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2025-54518", "url": "https://ubuntu.com/security/CVE-2025-54518", "cve_description": "Improper isolation of shared resources within the CPU operation cache on Zen 2-based products could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation.", "cve_priority": "high", "cve_public_date": "2026-05-15 05:16:00 UTC" }, { "cve": "CVE-2026-46174", "url": "https://ubuntu.com/security/CVE-2026-46174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2025-71150", "url": "https://ubuntu.com/security/CVE-2025-71150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix refcount leak when invalid session is found on session lookup When a session is found but its state is not SMB2_SESSION_VALID, It indicates that no valid session was found, but it is missing to decrement the reference count acquired by the session lookup, which results in a reference count leak. This patch fixes the issue by explicitly calling ksmbd_user_session_put to release the reference to the session.", "cve_priority": "medium", "cve_public_date": "2026-01-23 15:16:00 UTC" }, { "cve": "CVE-2026-23395", "url": "https://ubuntu.com/security/CVE-2026-23395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ Currently the code attempts to accept requests regardless of the command identifier which may cause multiple requests to be marked as pending (FLAG_DEFER_SETUP) which can cause more than L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer causing an overflow. The spec is quite clear that the same identifier shall not be used on subsequent requests: 'Within each signaling channel a different Identifier shall be used for each successive request or indication.' https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d So this attempts to check if there are any channels pending with the same identifier and rejects if any are found.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31549", "url": "https://ubuntu.com/security/CVE-2026-31549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: cp2615: fix serial string NULL-deref at probe The cp2615 driver uses the USB device serial string as the i2c adapter name but does not make sure that the string exists. Verify that the device has a serial number before accessing it to avoid triggering a NULL-pointer dereference (e.g. with malicious devices).", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31433", "url": "https://ubuntu.com/security/CVE-2026-31433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potencial OOB in get_file_all_info() for compound requests When a compound request consists of QUERY_DIRECTORY + QUERY_INFO (FILE_ALL_INFORMATION) and the first command consumes nearly the entire max_trans_size, get_file_all_info() would blindly call smbConvertToUTF16() with PATH_MAX, causing out-of-bounds write beyond the response buffer. In get_file_all_info(), there was a missing validation check for the client-provided OutputBufferLength before copying the filename into FileName field of the smb2_file_all_info structure. If the filename length exceeds the available buffer space, it could lead to potential buffer overflows or memory corruption during smbConvertToUTF16 conversion. This calculating the actual free buffer size using smb2_calc_max_out_buf_len() and returning -EINVAL if the buffer is insufficient and updating smbConvertToUTF16 to use the actual filename length (clamped by PATH_MAX) to ensure a safe copy operation.", "cve_priority": "high", "cve_public_date": "2026-04-22 09:16:00 UTC" }, { "cve": "CVE-2026-31480", "url": "https://ubuntu.com/security/CVE-2026-31480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential deadlock in cpu hotplug with osnoise The following sequence may leads deadlock in cpu hotplug: task1 task2 task3 ----- ----- ----- mutex_lock(&interface_lock) [CPU GOING OFFLINE] cpus_write_lock(); osnoise_cpu_die(); kthread_stop(task3); wait_for_completion(); osnoise_sleep(); mutex_lock(&interface_lock); cpus_read_lock(); [DEAD LOCK] Fix by swap the order of cpus_read_lock() and mutex_lock(&interface_lock).", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31466", "url": "https://ubuntu.com/security/CVE-2026-31466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix folio isn't locked in softleaf_to_folio() On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows: \tCPU0 CPU1 deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags. This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio() because of the race between folio split and zap_nonpresent_ptes() leading to a folio incorrectly undergoing modification without a folio lock being held. This is a BUG_ON() before commit 93976a20345b (\"mm: eliminate further swapops predicates\"), which in merged in v6.19-rc1. To fix it, add missing smp_rmb() if the softleaf entry is migration entry in softleaf_to_folio() and softleaf_to_page(). [tujinjiang@huawei.com: update function name and comments]", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43054", "url": "https://ubuntu.com/security/CVE-2026-43054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Drain commands in target_reset handler tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS without draining any in-flight commands. The SCSI EH documentation (scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver has made lower layers \"forget about timed out scmds\" and is ready for new commands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug, mpi3mr) enforces this by draining or completing outstanding commands before returning SUCCESS. Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight scsi_cmnd structures for recovery commands (e.g. TUR) while the target core still has async completion work queued for the old se_cmd. The memset in queuecommand zeroes se_lun and lun_ref_active, causing transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN reference prevents transport_clear_lun_ref() from completing, hanging configfs LUN unlink forever in D-state: INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transport_clear_lun_ref+0x78/0x90 [target_core_mod] core_tpg_remove_lun+0x28/0xb0 [target_core_mod] target_fabric_port_unlink+0x50/0x60 [target_core_mod] configfs_unlink+0x156/0x1f0 [configfs] vfs_unlink+0x109/0x290 do_unlinkat+0x1d5/0x2d0 Fix this by making tcm_loop_target_reset() actually drain commands: 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that the target core knows about (those not yet CMD_T_COMPLETE). 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and flush_work() on each se_cmd — this drains any deferred completion work for commands that already had CMD_T_COMPLETE set before the TMR (which the TMR skips via __target_check_io_state()). This is the same pattern used by mpi3mr, scsi_debug, and libsas to drain outstanding commands during reset.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-23401", "url": "https://ubuntu.com/security/CVE-2026-23401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE When installing an emulated MMIO SPTE, do so *after* dropping/zapping the existing SPTE (if it's shadow-present). While commit a54aa15c6bda3 was right about it being impossible to convert a shadow-present SPTE to an MMIO SPTE due to a _guest_ write, it failed to account for writes to guest memory that are outside the scope of KVM. E.g. if host userspace modifies a shadowed gPTE to switch from a memslot to emulted MMIO and then the guest hits a relevant page fault, KVM will install the MMIO SPTE without first zapping the shadow-present SPTE. ------------[ cut here ]------------ is_shadow_present_pte(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm] Call Trace: mmu_set_spte+0x237/0x440 [kvm] ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47fa3f ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-04-01 09:16:00 UTC" }, { "cve": "CVE-2026-31454", "url": "https://ubuntu.com/security/CVE-2026-31454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: save ailp before dropping the AIL lock in push callbacks In xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the AIL lock is dropped to perform buffer IO. Once the cluster buffer no longer protects the log item from reclaim, the log item may be freed by background reclaim or the dquot shrinker. The subsequent spin_lock() call dereferences lip->li_ailp, which is a use-after-free. Fix this by saving the ailp pointer in a local variable while the AIL lock is held and the log item is guaranteed to be valid.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31446", "url": "https://ubuntu.com/security/CVE-2026-31446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in update_super_work when racing with umount Commit b98535d09179 (\"ext4: fix bug_on in start_this_handle during umount filesystem\") moved ext4_unregister_sysfs() before flushing s_sb_upd_work to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups reads during unmount. However, this introduced a use-after-free because update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which accesses the kobject's kernfs_node after it has been freed by kobject_del() in ext4_unregister_sysfs(): update_super_work ext4_put_super ----------------- -------------- ext4_unregister_sysfs(sb) kobject_del(&sbi->s_kobj) __kobject_del() sysfs_remove_dir() kobj->sd = NULL sysfs_put(sd) kernfs_put() // RCU free ext4_notify_error_sysfs(sbi) sysfs_notify(&sbi->s_kobj) kn = kobj->sd // stale pointer kernfs_get(kn) // UAF on freed kernfs_node ext4_journal_destroy() flush_work(&sbi->s_sb_upd_work) Instead of reordering the teardown sequence, fix this by making ext4_notify_error_sysfs() detect that sysfs has already been torn down by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call in that case. A dedicated mutex (s_error_notify_mutex) serializes ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs() to prevent TOCTOU races where the kobject could be deleted between the state_in_sysfs check and the sysfs_notify() call.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31450", "url": "https://ubuntu.com/security/CVE-2026-31450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: publish jinode after initialization ext4_inode_attach_jinode() publishes ei->jinode to concurrent users. It used to set ei->jinode before jbd2_journal_init_jbd_inode(), allowing a reader to observe a non-NULL jinode with i_vfs_inode still unset. The fast commit flush path can then pass this jinode to jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and may crash. Below is the crash I observe: ``` BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xas_find_marked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: filemap_get_folios_tag+0x87/0x2a0 __filemap_fdatawait_range+0x5f/0xd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? cap_safe_nice+0x37/0x70 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 filemap_fdatawait_range_keep_errors+0x12/0x40 ext4_fc_commit+0x697/0x8b0 ? ext4_file_write_iter+0x64b/0x950 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? vfs_write+0x356/0x480 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ext4_sync_file+0xf7/0x370 do_fsync+0x3b/0x80 ? syscall_trace_enter+0x108/0x1d0 __x64_sys_fdatasync+0x16/0x20 do_syscall_64+0x62/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... ``` Fix this by initializing the jbd2_inode first. Use smp_wmb() and WRITE_ONCE() to publish ei->jinode after initialization. Readers use READ_ONCE() to fetch the pointer.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31726", "url": "https://ubuntu.com/security/CVE-2026-31726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix NULL pointer dereference during unbind race Commit b81ac4395bbe (\"usb: gadget: uvc: allow for application to cleanly shutdown\") introduced two stages of synchronization waits totaling 1500ms in uvc_function_unbind() to prevent several types of kernel panics. However, this timing-based approach is insufficient during power management (PM) transitions. When the PM subsystem starts freezing user space processes, the wait_event_interruptible_timeout() is aborted early, which allows the unbind thread to proceed and nullify the gadget pointer (cdev->gadget = NULL): [ 814.123447][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind() [ 814.178583][ T3173] PM: suspend entry (deep) [ 814.192487][ T3173] Freezing user space processes [ 814.197668][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind no clean disconnect, wait for release When the PM subsystem resumes or aborts the suspend and tasks are restarted, the V4L2 release path is executed and attempts to access the already nullified gadget pointer, triggering a kernel panic: [ 814.292597][ C0] PM: pm_system_irq_wakeup: 479 triggered dhdpcie_host_wake [ 814.386727][ T3173] Restarting tasks ... [ 814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 814.404021][ T4558] pc : usb_gadget_deactivate+0x14/0xf4 [ 814.404031][ T4558] lr : usb_function_deactivate+0x54/0x94 [ 814.404078][ T4558] Call trace: [ 814.404080][ T4558] usb_gadget_deactivate+0x14/0xf4 [ 814.404083][ T4558] usb_function_deactivate+0x54/0x94 [ 814.404087][ T4558] uvc_function_disconnect+0x1c/0x5c [ 814.404092][ T4558] uvc_v4l2_release+0x44/0xac [ 814.404095][ T4558] v4l2_release+0xcc/0x130 Address the race condition and NULL pointer dereference by: 1. State Synchronization (flag + mutex) Introduce a 'func_unbound' flag in struct uvc_device. This allows uvc_function_disconnect() to safely skip accessing the nullified cdev->gadget pointer. As suggested by Alan Stern, this flag is protected by a new mutex (uvc->lock) to ensure proper memory ordering and prevent instruction reordering or speculative loads. This mutex is also used to protect 'func_connected' for consistent state management. 2. Explicit Synchronization (completion) Use a completion to synchronize uvc_function_unbind() with the uvc_vdev_release() callback. This prevents Use-After-Free (UAF) by ensuring struct uvc_device is freed after all video device resources are released.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31728", "url": "https://ubuntu.com/security/CVE-2026-31728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop A race condition between gether_disconnect() and eth_stop() leads to a NULL pointer dereference. Specifically, if eth_stop() is triggered concurrently while gether_disconnect() is tearing down the endpoints, eth_stop() attempts to access the cleared endpoint descriptor, causing the following NPE: Unable to handle kernel NULL pointer dereference Call trace: __dwc3_gadget_ep_enable+0x60/0x788 dwc3_gadget_ep_enable+0x70/0xe4 usb_ep_enable+0x60/0x15c eth_stop+0xb8/0x108 Because eth_stop() crashes while holding the dev->lock, the thread running gether_disconnect() fails to acquire the same lock and spins forever, resulting in a hardlockup: Core - Debugging Information for Hardlockup core(7) Call trace: queued_spin_lock_slowpath+0x94/0x488 _raw_spin_lock+0x64/0x6c gether_disconnect+0x19c/0x1e8 ncm_set_alt+0x68/0x1a0 composite_setup+0x6a0/0xc50 The root cause is that the clearing of dev->port_usb in gether_disconnect() is delayed until the end of the function. Move the clearing of dev->port_usb to the very beginning of gether_disconnect() while holding dev->lock. This cuts off the link immediately, ensuring eth_stop() will see dev->port_usb as NULL and safely bail out.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31721", "url": "https://ubuntu.com/security/CVE-2026-31721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: move list and spinlock inits from bind to alloc There was an issue when you did the following: - setup and bind an hid gadget - open /dev/hidg0 - use the resulting fd in EPOLL_CTL_ADD - unbind the UDC - bind the UDC - use the fd in EPOLL_CTL_DEL When CONFIG_DEBUG_LIST was enabled, a list_del corruption was reported within remove_wait_queue (via ep_remove_wait_queue). After some debugging I found out that the queues, which f_hid registers via poll_wait were the problem. These were initialized using init_waitqueue_head inside hidg_bind. So effectively, the bind function re-initialized the queues while there were still items in them. The solution is to move the initialization from hidg_bind to hidg_alloc to extend their lifetimes to the lifetime of the function instance. Additionally, I found many other possibly problematic init calls in the bind function, which I moved as well.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31670", "url": "https://ubuntu.com/security/CVE-2026-31670", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rfkill: prevent unlimited numbers of rfkill events from being created Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a \"large\" number (i.e. 1000) to prevent abuses like this.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31634", "url": "https://ubuntu.com/security/CVE-2026-31634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix reference count leak in rxrpc_server_keyring() This patch fixes a reference count leak in rxrpc_server_keyring() by checking if rx->securities is already set.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31651", "url": "https://ubuntu.com/security/CVE-2026-31651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix NULL-deref on disconnect Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31656", "url": "https://ubuntu.com/security/CVE-2026-31656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` <4> [487.221889] Workqueue: i915-unordered engine_retire [i915] <4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] Call Trace: <4> [487.222711] <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ? __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ? __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ? __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] ``` Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it. (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31658", "url": "https://ubuntu.com/security/CVE-2026-31658", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit() When dma_map_single() fails in tse_start_xmit(), the function returns NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure. Add dev_kfree_skb_any() before returning to properly free the skb.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31660", "url": "https://ubuntu.com/security/CVE-2026-31660", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: allocate rx skb before consuming bytes pn532_receive_buf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already hand a complete frame to pn533_recv_frame() before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31661", "url": "https://ubuntu.com/security/CVE-2026-31661", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: Fix dma_free_coherent() size dma_alloc_consistent() may change the size to align it. The new size is saved in alloced. Change the free size to match the allocation size.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31662", "url": "https://ubuntu.com/security/CVE-2026-31662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round. Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31665", "url": "https://ubuntu.com/security/CVE-2026-31665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: fix use-after-free in timeout object destroy nft_ct_timeout_obj_destroy() frees the timeout object with kfree() immediately after nf_ct_untimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcu_dereference() in nf_ct_timeout_data(). Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c. KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2024-56557", "url": "https://ubuntu.com/security/CVE-2024-56557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer The AD7923 was updated to support devices with 8 channels, but the size of tx_buf and ring_xfer was not increased accordingly, leading to a potential buffer overflow in ad7923_update_scan_mode().", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2024-36898", "url": "https://ubuntu.com/security/CVE-2024-36898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: fix uninitialised kfifo If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace. Initialise the kfifo in the case where the software debounce is already active.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2025-40016", "url": "https://ubuntu.com/security/CVE-2025-40016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID. In a previous attempt commit 3dd075fe8ebb (\"media: uvcvideo: Require entities to have a non-zero unique ID\"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2026-31667", "url": "https://ubuntu.com/security/CVE-2026-31667", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: uinput - fix circular locking dependency with ff-core A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller): ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex The cycle is caused by four lock acquisition paths: 1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex. 2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex. 3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex. 4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex. Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes. To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock. Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible. Lock ordering after the fix: ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31671", "url": "https://ubuntu.com/security/CVE-2026-31671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_report() struct xfrm_user_report is a __u8 proto field followed by a struct xfrm_selector which means there is three \"empty\" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31672", "url": "https://ubuntu.com/security/CVE-2026-31672", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00usb: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the USB anchor lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43336", "url": "https://ubuntu.com/security/CVE-2026-43336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: chacha: Zeroize permuted_state before it leaves scope Since the ChaCha permutation is invertible, the local variable 'permuted_state' is sufficient to compute the original 'state', and thus the key, even after the permutation has been done. While the kernel is quite inconsistent about zeroizing secrets on the stack (and some prominent userspace crypto libraries don't bother at all since it's not guaranteed to work anyway), the kernel does try to do it as a best practice, especially in cases involving the RNG. Thus, explicitly zeroize 'permuted_state' before it goes out of scope.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31695", "url": "https://ubuntu.com/security/CVE-2026-31695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free Currently we execute `SET_NETDEV_DEV(dev, &priv->lowerdev->dev)` for the virt_wifi net devices. However, unregistering a virt_wifi device in netdev_run_todo() can happen together with the device referenced by SET_NETDEV_DEV(). It can result in use-after-free during the ethtool operations performed on a virt_wifi device that is currently being unregistered. Such a net device can have the `dev.parent` field pointing to the freed memory, but ethnl_ops_begin() calls `pm_runtime_get_sync(dev->dev.parent)`. Let's remove SET_NETDEV_DEV for virt_wifi to avoid bugs like this: ================================================================== BUG: KASAN: slab-use-after-free in __pm_runtime_resume+0xe2/0xf0 Read of size 2 at addr ffff88810cfc46f8 by task pm/606 Call Trace: dump_stack_lvl+0x4d/0x70 print_report+0x170/0x4f3 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 kasan_report+0xda/0x110 ? __pm_runtime_resume+0xe2/0xf0 ? __pm_runtime_resume+0xe2/0xf0 __pm_runtime_resume+0xe2/0xf0 ethnl_ops_begin+0x49/0x270 ethnl_set_features+0x23c/0xab0 ? __pfx_ethnl_set_features+0x10/0x10 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xf/0xf0 ? local_clock+0x10/0x30 ? kasan_save_track+0x25/0x60 ? __kasan_kmalloc+0x7f/0x90 ? genl_family_rcv_msg_attrs_parse.isra.0+0x150/0x2c0 genl_family_rcv_msg_doit+0x1e7/0x2c0 ? __pfx_genl_family_rcv_msg_doit+0x10/0x10 ? __pfx_cred_has_capability.isra.0+0x10/0x10 ? stack_trace_save+0x8e/0xc0 genl_rcv_msg+0x411/0x660 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_ethnl_set_features+0x10/0x10 netlink_rcv_skb+0x121/0x380 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_down_read+0x10/0x10 genl_rcv+0x23/0x30 netlink_unicast+0x60f/0x830 ? __pfx_netlink_unicast+0x10/0x10 ? __pfx___alloc_skb+0x10/0x10 netlink_sendmsg+0x6ea/0xbc0 ? __pfx_netlink_sendmsg+0x10/0x10 ? __futex_queue+0x10b/0x1f0 ____sys_sendmsg+0x7a2/0x950 ? copy_msghdr_from_user+0x26b/0x430 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ___sys_sendmsg+0xf8/0x180 ? __pfx____sys_sendmsg+0x10/0x10 ? __pfx_futex_wait+0x10/0x10 ? fdget+0x2e4/0x4a0 __sys_sendmsg+0x11f/0x1c0 ? __pfx___sys_sendmsg+0x10/0x10 do_syscall_64+0xe2/0x570 ? exc_page_fault+0x66/0xb0 entry_SYSCALL_64_after_hwframe+0x77/0x7f This fix may be combined with another one in the ethtool subsystem: https://lore.kernel.org/all/20260322075917.254874-1-alex.popov@linux.com/T/#u", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2024-56584", "url": "https://ubuntu.com/security/CVE-2024-56584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/tctx: work around xa_store() allocation error issue syzbot triggered the following WARN_ON: WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51 which is the WARN_ON_ONCE(!xa_empty(&tctx->xa)); sanity check in __io_uring_free() when a io_uring_task is going through its final put. The syzbot test case includes injecting memory allocation failures, and it very much looks like xa_store() can fail one of its memory allocations and end up with ->head being non-NULL even though no entries exist in the xarray. Until this issue gets sorted out, work around it by attempting to iterate entries in our xarray, and WARN_ON_ONCE() if one is found.", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2026-31720", "url": "https://ubuntu.com/security/CVE-2026-31720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: validate control request size f_audio_complete() copies req->length bytes into a 4-byte stack variable: u32 data = 0; memcpy(&data, req->buf, req->length); req->length is derived from the host-controlled USB request path, which can lead to a stack out-of-bounds write. Validate req->actual against the expected payload size for the supported control selectors and decode only the expected amount of data. This avoids copying a host-influenced length into a fixed-size stack object.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43342", "url": "https://ubuntu.com/security/CVE-2026-43342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Protect RNDIS options with mutex The class/subclass/protocol options are suspectible to race conditions as they can be accessed concurrently through configfs. Use existing mutex to protect these options. This issue was identified during code inspection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43343", "url": "https://ubuntu.com/security/CVE-2026-43343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_subset: Fix unbalanced refcnt in geth_free geth_alloc() increments the reference count, but geth_free() fails to decrement it. This prevents the configuration of attributes via configfs after unlinking the function. Decrement the reference count in geth_free() to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-68256", "url": "https://ubuntu.com/security/CVE-2025-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser The Information Element (IE) parser rtw_get_ie() trusted the length byte of each IE without validating that the IE body (len bytes after the 2-byte header) fits inside the remaining frame buffer. A malformed frame can advertise an IE length larger than the available data, causing the parser to increment its pointer beyond the buffer end. This results in out-of-bounds reads or, depending on the pattern, an infinite loop. Fix by validating that (offset + 2 + len) does not exceed the limit before accepting the IE or advancing to the next element. This prevents OOB reads and ensures the parser terminates safely on malformed frames.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40103", "url": "https://ubuntu.com/security/CVE-2025-40103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix refcount leak for cifs_sb_tlink Fix three refcount inconsistency issues related to `cifs_sb_tlink`. Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be called after successful calls to `cifs_sb_tlink()`. Three calls fail to update refcount accordingly, leading to possible resource leaks.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-38006", "url": "https://ubuntu.com/security/CVE-2025-38006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: Don't access ifa_index when missing In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but only when the struct ifaddrmsg is provided. Otherwise it will be comparing to uninitialised memory - reproducible in the syzkaller case from dhcpd, or busybox \"ip addr show\". The kernel MCTP implementation has always filtered by ifa_index, so existing userspace programs expecting to dump MCTP addresses must already be passing a valid ifa_index value (either 0 or a real index). BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40323", "url": "https://ubuntu.com/security/CVE-2025-40323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Set fb_display[i]->mode to NULL when the mode is released Recently, we discovered the following issue through syzkaller: BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0. Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2026-23031", "url": "https://ubuntu.com/security/CVE-2026-23031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak In gs_can_open(), the URBs for USB-in transfers are allocated, added to the parent->rx_submitted anchor and submitted. In the complete callback gs_usb_receive_bulk_callback(), the URB is processed and resubmitted. In gs_can_close() the URBs are freed by calling usb_kill_anchored_urbs(parent->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in gs_can_close(). Fix the memory leak by anchoring the URB in the gs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-43324", "url": "https://ubuntu.com/security/CVE-2026-43324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix interrupt synchronization error This fixes an error in synchronization in the dummy-hcd driver. The error has a somewhat involved history. The synchronization mechanism was introduced by commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), which added an emulated \"interrupts enabled\" flag together with code emulating synchronize_irq() (it waits until all current handler callbacks have returned). But the emulated interrupt-disable occurred too late, after the driver containing the handler callback routines had been told that it was unbound and no more callbacks would occur. Commit 4a5d797a9f9c (\"usb: gadget: dummy_hcd: fix gpf in gadget_setup\") tried to fix this by moving the synchronize_irq() emulation code from dummy_stop() to dummy_pullup(), which runs before the unbind callback. There still were races, though, because the emulated interrupt-disable still occurred too late. It couldn't be moved to dummy_pullup(), because that routine can be called for reasons other than an impending unbind. Therefore commits 7dc0c55e9f30 (\"USB: UDC core: Add udc_async_callbacks gadget op\") and 04145a03db9d (\"USB: UDC: Implement udc_async_callbacks in dummy-hcd\") added an API allowing the UDC core to tell dummy-hcd exactly when emulated interrupts and their callbacks should be disabled. That brings us to the current state of things, which is still wrong because the emulated synchronize_irq() occurs before the emulated interrupt-disable! That's no good, beause it means that more emulated interrupts can occur after the synchronize_irq() emulation has run, leading to the possibility that a callback handler may be running when the gadget driver is unbound. To fix this, we have to move the synchronize_irq() emulation code yet again, to the dummy_udc_async_callbacks() routine, which takes care of enabling and disabling emulated interrupt requests. The synchronization will now run immediately after emulated interrupts are disabled, which is where it belongs.", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43327", "url": "https://ubuntu.com/security/CVE-2026-43327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix locking/synchronization error Syzbot testing was able to provoke an addressing exception and crash in the usb_gadget_udc_reset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second (\"driver\") argument of NULL. The bad caller was set_link_state() in dummy_hcd.c, and the problem arose because of a race between a USB reset and driver unbind. These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first. The error responsible for the syzbot crash occurred because the stop_activity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stop_activity() occurs in set_link_state() when handling an emulated USB reset, after the test of dum->ints_enabled and before the increment of dum->callback_usage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->ints_enabled and dum->driver. Normally this other thread would have to wait for dum->callback_usage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callback_usage had not yet been incremented. The fix is to increment dum->callback_usage _before_ calling stop_activity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usb_gadget_udc_reset() safely returns and dum->callback_usage has been decremented again.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31737", "url": "https://ubuntu.com/security/CVE-2026-31737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ftgmac100: fix ring allocation unwind on open failure ftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, and rx_scratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function. Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31738", "url": "https://ubuntu.com/security/CVE-2026-31738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: validate ND option lengths in vxlan_na_create vxlan_na_create() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31747", "url": "https://ubuntu.com/security/CVE-2026-31747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me4000: Fix potential overrun of firmware buffer `me4000_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`. Note: The firmware loading was totally broken before commit ac584af59945 (\"staging: comedi: me4000: fix firmware downloading\"), but that is the most sensible target for this fix.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31748", "url": "https://ubuntu.com/security/CVE-2026-31748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me_daq: Fix potential overrun of firmware buffer `me2600_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Although it checks that the supplied firmware is at least 16 bytes long, it does not check that it is long enough to contain the data stream. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31749", "url": "https://ubuntu.com/security/CVE-2026-31749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: ni_atmio16d: Fix invalid clean-up after failed attach If the driver's COMEDI \"attach\" handler function (`atmio16d_attach()`) returns an error, the COMEDI core will call the driver's \"detach\" handler function (`atmio16d_detach()`) to clean up. This calls `reset_atmio16d()` unconditionally, but depending on where the error occurred in the attach handler, the device may not have been sufficiently initialized to call `reset_atmio16d()`. It uses `dev->iobase` as the I/O port base address and `dev->private` as the pointer to the COMEDI device's private data structure. `dev->iobase` may still be set to its initial value of 0, which would result in undesired writes to low I/O port addresses. `dev->private` may still be `NULL`, which would result in null pointer dereferences. Fix `atmio16d_detach()` by checking that `dev->private` is valid (non-null) before calling `reset_atmio16d()`. This implies that `dev->iobase` was set correctly since that is set up before `dev->private`.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43340", "url": "https://ubuntu.com/security/CVE-2026-43340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Reinit dev->spinlock between attachments to low-level drivers `struct comedi_device` is the main controlling structure for a COMEDI device created by the COMEDI subsystem. It contains a member `spinlock` containing a spin-lock that is initialized by the COMEDI subsystem, but is reserved for use by a low-level driver attached to the COMEDI device (at least since commit 25436dc9d84f (\"Staging: comedi: remove RT code\")). Some COMEDI devices (those created on initialization of the COMEDI subsystem when the \"comedi.comedi_num_legacy_minors\" parameter is non-zero) can be attached to different low-level drivers over their lifetime using the `COMEDI_DEVCONFIG` ioctl command. This can result in inconsistent lock states being reported when there is a mismatch in the spin-lock locking levels used by each low-level driver to which the COMEDI device has been attached. Fix it by reinitializing `dev->spinlock` before calling the low-level driver's `attach` function pointer if `CONFIG_LOCKDEP` is enabled.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31751", "url": "https://ubuntu.com/security/CVE-2026-31751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: dt2815: add hardware detection to prevent crash The dt2815 driver crashes when attached to I/O ports without actual hardware present. This occurs because syzkaller or users can attach the driver to arbitrary I/O addresses via COMEDI_DEVCONFIG ioctl. When no hardware exists at the specified port, inb() operations return 0xff (floating bus), but outb() operations can trigger page faults due to undefined behavior, especially under race conditions: BUG: unable to handle page fault for address: 000000007fffff90 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:dt2815_attach+0x6e0/0x1110 Add hardware detection by reading the status register before attempting any write operations. If the read returns 0xff, assume no hardware is present and fail the attach with -ENODEV. This prevents crashes from outb() operations on non-existent hardware.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31752", "url": "https://ubuntu.com/security/CVE-2026-31752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: validate ND option lengths br_nd_send() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31754", "url": "https://ubuntu.com/security/CVE-2026-31754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix state inconsistency on gadget init failure When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency. When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error, so cdns_role_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles. This leads to a synchronous external abort in xhci_gen_setup() when setting up the host controller: [ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408 [ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switch Fix by calling cdns_drd_gadget_off() in the error path to properly clean up the DRD gadget state.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31755", "url": "https://ubuntu.com/security/CVE-2026-31755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix NULL pointer dereference in ep_queue When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when __cdns3_gadget_ep_queue() is called, causing a kernel crash. Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints. This prevents potential crashes when ep_queue is called on endpoints that are not ready.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31756", "url": "https://ubuntu.com/security/CVE-2026-31756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop() dwc2_gadget_exit_clock_gating() internally calls call_gadget() macro, which expects hsotg->lock to be held since it does spin_unlock/spin_lock around the gadget driver callback invocation. However, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating() without holding the lock. This leads to: - spin_unlock on a lock that is not held (undefined behavior) - The lock remaining held after dwc2_gadget_exit_clock_gating() returns, causing a deadlock when spin_lock_irqsave() is called later in the same function. Fix this by acquiring hsotg->lock before calling dwc2_gadget_exit_clock_gating() and releasing it afterwards, which satisfies the locking requirement of the call_gadget() macro.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31758", "url": "https://ubuntu.com/security/CVE-2026-31758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbtmc: Flush anchored URBs in usbtmc_release When calling usbtmc_release, pending anchored URBs must be flushed or killed to prevent use-after-free errors (e.g. in the HCD giveback path). Call usbtmc_draw_down() to allow anchored URBs to be completed.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31759", "url": "https://ubuntu.com/security/CVE-2026-31759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: fix double free in ulpi_register_interface() error path When device_register() fails, ulpi_register() calls put_device() on ulpi->dev. The device release callback ulpi_dev_release() drops the OF node reference and frees ulpi, but the current error path in ulpi_register_interface() then calls kfree(ulpi) again, causing a double free. Let put_device() handle the cleanup through ulpi_dev_release() and avoid freeing ulpi again in ulpi_register_interface().", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31761", "url": "https://ubuntu.com/security/CVE-2026-31761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Move iio_device_register() to correct location iio_device_register() should be at the end of the probe function to prevent race conditions. Place iio_device_register() at the end of the probe function and place iio_device_unregister() accordingly.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31762", "url": "https://ubuntu.com/security/CVE-2026-31762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix irq resource leak The interrupt handler is setup but only a few lines down if iio_trigger_register() fails the function returns without properly releasing the handler. Add cleanup goto to resolve resource leak. Detected by Smatch: drivers/iio/gyro/mpu3050-core.c:1128 mpu3050_trigger_probe() warn: 'irq' from request_threaded_irq() not released on lines: 1124.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31763", "url": "https://ubuntu.com/security/CVE-2026-31763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix incorrect free_irq() variable The handler for the IRQ part of this driver is mpu3050->trig but, in the teardown free_irq() is called with handler mpu3050. Use correct IRQ handler when calling free_irq().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31770", "url": "https://ubuntu.com/security/CVE-2026-31770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) Fix division by zero in occ_show_power_1() In occ_show_power_1() case 1, the accumulator is divided by update_tag without checking for zero. If no samples have been collected yet (e.g. during early boot when the sensor block is included but hasn't been updated), update_tag is zero, causing a kernel divide-by-zero crash. The 2019 fix in commit 211186cae14d (\"hwmon: (occ) Fix division by zero issue\") only addressed occ_get_powr_avg() used by occ_show_power_2() and occ_show_power_a0(). This separate code path in occ_show_power_1() was missed. Fix this by reusing the existing occ_get_powr_avg() helper, which already handles the zero-sample case and uses mul_u64_u32_div() to multiply before dividing for better precision. Move the helper above occ_show_power_1() so it is visible at the call site. [groeck: Fix alignment problems reported by checkpatch]", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43334", "url": "https://ubuntu.com/security/CVE-2026-43334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: force responder MITM requirements before building the pairing response smp_cmd_pairing_req() currently builds the pairing response from the initiator auth_req before enforcing the local BT_SECURITY_HIGH requirement. If the initiator omits SMP_AUTH_MITM, the response can also omit it even though the local side still requires MITM. tk_request() then sees an auth value without SMP_AUTH_MITM and may select JUST_CFM, making method selection inconsistent with the pairing policy the responder already enforces. When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMP_AUTH_MITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31773", "url": "https://ubuntu.com/security/CVE-2026-31773", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: derive legacy responder STK authentication from MITM state The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved. For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result. This also keeps the legacy path aligned with the Secure Connections code, which already treats JUST_WORKS/JUST_CFM as unauthenticated.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31776", "url": "https://ubuntu.com/security/CVE-2026-31776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix missing SPDIFI1 index handling SPDIF1 DAIO type isn't properly handled in daio_device_index() for hw20k2, and it returned -EINVAL, which ended up with the out-of-bounds array access. Follow the hw20k1 pattern and return the proper index for this type, too.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31778", "url": "https://ubuntu.com/security/CVE-2026-31778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix stack out-of-bounds read in init_card The loop creates a whitespace-stripped copy of the card shortname where `len < sizeof(card->id)` is used for the bounds check. Since sizeof(card->id) is 16 and the local id buffer is also 16 bytes, writing 16 non-space characters fills the entire buffer, overwriting the terminating nullbyte. When this non-null-terminated string is later passed to snd_card_set_id() -> copy_valid_id_string(), the function scans forward with `while (*nid && ...)` and reads past the end of the stack buffer, reading the contents of the stack. A USB device with a product name containing many non-ASCII, non-space characters (e.g. multibyte UTF-8) will reliably trigger this as follows: BUG: KASAN: stack-out-of-bounds in copy_valid_id_string sound/core/init.c:696 [inline] BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c sound/core/init.c:718 The off-by-one has been present since commit bafeee5b1f8d (\"ALSA: snd_usb_caiaq: give better shortname\") from June 2009 (v2.6.31-rc1), which first introduced this whitespace-stripping loop. The original code never accounted for the null terminator when bounding the copy. Fix this by changing the loop bound to `sizeof(card->id) - 1`, ensuring at least one byte remains as the null terminator.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31780", "url": "https://ubuntu.com/security/CVE-2026-31780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation The variable valuesize is declared as u8 but accumulates the total length of all SSIDs to scan. Each SSID contributes up to 33 bytes (IEEE80211_MAX_SSID_LEN + 1), and with WILC_MAX_NUM_PROBED_SSID (10) SSIDs the total can reach 330, which wraps around to 74 when stored in a u8. This causes kmalloc to allocate only 75 bytes while the subsequent memcpy writes up to 331 bytes into the buffer, resulting in a 256-byte heap buffer overflow. Widen valuesize from u8 to u32 to accommodate the full range.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31781", "url": "https://ubuntu.com/security/CVE-2026-31781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ioc32: stop speculation on the drm_compat_ioctl path The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling array_index_nospec() on the index to the function pointer list.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43333", "url": "https://ubuntu.com/security/CVE-2026-43333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject direct access to nullable PTR_TO_BUF pointers check_mem_access() matches PTR_TO_BUF via base_type() which strips PTR_MAYBE_NULL, allowing direct dereference without a null check. Map iterator ctx->key and ctx->value are PTR_TO_BUF | PTR_MAYBE_NULL. On stop callbacks these are NULL, causing a kernel NULL dereference. Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching the existing PTR_TO_BTF_ID pattern.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31415", "url": "https://ubuntu.com/security/CVE-2026-31415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid overflows in ip6_datagram_send_ctl() Yiming Qian reported : I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via `skb_under_panic()` (local DoS). The core issue is a mismatch between: - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type `__u16`) and - a pointer to the *last* provided destination-options header (`opt->dst1opt`) when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided. - `include/net/ipv6.h`: - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible). (lines 291-307, especially 298) - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`: - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen` without rejecting duplicates. (lines 909-933) - `net/ipv6/ip6_output.c:__ip6_append_data()`: - Uses `opt->opt_flen + opt->opt_nflen` to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - `net/ipv6/ip6_output.c:__ip6_make_skb()`: - Calls `ipv6_push_frag_opts()` if `opt->opt_flen` is non-zero. (lines 1930-1934) - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`: - Push size comes from `ipv6_optlen(opt->dst1opt)` (based on the pointed-to header). (lines 1179-1185 and 1206-1211) 1. `opt_flen` is a 16-bit accumulator: - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`. 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs and increments `opt_flen` each time: - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`: - It computes `len = ((hdr->hdrlen + 1) << 3);` - It checks `CAP_NET_RAW` using `ns_capable(net->user_ns, CAP_NET_RAW)`. (line 922) - Then it does: - `opt->opt_flen += len;` (line 927) - `opt->dst1opt = hdr;` (line 928) There is no duplicate rejection here (unlike the legacy `IPV6_2292DSTOPTS` path which rejects duplicates at `net/ipv6/datagram.c:901-904`). If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps while `dst1opt` still points to a large (2048-byte) destination-options header. In the attached PoC (`poc.c`): - 32 cmsgs with `hdrlen=255` => `len = (255+1)*8 = 2048` - 1 cmsg with `hdrlen=0` => `len = 8` - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8` - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header. 3. The transmit path sizes headers using the wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1463-1465`: - `headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;` With wrapped `opt_flen`, `headersize`/headroom decisions underestimate what will be pushed later. 4. When building the final skb, the actual push length comes from `dst1opt` and is not limited by wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1930-1934`: - `if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);` - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes `dst1opt` via `ipv6_push_exthdr()`. - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does: - `skb_push(skb, ipv6_optlen(opt));` - `memcpy(h, opt, ipv6_optlen(opt));` With insufficient headroom, `skb_push()` underflows and triggers `skb_under_panic()` -> `BUG()`: - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`) - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`) - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target netns user namespace (`ns_capable(net->user_ns, CAP_NET_RAW)`). - Root (or any task with `CAP_NET_RAW`) can trigger this without user namespaces. - An unprivileged `uid=1000` user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced `CAP_NET_RAW` (the attached PoC does this). - Local denial of service: kernel BUG/panic (system crash). - ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31422", "url": "https://ubuntu.com/security/CVE-2026-31422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_flow: fix NULL pointer dereference on shared blocks flow_change() calls tcf_block_q() and dereferences q->handle to derive a default baseclass. Shared blocks leave block->q NULL, causing a NULL deref when a flow filter without a fully qualified baseclass is created on a shared block. Check tcf_block_shared() before accessing block->q and return -EINVAL for shared blocks. This avoids the null-deref shown below: ======================================================================= KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:flow_change (net/sched/cls_flow.c:508) Call Trace: tc_new_tfilter (net/sched/cls_api.c:2432) rtnetlink_rcv_msg (net/core/rtnetlink.c:6980) [...] =======================================================================", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31421", "url": "https://ubuntu.com/security/CVE-2026-31421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL pointer dereference on shared blocks The old-method path in fw_classify() calls tcf_block_q() and dereferences q->handle. Shared blocks leave block->q NULL, causing a NULL deref when an empty cls_fw filter is attached to a shared block and a packet with a nonzero major skb mark is classified. Reject the configuration in fw_change() when the old method (no TCA_OPTIONS) is used on a shared block, since fw_classify()'s old-method path needs block->q which is NULL for shared blocks. The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fw_classify (net/sched/cls_fw.c:81) Call Trace: tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860) tc_run (net/core/dev.c:4401) __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31417", "url": "https://ubuntu.com/security/CVE-2026-31417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix overflow when accumulating packets Add a check to ensure that `x25_sock.fraglen` does not overflow. The `fraglen` also needs to be resetted when purging `fragment_queue` in `x25_clear_queues()`.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43014", "url": "https://ubuntu.com/security/CVE-2026-43014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: properly unregister fixed rate clocks The additional resources allocated with clk_register_fixed_rate() need to be released with clk_unregister_fixed_rate(), otherwise they are lost.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43015", "url": "https://ubuntu.com/security/CVE-2026-43015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix clk handling on PCI glue driver removal platform_device_unregister() may still want to use the registered clks during runtime resume callback. Note that there is a commit d82d5303c4c5 (\"net: macb: fix use after free on rmmod\") that addressed the similar problem of clk vs platform device unregistration but just moved the bug to another place. Save the pointers to clks into local variables for reuse after platform device is unregistered. BUG: KASAN: use-after-free in clk_prepare+0x5a/0x60 Read of size 8 at addr ffff888104f85e00 by task modprobe/597 CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x8d/0xba print_report+0x17f/0x496 kasan_report+0xd9/0x180 clk_prepare+0x5a/0x60 macb_runtime_resume+0x13d/0x410 [macb] pm_generic_runtime_resume+0x97/0xd0 __rpm_callback+0xc8/0x4d0 rpm_callback+0xf6/0x230 rpm_resume+0xeeb/0x1a70 __pm_runtime_resume+0xb4/0x170 bus_remove_device+0x2e3/0x4b0 device_del+0x5b3/0xdc0 platform_device_del+0x4e/0x280 platform_device_unregister+0x11/0x50 pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 519: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x8e/0x90 __clk_register+0x458/0x2890 clk_hw_register+0x1a/0x60 __clk_hw_register_fixed_rate+0x255/0x410 clk_register_fixed_rate+0x3c/0xa0 macb_probe+0x1d8/0x42e [macb_pci] local_pci_probe+0xd7/0x190 pci_device_probe+0x252/0x600 really_probe+0x255/0x7f0 __driver_probe_device+0x1ee/0x330 driver_probe_device+0x4c/0x1f0 __driver_attach+0x1df/0x4e0 bus_for_each_dev+0x15d/0x1f0 bus_add_driver+0x486/0x5e0 driver_register+0x23a/0x3d0 do_one_initcall+0xfd/0x4d0 do_init_module+0x18b/0x5a0 load_module+0x5663/0x7950 __do_sys_finit_module+0x101/0x180 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 597: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x180 __kmem_cache_free+0xbc/0x320 clk_unregister+0x6de/0x8d0 macb_remove+0x73/0xc0 [macb_pci] pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31425", "url": "https://ubuntu.com/security/CVE-2026-31425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: ib: reject FRMR registration before IB connection is established rds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_data and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with i_cm_id = NULL because the connection worker has not yet called rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses the control message before any connection establishment, allowing rds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash the kernel. The existing guard in rds_ib_reg_frmr() only checks for !ic (added in commit 9e630bcb7701), which does not catch this case since ic is allocated early and is always non-NULL once the connection object exists. KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920 Call Trace: rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167) rds_ib_map_frmr (net/rds/ib_frmr.c:252) rds_ib_reg_frmr (net/rds/ib_frmr.c:430) rds_ib_get_mr (net/rds/ib_rdma.c:615) __rds_rdma_map (net/rds/rdma.c:295) rds_cmsg_rdma_map (net/rds/rdma.c:860) rds_sendmsg (net/rds/send.c:1363) ____sys_sendmsg do_syscall_64 Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all non-NULL before proceeding with FRMR registration, mirroring the guard already present in rds_ib_post_inv(). Return -ENODEV when the connection is not ready, which the existing error handling in rds_cmsg_send() converts to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to start the connection worker.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43020", "url": "https://ubuntu.com/security/CVE-2026-43020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate LTK enc_size on load Load Long Term Keys stores the user-provided enc_size and later uses it to size fixed-size stack operations when replying to LE LTK requests. An enc_size larger than the 16-byte key buffer can therefore overflow the reply stack buffer. Reject oversized enc_size values while validating the management LTK record so invalid keys never reach the stored key state.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43024", "url": "https://ubuntu.com/security/CVE-2026-43024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject immediate NF_QUEUE verdict nft_queue is always used from userspace nftables to deliver the NF_QUEUE verdict. Immediately emitting an NF_QUEUE verdict is never used by the userspace nft tools, so reject immediate NF_QUEUE verdicts. The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NF_QUEUE immediate verdicts to address this issue.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31424", "url": "https://ubuntu.com/security/CVE-2026-31424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP Weiming Shi says: xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_* constants. This is only correct for families whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING). ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports: - arpt_CLASSIFY - arpt_mangle - arpt_MARK that provide explicit NFPROTO_ARP match/target declarations.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43026", "url": "https://ubuntu.com/security/CVE-2026-43026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT. The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields. Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled. Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43027", "url": "https://ubuntu.com/security/CVE-2026-43027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_helper: pass helper to expect cleanup nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expect_iter_me() never matches any expectation and all of them survive the cleanup. After unregister returns, nfnl_cthelper_del() frees the helper object immediately. Subsequent expectation dumps or packet-driven init_conntrack() calls then dereference the freed exp->helper, causing a use-after-free. Pass the actual helper pointer so expectations referencing it are properly destroyed before the helper object is freed. BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43028", "url": "https://ubuntu.com/security/CVE-2026-43028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: ensure names are nul-terminated Reject names that lack a \\0 character before feeding them to functions that expect c-strings. Fixes tag is the most recent commit that needs this change.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31416", "url": "https://ubuntu.com/security/CVE-2026-31416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: account for netlink header size This is a followup to an old bug fix: NLMSG_DONE needs to account for the netlink header size, not just the attribute size. This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43329", "url": "https://ubuntu.com/security/CVE-2026-43329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: strictly check for maximum number of actions The maximum number of flowtable hardware offload actions in IPv6 is: * ethernet mangling (4 payload actions, 2 for each ethernet address) * SNAT (4 payload actions) * DNAT (4 payload actions) * Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. * Redirect (1 action) Which makes 17, while the maximum is 16. But act_ct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions. Update flow_action_entry_next() calls to check for the maximum number of supported actions. While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31680", "url": "https://ubuntu.com/security/CVE-2026-31680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: flowlabel: defer exclusive option free until RCU teardown `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file RCU read-side lock and prints `fl->opt->opt_nflen` when an option block is present. Exclusive flowlabels currently free `fl->opt` as soon as `fl->users` drops to zero in `fl_release()`. However, the surrounding `struct ip6_flowlabel` remains visible in the global hash table until later garbage collection removes it and `fl_free_rcu()` finally tears it down. A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that early `kfree()` and dereference freed option state, triggering a crash in `ip6fl_seq_show()`. Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43030", "url": "https://ubuntu.com/security/CVE-2026-43030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix regsafe() for pointers to packet In case rold->reg->range == BEYOND_PKT_END && rcur->reg->range == N regsafe() may return true which may lead to current state with valid packet range not being explored. Fix the bug.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43032", "url": "https://ubuntu.com/security/CVE-2026-43032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: pn533: bound the UART receive buffer pn532_receive_buf() appends every incoming byte to dev->recv_skb and only resets the buffer after pn532_uart_rx_is_frame() recognizes a complete frame. A continuous stream of bytes without a valid PN532 frame header therefore keeps growing the skb until skb_put_u8() hits the tail limit. Drop the accumulated partial frame once the fixed receive buffer is full so malformed UART traffic cannot grow the skb past PN532_UART_SKB_BUFF_LEN.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43035", "url": "https://ubuntu.com/security/CVE-2026-43035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to zero to prevent an info-leak When building netlink messages, tc_chain_fill_node() never initializes the tcm_info field of struct tcmsg. Since the allocation is not zeroed, kernel heap memory is leaked to userspace through this 4-byte field. The fix simply zeroes tcm_info alongside the other fields that are already initialized.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43339", "url": "https://ubuntu.com/security/CVE-2026-43339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible UaF in addrconf_permanent_addr() The mentioned helper try to warn the user about an exceptional condition, but the message is delivered too late, accessing the ipv6 after its possible deletion. Reorder the statement to avoid the possible UaF; while at it, place the warning outside the idev->lock as it needs no protection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31423", "url": "https://ubuntu.com/security/CVE-2026-31423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: fix divide-by-zero in rtsc_min() m2sm() converts a u32 slope to a u64 scaled value. For large inputs (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores the difference of two such u64 values in a u32 variable `dsm` and uses it as a divisor. When the difference is exactly 2^32 the truncation yields zero, causing a divide-by-zero oops in the concave-curve intersection path: Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...] Widen `dsm` to u64 and replace do_div() with div64_u64() so the full difference is preserved.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43040", "url": "https://ubuntu.com/security/CVE-2026-43040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak When processing Router Advertisements with user options the kernel builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data The fix is simple, just zeroes the padding fields.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43041", "url": "https://ubuntu.com/security/CVE-2026-43041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak __radix_tree_create() allocates and links intermediate nodes into the tree one by one. If a subsequent allocation fails, the already-linked nodes remain in the tree with no corresponding leaf entry. These orphaned internal nodes are never reclaimed because radix_tree_for_each_slot() only visits slots containing leaf values. The radix_tree API is deprecated in favor of xarray. As suggested by Matthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray instead of fixing the radix_tree itself [1]. xarray properly handles cleanup of internal nodes — xa_destroy() frees all internal xarray nodes when the qrtr_node is released, preventing the leak. [1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43043", "url": "https://ubuntu.com/security/CVE-2026-43043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af-alg - fix NULL pointer dereference in scatterwalk The AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL) when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL exactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent sendmsg() allocates a new SGL and chains it, but fails to clear the end marker on the previous SGL's last data entry. This causes the crypto scatterwalk to hit a premature end, returning NULL on sg_next() and leading to a kernel panic during dereference. Fix this by explicitly unmarking the end of the previous SGL when performing sg_chain() in af_alg_alloc_tsgl().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43046", "url": "https://ubuntu.com/security/CVE-2026-43046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject root items with drop_progress and zero drop_level [BUG] When recovering relocation at mount time, merge_reloc_root() and btrfs_drop_snapshot() both use BUG_ON(level == 0) to guard against an impossible state: a non-zero drop_progress combined with a zero drop_level in a root_item, which can be triggered: ------------[ cut here ]------------ kernel BUG at fs/btrfs/relocation.c:1545! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2 RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545 Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000 Call Trace: merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861 btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195 btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130 open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640 btrfs_fill_super fs/btrfs/super.c:987 [inline] btrfs_get_tree_super fs/btrfs/super.c:1951 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline] btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ... RIP: 0033:0x7f969c9a8fde Code: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f ---[ end trace 0000000000000000 ]--- The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamic metadata fuzzing tool that corrupts btrfs metadata at runtime. [CAUSE] A non-zero drop_progress.objectid means an interrupted btrfs_drop_snapshot() left a resume point on disk, and in that case drop_level must be greater than 0 because the checkpoint is only saved at internal node levels. Although this invariant is enforced when the kernel writes the root item, it is not validated when the root item is read back from disk. That allows on-disk corruption to provide an invalid state with drop_progress.objectid != 0 and drop_level == 0. When relocation recovery later processes such a root item, merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). The same invalid metadata can also trigger the corresponding BUG_ON() in btrfs_drop_snapshot(). [FIX] Fix this by validating the root_item invariant in tree-checker when reading root items from disk: if drop_progress.objectid is non-zero, drop_level must also be non-zero. Reject such malformed metadata with -EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot() and triggers the BUG_ON. After the fix, the same corruption is correctly rejected by tree-checker and the BUG_ON is no longer triggered.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43047", "url": "https://ubuntu.com/security/CVE-2026-43047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Check to ensure report responses match the request It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes. Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43050", "url": "https://ubuntu.com/security/CVE-2026-43050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix use-after-free in sock_def_readable() A race condition exists between lec_atm_close() setting priv->lecd to NULL and concurrent access to priv->lecd in send_to_lecd(), lec_handle_bridge(), and lec_atm_send(). When the socket is freed via RCU while another thread is still using it, a use-after-free occurs in sock_def_readable() when accessing the socket's wait queue. The root cause is that lec_atm_close() clears priv->lecd without any synchronization, while callers dereference priv->lecd without any protection against concurrent teardown. Fix this by converting priv->lecd to an RCU-protected pointer: - Mark priv->lecd as __rcu in lec.h - Use rcu_assign_pointer() in lec_atm_close() and lecd_attach() for safe pointer assignment - Use rcu_access_pointer() for NULL checks that do not dereference the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and lecd_attach() - Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(), lec_handle_bridge() and lec_atm_send() to safely access lecd - Use rcu_assign_pointer() followed by synchronize_rcu() in lec_atm_close() to ensure all readers have completed before proceeding. This is safe since lec_atm_close() is called from vcc_release() which holds lock_sock(), a sleeping lock. - Remove the manual sk_receive_queue drain from lec_atm_close() since vcc_destroy_socket() already drains it after lec_atm_close() returns. v2: Switch from spinlock + sock_hold/put approach to RCU to properly fix the race. The v1 spinlock approach had two issues pointed out by Eric Dumazet: 1. priv->lecd was still accessed directly after releasing the lock instead of using a local copy. 2. The spinlock did not prevent packets being queued after lec_atm_close() drains sk_receive_queue since timer and workqueue paths bypass netif_stop_queue(). Note: Syzbot patch testing was attempted but the test VM terminated unexpectedly with \"Connection to localhost closed by remote host\", likely due to a QEMU AHCI emulation issue unrelated to this fix. Compile testing with \"make W=1 net/atm/lec.o\" passes cleanly.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43051", "url": "https://ubuntu.com/security/CVE-2026-43051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq The wacom_intuos_bt_irq() function processes Bluetooth HID reports without sufficient bounds checking. A maliciously crafted short report can trigger an out-of-bounds read when copying data into the wacom structure. Specifically, report 0x03 requires at least 22 bytes to safely read the processed data and battery status, while report 0x04 (which falls through to 0x03) requires 32 bytes. Add explicit length checks for these report IDs and log a warning if a short report is received.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31555", "url": "https://ubuntu.com/security/CVE-2026-31555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Clear stale exiting pointer in futex_lock_pi() retry path Fuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524 When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'. After wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0\t\t\t CPU1\t\t CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; \t\t\t futex_lock_pi(uaddr) \t\t\t futex_lock_pi_atomic() \t\t\t\t attach_to_pi_owner() \t\t\t\t // observes EXITING \t\t\t\t *exiting = owner; // takes ref \t\t\t\t return -EBUSY \t\t\t wait_for_owner_exiting(-EBUSY, owner) \t\t\t\t put_task_struct(); // drops ref \t\t\t // exiting still points to owner \t\t\t goto retry; \t\t\t futex_lock_pi_atomic() \t\t\t\t lock_pi_update_atomic() \t\t\t\t cmpxchg(uaddr) \t\t\t\t\t*uaddr ^= WAITERS // whatever \t\t\t\t // value changed \t\t\t\t return -EAGAIN; \t\t\t wait_for_owner_exiting(-EAGAIN, exiting) // stale \t\t\t\t WARN_ON_ONCE(exiting) Fix this by resetting upon retry, essentially aligning it with requeue_pi.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43065", "url": "https://ubuntu.com/security/CVE-2026-43065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: always drain queued discard work in ext4_mb_release() While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]: > If the filesystem is initially mounted with the discard option, > deleting files will populate sbi->s_discard_list and queue > s_discard_work. If it is then remounted with nodiscard, the > EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is > neither cancelled nor flushed. [1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing. In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own. Fix it because it's a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-43066", "url": "https://ubuntu.com/security/CVE-2026-43066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths During code review, Joseph found that ext4_fc_replay_inode() calls ext4_get_fc_inode_loc() to get the inode location, which holds a reference to iloc.bh that must be released via brelse(). However, several error paths jump to the 'out' label without releasing iloc.bh: - ext4_handle_dirty_metadata() failure - sync_dirty_buffer() failure - ext4_mark_inode_used() failure - ext4_iget() failure Fix this by introducing an 'out_brelse' label placed just before the existing 'out' label to ensure iloc.bh is always released. Additionally, make ext4_fc_replay_inode() propagate errors properly instead of always returning 0.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31447", "url": "https://ubuntu.com/security/CVE-2026-31447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: reject mount if bigalloc with s_first_data_block != 0 bigalloc with s_first_data_block != 0 is not supported, reject mounting it.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43068", "url": "https://ubuntu.com/security/CVE-2026-43068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal() There's issue as follows: ... EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): error count since last fsck: 1 EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760 EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760 ... According to the log analysis, blocks are always requested from the corrupted block group. This may happen as follows: ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return error ext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out; After commit 9008a58e5dce (\"ext4: make the bitmap read routines return real error codes\") merged, Commit 163a203ddb36 (\"ext4: mark block group as corrupt on block bitmap error\") is no real solution for allocating blocks from corrupted block groups. This is because if 'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then 'ext4_mb_load_buddy()' may return an error. This means that the block allocation will fail. Therefore, check block group if corrupted when ext4_mb_load_buddy() returns error.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31452", "url": "https://ubuntu.com/security/CVE-2026-31452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: convert inline data to extents when truncate exceeds inline size Add a check in ext4_setattr() to convert files from inline data storage to extent-based storage when truncate() grows the file size beyond the inline capacity. This prevents the filesystem from entering an inconsistent state where the inline data flag is set but the file size exceeds what can be stored inline. Without this fix, the following sequence causes a kernel BUG_ON(): 1. Mount filesystem with inode that has inline flag set and small size 2. truncate(file, 50MB) - grows size but inline flag remains set 3. sendfile() attempts to write data 4. ext4_write_inline_data() hits BUG_ON(write_size > inline_capacity) The crash occurs because ext4_write_inline_data() expects inline storage to accommodate the write, but the actual inline capacity (~60 bytes for i_block + ~96 bytes for xattrs) is far smaller than the file size and write request. The fix checks if the new size from setattr exceeds the inode's actual inline capacity (EXT4_I(inode)->i_inline_size) and converts the file to extent-based storage before proceeding with the size change. This addresses the root cause by ensuring the inline data flag and file size remain consistent during truncate operations.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31455", "url": "https://ubuntu.com/security/CVE-2026-31455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: stop reclaim before pushing AIL during unmount The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while background reclaim and inodegc are still running. This is broken independently of any use-after-free issues - background reclaim and inodegc should not be running while the AIL is being pushed during unmount, as inodegc can dirty and insert inodes into the AIL during the flush, and background reclaim can race to abort and free dirty inodes. Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel background reclaim before pushing the AIL. Stop inodegc before cancelling m_reclaim_work because the inodegc worker can re-queue m_reclaim_work via xfs_inodegc_set_reclaimable.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31464", "url": "https://ubuntu.com/security/CVE-2026-31464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done() A malicious or compromised VIO server can return a num_written value in the discover targets MAD response that exceeds max_targets. This value is stored directly in vhost->num_targets without validation, and is then used as the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], which is only allocated for max_targets entries. Indices at or beyond max_targets access kernel memory outside the DMA-coherent allocation. The out-of-bounds data is subsequently embedded in Implicit Logout and PLOGI MADs that are sent back to the VIO server, leaking kernel memory. Fix by clamping num_written to max_targets before storing it.", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31467", "url": "https://ubuntu.com/security/CVE-2026-31467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: add GFP_NOIO in the bio completion if needed The bio completion path in the process context (e.g. dm-verity) will directly call into decompression rather than trigger another workqueue context for minimal scheduling latencies, which can then call vm_map_ram() with GFP_KERNEL. Due to insufficient memory, vm_map_ram() may generate memory swapping I/O, which can cause submit_bio_wait to deadlock in some scenarios. Trimmed down the call stack, as follows: f2fs_submit_read_io submit_bio //bio_list is initialized. mmc_blk_mq_recovery z_erofs_endio vm_map_ram __pte_alloc_kernel __alloc_pages_direct_reclaim shrink_folio_list __swap_writepage submit_bio_wait //bio_list is non-NULL, hang!!! Use memalloc_noio_{save,restore}() to wrap up this path.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31469", "url": "https://ubuntu.com/security/CVE-2026-31469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false A UAF issue occurs when the virtio_net driver is configured with napi_tx=N and the device's IFF_XMIT_DST_RELEASE flag is cleared (e.g., during the configuration of tc route filter rules). When IFF_XMIT_DST_RELEASE is removed from the net_device, the network stack expects the driver to hold the reference to skb->dst until the packet is fully transmitted and freed. In virtio_net with napi_tx=N, skbs may remain in the virtio transmit ring for an extended period. If the network namespace is destroyed while these skbs are still pending, the corresponding dst_ops structure has freed. When a subsequent packet is transmitted, free_old_xmit() is triggered to clean up old skbs. It then calls dst_release() on the skb associated with the stale dst_entry. Since the dst_ops (referenced by the dst_entry) has already been freed, a UAF kernel paging request occurs. fix it by adds skb_dst_drop(skb) in start_xmit to explicitly release the dst reference before the skb is queued in virtio_net. Call Trace: Unable to handle kernel paging request at virtual address ffff80007e150000 CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT ... percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P) dst_release+0xe0/0x110 net/core/dst.c:177 skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177 sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255 dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469 napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527 __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net] free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net] start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net] ... Reproduction Steps: NETDEV=\"enp3s0\" config_qdisc_route_filter() { tc qdisc del dev $NETDEV root tc qdisc add dev $NETDEV root handle 1: prio tc filter add dev $NETDEV parent 1:0 \\ \tprotocol ip prio 100 route to 100 flowid 1:1 ip route add 192.168.1.100/32 dev $NETDEV realm 100 } test_ns() { ip netns add testns ip link set $NETDEV netns testns ip netns exec testns ifconfig $NETDEV 10.0.32.46/24 ip netns exec testns ping -c 1 10.0.32.1 ip netns del testns } config_qdisc_route_filter test_ns sleep 2 test_ns", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31473", "url": "https://ubuntu.com/security/CVE-2026-31473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex MEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0) queue teardown paths. This can race request object cleanup against vb2 queue cancellation and lead to use-after-free reports. We already serialize request queueing against STREAMON/OFF with req_queue_mutex. Extend that serialization to REQBUFS, and also take the same mutex in media_request_ioctl_reinit() so REINIT is in the same exclusion domain. This keeps request cleanup and queue cancellation from running in parallel for request-capable devices.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31570", "url": "https://ubuntu.com/security/CVE-2026-31570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gw: fix OOB heap access in cgw_csum_crc8_rel() cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx(): int from = calc_idx(crc8->from_idx, cf->len); int to = calc_idx(crc8->to_idx, cf->len); int res = calc_idx(crc8->result_idx, cf->len); if (from < 0 || to < 0 || res < 0) return; However, the loop and the result write then use the raw s8 fields directly instead of the computed variables: for (i = crc8->from_idx; ...) /* BUG: raw negative index */ cf->data[crc8->result_idx] = ...; /* BUG: raw negative index */ With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame, calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf->data[-64], and the write goes to cf->data[-64]. This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before the start of the canfd_frame on the heap. The companion function cgw_csum_xor_rel() uses `from`/`to`/`res` correctly throughout; fix cgw_csum_crc8_rel() to match. Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62 To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31483", "url": "https://ubuntu.com/security/CVE-2026-31483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/syscalls: Add spectre boundary for syscall dispatch table The s390 syscall number is directly controlled by userspace, but does not have an array_index_nospec() boundary to prevent access past the syscall function pointer tables.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31485", "url": "https://ubuntu.com/security/CVE-2026-31485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-lpspi: fix teardown order issue (UAF) There is a teardown order issue in the driver. The SPI controller is registered using devm_spi_register_controller(), which delays unregistration of the SPI controller until after the fsl_lpspi_remove() function returns. As the fsl_lpspi_remove() function synchronously tears down the DMA channels, a running SPI transfer triggers the following NULL pointer dereference due to use after free: | fsl_lpspi 42550000.spi: I/O Error in DMA RX | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] | Call trace: | fsl_lpspi_dma_transfer+0x260/0x340 [spi_fsl_lpspi] | fsl_lpspi_transfer_one+0x198/0x448 [spi_fsl_lpspi] | spi_transfer_one_message+0x49c/0x7c8 | __spi_pump_transfer_message+0x120/0x420 | __spi_sync+0x2c4/0x520 | spi_sync+0x34/0x60 | spidev_message+0x20c/0x378 [spidev] | spidev_ioctl+0x398/0x750 [spidev] [...] Switch from devm_spi_register_controller() to spi_register_controller() in fsl_lpspi_probe() and add the corresponding spi_unregister_controller() in fsl_lpspi_remove().", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31565", "url": "https://ubuntu.com/security/CVE-2026-31565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix deadlock during netdev reset with active connections Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering device_delete and subsequent client removal. During client removal, uverbs_client waits for QP reference count to reach zero while cma_client holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31494", "url": "https://ubuntu.com/security/CVE-2026-31494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: use the current queue number for stats There's a potential mismatch between the memory reserved for statistics and the amount of memory written. gem_get_sset_count() correctly computes the number of stats based on the active queues, whereas gem_get_ethtool_stats() indiscriminately copies data using the maximum number of queues, and in the case the number of active queues is less than MACB_MAX_QUEUES, this results in a OOB write as observed in the KASAN splat. ================================================================== BUG: KASAN: vmalloc-out-of-bounds in gem_get_ethtool_stats+0x54/0x78 [macb] Write of size 760 at addr ffff80008080b000 by task ethtool/1027 CPU: [...] Tainted: [E]=UNSIGNED_MODULE Hardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 print_report+0x384/0x5e0 kasan_report+0xa0/0xf0 kasan_check_range+0xe8/0x190 __asan_memcpy+0x54/0x98 gem_get_ethtool_stats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] dev_ethtool+0x1220/0x38c0 dev_ioctl+0x4ac/0xca8 sock_do_ioctl+0x170/0x1d8 sock_ioctl+0x484/0x5d8 __arm64_sys_ioctl+0x12c/0x1b8 invoke_syscall+0xd4/0x258 el0_svc_common.constprop.0+0xb4/0x240 do_el0_svc+0x48/0x68 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 The buggy address belongs to a 1-page vmalloc region starting at 0xffff80008080b000 allocated at dev_ethtool+0x11f0/0x38c0 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff00000a333000 pfn:0xa333 flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff) raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== Fix it by making sure the copied size only considers the active number of queues.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31495", "url": "https://ubuntu.com/security/CVE-2026-31495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: use netlink policy range checks Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors. - CTA_PROTOINFO_TCP_STATE: reject values > TCP_CONNTRACK_SYN_SENT2 at policy level, removing the manual >= TCP_CONNTRACK_MAX check. - CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values > TCP_MAX_WSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count. - CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with CTA_FILTER_F_ALL, removing the manual mask checks. - CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding a new mask define grouping all valid expect flags. Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31427", "url": "https://ubuntu.com/security/CVE-2026-31427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp process_sdp() declares union nf_inet_addr rtp_addr on the stack and passes it to the nf_nat_sip sdp_session hook after walking the SDP media descriptions. However rtp_addr is only initialized inside the media loop when a recognized media type with a non-zero port is found. If the SDP body contains no m= lines, only inactive media sections (m=audio 0 ...) or only unrecognized media types, rtp_addr is never assigned. Despite that, the function still calls hooks->sdp_session() with &rtp_addr, causing nf_nat_sdp_session() to format the stale stack value as an IP address and rewrite the SDP session owner and connection lines with it. With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this results in the session-level o= and c= addresses being rewritten to 0.0.0.0 for inactive SDP sessions. Without stack auto-init the rewritten address is whatever happened to be on the stack. Fix this by pre-initializing rtp_addr from the session-level connection address (caddr) when available, and tracking via a have_rtp_addr flag whether any valid address was established. Skip the sdp_session hook entirely when no valid address exists.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31674", "url": "https://ubuntu.com/security/CVE-2026-31674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check() Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS. rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[]. Validate addrnr during rule installation so malformed rules are rejected before the match logic can use an out-of-range value.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31428", "url": "https://ubuntu.com/security/CVE-2026-31428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD __build_packet_message() manually constructs the NFULA_PAYLOAD netlink attribute using skb_put() and skb_copy_bits(), bypassing the standard nla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes are allocated (including NLA alignment padding), only data_len bytes of actual packet data are copied. The trailing nla_padlen(data_len) bytes (1-3 when data_len is not 4-byte aligned) are never initialized, leaking stale heap contents to userspace via the NFLOG netlink socket. Replace the manual attribute construction with nla_reserve(), which handles the tailroom check, header setup, and padding zeroing via __nla_reserve(). The subsequent skb_copy_bits() fills in the payload data on top of the properly initialized attribute.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31497", "url": "https://ubuntu.com/security/CVE-2026-31497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: clamp SCO altsetting table indices btusb_work() maps the number of active SCO links to USB alternate settings through a three-entry lookup table when CVSD traffic uses transparent voice settings. The lookup currently indexes alts[] with data->sco_num - 1 without first constraining sco_num to the number of available table entries. While the table only defines alternate settings for up to three SCO links, data->sco_num comes from hci_conn_num() and is used directly. Cap the lookup to the last table entry before indexing it so the driver keeps selecting the highest supported alternate setting without reading past alts[].", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31498", "url": "https://ubuntu.com/security/CVE-2026-31498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop l2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTED state to support L2CAP reconfiguration (e.g. MTU changes). However, since both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set from the initial configuration, the reconfiguration path falls through to l2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, and retrans_list without freeing the previous allocations and sets chan->sdu to NULL without freeing the existing skb. This leaks all previously allocated ERTM resources. Additionally, l2cap_parse_conf_req() does not validate the minimum value of remote_mps derived from the RFC max_pdu_size option. A zero value propagates to l2cap_segment_sdu() where pdu_len becomes zero, causing the while loop to never terminate since len is never decremented, exhausting all available memory. Fix the double-init by skipping l2cap_ertm_init() and l2cap_chan_ready() when the channel is already in BT_CONNECTED state, while still allowing the reconfiguration parameters to be updated through l2cap_parse_conf_req(). Also add a pdu_len zero check in l2cap_segment_sdu() as a safeguard.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31507", "url": "https://ubuntu.com/security/CVE-2026-31507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffer smc_rx_splice() allocates one smc_spd_priv per pipe_buffer and stores the pointer in pipe_buffer.private. The pipe_buf_operations for these buffers used .get = generic_pipe_buf_get, which only increments the page reference count when tee(2) duplicates a pipe buffer. The smc_spd_priv pointer itself was not handled, so after tee() both the original and the cloned pipe_buffer share the same smc_spd_priv *. When both pipes are subsequently released, smc_rx_pipe_buf_release() is called twice against the same object: 1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct] 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF] KASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), which then escalates to a NULL-pointer dereference and kernel panic via smc_rx_update_consumer() when it chases the freed priv->smc pointer: BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x650 kasan_report+0xc6/0x100 smc_rx_pipe_buf_release+0x78/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smc_rx_update_consumer+0x8d/0x350 Call Trace: smc_rx_pipe_buf_release+0x121/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception Beyond the memory-safety problem, duplicating an SMC splice buffer is semantically questionable: smc_rx_update_cons() would advance the consumer cursor twice for the same data, corrupting receive-window accounting. A refcount on smc_spd_priv could fix the double-free, but the cursor-accounting issue would still need to be addressed separately. The .get callback is invoked by both tee(2) and splice_pipe_to_pipe() for partial transfers; both will now return -EFAULT. Users who need to duplicate SMC socket data must use a copy-based read path.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31679", "url": "https://ubuntu.com/security/CVE-2026-31679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: validate MPLS set/set_masked payload length validate_set() accepted OVS_KEY_ATTR_MPLS as variable-sized payload for SET/SET_MASKED actions. In action handling, OVS expects fixed-size MPLS key data (struct ovs_key_mpls). Use the already normalized key_len (masked case included) and reject non-matching MPLS action key sizes. Reject invalid MPLS action payload lengths early.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31508", "url": "https://ubuntu.com/security/CVE-2026-31508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Avoid releasing netdev before teardown completes The patch cited in the Fixes tag below changed the teardown code for OVS ports to no longer unconditionally take the RTNL. After this change, the netdev_destroy() callback can proceed immediately to the call_rcu() invocation if the IFF_OVS_DATAPATH flag is already cleared on the netdev. The ovs_netdev_detach_dev() function clears the flag before completing the unregistration, and if it gets preempted after clearing the flag (as can happen on an -rt kernel), netdev_destroy() can complete and the device can be freed before the unregistration completes. This leads to a splat like: [ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025 [ 998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0 [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90 [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246 [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000 [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0 [ 998.393944] PKRU: 55555554 [ 998.393946] Call Trace: [ 998.393949] [ 998.393952] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393961] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393975] ? dp_device_event+0x41/0x80 [openvswitch] [ 998.394009] ? __die_body.cold+0x8/0x12 [ 998.394016] ? die_addr+0x3c/0x60 [ 998.394027] ? exc_general_protection+0x16d/0x390 [ 998.394042] ? asm_exc_general_protection+0x26/0x30 [ 998.394058] ? dev_set_promiscuity+0x8d/0xa0 [ 998.394066] ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch] [ 998.394092] dp_device_event+0x41/0x80 [openvswitch] [ 998.394102] notifier_call_chain+0x5a/0xd0 [ 998.394106] unregister_netdevice_many_notify+0x51b/0xa60 [ 998.394110] rtnl_dellink+0x169/0x3e0 [ 998.394121] ? rt_mutex_slowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlink_rcv_msg+0x142/0x3f0 [ 998.394128] ? avc_has_perm_noaudit+0x69/0xf0 [ 998.394130] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 998.394132] netlink_rcv_skb+0x50/0x100 [ 998.394138] netlink_unicast+0x292/0x3f0 [ 998.394141] netlink_sendmsg+0x21b/0x470 [ 998.394145] ____sys_sendmsg+0x39d/0x3d0 [ 998.394149] ___sys_sendmsg+0x9a/0xe0 [ 998.394156] __sys_sendmsg+0x7a/0xd0 [ 998.394160] do_syscall_64+0x7f/0x170 [ 998.394162] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 998.394165] RIP: 0033:0x7fad61bf4724 [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724 [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003 [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2 ---truncated---", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31509", "url": "https://ubuntu.com/security/CVE-2026-31509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix circular locking dependency in nci_close_device nci_close_device() flushes rx_wq and tx_wq while holding req_lock. This causes a circular locking dependency because nci_rx_work() running on rx_wq can end up taking req_lock too: nci_rx_work -> nci_rx_data_packet -> nci_data_exchange_complete -> __sk_destruct -> rawsock_destruct -> nfc_deactivate_target -> nci_deactivate_target -> nci_request -> mutex_lock(&ndev->req_lock) Move the flush of rx_wq after req_lock has been released. This should safe (I think) because NCI_UP has already been cleared and the transport is closed, so the work will see it and return -ENETDOWN. NIPA has been hitting this running the nci selftest with a debug kernel on roughly 4% of the runs.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31510", "url": "https://ubuntu.com/security/CVE-2026-31510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb Before using sk pointer, check if it is null. Fix the following: KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267] CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025 Workqueue: events l2cap_info_timeout RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce veth0_macvtap: entered promiscuous mode RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: __kasan_check_byte+0x12/0x40 lock_acquire+0x79/0x2e0 lock_sock_nested+0x48/0x100 ? l2cap_sock_ready_cb+0x46/0x160 l2cap_sock_ready_cb+0x46/0x160 l2cap_conn_start+0x779/0xff0 ? __pfx_l2cap_conn_start+0x10/0x10 ? l2cap_info_timeout+0x60/0xa0 ? __pfx___mutex_lock+0x10/0x10 l2cap_info_timeout+0x68/0xa0 ? process_scheduled_works+0xa8d/0x18c0 process_scheduled_works+0xb6e/0x18c0 ? __pfx_process_scheduled_works+0x10/0x10 ? assign_work+0x3d5/0x5e0 worker_thread+0xa53/0xfc0 kthread+0x388/0x470 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x51e/0xb90 ? __pfx_ret_from_fork+0x10/0x10 veth1_macvtap: entered promiscuous mode ? __switch_to+0xc7d/0x1450 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- batman_adv: batadv0: Interface activated: batadv_slave_0 batman_adv: batadv0: Interface activated: batadv_slave_1 netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce ieee80211 phy39: Selected rate control algorithm 'minstrel_ht' RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43069", "url": "https://ubuntu.com/security/CVE-2026-43069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_ll: Fix firmware leak on error path Smatch reports: drivers/bluetooth/hci_ll.c:587 download_firmware() warn: 'fw' from request_firmware() not released on lines: 544. In download_firmware(), if request_firmware() succeeds but the returned firmware content is invalid (no data or zero size), the function returns without releasing the firmware, resulting in a resource leak. Fix this by calling release_firmware() before returning when request_firmware() succeeded but the firmware content is invalid.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31408", "url": "https://ubuntu.com/security/CVE-2026-31408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold sco_recv_frame() reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold a reference under the lock. Fix by using sco_sock_hold() to take a reference before releasing the lock, and adding sock_put() on all exit paths.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-31512", "url": "https://ubuntu.com/security/CVE-2026-31512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv() l2cap_ecred_data_rcv() reads the SDU length field from skb->data using get_unaligned_le16() without first verifying that skb contains at least L2CAP_SDULEN_SIZE (2) bytes. When skb->len is less than 2, this reads past the valid data in the skb. The ERTM reassembly path correctly calls pskb_may_pull() before reading the SDU length (l2cap_reassemble_sdu, L2CAP_SAR_START case). Apply the same validation to the Enhanced Credit Based Flow Control data path.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31515", "url": "https://ubuntu.com/security/CVE-2026-31515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_key: validate families in pfkey_send_migrate() syzbot was able to trigger a crash in skb_put() [1] Issue is that pfkey_send_migrate() does not check old/new families, and that set_ipsecrequest() @family argument was truncated, thus possibly overfilling the skb. Validate families early, do not wait set_ipsecrequest(). [1] skbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev: kernel BUG at net/core/skbuff.c:214 ! Call Trace: skb_over_panic net/core/skbuff.c:219 [inline] skb_put+0x159/0x210 net/core/skbuff.c:2655 skb_put_zero include/linux/skbuff.h:2788 [inline] set_ipsecrequest net/key/af_key.c:3532 [inline] pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636 km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848 xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705 xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31518", "url": "https://ubuntu.com/security/CVE-2026-31518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: esp: fix skb leak with espintcp and async crypto When the TX queue for espintcp is full, esp_output_tail_tcp will return an error and not free the skb, because with synchronous crypto, the common xfrm output code will drop the packet for us. With async crypto (esp_output_done), we need to drop the skb when esp_output_tail_tcp returns an error.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31521", "url": "https://ubuntu.com/security/CVE-2026-31521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: module: Fix kernel panic when a symbol st_shndx is out of bounds The module loader doesn't check for bounds of the ELF section index in simplify_symbols(): for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) { \t\tconst char *name = info->strtab + sym[i].st_name; \t\tswitch (sym[i].st_shndx) { \t\tcase SHN_COMMON: \t\t[...] \t\tdefault: \t\t\t/* Divert to percpu allocation if a percpu var. */ \t\t\tif (sym[i].st_shndx == info->index.pcpu) \t\t\t\tsecbase = (unsigned long)mod_percpu(mod); \t\t\telse /** HERE --> **/\t\tsecbase = info->sechdrs[sym[i].st_shndx].sh_addr; \t\t\tsym[i].st_value += secbase; \t\t\tbreak; \t\t} \t} A symbol with an out-of-bounds st_shndx value, for example 0xffff (known as SHN_XINDEX or SHN_HIRESERVE), may cause a kernel panic: BUG: unable to handle page fault for address: ... RIP: 0010:simplify_symbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exception This can happen when module ELF is legitimately using SHN_XINDEX or when it is corrupted. Add a bounds check in simplify_symbols() to validate that st_shndx is within the valid range before using it. This issue was discovered due to a bug in llvm-objcopy, see relevant discussion for details [1]. [1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31522", "url": "https://ubuntu.com/security/CVE-2026-31522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: avoid memory leak in magicmouse_report_fixup() The magicmouse_report_fixup() function was returning a newly kmemdup()-allocated buffer, but never freeing it. The caller of report_fixup() does not take ownership of the returned pointer, but it *is* permitted to return a sub-portion of the input rdesc, whose lifetime is managed by the caller.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31523", "url": "https://ubuntu.com/security/CVE-2026-31523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-pci: ensure we're polling a polled queue A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31524", "url": "https://ubuntu.com/security/CVE-2026-31524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: asus: avoid memory leak in asus_report_fixup() The asus_report_fixup() function was returning a newly allocated kmemdup()-allocated buffer, but never freeing it. Switch to devm_kzalloc() to ensure the memory is managed and freed automatically when the device is removed. The caller of report_fixup() does not take ownership of the returned pointer, but it is permitted to return a pointer whose lifetime is at least that of the input buffer. Also fix a harmless out-of-bounds read by copying only the original descriptor size.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31788", "url": "https://ubuntu.com/security/CVE-2026-31788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: restrict usage in unprivileged domU The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains. In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature. The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest. Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today. The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot. This is XSA-482 --- V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich)", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31540", "url": "https://ubuntu.com/security/CVE-2026-31540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Check set_default_submission() before deferencing When the i915 driver firmware binaries are not present, the set_default_submission pointer is not set. This pointer is dereferenced during suspend anyways. Add a check to make sure it is set before dereferencing. [ 23.289926] PM: suspend entry (deep) [ 23.293558] Filesystems sync: 0.000 seconds [ 23.298010] Freezing user space processes [ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds) [ 23.309766] OOM killer disabled. [ 23.313027] Freezing remaining freezable tasks [ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 23.342038] serial 00:05: disabled [ 23.345719] serial 00:02: disabled [ 23.349342] serial 00:01: disabled [ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 23.361635] ata1.00: Entering standby power mode [ 23.368863] ata2.00: Entering standby power mode [ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 23.452194] #PF: supervisor instruction fetch in kernel mode [ 23.457896] #PF: error_code(0x0010) - not-present page [ 23.463065] PGD 0 P4D 0 [ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI [ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary) [ 23.482512] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 23.496511] Workqueue: async async_run_entry_fn [ 23.501087] RIP: 0010:0x0 [ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246 [ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f [ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000 [ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff [ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8 [ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68 [ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000 [ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0 [ 23.572539] PKRU: 55555554 [ 23.575281] Call Trace: [ 23.577770] [ 23.579905] intel_engines_reset_default_submission+0x42/0x60 [ 23.585695] __intel_gt_unset_wedged+0x191/0x200 [ 23.590360] intel_gt_unset_wedged+0x20/0x40 [ 23.594675] gt_sanitize+0x15e/0x170 [ 23.598290] i915_gem_suspend_late+0x6b/0x180 [ 23.602692] i915_drm_suspend_late+0x35/0xf0 [ 23.607008] ? __pfx_pci_pm_suspend_late+0x10/0x10 [ 23.611843] dpm_run_callback+0x78/0x1c0 [ 23.615817] device_suspend_late+0xde/0x2e0 [ 23.620037] async_suspend_late+0x18/0x30 [ 23.624082] async_run_entry_fn+0x25/0xa0 [ 23.628129] process_one_work+0x15b/0x380 [ 23.632182] worker_thread+0x2a5/0x3c0 [ 23.635973] ? __pfx_worker_thread+0x10/0x10 [ 23.640279] kthread+0xf6/0x1f0 [ 23.643464] ? __pfx_kthread+0x10/0x10 [ 23.647263] ? __pfx_kthread+0x10/0x10 [ 23.651045] ret_from_fork+0x131/0x190 [ 23.654837] ? __pfx_kthread+0x10/0x10 [ 23.658634] ret_from_fork_asm+0x1a/0x30 [ 23.662597] [ 23.664826] Modules linked in: [ 23.667914] CR2: 0000000000000000 [ 23.671271] ------------[ cut here ]------------ (cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad)", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23434", "url": "https://ubuntu.com/security/CVE-2026-23434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: serialize lock/unlock against other NAND operations nand_lock() and nand_unlock() call into chip->ops.lock_area/unlock_area without holding the NAND device lock. On controllers that implement SET_FEATURES via multiple low-level PIO commands, these can race with concurrent UBI/UBIFS background erase/write operations that hold the device lock, resulting in cmd_pending conflicts on the NAND controller. Add nand_get_device()/nand_release_device() around the lock/unlock operations to serialize them against all other NAND controller access.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23398", "url": "https://ubuntu.com/security/CVE-2026-23398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: fix NULL pointer dereference in icmp_tag_validation() icmp_tag_validation() unconditionally dereferences the result of rcu_dereference(inet_protos[proto]) without checking for NULL. The inet_protos[] array is sparse -- only about 15 of 256 protocol numbers have registered handlers. When ip_no_pmtu_disc is set to 3 (hardened PMTU mode) and the kernel receives an ICMP Fragmentation Needed error with a quoted inner IP header containing an unregistered protocol number, the NULL dereference causes a kernel panic in softirq context. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) Add a NULL check before accessing icmp_strict_tag_validation. If the protocol has no registered handler, return false since it cannot perform strict tag validation.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-23438", "url": "https://ubuntu.com/security/CVE-2026-23438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: guard flow control update with global_tx_fc in buffer switching mvpp2_bm_switch_buffers() unconditionally calls mvpp2_bm_pool_update_priv_fc() when switching between per-cpu and shared buffer pool modes. This function programs CM3 flow control registers via mvpp2_cm3_read()/mvpp2_cm3_write(), which dereference priv->cm3_base without any NULL check. When the CM3 SRAM resource is not present in the device tree (the third reg entry added by commit 60523583b07c (\"dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree\")), priv->cm3_base remains NULL and priv->global_tx_fc is false. Any operation that triggers mvpp2_bm_switch_buffers(), for example an MTU change that crosses the jumbo frame threshold, will crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2_cm3_read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2_bm_pool_update_fc+0x40/0x12c mvpp2_bm_pool_update_priv_fc+0x94/0xd8 mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0 mvpp2_change_mtu+0x140/0x380 __dev_set_mtu+0x1c/0x38 dev_set_mtu_ext+0x78/0x118 dev_set_mtu+0x48/0xa8 dev_ifsioc+0x21c/0x43c dev_ioctl+0x2d8/0x42c sock_ioctl+0x314/0x378 Every other flow control call site in the driver already guards hardware access with either priv->global_tx_fc or port->tx_fc. mvpp2_bm_switch_buffers() is the only place that omits this check. Add the missing priv->global_tx_fc guard to both the disable and re-enable calls in mvpp2_bm_switch_buffers(), consistent with the rest of the driver.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23397", "url": "https://ubuntu.com/security/CVE-2026-23397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfnetlink_osf: validate individual option lengths in fingerprints nfnl_osf_add_callback() validates opt_num bounds and string NUL-termination but does not check individual option length fields. A zero-length option causes nf_osf_match_one() to enter the option matching loop even when foptsize sums to zero, which matches packets with no TCP options where ctx->optp is NULL: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:227) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:293) nf_hook_slow (net/netfilter/core.c:623) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) Additionally, an MSS option (kind=2) with length < 4 causes out-of-bounds reads when nf_osf_match_one() unconditionally accesses optp[2] and optp[3] for MSS value extraction. While RFC 9293 section 3.2 specifies that the MSS option is always exactly 4 bytes (Kind=2, Length=4), the check uses \"< 4\" rather than \"!= 4\" because lengths greater than 4 do not cause memory safety issues -- the buffer is guaranteed to be at least foptsize bytes by the ctx->optsize == foptsize check. Reject fingerprints where any option has zero length, or where an MSS option has length less than 4, at add time rather than trusting these values in the packet matching hot path.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-31546", "url": "https://ubuntu.com/security/CVE-2026-31546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL deref in bond_debug_rlb_hash_show rlb_clear_slave intentionally keeps RLB hash-table entries on the rx_hashtbl_used_head list with slave set to NULL when no replacement slave is available. However, bond_debug_rlb_hash_show visites client_info->slave without checking if it's NULL. Other used-list iterators in bond_alb.c already handle this NULL-slave state safely: - rlb_update_client returns early on !client_info->slave - rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalance compare slave values before visiting - lb_req_update_subnet_clients continues if slave is NULL The following NULL deref crash can be trigger in bond_debug_rlb_hash_show: [ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seq_read_iter (fs/seq_file.c:231) [ 1.296341] seq_read (fs/seq_file.c:164) [ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfs_read (fs/read_write.c:572) [ 1.296981] ksys_read (fs/read_write.c:717) [ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) [ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add a NULL check and print \"(none)\" for entries with no assigned slave.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23439", "url": "https://ubuntu.com/security/CVE-2026-23439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n When CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0 (success) without actually creating a socket. Callers such as fou_create() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference. The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764) [...] Call Trace: genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130) This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23396", "url": "https://ubuntu.com/security/CVE-2026-23396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix NULL deref in mesh_matches_local() mesh_matches_local() unconditionally dereferences ie->mesh_config to compare mesh configuration parameters. When called from mesh_rx_csa_frame(), the parsed action-frame elements may not contain a Mesh Configuration IE, leaving ie->mesh_config NULL and triggering a kernel NULL pointer dereference. The other two callers are already safe: - ieee80211_mesh_rx_bcn_presp() checks !elems->mesh_config before calling mesh_matches_local() - mesh_plink_get_event() is only reached through mesh_process_plink_frame(), which checks !elems->mesh_config, too mesh_rx_csa_frame() is the only caller that passes raw parsed elements to mesh_matches_local() without guarding mesh_config. An adjacent attacker can exploit this by sending a crafted CSA action frame that includes a valid Mesh ID IE but omits the Mesh Configuration IE, crashing the kernel. The captured crash log: Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events_unbound cfg80211_wiphy_work [...] Call Trace: ? __pfx_mesh_matches_local (net/mac80211/mesh.c:65) ieee80211_mesh_rx_queued_mgmt (net/mac80211/mesh.c:1686) [...] ieee80211_iface_work (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802) [...] cfg80211_wiphy_work (net/wireless/core.c:426) process_one_work (net/kernel/workqueue.c:3280) ? assign_work (net/kernel/workqueue.c:1219) worker_thread (net/kernel/workqueue.c:3352) ? __pfx_worker_thread (net/kernel/workqueue.c:3385) kthread (net/kernel/kthread.c:436) [...] ret_from_fork_asm (net/arch/x86/entry/entry_64.S:255) This patch adds a NULL check for ie->mesh_config at the top of mesh_matches_local() to return false early when the Mesh Configuration IE is absent.", "cve_priority": "medium", "cve_public_date": "2026-03-26 11:16:00 UTC" }, { "cve": "CVE-2026-23446", "url": "https://ubuntu.com/security/CVE-2026-23446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: Do not perform PM inside suspend callback syzbot reports \"task hung in rpm_resume\" This is caused by aqc111_suspend calling the PM variant of its write_cmd routine. The simplified call trace looks like this: rpm_suspend() usb_suspend_both() - here udev->dev.power.runtime_status == RPM_SUSPENDING aqc111_suspend() - called for the usb device interface aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() - here we call rpm_resume() on our parent rpm_resume() - Here we wait for a status change that will never happen. At this point we block another task which holds rtnl_lock and locks up the whole networking stack. Fix this by replacing the write_cmd calls with their _nopm variants", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23452", "url": "https://ubuntu.com/security/CVE-2026-23452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM: runtime: Fix a race condition related to device removal The following code in pm_runtime_work() may dereference the dev->parent pointer after the parent device has been freed: \t/* Maybe the parent is now able to suspend. */ \tif (parent && !parent->power.ignore_children) { \t\tspin_unlock(&dev->power.lock); \t\tspin_lock(&parent->power.lock); \t\trpm_idle(parent, RPM_ASYNC); \t\tspin_unlock(&parent->power.lock); \t\tspin_lock(&dev->power.lock); \t} Fix this by inserting a flush_work() call in pm_runtime_remove(). Without this patch blktest block/001 triggers the following complaint sporadically: BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160 Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081 Workqueue: pm pm_runtime_work Call Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0 __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160 _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 Allocated by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50 __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23454", "url": "https://ubuntu.com/security/CVE-2026-23454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: fix use-after-free in mana_hwc_destroy_channel() by reordering teardown A potential race condition exists in mana_hwc_destroy_channel() where hwc->caller_ctx is freed before the HWC's Completion Queue (CQ) and Event Queue (EQ) are destroyed. This allows an in-flight CQ interrupt handler to dereference freed memory, leading to a use-after-free or NULL pointer dereference in mana_hwc_handle_resp(). mana_smc_teardown_hwc() signals the hardware to stop but does not synchronize against IRQ handlers already executing on other CPUs. The IRQ synchronization only happens in mana_hwc_destroy_cq() via mana_gd_destroy_eq() -> mana_gd_deregister_irq(). Since this runs after kfree(hwc->caller_ctx), a concurrent mana_hwc_rx_event_handler() can dereference freed caller_ctx (and rxq->msg_buf) in mana_hwc_handle_resp(). Fix this by reordering teardown to reverse-of-creation order: destroy the TX/RX work queues and CQ/EQ before freeing hwc->caller_ctx. This ensures all in-flight interrupt handlers complete before the memory they access is freed.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23391", "url": "https://ubuntu.com/security/CVE-2026-23391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_CT: drop pending enqueued packets on template removal Templates refer to objects that can go away while packets are sitting in nfqueue refer to: - helper, this can be an issue on module removal. - timeout policy, nfnetlink_cttimeout might remove it. The use of templates with zone and event cache filter are safe, since this just copies values. Flush these enqueued packets in case the template rule gets removed.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43060", "url": "https://ubuntu.com/security/CVE-2026-43060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: drop pending enqueued packets on removal Packets sitting in nfqueue might hold a reference to: - templates that specify the conntrack zone, because a percpu area is used and module removal is possible. - conntrack timeout policies and helper, where object removal leave a stale reference. Since these objects can just go away, drop enqueued packets to avoid stale reference to them. If there is a need for finer grain removal, this logic can be revisited to make selective packet drop upon dependencies.", "cve_priority": "high", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2025-68206", "url": "https://ubuntu.com/security/CVE-2025-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: add seqadj extension for natted connections Sequence adjustment may be required for FTP traffic with PASV/EPSV modes. due to need to re-write packet payload (IP, port) on the ftp control connection. This can require changes to the TCP length and expected seq / ack_seq. The easiest way to reproduce this issue is with PASV mode. Example ruleset: table inet ftp_nat { ct helper ftp_helper { type \"ftp\" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set \"ftp_helper\" } } table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { \t\t\t192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { \t\t\t192.168.13.2 : 192.168.100.1/32 } } } Note that the ftp helper gets assigned *after* the dnat setup. The inverse (nat after helper assign) is handled by an existing check in nf_nat_setup_info() and will not show the problem. Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ ftp nat changes do not work as expected in this case: Connected to 192.168.100.1. [..] ftp> epsv EPSV/EPRT on IPv4 off. ftp> ls 227 Entering passive mode (192,168,100,1,209,129). 421 Service not available, remote server has closed connection. Kernel logs: Missing nfct_seqadj_ext_add() setup call WARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41 [..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 .. Fix this by adding the required extension when a conntrack helper is assigned to a connection that has a nat binding.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-23456", "url": "https://ubuntu.com/security/CVE-2026-23456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case In decode_int(), the CONS case calls get_bits(bs, 2) to read a length value, then calls get_uint(bs, len) without checking that len bytes remain in the buffer. The existing boundary check only validates the 2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint() reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte slab-out-of-bounds read. Add a boundary check for len bytes after get_bits() and before get_uint().", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23457", "url": "https://ubuntu.com/security/CVE-2026-23457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp() sip_help_tcp() parses the SIP Content-Length header with simple_strtoul(), which returns unsigned long, but stores the result in unsigned int clen. On 64-bit systems, values exceeding UINT_MAX are silently truncated before computing the SIP message boundary. For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32, causing the parser to miscalculate where the current message ends. The loop then treats trailing data in the TCP segment as a second SIP message and processes it through the SDP parser. Fix this by changing clen to unsigned long to match the return type of simple_strtoul(), and reject Content-Length values that exceed the remaining TCP payload length.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23458", "url": "https://ubuntu.com/security/CVE-2026-23458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct() ctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for the netlink dump callback ctnetlink_exp_ct_dump_table(), but drops the conntrack reference immediately after netlink_dump_start(). When the dump spans multiple rounds, the second recvmsg() triggers the dump callback which dereferences the now-freed conntrack via nfct_help(ct), leading to a use-after-free on ct->ext. The bug is that the netlink_dump_control has no .start or .done callbacks to manage the conntrack reference across dump rounds. Other dump functions in the same file (e.g. ctnetlink_get_conntrack) properly use .start/.done callbacks for this purpose. Fix this by adding .start and .done callbacks that hold and release the conntrack reference for the duration of the dump, and move the nfct_help() call after the cb->args[0] early-return check in the dump callback to avoid dereferencing ct->ext unnecessarily. BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133 CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 ? aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0 Allocated by task 133: kmem_cache_alloc_noprof+0x134/0x440 __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180 Freed by task 0: slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2025-39764", "url": "https://ubuntu.com/security/CVE-2025-39764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: remove refcounting in expectation dumpers Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption. AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcount_inc_not_zero(&exp->use)) to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2026-23460", "url": "https://ubuntu.com/security/CVE-2026-23460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect syzkaller reported a bug [1], and the reproducer is available at [2]. ROSE sockets use four sk->sk_state values: TCP_CLOSE, TCP_LISTEN, TCP_SYN_SENT, and TCP_ESTABLISHED. rose_connect() already rejects calls for TCP_ESTABLISHED (-EISCONN) and TCP_CLOSE with SS_CONNECTING (-ECONNREFUSED), but lacks a check for TCP_SYN_SENT. When rose_connect() is called a second time while the first connection attempt is still in progress (TCP_SYN_SENT), it overwrites rose->neighbour via rose_get_neigh(). If that returns NULL, the socket is left with rose->state == ROSE_STATE_1 but rose->neighbour == NULL. When the socket is subsequently closed, rose_release() sees ROSE_STATE_1 and calls rose_write_internal() -> rose_transmit_link(skb, NULL), causing a NULL pointer dereference. Per connect(2), a second connect() while a connection is already in progress should return -EALREADY. Add this missing check for TCP_SYN_SENT to complete the state validation in rose_connect(). [1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271 [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23462", "url": "https://ubuntu.com/security/CVE-2026-23462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: Fix possible UAF This fixes the following trace caused by not dropping l2cap_conn reference when user->remove callback is called: [ 97.809249] l2cap_conn_free: freeing conn ffff88810a171c00 [ 97.809907] CPU: 1 UID: 0 PID: 1419 Comm: repro_standalon Not tainted 7.0.0-rc1-dirty #14 PREEMPT(lazy) [ 97.809935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 97.809947] Call Trace: [ 97.809954] [ 97.809961] dump_stack_lvl (lib/dump_stack.c:122) [ 97.809990] l2cap_conn_free (net/bluetooth/l2cap_core.c:1808) [ 97.810017] l2cap_conn_del (./include/linux/kref.h:66 net/bluetooth/l2cap_core.c:1821 net/bluetooth/l2cap_core.c:1798) [ 97.810055] l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7347 (discriminator 1) net/bluetooth/l2cap_core.c:7340 (discriminator 1)) [ 97.810086] ? __pfx_l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7341) [ 97.810117] hci_conn_hash_flush (./include/net/bluetooth/hci_core.h:2152 (discriminator 2) net/bluetooth/hci_conn.c:2644 (discriminator 2)) [ 97.810148] hci_dev_close_sync (net/bluetooth/hci_sync.c:5360) [ 97.810180] ? __pfx_hci_dev_close_sync (net/bluetooth/hci_sync.c:5285) [ 97.810212] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810242] ? up_write (./arch/x86/include/asm/atomic64_64.h:87 (discriminator 5) ./include/linux/atomic/atomic-arch-fallback.h:2852 (discriminator 5) ./include/linux/atomic/atomic-long.h:268 (discriminator 5) ./include/linux/atomic/atomic-instrumented.h:3391 (discriminator 5) kernel/locking/rwsem.c:1385 (discriminator 5) kernel/locking/rwsem.c:1643 (discriminator 5)) [ 97.810267] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810290] ? rcu_is_watching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/context_tracking.h:128 kernel/rcu/tree.c:752) [ 97.810320] hci_unregister_dev (net/bluetooth/hci_core.c:504 net/bluetooth/hci_core.c:2716) [ 97.810346] vhci_release (drivers/bluetooth/hci_vhci.c:691) [ 97.810375] ? __pfx_vhci_release (drivers/bluetooth/hci_vhci.c:678) [ 97.810404] __fput (fs/file_table.c:470) [ 97.810430] task_work_run (kernel/task_work.c:235) [ 97.810451] ? __pfx_task_work_run (kernel/task_work.c:201) [ 97.810472] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810495] ? do_raw_spin_unlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlock_debug.c:142 (discriminator 5)) [ 97.810527] do_exit (kernel/exit.c:972) [ 97.810547] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810574] ? __pfx_do_exit (kernel/exit.c:897) [ 97.810594] ? lock_acquire (kernel/locking/lockdep.c:470 (discriminator 6) kernel/locking/lockdep.c:5870 (discriminator 6) kernel/locking/lockdep.c:5825 (discriminator 6)) [ 97.810616] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810639] ? do_raw_spin_lock (kernel/locking/spinlock_debug.c:95 (discriminator 4) kernel/locking/spinlock_debug.c:118 (discriminator 4)) [ 97.810664] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810688] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1)) [ 97.810721] do_group_exit (kernel/exit.c:1093) [ 97.810745] get_signal (kernel/signal.c:3007 (discriminator 1)) [ 97.810772] ? security_file_permission (./arch/x86/include/asm/jump_label.h:37 security/security.c:2366) [ 97.810803] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810826] ? vfs_read (fs/read_write.c:555) [ 97.810854] ? __pfx_get_signal (kernel/signal.c:2800) [ 97.810880] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810905] ? __pfx_vfs_read (fs/read_write.c:555) [ 97.810932] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810960] arch_do_signal_or_restart (arch/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31551", "url": "https://ubuntu.com/security/CVE-2026-31551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Fix static_branch_dec() underflow for aql_disable. syzbot reported static_branch_dec() underflow in aql_enable_write(). [0] The problem is that aql_enable_write() does not serialise concurrent write()s to the debugfs. aql_enable_write() checks static_key_false(&aql_disable.key) and later calls static_branch_inc() or static_branch_dec(), but the state may change between the two calls. aql_disable does not need to track inc/dec. Let's use static_branch_enable() and static_branch_disable(). [0]: val == 0 WARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288 Modules linked in: CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full) Tainted: [U]=USER, [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311 Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 <0f> 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00 RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4 RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a R13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98 FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0 Call Trace: __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline] __static_key_slow_dec kernel/jump_label.c:321 [inline] static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336 aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343 short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383 vfs_write+0x2aa/0x1070 fs/read_write.c:684 ksys_pwrite64 fs/read_write.c:793 [inline] __do_sys_pwrite64 fs/read_write.c:801 [inline] __se_sys_pwrite64 fs/read_write.c:798 [inline] __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f530cf9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012 RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010 RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000 R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978 ", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23463", "url": "https://ubuntu.com/security/CVE-2026-23463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: fix race condition in qman_destroy_fq When QMAN_FQ_FLAG_DYNAMIC_FQID is set, there's a race condition between fq_table[fq->idx] state and freeing/allocating from the pool and WARN_ON(fq_table[fq->idx]) in qman_create_fq() gets triggered. Indeed, we can have: Thread A Thread B qman_destroy_fq() qman_create_fq() qman_release_fqid() qman_shutdown_fq() gen_pool_free() -- At this point, the fqid is available again -- qman_alloc_fqid() -- so, we can get the just-freed fqid in thread B -- fq->fqid = fqid; fq->idx = fqid * 2; WARN_ON(fq_table[fq->idx]); fq_table[fq->idx] = fq; fq_table[fq->idx] = NULL; And adding some logs between qman_release_fqid() and fq_table[fq->idx] = NULL makes the WARN_ON() trigger a lot more. To prevent that, ensure that fq_table[fq->idx] is set to NULL before gen_pool_free() is called by using smp_wmb().", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31683", "url": "https://ubuntu.com/security/CVE-2026-31683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: avoid OGM aggregation when skb tailroom is insufficient When OGM aggregation state is toggled at runtime, an existing forwarded packet may have been allocated with only packet_len bytes, while a later packet can still be selected for aggregation. Appending in this case can hit skb_put overflow conditions. Reject aggregation when the target skb tailroom cannot accommodate the new packet. The caller then falls back to creating a new forward packet instead of appending.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31550", "url": "https://ubuntu.com/security/CVE-2026-31550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: bcm: bcm2835-power: Increase ASB control timeout The bcm2835_asb_control() function uses a tight polling loop to wait for the ASB bridge to acknowledge a request. During intensive workloads, this handshake intermittently fails for V3D's master ASB on BCM2711, resulting in \"Failed to disable ASB master for v3d\" errors during runtime PM suspend. As a consequence, the failed power-off leaves V3D in a broken state, leading to bus faults or system hangs on later accesses. As the timeout is insufficient in some scenarios, increase the polling timeout from 1us to 5us, which is still negligible in the context of a power domain transition. Also, replace the open-coded ktime_get_ns()/ cpu_relax() polling loop with readl_poll_timeout_atomic().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23368", "url": "https://ubuntu.com/security/CVE-2026-23368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: register phy led_triggers during probe to avoid AB-BA deadlock There is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and LED_TRIGGER_PHY are enabled: [ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc <-- Trying to get lock \"triggers_list_lock\" via down_write(&triggers_list_lock); [ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234 [ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c [ 1362.065489] [<80651fc4>] phylink_fwnode_phy_connect+0x15c/0x23c [ 1362.071480] [<8066ee18>] mtk_open+0x7c/0xba0 [ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0 [ 1362.080384] [<806d7668>] __dev_change_flags+0x244/0x24c [ 1362.085598] [<806d7698>] dev_change_flags+0x28/0x78 [ 1362.090528] [<807150e4>] dev_ioctl+0x4c0/0x654 <-- Hold lock \"rtnl_mutex\" by calling rtnl_lock(); [ 1362.094985] [<80694360>] sock_ioctl+0x2f4/0x4e0 [ 1362.099567] [<802e9c4c>] sys_ioctl+0x32c/0xd8c [ 1362.104022] [<80014504>] syscall_common+0x34/0x58 Here LED_TRIGGER_PHY is registering LED triggers during phy_attach while holding RTNL and then taking triggers_list_lock. [ 1362.191101] [<806c2640>] register_netdevice_notifier+0x60/0x168 <-- Trying to get lock \"rtnl_mutex\" via rtnl_lock(); [ 1362.197073] [<805504ac>] netdev_trig_activate+0x194/0x1e4 [ 1362.202490] [<8054e28c>] led_trigger_set+0x1d4/0x360 <-- Hold lock \"triggers_list_lock\" by down_read(&triggers_list_lock); [ 1362.207511] [<8054eb38>] led_trigger_write+0xd8/0x14c [ 1362.212566] [<80381d98>] sysfs_kf_bin_write+0x80/0xbc [ 1362.217688] [<8037fcd8>] kernfs_fop_write_iter+0x17c/0x28c [ 1362.223174] [<802cbd70>] vfs_write+0x21c/0x3c4 [ 1362.227712] [<802cc0c4>] ksys_write+0x78/0x12c [ 1362.232164] [<80014504>] syscall_common+0x34/0x58 Here LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takes triggers_list_lock and then RTNL. A classical AB-BA deadlock. phy_led_triggers_registers() does not require the RTNL, it does not make any calls into the network stack which require protection. There is also no requirement the PHY has been attached to a MAC, the triggers only make use of phydev state. This allows the call to phy_led_triggers_registers() to be placed elsewhere. PHY probe() and release() don't hold RTNL, so solving the AB-BA deadlock.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23303", "url": "https://ubuntu.com/security/CVE-2026-23303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Don't log plaintext credentials in cifs_set_cifscreds When debug logging is enabled, cifs_set_cifscreds() logs the key payload and exposes the plaintext username and password. Remove the debug log to avoid exposing credentials.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23335", "url": "https://ubuntu.com/security/CVE-2026-23335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah() struct irdma_create_ah_resp { // 8 bytes, no padding __u32 ah_id; // offset 0 - SET (uresp.ah_id = ah->sc_ah.ah_info.ah_idx) __u8 rsvd[4]; // offset 4 - NEVER SET <- LEAK }; rsvd[4]: 4 bytes of stack memory leaked unconditionally. Only ah_id is assigned before ib_respond_udata(). The reserved members of the structure were not zeroed.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23336", "url": "https://ubuntu.com/security/CVE-2026-23336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel rfkill_block work in wiphy_unregister() There is a use-after-free error in cfg80211_shutdown_all_interfaces found by syzkaller: BUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220 Read of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326 CPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events cfg80211_rfkill_block_work Call Trace: dump_stack_lvl+0x116/0x1f0 print_report+0xcd/0x630 kasan_report+0xe0/0x110 cfg80211_shutdown_all_interfaces+0x213/0x220 cfg80211_rfkill_block_work+0x1e/0x30 process_one_work+0x9cf/0x1b70 worker_thread+0x6c8/0xf10 kthread+0x3c5/0x780 ret_from_fork+0x56d/0x700 ret_from_fork_asm+0x1a/0x30 The problem arises due to the rfkill_block work is not cancelled when wiphy is being unregistered. In order to fix the issue cancel the corresponding work in wiphy_unregister(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23281", "url": "https://ubuntu.com/security/CVE-2026-23281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix use-after-free in lbs_free_adapter() The lbs_free_adapter() function uses timer_delete() (non-synchronous) for both command_timer and tx_lockup_timer before the structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If a timer callback is executing when lbs_free_adapter() is called, the callback will access freed memory since lbs_cfg_free() frees the containing structure immediately after lbs_free_adapter() returns. Both timer callbacks (lbs_cmd_timeout_handler and lbs_tx_lockup_handler) access priv->driver_lock, priv->cur_cmd, priv->dev, and other fields, which would all be use-after-free violations. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning. This bug was introduced in commit 8f641d93c38a (\"libertas: detect TX lockups and reset hardware\") where del_timer() was used instead of del_timer_sync() in the cleanup path. The command_timer has had the same issue since the driver was first written.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-38562", "url": "https://ubuntu.com/security/CVE-2025-38562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference error in generate_encryptionkey If client send two session setups with krb5 authenticate to ksmbd, null pointer dereference error in generate_encryptionkey could happen. sess->Preauth_HashValue is set to NULL if session is valid. So this patch skip generate encryption key if session is valid.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2026-45920", "url": "https://ubuntu.com/security/CVE-2026-45920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix dirtyclusters double decrement on fs shutdown fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count: WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4] Tracing the failure shows that the warning fires due to an s_dirtyclusters_counter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4_mb_mark_diskspace_used() and the caller ext4_mb_new_blocks(). First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4_handle_dirty_metadata() call(s) made from ext4_mb_mark_context(). The changed value is non-zero at this point, so ext4_mb_mark_diskspace_used() does not exit after the error bubbles up from ext4_mb_mark_context(). Instead, the former decrements both cluster counters and returns the error up to ext4_mb_new_blocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency. To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4_mb_new_blocks() is responsible for acquiring cluster reservation (via ext4_claim_free_clusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45899", "url": "https://ubuntu.com/security/CVE-2026-45899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop extent cache when splitting extent fails When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45985", "url": "https://ubuntu.com/security/CVE-2026-45985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues. Assume we have an unwritten extent, and then DIO writes the second half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set. Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree. [0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone. Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45924", "url": "https://ubuntu.com/security/CVE-2026-45924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths There are two places where ksmbd_vfs_kern_path_end_removing() needs to be called in order to balance what the corresponding successful call to ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and put the taken references. Otherwise there might be potential deadlocks and unbalanced locks which are caught like: BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work 2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660 CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30 Found by Linux Verification Center (linuxtesting.org).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23227", "url": "https://ubuntu.com/security/CVE-2026-23227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/free Exynos Virtual Display driver performs memory alloc/free operations without lock protection, which easily causes concurrency problem. For example, use-after-free can occur in race scenario like this: ``` \tCPU0\t\t\t\tCPU1\t\t\t\tCPU2 \t----\t\t\t\t----\t\t\t\t---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... \t\t\t\t\t\t\t\tdrm_mode_getconnector() \t\t\t\t\t\t\t\t drm_helper_probe_single_connector_modes() \t\t\t\t\t\t\t\t vidi_get_modes() \t\t\t\t\t\t\t\t if (ctx->raw_edid) // true \t\t\t\t\t\t\t\t drm_edid_dup(ctx->raw_edid); \t\t\t\t\t\t\t\t if (!drm_edid) // false \t\t\t\t\t\t\t\t ... \t\t\t\tvidi_connection_ioctl() \t\t\t\t if (vidi->connection) // false \t\t\t\t drm_edid_free(ctx->raw_edid); // free drm_edid \t\t\t\t ... \t\t\t\t\t\t\t\t drm_edid_alloc(drm_edid->edid) \t\t\t\t\t\t\t\t kmemdup(edid); // UAF!! \t\t\t\t\t\t\t\t ... ``` To prevent these vulns, at least in vidi_context, member variables related to memory alloc/free should be protected with ctx->lock.", "cve_priority": "high", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-45958", "url": "https://ubuntu.com/security/CVE-2026-45958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: fix to avoid directly dereferencing user pointer In vidi_connection_ioctl(), vidi->edid(user pointer) is directly dereferenced in the kernel. This allows arbitrary kernel memory access from the user space, so instead of directly accessing the user pointer in the kernel, we should modify it to copy edid to kernel memory using copy_from_user() and use it.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45956", "url": "https://ubuntu.com/security/CVE-2026-45956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl() vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to obtain a struct vidi_context pointer. However, drm_dev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device. This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more. To resolve this issue, we need to store/delete the vidi device pointer in exynos_drm_private->vidi_dev during bind/unbind, and then read this exynos_drm_private->vidi_dev within ioctl() to obtain the correct struct vidi_context pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23100", "url": "https://ubuntu.com/security/CVE-2026-23100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb_pmd_shared() Patch series \"mm/hugetlb: fixes for PMD table sharing (incl. using mmu_gather)\", v3. One functional fix, one performance regression fix, and two related comment fixes. I cleaned up my prototype I recently shared [1] for the performance fix, deferring most of the cleanups I had in the prototype to a later point. While doing that I identified the other things. The goal of this patch set is to be backported to stable trees \"fairly\" easily. At least patch #1 and #4. Patch #1 fixes hugetlb_pmd_shared() not detecting any sharing Patch #2 + #3 are simple comment fixes that patch #4 interacts with. Patch #4 is a fix for the reported performance regression due to excessive IPI broadcasts during fork()+exit(). The last patch is all about TLB flushes, IPIs and mmu_gather. Read: complicated There are plenty of cleanups in the future to be had + one reasonable optimization on x86. But that's all out of scope for this series. Runtime tested, with a focus on fixing the performance regression using the original reproducer [2] on x86. This patch (of 4): We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->pt_share_count to identify sharing. We didn't convert hugetlb_pmd_shared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table. Page migration, like mbind() or migrate_pages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as \"private\" although they are \"shared\", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the pagemap interface. Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-43061", "url": "https://ubuntu.com/security/CVE-2026-43061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Fix TX deadlock when using DMA `dmaengine_terminate_async` does not guarantee that the `__dma_tx_complete` callback will run. The callback is currently the only place where `dma->tx_running` gets cleared. If the transaction is canceled and the callback never runs, then `dma->tx_running` will never get cleared and we will never schedule new TX DMA transactions again. This change makes it so we clear `dma->tx_running` after we terminate the DMA transaction. This is \"safe\" because `serial8250_tx_dma_flush` is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to `dma->tx_running` is serialized.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-23474", "url": "https://ubuntu.com/security/CVE-2026-23474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: Avoid boot crash in RedBoot partition table parser Given CONFIG_FORTIFY_SOURCE=y and a recent compiler, commit 439a1bcac648 (\"fortify: Use __builtin_dynamic_object_size() when available\") produces the warning below and an oops. Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000 ------------[ cut here ]------------ WARNING: lib/string_helpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1 memcmp: detected buffer overflow: 15 byte read of buffer size 14 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONE As Kees said, \"'names' is pointing to the final 'namelen' many bytes of the allocation ... 'namelen' could be basically any length at all. This fortify warning looks legit to me -- this code used to be reading beyond the end of the allocation.\" Since the size of the dynamic allocation is calculated with strlen() we can use strcmp() instead of memcmp() and remain within bounds.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31393", "url": "https://ubuntu.com/security/CVE-2026-31393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present: - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8). - L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5). A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data. Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43062", "url": "https://ubuntu.com/security/CVE-2026-43062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp() l2cap_ecred_reconf_rsp() casts the incoming data to struct l2cap_ecred_conn_rsp (the ECRED *connection* response, 8 bytes with result at offset 6) instead of struct l2cap_ecred_reconf_rsp (2 bytes with result at offset 0). This causes two problems: - The sizeof(*rsp) length check requires 8 bytes instead of the correct 2, so valid L2CAP_ECRED_RECONF_RSP packets are rejected with -EPROTO. - rsp->result reads from offset 6 instead of offset 0, returning wrong data when the packet is large enough to pass the check. Fix by using the correct type. Also pass the already byte-swapped result variable to BT_DBG instead of the raw __le16 field.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31396", "url": "https://ubuntu.com/security/CVE-2026-31396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix use-after-free access to PTP clock PTP clock is registered on every opening of the interface and destroyed on every closing. However it may be accessed via get_ts_info ethtool call which is possible while the interface is just present in the kernel. BUG: KASAN: use-after-free in ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 Read of size 4 at addr ffff8880194345cc by task syz.0.6/948 CPU: 1 PID: 948 Comm: syz.0.6 Not tainted 6.1.164+ #109 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x17f/0x496 mm/kasan/report.c:420 kasan_report+0xd9/0x180 mm/kasan/report.c:524 ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 gem_get_ts_info+0x138/0x1e0 drivers/net/ethernet/cadence/macb_main.c:3349 macb_get_ts_info+0x68/0xb0 drivers/net/ethernet/cadence/macb_main.c:3371 __ethtool_get_ts_info+0x17c/0x260 net/ethtool/common.c:558 ethtool_get_ts_info net/ethtool/ioctl.c:2367 [inline] __dev_ethtool net/ethtool/ioctl.c:3017 [inline] dev_ethtool+0x2b05/0x6290 net/ethtool/ioctl.c:3095 dev_ioctl+0x637/0x1070 net/core/dev_ioctl.c:510 sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215 sock_ioctl+0x577/0x6d0 net/socket.c:1320 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 457: kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:699 [inline] ptp_clock_register+0x144/0x10e0 drivers/ptp/ptp_clock.c:235 gem_ptp_init+0x46f/0x930 drivers/net/ethernet/cadence/macb_ptp.c:375 macb_open+0x901/0xd10 drivers/net/ethernet/cadence/macb_main.c:2920 __dev_open+0x2ce/0x500 net/core/dev.c:1501 __dev_change_flags+0x56a/0x740 net/core/dev.c:8651 dev_change_flags+0x92/0x170 net/core/dev.c:8722 do_setlink+0xaf8/0x3a80 net/core/rtnetlink.c:2833 __rtnl_newlink+0xbf4/0x1940 net/core/rtnetlink.c:3608 rtnl_newlink+0x63/0xa0 net/core/rtnetlink.c:3655 rtnetlink_rcv_msg+0x3c6/0xed0 net/core/rtnetlink.c:6150 netlink_rcv_skb+0x15d/0x430 net/netlink/af_netlink.c:2511 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x6d7/0xa30 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x97e/0xeb0 net/netlink/af_netlink.c:1872 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x14b/0x180 net/socket.c:730 __sys_sendto+0x320/0x3b0 net/socket.c:2152 __do_sys_sendto net/socket.c:2164 [inline] __se_sys_sendto net/socket.c:2160 [inline] __x64_sys_sendto+0xdc/0x1b0 net/socket.c:2160 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 938: kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1729 [inline] slab_free_freelist_hook mm/slub.c:1755 [inline] slab_free mm/slub.c:3687 [inline] __kmem_cache_free+0xbc/0x320 mm/slub.c:3700 device_release+0xa0/0x240 drivers/base/core.c:2507 kobject_cleanup lib/kobject.c:681 [inline] kobject_release lib/kobject.c:712 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1cd/0x350 lib/kobject.c:729 put_device+0x1b/0x30 drivers/base/core.c:3805 ptp_clock_unregister+0x171/0x270 drivers/ptp/ptp_clock.c:391 gem_ptp_remove+0x4e/0x1f0 drivers/net/ethernet/cadence/macb_ptp.c:404 macb_close+0x1c8/0x270 drivers/net/ethernet/cadence/macb_main.c:2966 __dev_close_many+0x1b9/0x310 net/core/dev.c:1585 __dev_close net/core/dev.c:1597 [inline] __dev_change_flags+0x2bb/0x740 net/core/dev.c:8649 dev_change_fl ---truncated---", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31545", "url": "https://ubuntu.com/security/CVE-2026-31545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: nxp-nci: allow GPIOs to sleep Allow the firmware and enable GPIOs to sleep. This fixes a `WARN_ON' and allows the driver to operate GPIOs which are connected to I2C GPIO expanders. -- >8 -- kernel: WARNING: CPU: 3 PID: 2636 at drivers/gpio/gpiolib.c:3880 gpiod_set_value+0x88/0x98 -- >8 --", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31399", "url": "https://ubuntu.com/security/CVE-2026-31399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/bus: Fix potential use after free in asynchronous initialization Dingisoul with KASAN reports a use after free if device_add() fails in nd_async_device_register(). Commit b6eae0f61db2 (\"libnvdimm: Hold reference on parent while scheduling async init\") correctly added a reference on the parent device to be held until asynchronous initialization was complete. However, if device_add() results in an allocation failure the ref count of the device drops to 0 prior to the parent pointer being accessed. Thus resulting in use after free. The bug bot AI correctly identified the fix. Save a reference to the parent pointer to be used to drop the parent reference regardless of the outcome of device_add().", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31400", "url": "https://ubuntu.com/security/CVE-2026-31400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix cache_request leak in cache_release When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request. In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup. The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up. Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, dequeue and free the cache_request.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2024-46715", "url": "https://ubuntu.com/security/CVE-2024-46715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver: iio: add missing checks on iio_info's callback access Some callbacks from iio_info structure are accessed without any check, so if a driver doesn't implement them trying to access the corresponding sysfs entries produce a kernel oops such as: [ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute [...] [ 2203.783416] Call trace: [ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48 [ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120 [ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4 [ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0 [ 2203.802236] vfs_read from ksys_read+0xa4/0xd4 [ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54 [ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0) [ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000 [ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000 [ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0 [ 2203.830363] Code: bad PC value [ 2203.832695] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-09-18 07:15:00 UTC" }, { "cve": "CVE-2026-23113", "url": "https://ubuntu.com/security/CVE-2026-23113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't support ->read_iter(), loop_rw_iter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path: INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000 Call Trace: context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98 There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2025-39748", "url": "https://ubuntu.com/security/CVE-2025-39748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Forget ranges when refining tnum after JSET Syzbot reported a kernel warning due to a range invariant violation on the following BPF program. 0: call bpf_get_netns_cookie 1: if r0 == 0 goto 2: if r0 & Oxffffffff goto The issue is on the path where we fall through both jumps. That path is unreachable at runtime: after insn 1, we know r0 != 0, but with the sign extension on the jset, we would only fallthrough insn 2 if r0 == 0. Unfortunately, is_branch_taken() isn't currently able to figure this out, so the verifier walks all branches. The verifier then refines the register bounds using the second condition and we end up with inconsistent bounds on this unreachable path: 1: if r0 == 0 goto r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2: if r0 & 0xffffffff goto r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0) r0 after reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0) Improving the range refinement for JSET to cover all cases is tricky. We also don't expect many users to rely on JSET given LLVM doesn't generate those instructions. So instead of improving the range refinement for JSETs, Eduard suggested we forget the ranges whenever we're narrowing tnums after a JSET. This patch implements that approach.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2026-43357", "url": "https://ubuntu.com/security/CVE-2026-43357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050-core: fix pm_runtime error handling The return value of pm_runtime_get_sync() is not checked, allowing the driver to access hardware that may fail to resume. The device usage count is also unconditionally incremented. Use pm_runtime_resume_and_get() which propagates errors and avoids incrementing the usage count on failure. In preenable, add pm_runtime_put_autosuspend() on set_8khz_samplerate() failure since postdisable does not run when preenable fails.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43476", "url": "https://ubuntu.com/security/CVE-2026-43476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas() sizeof(num) evaluates to sizeof(size_t) (8 bytes on 64-bit) instead of the intended __be32 element size (4 bytes). Use sizeof(*meas) to correctly match the buffer element type.", "cve_priority": "medium", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43363", "url": "https://ubuntu.com/security/CVE-2026-43363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/apic: Disable x2apic on resume if the kernel expects so When resuming from s2ram, firmware may re-enable x2apic mode, which may have been disabled by the kernel during boot either because it doesn't support IRQ remapping or for other reasons. This causes the kernel to continue using the xapic interface, while the hardware is in x2apic mode, which causes hangs. This happens on defconfig + bare metal + s2ram. Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be disabled, i.e. when x2apic_mode = 0. The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the pre-sleep configuration or initial boot configuration for each CPU, including MSR state: When executing from the power-on reset vector as a result of waking from an S2 or S3 sleep state, the platform firmware performs only the hardware initialization required to restore the system to either the state the platform was in prior to the initial operating system boot, or to the pre-sleep configuration state. In multiprocessor systems, non-boot processors should be placed in the same state as prior to the initial operating system boot. (further ahead) If this is an S2 or S3 wake, then the platform runtime firmware restores minimum context of the system before jumping to the waking vector. This includes: \tCPU configuration. Platform runtime firmware restores the pre-sleep \tconfiguration or initial boot configuration of each CPU (MSR, MTRR, \tfirmware update, SMBase, and so on). Interrupts must be disabled (for \tIA-32 processors, disabled by CLI instruction). \t(and other things) So at least as per the spec, re-enablement of x2apic by the firmware is allowed if \"x2apic on\" is a part of the initial boot configuration. [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization [ bp: Massage. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43365", "url": "https://ubuntu.com/security/CVE-2026-43365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix undersized l_iclog_roundoff values If the superblock doesn't list a log stripe unit, we set the incore log roundoff value to 512. This leads to corrupt logs and unmountable filesystems in generic/617 on a disk with 4k physical sectors... XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197. XFS (sda1): failed to locate log tail XFS (sda1): log mount/recovery failed: error -74 XFS (sda1): log mount failed XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Ending clean mount ...on the current xfsprogs for-next which has a broken mkfs. xfs_info shows this... meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1 data = bsize=4096 blocks=2579968, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=4096 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=268435456 extents = zoned=0 start=0 reserved=0 ...observe that the log section has sectsz=4096 sunit=0, which means that the roundoff factor is 512, not 4096 as you'd expect. We should fix mkfs not to generate broken filesystems, but anyone can fuzz the ondisk superblock so we should be more cautious. I think the inadequate logic predates commit a6a65fef5ef8d0, but that's clearly going to require a different backport.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43370", "url": "https://ubuntu.com/security/CVE-2026-43370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix use-after-free race in VM acquire Replace non-atomic vm->process_info assignment with cmpxchg() to prevent race when parent/child processes sharing a drm_file both try to acquire the same VM after fork(). (cherry picked from commit c7c573275ec20db05be769288a3e3bb2250ec618)", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43373", "url": "https://ubuntu.com/security/CVE-2026-43373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ncsi: fix skb leak in error paths Early return paths in NCSI RX and AEN handlers fail to release the received skb, resulting in a memory leak. Specifically, ncsi_aen_handler() returns on invalid AEN packets without consuming the skb. Similarly, ncsi_rcv_rsp() exits early when failing to resolve the NCSI device, response handler, or request, leaving the skb unfreed.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43380", "url": "https://ubuntu.com/security/CVE-2026-43380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read The q54sj108a2_debugfs_read function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes 'data' as the destination and 'data_char' as the source. Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since 'data' is only 34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the end of the buffer onto the stack. Additionally, the arguments were swapped: it was reading from the zero-initialized 'data_char' and writing to 'data', resulting in all-zero output regardless of the actual I2C read. Fix this by: 1. Expanding 'data_char' to 66 bytes to safely hold the hex output. 2. Correcting the bin2hex() argument order and using the actual read count. 3. Using a pointer to select the correct output buffer for the final simple_read_from_buffer call.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43381", "url": "https://ubuntu.com/security/CVE-2026-43381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dpcd: return EBUSY for aux xfer if the device is asleep If we have runtime suspended, and userspace wants to use /dev/drm_dp_* then just tell it the device is busy instead of crashing in the GSP code. WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy) Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024 RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them awake while fw updates are happening.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43382", "url": "https://ubuntu.com/security/CVE-2026-43382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid double-rtnl_lock ELP metric worker batadv_v_elp_get_throughput() might be called when the RTNL lock is already held. This could be problematic when the work queue item is cancelled via cancel_delayed_work_sync() in batadv_v_elp_iface_disable(). In this case, an rtnl_lock() would cause a deadlock. To avoid this, rtnl_trylock() was used in this function to skip the retrieval of the ethtool information in case the RTNL lock was already held. But for cfg80211 interfaces, batadv_get_real_netdev() was called - which also uses rtnl_lock(). The approach for __ethtool_get_link_ksettings() must also be used instead and the lockless version __batadv_get_real_netdev() has to be called.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-31405", "url": "https://ubuntu.com/security/CVE-2026-31405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-net: fix OOB access in ULE extension header tables The ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables in handle_one_ule_extension() are declared with 255 elements (valid indices 0-254), but the index htype is derived from network-controlled data as (ule_sndu_type & 0x00FF), giving a range of 0-255. When htype equals 255, an out-of-bounds read occurs on the function pointer table, and the OOB value may be called as a function pointer. Add a bounds check on htype against the array size before either table is accessed. Out-of-range values now cause the SNDU to be discarded.", "cve_priority": "high", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-43387", "url": "https://ubuntu.com/security/CVE-2026-43387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: properly validate the data in rtw_get_ie_ex() Just like in commit 154828bf9559 (\"staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser\"), we don't trust the data in the frame so we should check the length better before acting on it", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43386", "url": "https://ubuntu.com/security/CVE-2026-43386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie The current code checks 'i + 5 < in_len' at the end of the if statement. However, it accesses 'in_ie[i + 5]' before that check, which can lead to an out-of-bounds read. Move the length check to the beginning of the conditional to ensure the index is within bounds before accessing the array.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43420", "url": "https://ubuntu.com/security/CVE-2026-43420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix i_nlink underrun during async unlink During async unlink, we drop the `i_nlink` counter before we receive the completion (that will eventually update the `i_nlink`) because \"we assume that the unlink will succeed\". That is not a bad idea, but it races against deletions by other clients (or against the completion of our own unlink) and can lead to an underrun which emits a WARNING like this one: WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68 Modules linked in: CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drop_nlink+0x50/0x68 lr : ceph_unlink+0x6c4/0x720 sp : ffff80012173bc90 x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680 x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647 x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203 x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365 x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74 x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94 x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002 x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8 Call trace: drop_nlink+0x50/0x68 (P) vfs_unlink+0xb0/0x2e8 do_unlinkat+0x204/0x288 __arm64_sys_unlinkat+0x3c/0x80 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0xa4/0xc8 el0_svc+0x18/0x58 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x154/0x158 In ceph_unlink(), a call to ceph_mdsc_submit_request() submits the CEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion. Meanwhile, between this call and the following drop_nlink() call, a worker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT or just a CEPH_MSG_CLIENT_REPLY (the latter of which could be our own completion). These will lead to a set_nlink() call, updating the `i_nlink` counter to the value received from the MDS. If that new `i_nlink` value happens to be zero, it is illegal to decrement it further. But that is exactly what ceph_unlink() will do then. The WARNING can be reproduced this way: 1. Force async unlink; only the async code path is affected. Having no real clue about Ceph internals, I was unable to find out why the MDS wouldn't give me the \"Fxr\" capabilities, so I patched get_caps_for_async_unlink() to always succeed. (Note that the WARNING dump above was found on an unpatched kernel, without this kludge - this is not a theoretical bug.) 2. Add a sleep call after ceph_mdsc_submit_request() so the unlink completion gets handled by a worker thread before drop_nlink() is called. This guarantees that the `i_nlink` is already zero before drop_nlink() runs. The solution is to skip the counter decrement when it is already zero, but doing so without a lock is still racy (TOCTOU). Since ceph_fill_inode() and handle_cap_grant() both hold the `ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, this seems like the proper lock to protect the `i_nlink` updates. I found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using `afs_vnode.cb_lock`). All three have the zero check as well.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43405", "url": "https://ubuntu.com/security/CVE-2026-43405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Use u32 for non-negative values in ceph_monmap_decode() This patch fixes unnecessary implicit conversions that change signedness of blob_len and num_mon in ceph_monmap_decode(). Currently blob_len and num_mon are (signed) int variables. They are used to hold values that are always non-negative and get assigned in ceph_decode_32_safe(), which is meant to assign u32 values. Both variables are subsequently used as unsigned values, and the value of num_mon is further assigned to monmap->num_mon, which is of type u32. Therefore, both variables should be of type u32. This is especially relevant for num_mon. If the value read from the incoming message is very large, it is interpreted as a negative value, and the check for num_mon > CEPH_MAX_MON does not catch it. This leads to the attempt to allocate a very large chunk of memory for monmap, which will most likely fail. In this case, an unnecessary attempt to allocate memory is performed, and -ENOMEM is returned instead of -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43411", "url": "https://ubuntu.com/security/CVE-2026-43411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix divide-by-zero in tipc_sk_filter_connect() A user can set conn_timeout to any value via setsockopt(TIPC_CONN_TIMEOUT), including values less than 4. When a SYN is rejected with TIPC_ERR_OVERLOAD and the retry path in tipc_sk_filter_connect() executes: delay %= (tsk->conn_timeout / 4); If conn_timeout is in the range [0, 3], the integer division yields 0, and the modulo operation triggers a divide-by-zero exception, causing a kernel oops/panic. Fix this by clamping conn_timeout to a minimum of 4 at the point of use in tipc_sk_filter_connect(). Oops: divide error: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+ RIP: 0010:tipc_sk_filter_rcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362) Call Trace: tipc_sk_backlog_rcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406) __release_sock (include/net/sock.h:1185 net/core/sock.c:3213) release_sock (net/core/sock.c:3797) tipc_connect (net/tipc/socket.c:2570) __sys_connect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098)", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43484", "url": "https://ubuntu.com/security/CVE-2026-43484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: core: Avoid bitfield RMW for claim/retune flags Move claimed and retune control flags out of the bitfield word to avoid unrelated RMW side effects in asynchronous contexts. The host->claimed bit shared a word with retune flags. Writes to claimed in __mmc_claim_host() or retune_now in mmc_mq_queue_rq() can overwrite other bits when concurrent updates happen in other contexts, triggering spurious WARN_ON(!host->claimed). Convert claimed, can_retune, retune_now and retune_paused to bool to remove shared-word coupling.", "cve_priority": "low", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43425", "url": "https://ubuntu.com/security/CVE-2026-43425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: kill download URB on timeout mdc800_device_read() submits download_urb and waits for completion. If the timeout fires and the device has not responded, the function returns without killing the URB, leaving it active. A subsequent read() resubmits the same URB while it is still in-flight, triggering the WARN in usb_submit_urb(): \"URB submitted while active\" Check the return value of wait_event_timeout() and kill the URB if it indicates timeout, ensuring the URB is complete before its status is inspected or the URB is resubmitted. Similar to - commit 372c93131998 (\"USB: yurex: fix control-URB timeout handling\") - commit b98d5000c505 (\"media: rc: iguanair: handle timeouts\")", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43426", "url": "https://ubuntu.com/security/CVE-2026-43426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: fix use-after-free in ISR during device removal In usbhs_remove(), the driver frees resources (including the pipe array) while the interrupt handler (usbhs_interrupt) is still registered. If an interrupt fires after usbhs_pipe_remove() but before the driver is fully unbound, the ISR may access freed memory, causing a use-after-free. Fix this by calling devm_free_irq() before freeing resources. This ensures the interrupt handler is both disabled and synchronized (waits for any running ISR to complete) before usbhs_pipe_remove() is called.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43427", "url": "https://ubuntu.com/security/CVE-2026-43427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: class: cdc-wdm: fix reordering issue in read code path Quoting the bug report: Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdm_read() can see the new length and call copy_to_user() on uninitialized memory. This also violates LKMM data race rules [1]. Fix it by using WRITE_ONCE and memory barriers.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43428", "url": "https://ubuntu.com/security/CVE-2026-43428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: core: Limit the length of unkillable synchronous timeouts The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device. To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector. In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43429", "url": "https://ubuntu.com/security/CVE-2026-43429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: Use usb_bulk_msg_killable() with user-specified timeouts The usbtmc driver accepts timeout values specified by the user in an ioctl command, and uses these timeouts for some usb_bulk_msg() calls. Since the user can specify arbitrarily long timeouts and usb_bulk_msg() uses unkillable waits, call usb_bulk_msg_killable() instead to avoid the possibility of the user hanging a kernel thread indefinitely.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43430", "url": "https://ubuntu.com/security/CVE-2026-43430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: yurex: fix race in probe The bbu member of the descriptor must be set to the value standing for uninitialized values before the URB whose completion handler sets bbu is submitted. Otherwise there is a window during which probing can overwrite already retrieved data.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43432", "url": "https://ubuntu.com/security/CVE-2026-43432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix memory leak in xhci_disable_slot() xhci_alloc_command() allocates a command structure and, when the second argument is true, also allocates a completion structure. Currently, the error handling path in xhci_disable_slot() only frees the command structure using kfree(), causing the completion structure to leak. Use xhci_free_command() instead of kfree(). xhci_free_command() correctly frees both the command structure and the associated completion structure. Since the command structure is allocated with zero-initialization, command->in_ctx is NULL and will not be erroneously freed by xhci_free_command(). This bug was found using an experimental static analysis tool we are developing. The tool is based on the LLVM framework and is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available, but we plan to open-source it after our research is published. The bug was originally detected on v6.13-rc1 using our static analysis tool, and we have verified that the issue persists in the latest mainline kernel. We performed build testing on x86_64 with allyesconfig using GCC=11.4.0. Since triggering these error paths in xhci_disable_slot() requires specific hardware conditions or abnormal state, we were unable to construct a test case to reliably trigger these specific error paths at runtime.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43439", "url": "https://ubuntu.com/security/CVE-2026-43439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup: fix race between task migration and iteration When a task is migrated out of a css_set, cgroup_migrate_add_task() first moves it from cset->tasks to cset->mg_tasks via: list_move_tail(&task->cg_list, &cset->mg_tasks); If a css_task_iter currently has it->task_pos pointing to this task, css_set_move_task() calls css_task_iter_skip() to keep the iterator valid. However, since the task has already been moved to ->mg_tasks, the iterator is advanced relative to the mg_tasks list instead of the original tasks list. As a result, remaining tasks on cset->tasks, as well as tasks queued on cset->mg_tasks, can be skipped by iteration. Fix this by calling css_set_skip_task_iters() before unlinking task->cg_list from cset->tasks. This advances all active iterators to the next task on cset->tasks, so iteration continues correctly even when a task is concurrently being migrated. This race is hard to hit in practice without instrumentation, but it can be reproduced by artificially slowing down cgroup_procs_show(). For example, on an Android device a temporary /sys/kernel/cgroup/cgroup_test knob can be added to inject a delay into cgroup_procs_show(), and then: 1) Spawn three long-running tasks (PIDs 101, 102, 103). 2) Create a test cgroup and move the tasks into it. 3) Enable a large delay via /sys/kernel/cgroup/cgroup_test. 4) In one shell, read cgroup.procs from the test cgroup. 5) Within the delay window, in another shell migrate PID 102 by writing it to a different cgroup.procs file. Under this setup, cgroup.procs can intermittently show only PID 101 while skipping PID 103. Once the migration completes, reading the file again shows all tasks as expected. Note that this change does not allow removing the existing css_set_skip_task_iters() call in css_set_move_task(). The new call in cgroup_migrate_add_task() only handles iterators that are racing with migration while the task is still on cset->tasks. Iterators may also start after the task has been moved to cset->mg_tasks. If we dropped css_set_skip_task_iters() from css_set_move_task(), such iterators could keep task_pos pointing to a migrating task, causing css_task_iter_advance() to malfunction on the destination css_set, up to and including crashes or infinite loops. The race window between migration and iteration is very small, and css_task_iter is not on a hot path. In the worst case, when an iterator is positioned on the first thread of the migrating process, cgroup_migrate_add_task() may have to skip multiple tasks via css_set_skip_task_iters(). However, this only happens when migration and iteration actually race, so the performance impact is negligible compared to the correctness fix provided here.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43480", "url": "https://ubuntu.com/security/CVE-2026-43480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisition The acp3x_5682_init() function did not check the return value of clk_get(), which could lead to dereferencing error pointers in rt5682_clk_enable(). Fix this by: 1. Changing clk_get() to the device-managed devm_clk_get(). 2. Adding proper IS_ERR() checks for both clock acquisitions.", "cve_priority": "low", "cve_public_date": "2026-05-13 16:16:00 UTC" }, { "cve": "CVE-2026-43445", "url": "https://ubuntu.com/security/CVE-2026-43445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: e1000/e1000e: Fix leak in 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 after a successful 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 would leak. In these commits, a faulty while condition caused an infinite loop in dma_error: Commit 03b1320dfcee (\"e1000e: remove use of skb_dma_map from e1000e driver\") Commit 602c0554d7b0 (\"e1000: remove use of skb_dma_map from e1000 driver\") Commit c1fa347f20f1 (\"e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()\") fixed the infinite loop, but introduced the off-by-one error. This issue may still exist in the igbvf driver, but I did not address it in this patch.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43449", "url": "https://ubuntu.com/security/CVE-2026-43449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_set dev->online_queues is a count incremented in nvme_init_queue. Thus, valid indices are 0 through dev->online_queues − 1. This patch fixes the loop condition to ensure the index stays within the valid range. Index 0 is excluded because it is the admin queue. KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74 CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: nvme-reset-wq nvme_reset_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xea/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xce/0x5d0 mm/kasan/report.c:482 kasan_report+0xdc/0x110 mm/kasan/report.c:595 __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c:379 nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c:3252 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 34 on cpu 1 at 4.241550s: kasan_save_stack+0x2c/0x60 mm/kasan/common.c:57 kasan_save_track+0x1c/0x70 mm/kasan/common.c:78 kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c:570 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5657 [inline] __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c:5663 kmalloc_array_node_noprof include/linux/slab.h:1075 [inline] nvme_pci_alloc_dev drivers/nvme/host/pci.c:3479 [inline] nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534 local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c:324 pci_call_probe drivers/pci/pci-driver.c:392 [inline] __pci_device_probe drivers/pci/pci-driver.c:417 [inline] pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c:451 call_driver_probe drivers/base/dd.c:583 [inline] really_probe+0x29b/0xb70 drivers/base/dd.c:661 __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c:803 driver_probe_device+0x56/0x1f0 drivers/base/dd.c:833 __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c:1159 async_run_entry_fn+0xa6/0x4b0 kernel/async.c:129 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 The buggy address belongs to the object at ffff88800592a000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 244 bytes to the right of allocated 1152-byte region [ffff88800592a000, ffff88800592a480) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff) page_type: f5(slab) raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000 head: 000fffffc0000040 ffff888001042000 00000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43450", "url": "https://ubuntu.com/security/CVE-2026-43450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table() nfnl_cthelper_dump_table() has a 'goto restart' that jumps to a label inside the for loop body. When the \"last\" helper saved in cb->args[1] is deleted between dump rounds, every entry fails the (cur != last) check, so cb->args[1] is never cleared. The for loop finishes with cb->args[0] == nf_ct_helper_hsize, and the 'goto restart' jumps back into the loop body bypassing the bounds check, causing an 8-byte out-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize]. The 'goto restart' block was meant to re-traverse the current bucket when \"last\" is no longer found, but it was placed after the for loop instead of inside it. Move the block into the for loop body so that the restart only occurs while cb->args[0] is still within bounds. BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131 Call Trace: nfnl_cthelper_dump_table+0x9f/0x1b0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 sock_recvmsg+0xde/0xf0 __sys_recvfrom+0x150/0x200 __x64_sys_recvfrom+0x76/0x90 do_syscall_64+0xc3/0x6e0 Allocated by task 1: __kvmalloc_node_noprof+0x21b/0x700 nf_ct_alloc_hashtable+0x65/0xd0 nf_conntrack_helper_init+0x21/0x60 nf_conntrack_init_start+0x18d/0x300 nf_conntrack_standalone_init+0x12/0xc0", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43451", "url": "https://ubuntu.com/security/CVE-2026-43451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: fix entry leak in bridge verdict error path nfqnl_recv_verdict() calls find_dequeue_entry() to remove the queue entry from the queue data structures, taking ownership of the entry. For PF_BRIDGE packets, it then calls nfqa_parse_bridge() to parse VLAN attributes. If nfqa_parse_bridge() returns an error (e.g. NFQA_VLAN present but NFQA_VLAN_TCI missing), the function returns immediately without freeing the dequeued entry or its sk_buff. This leaks the nf_queue_entry, its associated sk_buff, and all held references (net_device refcounts, struct net refcount). Repeated triggering exhausts kernel memory. Fix this by dropping the entry via nfqnl_reinject() with NF_DROP verdict on the error path, consistent with other error handling in this file.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43452", "url": "https://ubuntu.com/security/CVE-2026-43452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: guard option walkers against 1-byte tail reads When the last byte of options is a non-single-byte option kind, walkers that advance with i += op[i + 1] ? : 1 can read op[i + 1] past the end of the option area. Add an explicit i == optlen - 1 check before dereferencing op[i + 1] in xt_tcpudp and xt_dccp option walkers.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43453", "url": "https://ubuntu.com/security/CVE-2026-43453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop() pipapo_drop() passes rulemap[i + 1].n to pipapo_unmap() as the to_offset argument on every iteration, including the last one where i == m->field_count - 1. This reads one element past the end of the stack-allocated rulemap array (declared as rulemap[NFT_PIPAPO_MAX_FIELDS] with NFT_PIPAPO_MAX_FIELDS == 16). Although pipapo_unmap() returns early when is_last is true without using the to_offset value, the argument is evaluated at the call site before the function body executes, making this a genuine out-of-bounds stack read confirmed by KASAN: BUG: KASAN: stack-out-of-bounds in pipapo_drop+0x50c/0x57c [nf_tables] Read of size 4 at addr ffff8000810e71a4 This frame has 1 object: [32, 160) 'rulemap' The buggy address is at offset 164 -- exactly 4 bytes past the end of the rulemap array. Pass 0 instead of rulemap[i + 1].n on the last iteration to avoid the out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43458", "url": "https://ubuntu.com/security/CVE-2026-43458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: caif: hold tty->link reference in ldisc_open and ser_release A reproducer triggers a KASAN slab-use-after-free in pty_write_room() when caif_serial's TX path calls tty_write_room(). The faulting access is on tty->link->port. Hold an extra kref on tty->link for the lifetime of the caif_serial line discipline: get it in ldisc_open() and drop it in ser_release(), and also drop it on the ldisc_open() error path. With this change applied, the reproducer no longer triggers the UAF in my testing.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43459", "url": "https://ubuntu.com/security/CVE-2026-43459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-core: flush delayed work before removing DAIs and widgets When a sound card is unbound while a PCM stream is open, a use-after-free can occur in snd_soc_dapm_stream_event(), called from the close_delayed_work workqueue handler. During unbind, snd_soc_unbind_card() flushes delayed work and then calls soc_cleanup_card_resources(). Inside cleanup, snd_card_disconnect_sync() releases all PCM file descriptors, and the resulting PCM close path can call snd_soc_dapm_stream_stop() which schedules new delayed work with a pmdown_time timer delay. Since this happens after the flush in snd_soc_unbind_card(), the new work is not caught. soc_remove_link_components() then frees DAPM widgets before this work fires, leading to the use-after-free. The existing flush in soc_free_pcm_runtime() also cannot help as it runs after soc_remove_link_components() has already freed the widgets. Add a flush in soc_cleanup_card_resources() after snd_card_disconnect_sync() (after which no new PCM closes can schedule further delayed work) and before soc_remove_link_dais() and soc_remove_link_components() (which tear down the structures the delayed work accesses).", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-23277", "url": "https://ubuntu.com/security/CVE-2026-23277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit teql_master_xmit() calls netdev_start_xmit(skb, slave) to transmit through slave devices, but does not update skb->dev to the slave device beforehand. When a gretap tunnel is a TEQL slave, the transmit path reaches iptunnel_xmit() which saves dev = skb->dev (still pointing to teql0 master) and later calls iptunnel_xmit_stats(dev, pkt_len). This function does: get_cpu_ptr(dev->tstats) Since teql_master_setup() does not set dev->pcpu_stat_type to NETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstats for teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computes NULL + __per_cpu_offset[cpu], resulting in a page fault. BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206) Fix this by setting skb->dev = slave before calling netdev_start_xmit(), so that tunnel xmit functions see the correct slave device with properly allocated tstats.", "cve_priority": "medium", "cve_public_date": "2026-03-20 09:16:00 UTC" }, { "cve": "CVE-2026-43466", "url": "https://ubuntu.com/security/CVE-2026-43466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery In case of a TX error CQE, a recovery flow is triggered, mlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc, desyncing the DMA FIFO producer and consumer. After recovery, the producer pushes new DMA entries at the old dma_fifo_pc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery. The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dma_fifo_cc is already equal to dma_fifo_pc. There is no need to reset either counter, similar to how skb_fifo pc/cc are untouched. Remove the 'dma_fifo_cc = 0' reset. This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90 Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: ? __warn+0x7d/0x110 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0x16d/0x180 ? handle_bug+0x4f/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 ? iommu_dma_unmap_page+0x2e/0x90 dma_unmap_page_attrs+0x10d/0x1b0 mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core] mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core] mlx5e_napi_poll+0x8b/0xac0 [mlx5_core] __napi_poll+0x24/0x190 net_rx_action+0x32a/0x3b0 ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core] ? notifier_call_chain+0x35/0xa0 handle_softirqs+0xc9/0x270 irq_exit_rcu+0x71/0xd0 common_interrupt+0x7f/0xa0 asm_common_interrupt+0x22/0x40", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43469", "url": "https://ubuntu.com/security/CVE-2026-43469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decrement re_receiving on the early exit paths In the event that rpcrdma_post_recvs() fails to create a work request (due to memory allocation failure, say) or otherwise exits early, we should decrement ep->re_receiving before returning. Otherwise we will hang in rpcrdma_xprt_drain() as re_receiving will never reach zero and the completion will never be triggered. On a system with high memory pressure, this can appear as the following hung task: INFO: task kworker/u385:17:8393 blocked for more than 122 seconds. Tainted: G S E 6.19.0 #3 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u385:17 state:D stack:0 pid:8393 tgid:8393 ppid:2 task_flags:0x4248060 flags:0x00080000 Workqueue: xprtiod xprt_autoclose [sunrpc] Call Trace: __schedule+0x48b/0x18b0 ? ib_post_send_mad+0x247/0xae0 [ib_core] schedule+0x27/0xf0 schedule_timeout+0x104/0x110 __wait_for_common+0x98/0x180 ? __pfx_schedule_timeout+0x10/0x10 wait_for_completion+0x24/0x40 rpcrdma_xprt_disconnect+0x444/0x460 [rpcrdma] xprt_rdma_close+0x12/0x40 [rpcrdma] xprt_autoclose+0x5f/0x120 [sunrpc] process_one_work+0x191/0x3e0 worker_thread+0x2e3/0x420 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x273/0x2b0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2025-54505", "url": "https://ubuntu.com/security/CVE-2025-54505", "cve_description": "A transient execution vulnerability within AMD CPUs may allow a local user-privileged attacker to leak data via the floating point divisor unit, potentially resulting in loss of confidentiality.", "cve_priority": "medium", "cve_public_date": "2026-04-27 16:16:00 UTC" }, { "cve": "CVE-2026-31628", "url": "https://ubuntu.com/security/CVE-2026-31628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU: Fix FPDSS on Zen1 Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43472", "url": "https://ubuntu.com/security/CVE-2026-43472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: unshare: fix unshare_fs() handling There's an unpleasant corner case in unshare(2), when we have a CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that case copy_mnt_ns() gets passed current->fs instead of a private copy, which causes interesting warts in proof of correctness] > I guess if private means fs->users == 1, the condition could still be true. Unfortunately, it's worse than just a convoluted proof of correctness. Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS (and current->fs->users == 1). We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and flips current->fs->{pwd,root} to corresponding locations in the new namespace. Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM). We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's destroyed and its mount tree is dissolved, but... current->fs->root and current->fs->pwd are both left pointing to now detached mounts. They are pinning those, so it's not a UAF, but it leaves the calling process with unshare(2) failing with -ENOMEM _and_ leaving it with pwd and root on detached isolated mounts. The last part is clearly a bug. There is other fun related to that mess (races with pivot_root(), including the one between pivot_root() and fork(), of all things), but this one is easy to isolate and fix - treat CLONE_NEWNS as \"allocate a new fs_struct even if it hadn't been shared in the first place\". Sure, we could go for something like \"if both CLONE_NEWNS *and* one of the things that might end up failing after copy_mnt_ns() call in create_new_namespaces() are set, force allocation of new fs_struct\", but let's keep it simple - the cost of copy_fs_struct() is trivial. Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets a freshly allocated fs_struct, yet to be attached to anything. That seriously simplifies the analysis... FWIW, that bug had been there since the introduction of unshare(2) ;-/", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-43473", "url": "https://ubuntu.com/security/CVE-2026-43473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Add NULL checks when resetting request and reply queues The driver encountered a crash during resource cleanup when the reply and request queues were NULL due to freed memory. This issue occurred when the creation of reply or request queues failed, and the driver freed the memory first, but attempted to mem set the content of the freed memory, leading to a system crash. Add NULL pointer checks for reply and request queues before accessing the reply/request memory during cleanup", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-43475", "url": "https://ubuntu.com/security/CVE-2026-43475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT This resolves the follow splat and lock-up when running with PREEMPT_RT enabled on Hyper-V: [ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002 [ 415.140822] INFO: lockdep is turned off. [ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common [ 415.140846] Preemption disabled at: [ 415.140847] [] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)} [ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024 [ 415.140857] Call Trace: [ 415.140861] [ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140863] dump_stack_lvl+0x91/0xb0 [ 415.140870] __schedule_bug+0x9c/0xc0 [ 415.140875] __schedule+0xdf6/0x1300 [ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980 [ 415.140879] ? rcu_is_watching+0x12/0x60 [ 415.140883] schedule_rtlock+0x21/0x40 [ 415.140885] rtlock_slowlock_locked+0x502/0x1980 [ 415.140891] rt_spin_lock+0x89/0x1e0 [ 415.140893] hv_ringbuffer_write+0x87/0x2a0 [ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0 [ 415.140900] ? rcu_is_watching+0x12/0x60 [ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc] [ 415.140904] ? HARDIRQ_verbose+0x10/0x10 [ 415.140908] ? __rq_qos_issue+0x28/0x40 [ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod] [ 415.140926] __blk_mq_issue_directly+0x4a/0xc0 [ 415.140928] blk_mq_issue_direct+0x87/0x2b0 [ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440 [ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0 [ 415.140935] __blk_flush_plug+0xf4/0x150 [ 415.140940] __submit_bio+0x2b2/0x5c0 [ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360 [ 415.140946] submit_bio_noacct_nocheck+0x272/0x360 [ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4] [ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4] [ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4] [ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4] [ 415.141060] generic_perform_write+0x14e/0x2c0 [ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4] [ 415.141083] vfs_write+0x2ca/0x570 [ 415.141087] ksys_write+0x76/0xf0 [ 415.141089] do_syscall_64+0x99/0x1490 [ 415.141093] ? rcu_is_watching+0x12/0x60 [ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0 [ 415.141097] ? rcu_is_watching+0x12/0x60 [ 415.141098] ? lock_release+0x1f0/0x2a0 [ 415.141100] ? rcu_is_watching+0x12/0x60 [ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0 [ 415.141103] ? rcu_is_watching+0x12/0x60 [ 415.141104] ? __schedule+0xb34/0x1300 [ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170 [ 415.141109] ? do_nanosleep+0x8b/0x160 [ 415.141111] ? hrtimer_nanosleep+0x89/0x100 [ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10 [ 415.141116] ? xfd_validate_state+0x26/0x90 [ 415.141118] ? rcu_is_watching+0x12/0x60 [ 415.141120] ? do_syscall_64+0x1e0/0x1490 [ 415.141121] ? do_syscall_64+0x1e0/0x1490 [ 415.141123] ? rcu_is_watching+0x12/0x60 [ 415.141124] ? do_syscall_64+0x1e0/0x1490 [ 415.141125] ? do_syscall_64+0x1e0/0x1490 [ 415.141127] ? irqentry_exit+0x140/0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:17:00 UTC" }, { "cve": "CVE-2026-23270", "url": "https://ubuntu.com/security/CVE-2026-23270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocks As Paolo said earlier [1]: \"Since the blamed commit below, classify can return TC_ACT_CONSUMED while the current skb being held by the defragmentation engine. As reported by GangMin Kim, if such packet is that may cause a UaF when the defrag engine later on tries to tuch again such packet.\" act_ct was never meant to be used in the egress path, however some users are attaching it to egress today [2]. Attempting to reach a middle ground, we noticed that, while most qdiscs are not handling TC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, we address the issue by only allowing act_ct to bind to clsact/ingress qdiscs and shared blocks. That way it's still possible to attach act_ct to egress (albeit only with clsact). [1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/ [2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23300", "url": "https://ubuntu.com/security/CVE-2026-23300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop When a standalone IPv6 nexthop object is created with a loopback device (e.g., \"ip -6 nexthop add id 100 dev lo\"), fib6_nh_init() misclassifies it as a reject route. This is because nexthop objects have no destination prefix (fc_dst=::), causing fib6_is_reject() to match any loopback nexthop. The reject path skips fib_nh_common_init(), leaving nhc_pcpu_rth_output unallocated. If an IPv4 route later references this nexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and panics. Simplify the check in fib6_nh_init() to only match explicit reject routes (RTF_REJECT) instead of using fib6_is_reject(). The loopback promotion heuristic in fib6_is_reject() is handled separately by ip6_route_info_create_nh(). After this change, the three cases behave as follows: 1. Explicit reject route (\"ip -6 route add unreachable 2001:db8::/64\"): RTF_REJECT is set, enters reject path, skips fib_nh_common_init(). No behavior change. 2. Implicit loopback reject route (\"ip -6 route add 2001:db8::/32 dev lo\"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. ip6_route_info_create_nh() still promotes it to reject afterward. nhc_pcpu_rth_output is allocated but unused, which is harmless. 3. Standalone nexthop object (\"ip -6 nexthop add id 100 dev lo\"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. nhc_pcpu_rth_output is properly allocated, fixing the crash when IPv4 routes reference this nexthop.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23293", "url": "https://ubuntu.com/security/CVE-2026-23293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. If an IPv6 packet is injected into the interface, route_shortcircuit() is called and a NULL pointer dereference happens on neigh_lookup(). BUG: kernel NULL pointer dereference, address: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neigh_lookup+0x20/0x270 [...] Call Trace: vxlan_xmit+0x638/0x1ef0 [vxlan] dev_hard_start_xmit+0x9e/0x2e0 __dev_queue_xmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x12f/0x1590 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix this by adding an early check on route_shortcircuit() when protocol is ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here because VXLAN can be built-in even when IPv6 is built as a module.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23381", "url": "https://ubuntu.com/security/CVE-2026-23381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. Then, if neigh_suppress is enabled and an ICMPv6 Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() will dereference ipv6_stub->nd_tbl which is NULL, passing it to neigh_lookup(). This causes a kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neigh_lookup+0x16/0xe0 [...] Call Trace: ? neigh_lookup+0x16/0xe0 br_do_suppress_nd+0x160/0x290 [bridge] br_handle_frame_finish+0x500/0x620 [bridge] br_handle_frame+0x353/0x440 [bridge] __netif_receive_skb_core.constprop.0+0x298/0x1110 __netif_receive_skb_one_core+0x3d/0xa0 process_backlog+0xa0/0x140 __napi_poll+0x2c/0x170 net_rx_action+0x2c4/0x3a0 handle_softirqs+0xd0/0x270 do_softirq+0x3f/0x60 Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() in the callers. This is in essence disabling NS/NA suppression when IPv6 is disabled.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23372", "url": "https://ubuntu.com/security/CVE-2026-23372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: rawsock: cancel tx_work before socket teardown In rawsock_release(), cancel any pending tx_work and purge the write queue before orphaning the socket. rawsock_tx_work runs on the system workqueue and calls nfc_data_exchange which dereferences the NCI device. Without synchronization, tx_work can race with socket and device teardown when a process is killed (e.g. by SIGKILL), leading to use-after-free or leaked references. Set SEND_SHUTDOWN first so that if tx_work is already running it will see the flag and skip transmitting, then use cancel_work_sync to wait for any in-progress execution to finish, and finally purge any remaining queued skbs.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23339", "url": "https://ubuntu.com/security/CVE-2026-23339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: free skb on nci_transceive early error paths nci_transceive() takes ownership of the skb passed by the caller, but the -EPROTO, -EINVAL, and -EBUSY error paths return without freeing it. Due to issues clearing NCI_DATA_EXCHANGE fixed by subsequent changes the nci/nci_dev selftest hits the error path occasionally in NIPA, and kmemleak detects leaks: unreferenced object 0xff11000015ce6a40 (size 640): comm \"nci_dev\", pid 3954, jiffies 4295441246 hex dump (first 32 bytes): 6b 6b 6b 6b 00 a4 00 0c 02 e1 03 6b 6b 6b 6b 6b kkkk.......kkkkk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk backtrace (crc 7c40cc2a): kmem_cache_alloc_node_noprof+0x492/0x630 __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xc6/0x8f0 sock_alloc_send_pskb+0x326/0x3f0 nfc_alloc_send_skb+0x94/0x1d0 rawsock_sendmsg+0x162/0x4c0 do_syscall_64+0x117/0xfc0", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23340", "url": "https://ubuntu.com/security/CVE-2026-23340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs When shrinking the number of real tx queues, netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush qdiscs for queues which will no longer be used. qdisc_reset_all_tx_gt() currently serializes qdisc_reset() with qdisc_lock(). However, for lockless qdiscs, the dequeue path is serialized by qdisc_run_begin/end() using qdisc->seqlock instead, so qdisc_reset() can run concurrently with __qdisc_run() and free skbs while they are still being dequeued, leading to UAF. This can easily be reproduced on e.g. virtio-net by imposing heavy traffic while frequently changing the number of queue pairs: iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 done With KASAN enabled, this leads to reports like: BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: ... __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 udp_sendmsg+0x13c9/0x1fc0 ... Allocated by task 1270 on cpu 5 at 44.558414s: ... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg+0x13a6/0x1fc0 ... Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a/0x890 ... Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path by taking qdisc->seqlock for TCQ_F_NOLOCK qdiscs, matching the serialization model already used by dev_reset_queue(). Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state reflects an empty queue, avoiding needless re-scheduling.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23304", "url": "https://ubuntu.com/security/CVE-2026-23304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu() l3mdev_master_dev_rcu() can return NULL when the slave device is being un-slaved from a VRF. All other callers deal with this, but we lost the fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu() with commit 4832c30d5458 (\"net: ipv6: put host and anycast routes on device with address\"). KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418) Call Trace: ip6_pol_route (net/ipv6/route.c:2318) fib6_rule_lookup (net/ipv6/fib6_rules.c:115) ip6_route_output_flags (net/ipv6/route.c:2607) vrf_process_v6_outbound (drivers/net/vrf.c:437) I was tempted to rework the un-slaving code to clear the flag first and insert synchronize_rcu() before we remove the upper. But looks like the explicit fallback to loopback_dev is an established pattern. And I guess avoiding the synchronize_rcu() is nice, too.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23420", "url": "https://ubuntu.com/security/CVE-2026-23420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: Fix a locking bug Make sure that wl->mutex is locked before it is unlocked. This has been detected by the Clang thread-safety analyzer.", "cve_priority": "medium", "cve_public_date": "2026-04-03 14:16:00 UTC" }, { "cve": "CVE-2026-23357", "url": "https://ubuntu.com/security/CVE-2026-23357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix deadlock in error path of mcp251x_open The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish. This issue is similar to the one fixed in commit 7dd9c26bd6cf (\"can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\") but for the error path. To solve this issue move the call to free_irq() after the lock is released. Setting `priv->force_quit = 1` beforehand ensure that the IRQ handler will exit right away once it acquired the lock.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23362", "url": "https://ubuntu.com/security/CVE-2026-23362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix locking for bcm_op runtime updates Commit c2aba69d0c36 (\"can: bcm: add locking for bcm_op runtime updates\") added a locking for some variables that can be modified at runtime when updating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup(). Usually the RX_SETUP only handles and filters incoming traffic with one exception: When the RX_RTR_FRAME flag is set a predefined CAN frame is sent when a specific RTR frame is received. Therefore the rx bcm_op uses bcm_can_tx() which uses the bcm_tx_lock that was only initialized in bcm_tx_setup(). Add the missing spin_lock_init() when allocating the bcm_op in bcm_rx_setup() to handle the RTR case properly.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23286", "url": "https://ubuntu.com/security/CVE-2026-23286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix null-ptr-deref in lec_arp_clear_vccs syzkaller reported a null-ptr-deref in lec_arp_clear_vccs(). This issue can be easily reproduced using the syzkaller reproducer. In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared by multiple lec_arp_table entries (e.g., via entry->vcc or entry->recv_vcc). When the underlying VCC is closed, lec_vcc_close() iterates over all ARP entries and calls lec_arp_clear_vccs() for each matched entry. For example, when lec_vcc_close() iterates through the hlists in priv->lec_arp_empty_ones or other ARP tables: 1. In the first iteration, for the first matched ARP entry sharing the VCC, lec_arp_clear_vccs() frees the associated vpriv (which is vcc->user_back) and sets vcc->user_back to NULL. 2. In the second iteration, for the next matched ARP entry sharing the same VCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv from vcc->user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference it via `vcc->pop = vpriv->old_pop`, leading to a null-ptr-deref crash. Fix this by adding a null check for vpriv before dereferencing it. If vpriv is already NULL, it means the VCC has been cleared by a previous call, so we can safely skip the cleanup and just clear the entry's vcc/recv_vcc pointers. The entire cleanup block (including vcc_release_async()) is placed inside the vpriv guard because a NULL vpriv indicates the VCC has already been fully released by a prior iteration — repeating the teardown would redundantly set flags and trigger callbacks on an already-closing socket. The Fixes tag points to the initial commit because the entry->vcc path has been vulnerable since the original code. The entry->recv_vcc path was later added by commit 8d9f73c0ad2f (\"atm: fix a memory leak of vcc->user_back\") with the same pattern, and both paths are fixed here.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23296", "url": "https://ubuntu.com/security/CVE-2026-23296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix refcount leak for tagset_refcnt This leak will cause a hang when tearing down the SCSI host. For example, iscsid hangs with the following call trace: [130120.652718] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured PID: 2528 TASK: ffff9d0408974e00 CPU: 3 COMMAND: \"iscsid\" #0 [ffffb5b9c134b9e0] __schedule at ffffffff860657d4 #1 [ffffb5b9c134ba28] schedule at ffffffff86065c6f #2 [ffffb5b9c134ba40] schedule_timeout at ffffffff86069fb0 #3 [ffffb5b9c134bab0] __wait_for_common at ffffffff8606674f #4 [ffffb5b9c134bb10] scsi_remove_host at ffffffff85bfe84b #5 [ffffb5b9c134bb30] iscsi_sw_tcp_session_destroy at ffffffffc03031c4 [iscsi_tcp] #6 [ffffb5b9c134bb48] iscsi_if_recv_msg at ffffffffc0292692 [scsi_transport_iscsi] #7 [ffffb5b9c134bb98] iscsi_if_rx at ffffffffc02929c2 [scsi_transport_iscsi] #8 [ffffb5b9c134bbf0] netlink_unicast at ffffffff85e551d6 #9 [ffffb5b9c134bc38] netlink_sendmsg at ffffffff85e554ef", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23356", "url": "https://ubuntu.com/security/CVE-2026-23356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: fix \"LOGIC BUG\" in drbd_al_begin_io_nonblock() Even though we check that we \"should\" be able to do lc_get_cumulative() while holding the device->al_lock spinlock, it may still fail, if some other code path decided to do lc_try_lock() with bad timing. If that happened, we logged \"LOGIC BUG for enr=...\", but still did not return an error. The rest of the code now assumed that this request has references for the relevant activity log extents. The implcations are that during an active resync, mutual exclusivity of resync versus application IO is not guaranteed. And a potential crash at this point may not realizs that these extents could have been target of in-flight IO and would need to be resynced just in case. Also, once the request completes, it will give up activity log references it does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put(). Fix: Do not crash the kernel for a condition that is harmless during normal operation: also catch \"e->refcnt == 0\", not only \"e == NULL\" when being noisy about \"al_complete_io() called on inactive extent %u\\n\". And do not try to be smart and \"guess\" whether something will work, then be surprised when it does not. Deal with the fact that it may or may not work. If it does not, remember a possible \"partially in activity log\" state (only possible for requests that cross extent boundaries), and return an error code from drbd_al_begin_io_nonblock(). A latter call for the same request will then resume from where we left off.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23388", "url": "https://ubuntu.com/security/CVE-2026-23388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check metadata block offset is within range Syzkaller reports a \"general protection fault in squashfs_copy_data\" This is ultimately caused by a corrupted index look-up table, which produces a negative metadata block offset. This is subsequently passed to squashfs_copy_data (via squashfs_read_metadata) where the negative offset causes an out of bounds access. The fix is to check that the offset is within range in squashfs_read_metadata. This will trap this and other cases.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23379", "url": "https://ubuntu.com/security/CVE-2026-23379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: fix divide by zero in the offload path Offloading ETS requires computing each class' WRR weight: this is done by averaging over the sums of quanta as 'q_sum' and 'q_psum'. Using unsigned int, the same integer size as the individual DRR quanta, can overflow and even cause division by zero, like it happened in the following splat: Oops: divide error: 0000 [#1] SMP PTI CPU: 13 UID: 0 PID: 487 Comm: tc Tainted: G E 6.19.0-virtme #45 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Call Trace: ets_qdisc_change+0x870/0xf40 [sch_ets] qdisc_create+0x12b/0x540 tc_modify_qdisc+0x6d7/0xbd0 rtnetlink_rcv_msg+0x168/0x6b0 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x1d6/0x2b0 netlink_sendmsg+0x22e/0x470 ____sys_sendmsg+0x38a/0x3c0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x111/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f440b81c77e Code: 4d 89 d8 e8 d4 bc 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff951e4c10 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000481820 RCX: 00007f440b81c77e RDX: 0000000000000000 RSI: 00007fff951e4cd0 RDI: 0000000000000003 RBP: 00007fff951e4c20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff951f4fa8 R13: 00000000699ddede R14: 00007f440bb01000 R15: 0000000000486980 Modules linked in: sch_ets(E) netdevsim(E) ---[ end trace 0000000000000000 ]--- RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]--- Fix this using 64-bit integers for 'q_sum' and 'q_psum'.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23289", "url": "https://ubuntu.com/security/CVE-2026-23289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq() Fix a user triggerable leak on the system call failure path.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23279", "url": "https://ubuntu.com/security/CVE-2026-23279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix NULL pointer dereference in mesh_rx_csa_frame() In mesh_rx_csa_frame(), elems->mesh_chansw_params_ie is dereferenced at lines 1638 and 1642 without a prior NULL check: ifmsh->chsw_ttl = elems->mesh_chansw_params_ie->mesh_ttl; ... pre_value = le16_to_cpu(elems->mesh_chansw_params_ie->mesh_pre_value); The mesh_matches_local() check above only validates the Mesh ID, Mesh Configuration, and Supported Rates IEs. It does not verify the presence of the Mesh Channel Switch Parameters IE (element ID 118). When a received CSA action frame omits that IE, ieee802_11_parse_elems() leaves elems->mesh_chansw_params_ie as NULL, and the unconditional dereference causes a kernel NULL pointer dereference. A remote mesh peer with an established peer link (PLINK_ESTAB) can trigger this by sending a crafted SPECTRUM_MGMT/CHL_SWITCH action frame that includes a matching Mesh ID and Mesh Configuration IE but omits the Mesh Channel Switch Parameters IE. No authentication beyond the default open mesh peering is required. Crash confirmed on kernel 6.17.0-5-generic via mac80211_hwsim: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:ieee80211_mesh_rx_queued_mgmt+0x143/0x2a0 [mac80211] CR2: 0000000000000000 Fix by adding a NULL check for mesh_chansw_params_ie after mesh_matches_local() returns, consistent with how other optional IEs are guarded throughout the mesh code. The bug has been present since v3.13 (released 2014-01-19).", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23367", "url": "https://ubuntu.com/security/CVE-2026-23367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: radiotap: reject radiotap with unknown bits The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator->_next_ns_data isn't initialized (it's only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value. Fix this by moving the rejection of unknown radiotap fields down to after the in-namespace lookup, so it will really use iterator->_next_ns_data only for vendor namespaces, even in case undefined fields are present.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23318", "url": "https://ubuntu.com/security/CVE-2026-23318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Use correct version for UAC3 header validation The entry of the validators table for UAC3 AC header descriptor is defined with the wrong protocol version UAC_VERSION_2, while it should have been UAC_VERSION_3. This results in the validator never matching for actual UAC3 devices (protocol == UAC_VERSION_3), causing their header descriptors to bypass validation entirely. A malicious USB device presenting a truncated UAC3 header could exploit this to cause out-of-bounds reads when the driver later accesses unvalidated descriptor fields. The bug was introduced in the same commit as the recently fixed UAC3 feature unit sub-type typo, and appears to be from the same copy-paste error when the UAC3 section was created from the UAC2 section.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23370", "url": "https://ubuntu.com/security/CVE-2026-23370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data set_new_password() hex dumps the entire buffer, which contains plaintext password data, including current and new passwords. Remove the hex dump to avoid leaking credentials.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23352", "url": "https://ubuntu.com/security/CVE-2026-23352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/efi: defer freeing of boot services memory efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late(). There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area(). More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete. Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM. If the freed memory resides in the areas that memory map for them is still uninitialized, they won't be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages. Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map. Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that's undesirable late in boot when there is concurrency. More robust approach is to only defer freeing of the EFI boot services memory. Split efi_free_boot_services() in two. First efi_unmap_boot_services() collects ranges that should be freed into an array then efi_free_boot_services() later frees them after deferred init is complete.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23382", "url": "https://ubuntu.com/security/CVE-2026-23382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them In commit 2ff5baa9b527 (\"HID: appleir: Fix potential NULL dereference at raw event handle\"), we handle the fact that raw event callbacks can happen even for a HID device that has not been \"claimed\" causing a crash if a broken device were attempted to be connected to the system. Fix up the remaining in-tree HID drivers that forgot to add this same check to resolve the same issue.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23324", "url": "https://ubuntu.com/security/CVE-2026-23324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: usb: etas_es58x: correctly anchor the urb in the read bulk callback When submitting an urb, that is using the anchor pattern, it needs to be anchored before submitting it otherwise it could be leaked if usb_kill_anchored_urbs() is called. This logic is correctly done elsewhere in the driver, except in the read bulk callback so do that here also.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23298", "url": "https://ubuntu.com/security/CVE-2026-23298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ucan: Fix infinite loop from zero-length messages If a broken ucan device gets a message with the message length field set to 0, then the driver will loop for forever in ucan_read_bulk_callback(), hanging the system. If the length is 0, just skip the message and go on to the next one. This has been fixed in the kvaser_usb driver in the past in commit 0c73772cd2b8 (\"can: kvaser_usb: leaf: Fix potential infinite loop in command parsers\"), so there must be some broken devices out there like this somewhere.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23307", "url": "https://ubuntu.com/security/CVE-2026-23307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a message When looking at the data in a USB urb, the actual_length is the size of the buffer passed to the driver, not the transfer_buffer_length which is set by the driver as the max size of the buffer. When parsing the messages in ems_usb_read_bulk_callback() properly check the size both at the beginning of parsing the message to make sure it is big enough for the expected structure, and at the end of the message to make sure we don't overflow past the end of the buffer for the next message.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23290", "url": "https://ubuntu.com/security/CVE-2026-23290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: validate USB endpoints The pegasus driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23365", "url": "https://ubuntu.com/security/CVE-2026-23365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kalmia: validate USB endpoints The kalmia driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23312", "url": "https://ubuntu.com/security/CVE-2026-23312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: validate USB endpoints The kaweth driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23291", "url": "https://ubuntu.com/security/CVE-2026-23291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: properly drop the usb interface reference on disconnect When the device is disconnected from the driver, there is a \"dangling\" reference count on the usb interface that was grabbed in the probe callback. Fix this up by properly dropping the reference after we are done with it.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23253", "url": "https://ubuntu.com/security/CVE-2026-23253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: fix wrong reinitialization of ringbuffer on reopen dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock.", "cve_priority": "high", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-43123", "url": "https://ubuntu.com/security/CVE-2026-43123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: check return value of con2fb_acquire_newinfo() If fbcon_open() fails when called from con2fb_acquire_newinfo() then info->fbcon_par pointer remains NULL which is later dereferenced. Add check for return value of the function con2fb_acquire_newinfo() to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23220", "url": "https://ubuntu.com/security/CVE-2026-23220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error paths The problem occurs when a signed request fails smb2 signature verification check. In __process_request(), if check_sign_req() returns an error, set_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called. set_smb2_rsp_status() set work->next_smb2_rcv_hdr_off as zero. By resetting next_smb2_rcv_hdr_off to zero, the pointer to the next command in the chain is lost. Consequently, is_chained_smb2_message() continues to point to the same request header instead of advancing. If the header's NextCommand field is non-zero, the function returns true, causing __handle_ksmbd_work() to repeatedly process the same failed request in an infinite loop. This results in the kernel log being flooded with \"bad smb2 signature\" messages and high CPU usage. This patch fixes the issue by changing the return value from SERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures that the processing loop terminates immediately rather than attempting to continue from an invalidated offset.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-45911", "url": "https://ubuntu.com/security/CVE-2026-45911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix role switching during resume If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference. The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped. So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usb_hcd_is_primary_hcd+0x0/0x1c lr : cdns_host_resume+0x24/0x5c ... Call trace: usb_hcd_is_primary_hcd+0x0/0x1c (P) cdns_resume+0x6c/0xbc cdns3_controller_resume.isra.0+0xe8/0x17c cdns3_plat_resume+0x18/0x24 platform_pm_resume+0x2c/0x68 dpm_run_callback+0x90/0x248 device_resume+0x100/0x24c dpm_resume+0x190/0x2ec dpm_resume_end+0x18/0x34 suspend_devices_and_enter+0x2b0/0xa44 pm_suspend+0x16c/0x5fc state_store+0x80/0xec kobj_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x130/0x1dc vfs_write+0x240/0x370 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0x108 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-71287", "url": "https://ubuntu.com/security/CVE-2025-71287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memory: mtk-smi: fix device leak on larb probe Make sure to drop the reference taken when looking up the SMI device during larb probe on late probe failure (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23359", "url": "https://ubuntu.com/security/CVE-2026-23359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stack-out-of-bounds write in devmap get_upper_ifindexes() iterates over all upper devices and writes their indices into an array without checking bounds. Also the callers assume that the max number of upper devices is MAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack, but that assumption is not correct and the number of upper devices could be larger than MAX_NEST_DEV (e.g., many macvlans), causing a stack-out-of-bounds write. Add a max parameter to get_upper_ifindexes() to avoid the issue. When there are too many upper devices, return -EOVERFLOW and abort the redirect. To reproduce, create more than MAX_NEST_DEV(8) macvlans on a device with an XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS. Then send a packet to the device to trigger the XDP redirect path.", "cve_priority": "low", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43291", "url": "https://ubuntu.com/security/CVE-2026-43291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: nfc: nci: Fix parameter validation for packet data Since commit 9c328f54741b (\"net: nfc: nci: Add parameter validation for packet data\") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct).", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43283", "url": "https://ubuntu.com/security/CVE-2026-43283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle dma_free_coherent() in error path takes priv->rx_buf.alloc_len as the dma handle. This would lead to improper unmapping of the buffer. Change the dma handle to priv->rx_buf.alloc_phys.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43264", "url": "https://ubuntu.com/security/CVE-2026-43264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: of: display_timing: fix refcount leak in of_get_display_timings() of_parse_phandle() returns a device_node with refcount incremented, which is stored in 'entry' and then copied to 'native_mode'. When the error paths at lines 184 or 192 jump to 'entryfail', native_mode's refcount is not decremented, causing a refcount leak. Fix this by changing the goto target from 'entryfail' to 'timingfail', which properly calls of_node_put(native_mode) before cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43202", "url": "https://ubuntu.com/security/CVE-2026-43202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: vt8500lcdfb: fix missing dma_free_coherent() fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not freed if the error path is reached.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43203", "url": "https://ubuntu.com/security/CVE-2026-43203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: fore200e: fix use-after-free in tasklets during device removal When the PCA-200E or SBA-200E adapter is being detached, the fore200e is deallocated. However, the tx_tasklet or rx_tasklet may still be running or pending, leading to use-after-free bug when the already freed fore200e is accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet(). One of the race conditions can occur as follows: CPU 0 (cleanup) | CPU 1 (tasklet) fore200e_pca_remove_one() | fore200e_interrupt() fore200e_shutdown() | tasklet_schedule() kfree(fore200e) | fore200e_tx_tasklet() | fore200e-> // UAF Fix this by ensuring tx_tasklet or rx_tasklet is properly canceled before the fore200e is released. Add tasklet_kill() in fore200e_shutdown() to synchronize with any pending or running tasklets. Moreover, since fore200e_reset() could prevent further interrupts or data transfers, the tasklet_kill() should be placed after fore200e_reset() to prevent the tasklet from being rescheduled in fore200e_interrupt(). Finally, it only needs to do tasklet_kill() when the fore200e state is greater than or equal to FORE200E_STATE_IRQ, since tasklets are uninitialized in earlier states. In a word, the tasklet_kill() should be placed in the FORE200E_STATE_IRQ branch within the switch...case structure. This bug was identified through static analysis.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43149", "url": "https://ubuntu.com/security/CVE-2026-43149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean() The priv->rx_buffer and priv->tx_buffer are alloc'd together as contiguous buffers in uhdlc_init() but freed as two buffers in uhdlc_memclean(). Change the cleanup to only call dma_free_coherent() once on the whole buffer.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43273", "url": "https://ubuntu.com/security/CVE-2026-43273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: supply snapshot context in ceph_zero_partial_object() The ceph_zero_partial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.conf dd if=/dev/urandom of=/mnt/mycephfs/foo bs=64K count=1 mkdir /mnt/mycephfs/.snap/snap1 md5sum /mnt/mycephfs/.snap/snap1/foo fallocate -p -o 0 -l 4096 /mnt/mycephfs/foo echo 3 > /proc/sys/vm/drop/caches md5sum /mnt/mycephfs/.snap/snap1/foo # get different md5sum!!", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43159", "url": "https://ubuntu.com/security/CVE-2026-43159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix null dereference in find_network The variable pwlan has the possibility of being NULL when passed into rtw_free_network_nolock() which would later dereference the variable.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43211", "url": "https://ubuntu.com/security/CVE-2026-43211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: Fix pci_slot_trylock() error handling Commit a4e772898f8b (\"PCI: Add missing bridge lock to pci_bus_lock()\") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails. Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } } After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug. This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread. Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path. [Same patch later posted by Keith at https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com]", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43206", "url": "https://ubuntu.com/security/CVE-2026-43206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8 bytes via memset without checking the buffer size parameter. This allows unprivileged userspace to trigger an out-of bounds kernel memory write by passing a small buffer, leading to potential privilege escalation.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43275", "url": "https://ubuntu.com/security/CVE-2026-43275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Flush exception handling work when RPM level is zero Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0. When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race condition where the driver could attempt to access the host controller to handle an exception after the system had already entered a deep power-down state, resulting in a system crash. Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete and prevents illegal hardware access during the power-down sequence.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43145", "url": "https://ubuntu.com/security/CVE-2026-43145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_rproc: Fix invalid loaded resource table detection imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded resource table even when the current firmware does not provide one. When the device tree contains a \"rsc-table\" entry, priv->rsc_table is non-NULL and denotes where a resource table would be located if one is present in memory. However, when the current firmware has no resource table, rproc->table_ptr is NULL. The function still returns priv->rsc_table, and the remoteproc core interprets this as a valid loaded resource table. Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when there is no resource table for the current firmware (i.e. when rproc->table_ptr is NULL). This aligns the function's semantics with the remoteproc core: a loaded resource table is only reported when a valid table_ptr exists. With this change, starting firmware without a resource table no longer triggers a crash.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43147", "url": "https://ubuntu.com/security/CVE-2026-43147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV\" This reverts commit 05703271c3cd (\"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV\"), which causes a deadlock by recursively taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of pci_stop_and_remove_bus_device(). For example with the following sequence of commands: $ echo > /sys/bus/pci/devices//sriov_numvfs $ echo 1 > /sys/bus/pci/devices//remove A trimmed trace of the deadlock on a mlx5 device is as below: zsh/5715 is trying to acquire lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140 but task is already holding lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110 [<00000259779c844e>] print_deadlock_bug+0x31e/0x330 [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0 [<00000259779bffac>] lock_acquire+0x14c/0x350 [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520 [<000002597896413c>] mutex_lock_nested+0x3c/0x50 [<00000259784a07e4>] sriov_disable+0x34/0x140 [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core] [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core] [<00000259784857fc>] pci_device_remove+0x3c/0xa0 [<000002597851012e>] device_release_driver_internal+0x18e/0x280 [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0 [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80 [<00000259784972c2>] remove_store+0x72/0x90 [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200 [<0000025977d7241c>] vfs_write+0x24c/0x300 [<0000025977d72696>] ksys_write+0x86/0x110 [<000002597895b61c>] __do_syscall+0x14c/0x400 [<000002597896e0ee>] system_call+0x6e/0x90 This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43289", "url": "https://ubuntu.com/security/CVE-2026-43289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kexec: derive purgatory entry from symbol kexec_load_purgatory() derives image->start by locating e_entry inside an SHF_EXECINSTR section. If the purgatory object contains multiple executable sections with overlapping sh_addr, the entrypoint check can match more than once and trigger a WARN. Derive the entry section from the purgatory_start symbol when present and compute image->start from its final placement. Keep the existing e_entry fallback for purgatories that do not expose the symbol. WARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784 Call Trace: bzImage64_load+0x133/0xa00 __do_sys_kexec_file_load+0x2b3/0x5c0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e [me@linux.beauty: move helper to avoid forward declaration, per Baoquan]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43168", "url": "https://ubuntu.com/security/CVE-2026-43168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix reflink preserve cleanup issue commit c06c303832ec (\"ocfs2: fix xattr array entry __counted_by error\") doesn't handle all cases and the cleanup job for preserved xattr entries still has bug: - the 'last' pointer should be shifted by one unit after cleanup an array entry. - current code logic doesn't cleanup the first entry when xh_count is 1. Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43295", "url": "https://ubuntu.com/security/CVE-2026-43295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net() When idtab allocation fails, net is not registered with rio_add_net() yet, so kfree(net) is sufficient to release the memory. Set mport->net to NULL to avoid dangling pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43148", "url": "https://ubuntu.com/security/CVE-2026-43148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/smp: Add check for kcalloc() failure in parse_thread_groups() As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing it to of_property_read_u32_array().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43163", "url": "https://ubuntu.com/security/CVE-2026-43163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/bitmap: fix GPF in write_page caused by resize race A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod] This is a use-after-free race between bitmap_daemon_work() and __bitmap_resize(). The daemon iterates over `bitmap->storage.filemap` without locking, while the resize path frees that storage via md_bitmap_file_unmap(). `quiesce()` does not stop the md thread, allowing concurrent access to freed pages. Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43200", "url": "https://ubuntu.com/security/CVE-2026-43200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functions struct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target); While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specify the parameters in the correct order, pci_primary_epc_epf_unlink() and pci_secondary_epc_epf_unlink() specify the parameters in the wrong order, leading to the below kernel crash when using the unlink command in configfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0 [mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43158", "url": "https://ubuntu.com/security/CVE-2026-43158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix freemap adjustments when adding xattrs to leaf blocks xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) \t\t\t\t\t+ xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where \"rhs\" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 (\"xfs: fix attr leaf header freemap.size underflow\") and the previous patch that resets zero length freemap entries to have base = 0.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43187", "url": "https://ubuntu.com/security/CVE-2026-43187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: delete attr leaf freemap entries when empty Back in commit 2a2b5932db6758 (\"xfs: fix attr leaf header freemap.size underflow\"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the \"pushed-up\" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43130", "url": "https://ubuntu.com/security/CVE-2026-43130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode Commit 4fc82cd907ac (\"iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected\") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system. For example, if a VM fails to connect to the PCIe device, \"virsh destroy\" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd. Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput Although pci_device_is_present() is slower than pci_dev_is_disconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase. Besides, devtlb_invalidation_with_pasid() is called only in the paths below, which are far less frequent than memory map/unmap. 1. mm-struct release 2. {attach,release}_dev 3. set/remove PASID 4. dirty-tracking setup The gain in system stability far outweighs the negligible cost of using pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43133", "url": "https://ubuntu.com/security/CVE-2026-43133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation Commit cc3ed80ae69f (\"KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state\") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01. As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43196", "url": "https://ubuntu.com/security/CVE-2026-43196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: ti: pruss: Fix double free in pruss_clk_mux_setup() In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectly calls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np) on the error path. However, after the devm_add_action_or_reset() returns, the of_node_put(clk_mux_np) is called again, causing a double free. Fix by returning directly, to avoid the duplicate of_node_put().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43242", "url": "https://ubuntu.com/security/CVE-2026-43242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: ti: k3-socinfo: Fix regmap leak on probe failure The mmio regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43278", "url": "https://ubuntu.com/security/CVE-2026-43278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: clear cloned request bio pointer when last clone bio completes Stale rq->bio values have been observed to cause double-initialization of cloned bios in request-based device-mapper targets, leading to use-after-free and double-free scenarios. One such case occurs when using dm-multipath on top of a PCIe NVMe namespace, where cloned request bios are freed during blk_complete_request(), but rq->bio is left intact. Subsequent clone teardown then attempts to free the same bios again via blk_rq_unprep_clone(). The resulting double-free path looks like: nvme_pci_complete_batch() nvme_complete_batch() blk_mq_end_request_batch() blk_complete_request() // called on a DM clone request bio_endio() // first free of all clone bios ... rq->end_io() // end_clone_request() dm_complete_request(tio->orig) dm_softirq_done() dm_done() dm_end_request() blk_rq_unprep_clone() // second free of clone bios Fix this by clearing the clone request's bio pointer when the last cloned bio completes, ensuring that later teardown paths do not attempt to free already-released bios.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43312", "url": "https://ubuntu.com/security/CVE-2026-43312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov5647: Initialize subdev before controls In ov5647_init_controls() we call v4l2_get_subdevdata, but it is initialized by v4l2_i2c_subdev_init() in the probe, which currently happens after init_controls(). This can result in a segfault if the error condition is hit, and we try to access i2c_client, so fix the order.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43182", "url": "https://ubuntu.com/security/CVE-2026-43182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ccs: Avoid possible division by zero Calculating maximum M for scaler configuration involves dividing by MIN_X_OUTPUT_SIZE limit register's value. Albeit the value is presumably non-zero, the driver was missing the check it in fact was. Fix this.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43246", "url": "https://ubuntu.com/security/CVE-2026-43246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c/tw9906: Fix potential memory leak in tw9906_probe() In one of the error paths in tw9906_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43218", "url": "https://ubuntu.com/security/CVE-2026-43218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c/tw9903: Fix potential memory leak in tw9903_probe() In one of the error paths in tw9903_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43135", "url": "https://ubuntu.com/security/CVE-2026-43135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: Add missing unmap in snd_cx23885_hw_params() In error path, add cx23885_alsa_dma_unmap() to release the resource acquired by cx23885_alsa_dma_map().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43257", "url": "https://ubuntu.com/security/CVE-2026-43257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx88: Add missing unmap in snd_cx88_hw_params() In error path, add cx88_alsa_dma_unmap() to release resource acquired by cx88_alsa_dma_map().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43231", "url": "https://ubuntu.com/security/CVE-2026-43231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-keene: fix memory leak in error path Fix a memory leak in usb_keene_probe(). The v4l2 control handler is initialized and controls are added, but if v4l2_device_register() or video_register_device() fails afterward, the handler was never freed, leaking memory. Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensure the control handler is properly freed for all error paths after it is initialized.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43136", "url": "https://ubuntu.com/security/CVE-2026-43136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Check maxfield in hidpp_get_report_length() Do not crash when a report has no fields. Fake USB gadgets can send their own HID report descriptors and can define report structures without valid fields. This can be used to crash the kernel over USB.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43251", "url": "https://ubuntu.com/security/CVE-2026-43251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: prodikeys: Check presence of pm->input_ep82 Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, pm->input_ep82 stays NULL, which leads to a crash later. This does not happen with the real device, but can be provoked by imposing as one.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43140", "url": "https://ubuntu.com/security/CVE-2026-43140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: Do not crash on missing msc->input Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, msc->input stays NULL, leading to a crash at a later time. Detect this condition in the input_configured() hook and reject the device. This is not supposed to happen with actual magic mouse devices, but can be provoked by imposing as a magic mouse USB device.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43152", "url": "https://ubuntu.com/security/CVE-2026-43152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hid-pl: handle probe errors Errors in init must be reported back or we'll follow a NULL pointer the first time FF is used.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43315", "url": "https://ubuntu.com/security/CVE-2026-43315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeeding Drop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failing as it is trivially easy to trigger from userspace by modifying CPUID after loading CR3. E.g. modifying the state restoration selftest like so: --- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main(int argc, char *argv[]) /* Restore state in a new VM. */ vcpu = vm_recreate_with_one_vcpu(vm); - vcpu_load_state(vcpu, state); + + if (stage == 4) { + state->sregs.cr3 = BIT(44); + vcpu_load_state(vcpu, state); + + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36); + __vcpu_nested_state_set(vcpu, &state->nested); + } else { + vcpu_load_state(vcpu, state); + } /* * Restore XSAVE state in a dummy vCPU, first without doing generates: WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd] Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm] CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd] Call Trace: kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm] kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Simply delete the WARN instead of trying to prevent userspace from shoving \"illegal\" state into CR3. For better or worse, KVM's ABI allows userspace to set CPUID after SREGS, and vice versa, and KVM is very permissive when it comes to guest CPUID. I.e. attempting to enforce the virtual CPU model when setting CPUID could break userspace. Given that the WARN doesn't provide any meaningful protection for KVM or benefit for userspace, simply drop it even though the odds of breaking userspace are minuscule. Opportunistically delete a spurious newline.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43270", "url": "https://ubuntu.com/security/CVE-2026-43270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove() In mtk_mdp_probe(), vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43207", "url": "https://ubuntu.com/security/CVE-2026-43207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix error handling in probe function Add mtk_mdp_unregister_m2m_device() on the error handling path to prevent resource leak. Add check for the return value of vpu_get_plat_device() to prevent null pointer dereference. And vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43132", "url": "https://ubuntu.com/security/CVE-2026-43132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: correctly handle dm_bufio_client_create() failure If either of the calls to dm_bufio_client_create() in verity_fec_ctr() fails, then dm_bufio_client_destroy() is later called with an ERR_PTR() argument. That causes a crash. Fix this.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2025-71274", "url": "https://ubuntu.com/security/CVE-2025-71274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: core: fix race in driver_override_show() and use core helper The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string_attr macro with explicit show and store functions. The new driver_override_store uses the standard driver_set_override helper. Since the introduction of driver_set_override, the comments in include/linux/rpmsg.h have stated that this helper must be used to set or clear driver_override, but the implementation was not updated until now. Because driver_set_override modifies and frees the string while holding the device_lock, the new driver_override_show now correctly holds the device_lock during the read operation to prevent the race. Additionally, since rpmsg_string_attr has only ever been used for driver_override, removing the macro simplifies the code.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43233", "url": "https://ubuntu.com/security/CVE-2026-43233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: fix OOB read in decode_choice() In decode_choice(), the boundary check before get_len() uses the variable `len`, which is still 0 from its initialization at the top of the function: unsigned int type, ext, len = 0; ... if (ext || (son->attr & OPEN)) { BYTE_ALIGN(bs); if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */ return H323_ERROR_BOUND; len = get_len(bs); /* OOB read */ When the bitstream is exactly consumed (bs->cur == bs->end), the check nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent get_len() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well. This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nf_conntrack_h323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer. Fix this by checking for 2 bytes (the maximum that get_len() may read) instead of the uninitialized `len`. This matches the pattern used at every other get_len() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43205", "url": "https://ubuntu.com/security/CVE-2026-43205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: validate num_ifs to prevent out-of-bounds write The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes() but never validates it against DPSW_MAX_IF (64). This value controls iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices into the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reports num_ifs >= 64, the loop can write past the array bounds. Add a bound check for num_ifs in dpaa2_switch_init(). dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all ports match the flood filter, the loop fills all 64 slots and the control interface write overflows by one entry. The check uses >= because num_ifs == DPSW_MAX_IF is also functionally broken. build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ...", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43194", "url": "https://ubuntu.com/security/CVE-2026-43194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: consume xmit errors of GSO frames udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min. These tests use veth to simulate GRO. They attach a trivial (\"return XDP_PASS;\") XDP program to the veth to force TSO off and NAPI on. Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]). In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck. The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok | ok ok ok \\\\ \t\t\t snd_nxt \"x\" means packet lost by veth, and \"ok\" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent. So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above). Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely. We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-\"networks\" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix? Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link).", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43156", "url": "https://ubuntu.com/security/CVE-2026-43156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: enable basic endpoint checking pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors: - usb_rcvbulkpipe(dev, 1) for RX data - usb_sndbulkpipe(dev, 2) for TX data - usb_rcvintpipe(dev, 3) for status interrupts A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes. Add a pegasus_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion. Similar fix to - commit 90b7f2961798 (\"net: usb: rtl8150: enable basic endpoint checking\") - commit 9e7021d2aeae (\"net: usb: catc: enable basic endpoint checking\")", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43232", "url": "https://ubuntu.com/security/CVE-2026-43232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets When the FarSync T-series card is being detached, the fst_card_info is deallocated in fst_remove_one(). However, the fst_tx_task or fst_int_task may still be running or pending, leading to use-after-free bugs when the already freed fst_card_info is accessed in fst_process_tx_work_q() or fst_process_int_work_q(). A typical race condition is depicted below: CPU 0 (cleanup) | CPU 1 (tasklet) | fst_start_xmit() fst_remove_one() | tasklet_schedule() unregister_hdlc_device()| | fst_process_tx_work_q() //handler kfree(card) //free | do_bottom_half_tx() | card-> //use The following KASAN trace was captured: ================================================================== BUG: KASAN: slab-use-after-free in do_bottom_half_tx+0xb88/0xd00 Read of size 4 at addr ffff88800aad101c by task ksoftirqd/3/32 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcb/0x5d0 ? do_bottom_half_tx+0xb88/0xd00 kasan_report+0xb8/0xf0 ? do_bottom_half_tx+0xb88/0xd00 do_bottom_half_tx+0xb88/0xd00 ? _raw_spin_lock_irqsave+0x85/0xe0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx___hrtimer_run_queues+0x10/0x10 fst_process_tx_work_q+0x67/0x90 tasklet_action_common+0x1fa/0x720 ? hrtimer_interrupt+0x31f/0x780 handle_softirqs+0x176/0x530 __irq_exit_rcu+0xab/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 41 on cpu 3 at 72.330843s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 __kasan_kmalloc+0x7f/0x90 fst_add_one+0x1a5/0x1cd0 local_pci_probe+0xdd/0x190 pci_device_probe+0x341/0x480 really_probe+0x1c6/0x6a0 __driver_probe_device+0x248/0x310 driver_probe_device+0x48/0x210 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x101/0x190 __device_attach+0x198/0x3a0 device_initial_probe+0x78/0xa0 pci_bus_add_device+0x81/0xc0 pci_bus_add_devices+0x7e/0x190 enable_slot+0x9b9/0x1130 acpiphp_check_bridge.part.0+0x2e1/0x460 acpiphp_hotplug_notify+0x36c/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... Freed by task 41 on cpu 1 at 75.138639s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x135/0x410 fst_remove_one+0x2ca/0x540 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0x364/0x530 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device+0xd/0x20 disable_slot+0x116/0x260 acpiphp_disable_and_eject_slot+0x4b/0x190 acpiphp_hotplug_notify+0x230/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... The buggy address belongs to the object at ffff88800aad1000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 28 bytes inside of freed 1024-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xaad0 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x100000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000003 ffffea00002ab401 00000000ffffffff 00000000ffffffff head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88800aad0f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800aad0f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800aad1000: fa fb ---truncated---", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43134", "url": "https://ubuntu.com/security/CVE-2026-43134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ This adds a check for encryption key size upon receiving L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAP_CR_LE_BAD_KEY_SIZE.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43180", "url": "https://ubuntu.com/security/CVE-2026-43180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls netif_stop_queue() and netif_wake_queue(). These are TX queue flow control functions unrelated to RX multicast configuration. The premature netif_wake_queue() can re-enable TX while tx_urb is still in-flight, leading to a double usb_submit_urb() on the same URB: kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); } kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done } kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active } This triggers the WARN in usb_submit_urb(): \"URB submitted while active\" This is a similar class of bug fixed in rtl8150 by - commit 958baf5eaee3 (\"net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast\"). Also kaweth_set_rx_mode() is already functionally broken, the real set_rx_mode action is performed by kaweth_async_set_rx_mode(), which in turn is not a no-op only at ndo_open() time.", "cve_priority": "low", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43139", "url": "https://ubuntu.com/security/CVE-2026-43139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix uninitialized saddr in xfrm6_get_saddr() xfrm6_get_saddr() does not check the return value of ipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6_get_saddr() still returns 0 (success). This causes the caller xfrm_tmpl_resolve_one() to use the uninitialized address in xfrm_state_find(), triggering KMSAN warning: ===================================================== BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940 xfrm_state_find+0x2424/0xa940 xfrm_resolve_and_create_bundle+0x906/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 xfrm_lookup_route+0x63/0x2b0 ip_route_output_flow+0x1ce/0x270 udp_sendmsg+0x2ce1/0x3400 inet_sendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64_sys_sendto+0x130/0x200 x64_sys_call+0x332b/0x3e70 do_syscall_64+0xd3/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable tmp.i.i created at: xfrm_resolve_and_create_bundle+0x3e3/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 ===================================================== Fix by checking the return value of ipv6_dev_get_saddr() and propagating the error.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43141", "url": "https://ubuntu.com/security/CVE-2026-43141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut Number of MW LUTs depends on NTB configuration and can be set to zero, in such scenario rounddown_pow_of_two will cause undefined behaviour and should not be performed. This patch ensures that rounddown_pow_of_two is called on valid value.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43241", "url": "https://ubuntu.com/security/CVE-2026-43241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access Number of MW LUTs depends on NTB configuration and can be set to MAX_MWS, This patch protects against invalid index out of bounds access to mw_sizes When invalid access print message to user that configuration is not valid.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43279", "url": "https://ubuntu.com/security/CVE-2026-43279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Add sanity check for OOB writes at silencing At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2025-71267", "url": "https://ubuntu.com/security/CVE-2025-71267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an ATTR_LIST attribute indicates a zero data size while the driver allocates memory for it. When ntfs_load_attr_list() processes a resident ATTR_LIST with data_size set to zero, it still allocates memory because of al_aligned(0). This creates an inconsistent state where ni->attr_list.size is zero, but ni->attr_list.le is non-null. This causes ni_enum_attr_ex to incorrectly assume that no attribute list exists and enumerates only the primary MFT record. When it finds ATTR_LIST, the code reloads it and restarts the enumeration, repeating indefinitely. The mount operation never completes, hanging the kernel thread. This patch adds validation to ensure that data_size is non-zero before memory allocation. When a zero-sized ATTR_LIST is detected, the function returns -EINVAL, preventing a DoS vulnerability.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2025-71265", "url": "https://ubuntu.com/security/CVE-2025-71265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an attribute header indicates an empty run list, while directory entries reference it as containing actual data. In NTFS, setting evcn=-1 with svcn=0 is a valid way to represent an empty run list, and run_unpack() correctly handles this by checking if evcn + 1 equals svcn and returning early without parsing any run data. However, this creates a problem when there is metadata inconsistency, where the attribute header claims to be empty (evcn=-1) but the caller expects to read actual data. When run_unpack() immediately returns success upon seeing this condition, it leaves the runs_tree uninitialized with run->runs as a NULL. The calling function attr_load_runs_range() assumes that a successful return means that the runs were loaded and sets clen to 0, expecting the next run_lookup_entry() call to succeed. Because runs_tree remains uninitialized, run_lookup_entry() continues to fail, and the loop increments vcn by zero (vcn += 0), leading to an infinite loop. This patch adds a retry counter to detect when run_lookup_entry() fails consecutively after attr_load_runs_vcn(). If the run is still not found on the second attempt, it indicates corrupted metadata and returns -EINVAL, preventing the Denial-of-Service (DoS) vulnerability.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2025-71266", "url": "https://ubuntu.com/security/CVE-2025-71266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: check return value of indx_find to avoid infinite loop We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed dentry in the ntfs3 filesystem can cause the kernel to hang during the lookup operations. By setting the HAS_SUB_NODE flag in an INDEX_ENTRY within a directory's INDEX_ALLOCATION block and manipulating the VCN pointer, an attacker can cause the indx_find() function to repeatedly read the same block, allocating 4 KB of memory each time. The kernel lacks VCN loop detection and depth limits, causing memory exhaustion and an OOM crash. This patch adds a return value check for fnd_push() to prevent a memory exhaustion vulnerability caused by infinite loops. When the index exceeds the size of the fnd->nodes array, fnd_push() returns -EINVAL. The indx_find() function checks this return value and stops processing, preventing further memory allocation.", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-43225", "url": "https://ubuntu.com/security/CVE-2026-43225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix memory leak on failure path cfg80211_inform_bss_frame() may return NULL on failure. In that case, the allocated buffer 'buf' is not freed and the function returns early, leading to potential memory leak. Fix this by ensuring that 'buf' is freed on both success and failure paths.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43230", "url": "https://ubuntu.com/security/CVE-2026-43230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: Clear reconnect pending bit When canceling the reconnect worker, care must be taken to reset the reconnect-pending bit. If the reconnect worker has not yet been scheduled before it is canceled, the reconnect-pending bit will stay on forever.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43296", "url": "https://ubuntu.com/security/CVE-2026-43296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Workaround SQM/PSE stalls by disabling sticky NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated. work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21) These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43226", "url": "https://ubuntu.com/security/CVE-2026-43226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: No shortcut out of RDS_CONN_ERROR RDS connections carry a state \"rds_conn_path::cp_state\" and transitions from one state to another and are conditional upon an expected state: \"rds_conn_path_transition.\" There is one exception to this conditionality, which is \"RDS_CONN_ERROR\" that can be enforced by \"rds_conn_path_drop\" regardless of what state the condition is currently in. But as soon as a connection enters state \"RDS_CONN_ERROR\", the connection handling code expects it to go through the shutdown-path. The RDS/TCP multipath changes added a shortcut out of \"RDS_CONN_ERROR\" straight back to \"RDS_CONN_CONNECTING\" via \"rds_tcp_accept_one_path\" (e.g. after \"rds_tcp_state_change\"). A subsequent \"rds_tcp_reset_callbacks\" can then transition the state to \"RDS_CONN_RESETTING\" with a shutdown-worker queued. That'll trip up \"rds_conn_init_shutdown\", which was never adjusted to handle \"RDS_CONN_RESETTING\" and subsequently drops the connection with the dreaded \"DR_INV_CONN_STATE\", which leaves \"RDS_SHUTDOWN_WORK_QUEUED\" on forever. So we do two things here: a) Don't shortcut \"RDS_CONN_ERROR\", but take the longer path through the shutdown code. b) Add \"RDS_CONN_RESETTING\" to the expected states in \"rds_conn_init_shutdown\" so that we won't error out and get stuck, if we ever hit weird state transitions like this again.\"", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43190", "url": "https://ubuntu.com/security/CVE-2026-43190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_tcpmss: check remaining length before reading optlen Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload).", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43255", "url": "https://ubuntu.com/security/CVE-2026-43255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix WARNING in usb_tx_block The function usb_tx_block() submits cardp->tx_urb without ensuring that any previous transmission on this URB has completed. If a second call occurs while the URB is still active (e.g. during rapid firmware loading), usb_submit_urb() detects the active state and triggers a warning: 'URB submitted while active'. Fix this by enforcing serialization: call usb_kill_urb() before submitting the new request. This ensures the URB is idle and safe to reuse.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43314", "url": "https://ubuntu.com/security/CVE-2026-43314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: remove fake timeout to avoid leak request Since commit 15f73f5b3e59 (\"blk-mq: move failure injection out of blk_mq_complete_request\"), drivers are responsible for calling blk_should_fake_timeout() at appropriate code paths and opportunities. However, the dm driver does not implement its own timeout handler and relies on the timeout handling of its slave devices. If an io-timeout-fail error is injected to a dm device, the request will be leaked and never completed, causing tasks to hang indefinitely. Reproduce: 1. prepare dm which has iscsi slave device 2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times 3. read/write dm 4. iscsiadm -m node -u Result: hang task like below [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds. [ 862.244133] Tainted: G E 6.19.0-rc1+ #51 [ 862.244337] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000 [ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi] [ 862.245264] Call Trace: [ 862.245587] [ 862.245814] __schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120 [ 862.247688] elevator_change+0x16d/0x460 [ 862.247893] elevator_set_none+0x87/0xf0 [ 862.248798] blk_unregister_queue+0x12e/0x2a0 [ 862.248995] __del_gendisk+0x231/0x7e0 [ 862.250143] del_gendisk+0x12f/0x1d0 [ 862.250339] sd_remove+0x85/0x130 [sd_mod] [ 862.250650] device_release_driver_internal+0x36d/0x530 [ 862.250849] bus_remove_device+0x1dd/0x3f0 [ 862.251042] device_del+0x38a/0x930 [ 862.252095] __scsi_remove_device+0x293/0x360 [ 862.252291] scsi_remove_target+0x486/0x760 [ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi] [ 862.252886] process_one_work+0x633/0xe50 [ 862.253101] worker_thread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] ret_from_fork+0x2a6/0x470 [ 862.255852] ret_from_fork_asm+0x1a/0x30 [ 862.256037] Remove the blk_should_fake_timeout() check from dm, as dm has no native timeout handling and should not attempt to fake timeouts.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-71292", "url": "https://ubuntu.com/security/CVE-2025-71292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: nlink overflow in jfs_rename If nlink is maximal for a directory (-1) and inside that directory you perform a rename for some child directory (not moving from the parent), then the nlink of the first directory is first incremented and later decremented. Normally this is fine, but when nlink = -1 this causes a wrap around to 0, and then drop_nlink issues a warning. After applying the patch syzbot no longer issues any warnings. I also ran some basic fs tests to look for any regressions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43236", "url": "https://ubuntu.com/security/CVE-2026-43236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying the atmel_hlcdc_plane state structure without properly duplicating the drm_plane_state. In particular, state->commit remained set to the old state commit, which can lead to a use-after-free in the next drm_atomic_commit() call. Fix this by calling __drm_atomic_helper_duplicate_plane_state(), which correctly clones the base drm_plane_state (including the ->commit pointer). It has been seen when closing and re-opening the device node while another DRM client (e.g. fbdev) is still attached: ============================================================================= BUG kmalloc-64 (Not tainted): Poison overwritten ----------------------------------------------------------------------------- 0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0 pid=29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28 Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0 pid=169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0 flags=0x200(workingset|zone=0) Object 0xc611b340 @offset=832 fp=0xc611b7c0", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43269", "url": "https://ubuntu.com/security/CVE-2026-43269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback After several commits, the slab memory increases. Some drm_crtc_commit objects are not freed. The atomic_destroy_state callback only put the framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function to put all the objects that are no longer needed. It has been seen after hours of usage of a graphics application or using kmemleak: unreferenced object 0xc63a6580 (size 64): comm \"egt_basic\", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleak_alloc+0x34/0x3c __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43287", "url": "https://ubuntu.com/security/CVE-2026-43287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Account property blob allocations to memcg DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory. Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM. Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43183", "url": "https://ubuntu.com/security/CVE-2026-43183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx25821: Fix a resource leak in cx25821_dev_setup() Add release_mem_region() if ioremap() fails to release the memory region obtained by cx25821_get_resources().", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43316", "url": "https://ubuntu.com/security/CVE-2026-43316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: solo6x10: Check for out of bounds chip_id Clang with CONFIG_UBSAN_SHIFT=y noticed a condition where a signed type (literal \"1\" is an \"int\") could end up being shifted beyond 32 bits, so instrumentation was added (and due to the double is_tw286x() call seen via inlining), Clang decides the second one must now be undefined behavior and elides the rest of the function[1]. This is a known problem with Clang (that is still being worked on), but we can avoid the entire problem by actually checking the existing max chip ID, and now there is no runtime instrumentation added at all since everything is known to be within bounds. Additionally use an unsigned value for the shift to remove the instrumentation even without the explicit bounds checking. [hverkuil: fix checkpatch warning for is_tw286x]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43223", "url": "https://ubuntu.com/security/CVE-2026-43223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix URB leak in pvr2_send_request_ex When pvr2_send_request_ex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2_send_request_ex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usb_submit_urb(). Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43302", "url": "https://ubuntu.com/security/CVE-2026-43302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Set DMA segment size to avoid debug warnings When using V3D rendering with CONFIG_DMA_API_DEBUG enabled, the kernel occasionally reports a segment size mismatch. This is because 'max_seg_size' is not set. The kernel defaults to 64K. setting 'max_seg_size' to the maximum will prevent 'debug_dma_map_sg()' from complaining about the over-mapping of the V3D segment length. DMA-API: v3d 1002000000.v3d: mapping sg segment longer than device claims to support [len=8290304] [max=65536] WARNING: CPU: 0 PID: 493 at kernel/dma/debug.c:1179 debug_dma_map_sg+0x330/0x388 CPU: 0 UID: 0 PID: 493 Comm: Xorg Not tainted 6.12.53-yocto-standard #1 Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_dma_map_sg+0x330/0x388 lr : debug_dma_map_sg+0x330/0x388 sp : ffff8000829a3ac0 x29: ffff8000829a3ac0 x28: 0000000000000001 x27: ffff8000813fe000 x26: ffffc1ffc0000000 x25: ffff00010fdeb760 x24: 0000000000000000 x23: ffff8000816a9bf0 x22: 0000000000000001 x21: 0000000000000002 x20: 0000000000000002 x19: ffff00010185e810 x18: ffffffffffffffff x17: 69766564206e6168 x16: 74207265676e6f6c x15: 20746e656d676573 x14: 20677320676e6970 x13: 5d34303334393134 x12: 0000000000000000 x11: 00000000000000c0 x10: 00000000000009c0 x9 : ffff8000800e0b7c x8 : ffff00010a315ca0 x7 : ffff8000816a5110 x6 : 0000000000000001 x5 : 000000000000002b x4 : 0000000000000002 x3 : 0000000000000008 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00010a315280 Call trace: debug_dma_map_sg+0x330/0x388 __dma_map_sg_attrs+0xc0/0x278 dma_map_sgtable+0x30/0x58 drm_gem_shmem_get_pages_sgt+0xb4/0x140 v3d_bo_create_finish+0x28/0x130 [v3d] v3d_create_bo_ioctl+0x54/0x180 [v3d] drm_ioctl_kernel+0xc8/0x140 drm_ioctl+0x2d4/0x4d8", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43124", "url": "https://ubuntu.com/security/CVE-2026-43124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore: ram_core: fix incorrect success return when vmap() fails In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43227", "url": "https://ubuntu.com/security/CVE-2026-43227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/sh_tmu: Always leave device running after probe The TMU device can be used as both a clocksource and a clockevent provider. The driver tries to be smart and power itself on and off, as well as enabling and disabling its clock when it's not in operation. This behavior is slightly altered if the TMU is used as an early platform device in which case the device is left powered on after probe, but the clock is still enabled and disabled at runtime. This has worked for a long time, but recent improvements in PREEMPT_RT and PROVE_LOCKING have highlighted an issue. As the TMU registers itself as a clockevent provider, clockevents_register_device(), it needs to use raw spinlocks internally as this is the context of which the clockevent framework interacts with the TMU driver. However in the context of holding a raw spinlock the TMU driver can't really manage its power state or clock with calls to pm_runtime_*() and clk_*() as these calls end up in other platform drivers using regular spinlocks to control power and clocks. This mix of spinlock contexts trips a lockdep warning. ============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90 For non-PREEMPT_RT builds this is not really an issue, but for PREEMPT_RT builds where normal spinlocks can sleep this might be an issue. Be cautious and always leave the power and clock running after probe.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43313", "url": "https://ubuntu.com/security/CVE-2026-43313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4() In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDE device and then reassigned an ISA device: dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...); dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...); If the first lookup succeeds but the second fails, dev becomes NULL. This leads to a potential null-pointer dereference when dev_dbg() is called: if (errata.piix4.bmisx) dev_dbg(&dev->dev, ...); To prevent this, use two temporary pointers and retrieve each device independently, avoiding overwriting dev with a possible NULL value. [ rjw: Subject adjustment, added an empty code line ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43266", "url": "https://ubuntu.com/security/CVE-2026-43266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EFI/CPER: don't go past the ARM processor CPER record buffer There's a logic inside GHES/CPER to detect if the section_length is too small, but it doesn't detect if it is too big. Currently, if the firmware receives an ARM processor CPER record stating that a section length is big, kernel will blindly trust section_length, producing a very long dump. For instance, a 67 bytes record with ERR_INFO_NUM set 46198 and section length set to 854918320 would dump a lot of data going a way past the firmware memory-mapped area. Fix it by adding a logic to prevent it to go past the buffer if ERR_INFO_NUM is too big, making it report instead: \t[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 \t[Hardware Error]: event severity: recoverable \t[Hardware Error]: Error 0, type: recoverable \t[Hardware Error]: section_type: ARM processor error \t[Hardware Error]: MIDR: 0xff304b2f8476870a \t[Hardware Error]: section length: 854918320, CPER size: 67 \t[Hardware Error]: section length is too big \t[Hardware Error]: firmware-generated error record is incorrect \t[Hardware Error]: ERR_INFO_NUM is 46198 [ rjw: Subject and changelog tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43277", "url": "https://ubuntu.com/security/CVE-2026-43277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: APEI/GHES: ensure that won't go past CPER allocated record The logic at ghes_new() prevents allocating too large records, by checking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB). Yet, the allocation is done with the actual number of pages from the CPER bios table location, which can be smaller. Yet, a bad firmware could send data with a different size, which might be bigger than the allocated memory, causing an OOPS: Unable to handle kernel paging request at virtual address fff00000f9b40000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000 [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 Workqueue: kacpi_notify acpi_os_execute_deferred pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : hex_dump_to_buffer+0x30c/0x4a0 lr : hex_dump_to_buffer+0x328/0x4a0 sp : ffff800080e13880 x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083 x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004 x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083 x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010 x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008 x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020 x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000 x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008 Call trace: hex_dump_to_buffer+0x30c/0x4a0 (P) print_hex_dump+0xac/0x170 cper_estatus_print_section+0x90c/0x968 cper_estatus_print+0xf0/0x158 __ghes_print_estatus+0xa0/0x148 ghes_proc+0x1bc/0x220 ghes_notify_hed+0x5c/0xb8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x80 acpi_hed_notify+0x28/0x40 acpi_ev_notify_dispatch+0x50/0x80 acpi_os_execute_deferred+0x24/0x48 process_one_work+0x15c/0x3b0 worker_thread+0x2d0/0x400 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44) ---[ end trace 0000000000000000 ]--- Prevent that by taking the actual allocated are into account when checking for CPER length. [ rjw: Subject tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43171", "url": "https://ubuntu.com/security/CVE-2026-43171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EFI/CPER: don't dump the entire memory region The current logic at cper_print_fw_err() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory. The end result can be: - the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region. Fix it by checking if the section length is too small before doing a hex dump. [ rjw: Subject tweaks ]", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43184", "url": "https://ubuntu.com/security/CVE-2026-43184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rnbd-srv: Zero the rsp buffer before using it Before using the data buffer to send back the response message, zero it completely. This prevents any stray bytes to be picked up by the client side when there the message is exchanged between different protocol versions.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43261", "url": "https://ubuntu.com/security/CVE-2026-43261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Add support for TSV110 Spectre-BHB mitigation The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43262", "url": "https://ubuntu.com/security/CVE-2026-43262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fiemap page fault fix In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault. Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary. Fixes xfstest generic/742.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43209", "url": "https://ubuntu.com/security/CVE-2026-43209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: minix: Add required sanity checking to minix_check_superblock() The fs/minix implementation of the minix filesystem does not currently support any other value for s_log_zone_size than 0. This is also the only value supported in util-linux; see mkfs.minix.c line 511. In addition, this patch adds some sanity checking for the other minix superblock fields, and moves the minix_blocks_needed() checks for the zmap and imap also to minix_check_super_block(). This also closes a related syzbot bug report.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43268", "url": "https://ubuntu.com/security/CVE-2026-43268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: pretend special inodes as regular files Since commit af153bb63a33 (\"vfs: catch invalid modes in may_open()\") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23241", "url": "https://ubuntu.com/security/CVE-2026-23241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: add missing syscalls to read class The \"at\" variant of getxattr() and listxattr() are missing from the audit read class. Calling getxattrat() or listxattrat() on a file to read its extended attributes will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds missing syscalls to the audit read class.", "cve_priority": "medium", "cve_public_date": "2026-03-17 10:16:00 UTC" }, { "cve": "CVE-2025-71239", "url": "https://ubuntu.com/security/CVE-2025-71239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: add fchmodat2() to change attributes class fchmodat2(), introduced in version 6.6 is currently not in the change attribute class of audit. Calling fchmodat2() to change a file attribute in the same fashion than chmod() or fchmodat() will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds fchmodat2() to the change attributes class.", "cve_priority": "medium", "cve_public_date": "2026-03-17 10:15:00 UTC" }, { "cve": "CVE-2026-45964", "url": "https://ubuntu.com/security/CVE-2026-45964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path Commit 5940d1cf9f42 (\"SUNRPC: Rebalance a kref in auth_gss.c\") added a kref_get(&gss_auth->kref) call to balance the gss_put_auth() done in gss_release_msg(), but forgot to add a corresponding kref_put() on the error path when kstrdup_const() fails. If service_name is non-NULL and kstrdup_const() fails, the function jumps to err_put_pipe_version which calls put_pipe_version() and kfree(gss_msg), but never releases the gss_auth reference. This leads to a kref leak where the gss_auth structure is never freed. Add a forward declaration for gss_free_callback() and call kref_put() in the err_put_pipe_version error path to properly release the reference taken earlier.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45870", "url": "https://ubuntu.com/security/CVE-2026-45870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: auth_gss: fix memory leaks in XDR decoding error paths The gssx_dec_ctx(), gssx_dec_status(), and gssx_dec_name() functions allocate memory via gssx_dec_buffer(), which calls kmemdup(). When a subsequent decode operation fails, these functions return immediately without freeing previously allocated buffers, causing memory leaks. The leak in gssx_dec_ctx() is particularly relevant because the caller (gssp_accept_sec_context_upcall) initializes several buffer length fields to non-zero values, resulting in memory allocation: struct gssx_ctx rctxh = { .exported_context_token.len = GSSX_max_output_handle_sz, .mech.len = GSS_OID_MAX_LEN, .src_name.display_name.len = GSSX_max_princ_sz, .targ_name.display_name.len = GSSX_max_princ_sz }; If, for example, gssx_dec_name() succeeds for src_name but fails for targ_name, the memory allocated for exported_context_token, mech, and src_name.display_name remains unreferenced and cannot be reclaimed. Add error handling with goto-based cleanup to free any previously allocated buffers before returning an error.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45948", "url": "https://ubuntu.com/security/CVE-2026-45948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leak in ext4_ext_shift_extents() In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4_find_extent(), leading to a memory leak. Fix this by jumping to the out label to ensure the path is properly released.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45912", "url": "https://ubuntu.com/security/CVE-2026-45912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't cache extent during splitting extent Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful. Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, when ext4_split_extent_at() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4_find_extent() and ext4_cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting. In adition, if the unwritten extent cache is not shrunk during the splitting, ext4_cache_extents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46250", "url": "https://ubuntu.com/security/CVE-2026-46250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: MIPS: Work around LLVM bug when gp is used as global register variable On MIPS, __current_thread_info is defined as global register variable locating in $gp, and is simply assigned with new address during kernel relocation. This however is broken with LLVM, which always restores $gp if it finds $gp is clobbered in any form, including when intentionally through a global register variable. This is against GCC's documentation[1], which requires a callee-saved register used as global register variable not to be restored if it's clobbered. As a result, $gp will continue to point to the unrelocated kernel after the epilog of relocate_kernel(), leading to an early crash in init_idle, [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY [ 0.000000] Tainted: [W]=WARN [ 0.000000] Hardware name: loongson,loongson64v-4core-virtio [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240 [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001 [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002 [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80 [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80 [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90 [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90 [ 0.000000] Hi : 0000000000000000 [ 0.000000] Lo : 0000000000000000 [ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270 [ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270 [ 0.000000] Status: 540000e2\tKX SX UX KERNEL EXL [ 0.000000] Cause : 00000008 (ExcCode 02) [ 0.000000] BadVA : 0000000000000000 [ 0.000000] PrId : 00006305 (ICT Loongson-3) [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000) [ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528 [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000 [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258 [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98 [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [] init_idle+0x130/0x270 [ 0.000000] [] sched_init+0x5c8/0x6c0 [ 0.000000] [] start_kernel+0x27c/0x7a8 This bug has been reported to LLVM[2] and affects version from (at least) 18 to 21. Let's work around this by using inline assembly to assign $gp before a fix is widely available.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45974", "url": "https://ubuntu.com/security/CVE-2026-45974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not found If btrfs_search_slot_for_read() returns 1, it means we did not find any key greater than or equals to the key we asked for, meaning we have reached the end of the tree and therefore the path is not valid. If this happens we need to break out of the loop and stop, instead of continuing and accessing an invalid path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45965", "url": "https://ubuntu.com/security/CVE-2026-45965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix invalid deref of rawdata when export_binary is unset If the export_binary parameter is disabled on runtime, profiles that were loaded before that will still have their rawdata stored in apparmorfs, with a symbolic link to the rawdata on the policy directory. When one of those profiles are replaced, the rawdata is set to NULL, but when trying to resolve the symbolic links to rawdata for that profile, it will try to dereference profile->rawdata->name when profile->rawdata is now NULL causing an oops. Fix it by checking if rawdata is set. [ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088 [ 168.657420] #PF: supervisor read access in kernel mode [ 168.660619] #PF: error_code(0x0000) - not-present page [ 168.663613] PGD 0 P4D 0 [ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI [ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary) [ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330 [ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8 [ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282 [ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158 [ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80 [ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000 [ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80 [ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0 [ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000 [ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0 [ 168.701696] Call Trace: [ 168.702325] [ 168.702995] rawdata_get_link_data+0x1c/0x30 [ 168.704145] vfs_readlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64_sys_readlink+0x1e/0x30 [ 168.708653] x64_sys_call+0x1d77/0x26b0 [ 168.709525] do_syscall_64+0x81/0x500 [ 168.710348] ? do_statx+0x72/0xb0 [ 168.711109] ? putname+0x3e/0x80 [ 168.711845] ? __x64_sys_statx+0xb7/0x100 [ 168.712711] ? x64_sys_call+0x10fc/0x26b0 [ 168.713577] ? do_syscall_64+0xbf/0x500 [ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0 [ 168.715404] ? irqentry_exit+0xb2/0x740 [ 168.716359] ? exc_page_fault+0x90/0x1b0 [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45848", "url": "https://ubuntu.com/security/CVE-2026-45848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix NULL sock in aa_sock_file_perm Deal with the potential that sock and sock-sk can be NULL during socket setup or teardown. This could lead to an oops. The fix for NULL pointer dereference in __unix_needs_revalidation shows this is at least possible for af_unix sockets. While the fix for af_unix sockets applies for newer mediation this is still the fall back path for older af_unix mediation and other sockets, so ensure it is covered.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45970", "url": "https://ubuntu.com/security/CVE-2026-45970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: alb: fix UAF in rlb_arp_recv during bond up/down The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN. However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag. [ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? __pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry. Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45847", "url": "https://ubuntu.com/security/CVE-2026-45847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: remove WARN_ON_ONCE when accessing forward path array Although unlikely, recent support for IPIP tunnels increases chances of reaching this WARN_ON_ONCE if userspace manages to build a sufficiently long forward path. Remove it.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45890", "url": "https://ubuntu.com/security/CVE-2026-45890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen-netback: reject zero-queue configuration from guest A malicious or buggy Xen guest can write \"0\" to the xenbus key \"multi-queue-num-queues\". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range(). On systems with panic_on_warn=1, this allows a guest-to-host denial of service. The Xen network interface specification requires the queue count to be \"greater than zero\". Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45968", "url": "https://ubuntu.com/security/CVE-2026-45968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuidle: Skip governor when only one idle state is available On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash. [ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668 Fix this by adding a bail-out in cpuidle_select() that returns state 0 directly when state_count <= 1, bypassing the governor and keeping the tick running.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45935", "url": "https://ubuntu.com/security/CVE-2026-45935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot In the 'DeleteIndexEntryRoot' case of the 'do_action' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking. Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize); It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to size_t for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow. This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45864", "url": "https://ubuntu.com/security/CVE-2026-45864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent infinite loops caused by the next valid being the same When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1]. Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this. [1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45868", "url": "https://ubuntu.com/security/CVE-2026-45868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix refcount leak in pcs_add_gpio_func() of_parse_phandle_with_args() returns a device_node pointer with refcount incremented in gpiospec.np. The loop iterates through all phandles but never releases the reference, causing a refcount leak on each iteration. Add of_node_put() calls to release the reference after extracting the needed arguments and on the error path when devm_kzalloc() fails. This bug was detected by our static analysis tool and verified by my code review.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45883", "url": "https://ubuntu.com/security/CVE-2026-45883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: sca3000: Fix a resource leak in sca3000_probe() spi->irq from request_threaded_irq() not released when iio_device_register() fails. Add an return value check and jump to a common error handler when iio_device_register() fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45875", "url": "https://ubuntu.com/security/CVE-2026-45875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: arizona: Fix regulator resource leak on wm5102_clear_write_sequencer() failure The wm5102_clear_write_sequencer() helper may return an error and just return, bypassing the cleanup sequence and causing regulators to remain enabled, leading to a resource leak. Change the direct return to jump to the err_reset label to properly free the resources.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45978", "url": "https://ubuntu.com/security/CVE-2026-45978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: greybus: lights: avoid NULL deref gb_lights_light_config() stores channel_count before allocating the channels array. If kcalloc() fails, gb_lights_release() iterates the non-zero count and dereferences light->channels, which is NULL. Allocate channels first and only then publish channels_count so the cleanup path can't walk a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45954", "url": "https://ubuntu.com/security/CVE-2026-45954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe() In au1200fb_drv_probe(), when platform_get_irq fails(), it directly returns from the function with an error code, which causes a memory leak. Replace it with a goto label to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45857", "url": "https://ubuntu.com/security/CVE-2026-45857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: csiostor: Fix dereference of null pointer rn The error exit path when rn is NULL ends up deferencing the null pointer rn via the use of the macro CSIO_INC_STATS. Fix this by adding a new error return path label after the use of the macro to avoid the deference.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45856", "url": "https://ubuntu.com/security/CVE-2026-45856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45852", "url": "https://ubuntu.com/security/CVE-2026-45852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45869", "url": "https://ubuntu.com/security/CVE-2026-45869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: wm97xx: Fix NULL pointer dereference in power_supply_changed() In `probe()`, `request_irq()` is called before allocating/registering a `power_supply` handle. If an interrupt is fired between the call to `request_irq()` and `power_supply_register()`, the `power_supply` handle will be used uninitialized in `power_supply_changed()` in `wm97xx_bat_update()` (triggered from the interrupt handler). This will lead to a `NULL` pointer dereference since Fix this racy `NULL` pointer dereference by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Since the IRQ is the last thing requests in the `probe()` now, remove the error path for freeing it. Instead add one for unregistering the `power_supply` handle when IRQ request fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45916", "url": "https://ubuntu.com/security/CVE-2026-45916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sbs-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Keep the old behavior of just printing a warning in case of any failures during the IRQ request and finishing the probe successfully.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46270", "url": "https://ubuntu.com/security/CVE-2026-46270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: rt9455: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45936", "url": "https://ubuntu.com/security/CVE-2026-45936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: goldfish: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45885", "url": "https://ubuntu.com/security/CVE-2026-45885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cpcap-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45879", "url": "https://ubuntu.com/security/CVE-2026-45879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq25980: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45902", "url": "https://ubuntu.com/security/CVE-2026-45902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45867", "url": "https://ubuntu.com/security/CVE-2026-45867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: act8945a: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45946", "url": "https://ubuntu.com/security/CVE-2026-45946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Commit 1c1f13a006ed (\"power: supply: ab8500: Move to componentized binding\") introduced this issue during a refactorization. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45866", "url": "https://ubuntu.com/security/CVE-2026-45866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: caif: fix use-after-free in caif_serial ldisc_close() There is a use-after-free bug in caif_serial where handle_tx() may access ser->tty after the tty has been freed. The race condition occurs between ldisc_close() and packet transmission: CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldisc_close() tty_kref_put(ser->tty) [tty may be freed here] <-- race window --> caif_xmit() handle_tx() tty = ser->tty // dangling ptr tty->ops->write() // UAF! schedule_work() ser_release() unregister_netdevice() The root cause is that tty_kref_put() is called in ldisc_close() while the network device is still active and can receive packets. Since ser and tty have a 1:1 binding relationship with consistent lifecycles (ser is allocated in ldisc_open and freed in ser_release via unregister_netdevice, and each ser binds exactly one tty), we can safely defer the tty reference release to ser_release() where the network device is unregistered. Fix this by moving tty_kref_put() from ldisc_close() to ser_release(), after unregister_netdevice(). This ensures the tty reference is held as long as the network device exists, preventing the UAF. Note: We save ser->tty before unregister_netdevice() because ser is embedded in netdev's private data and will be freed along with netdev (needs_free_netdev = true). How to reproduce: Add mdelay(500) at the beginning of ldisc_close() to widen the race window, then run the reproducer program [1]. Note: There is a separate deadloop issue in handle_tx() when using PORT_UNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper serial backend). This deadloop exists even without this patch, and is likely caused by inconsistency between uart_write_room() and uart_write() in serial core. It has been addressed in a separate patch [2]. KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in handle_tx+0x5d1/0x620 Read of size 1 at addr ffff8881131e1490 by task caif_uaf_trigge/9929 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xd0/0x630 kasan_report+0xe4/0x120 handle_tx+0x5d1/0x620 dev_hard_start_xmit+0x9d/0x6c0 __dev_queue_xmit+0x6e2/0x4410 packet_xmit+0x243/0x360 packet_sendmsg+0x26cf/0x5500 __sys_sendto+0x4a3/0x520 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0xc9/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f615df2c0d7 Allocated by task 9930: Freed by task 64: Last potentially related work creation: The buggy address belongs to the object at ffff8881131e1000 which belongs to the cache kmalloc-cg-2k of size 2048 The buggy address is located 1168 bytes inside of freed 2048-byte region [ffff8881131e1000, ffff8881131e1800) The buggy address belongs to the physical page: page_owner tracks the page as allocated page last free pid 9778 tgid 9778 stack trace: Memory state around the buggy address: ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-31411", "url": "https://ubuntu.com/security/CVE-2026-31411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: fix crash due to unvalidated vcc pointer in sigd_send() Reproducer available at [1]. The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values. Fix this by introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found. Since struct atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock_hold/sock_put is sufficient to keep the vcc alive while it is being used. Note that there may be a race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety. [1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3", "cve_priority": "medium", "cve_public_date": "2026-04-08 14:16:00 UTC" }, { "cve": "CVE-2026-46259", "url": "https://ubuntu.com/security/CVE-2026-46259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent.", "cve_priority": "high", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45891", "url": "https://ubuntu.com/security/CVE-2026-45891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix double free issue for tx spare buffer In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory. Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory. The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer. Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new `tx_spare` fails. This ensures the error cleanup path only frees genuinely newly allocated buffers.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45873", "url": "https://ubuntu.com/security/CVE-2026-45873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets Userspace provides an optimized representation in case intervals are adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous set checks on start elements for this reason. However, it is possible to add intervals that overlap to this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end \tA B start end A C Restore the check on overlapping start elements to report an overlap.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46267", "url": "https://ubuntu.com/security/CVE-2026-46267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: hci: shdlc: Stop timers and work before freeing context llc_shdlc_deinit() purges SHDLC skb queues and frees the llc_shdlc structure while its timers and state machine work may still be active. Timer callbacks can schedule sm_work, and sm_work accesses SHDLC state and the skb queues. If teardown happens in parallel with a queued/running work item, it can lead to UAF and other shutdown races. Stop all SHDLC timers and cancel sm_work synchronously before purging the queues and freeing the context. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-46249", "url": "https://ubuntu.com/security/CVE-2026-46249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix PF driver crash with kexec kernel booting During a kexec reboot the hardware is not power-cycled, so AF state from the old kernel can persist into the new kernel. When AF and PF drivers are built as modules, the PF driver may probe before AF reinitializes the hardware. The PF driver treats the RVUM block revision as an indication that AF initialization is complete. If this value is left uncleared at shutdown, PF may incorrectly assume AF is ready and access stale hardware state, leading to a crash. Clear the RVUM block revision during AF shutdown to avoid PF mis-detecting AF readiness after kexec.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45915", "url": "https://ubuntu.com/security/CVE-2026-45915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: avoid parent link count underflow in rmdir Corrupted FAT images can leave a directory inode with an incorrect i_nlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls drop_nlink(dir) and can drive i_nlink to 0, triggering the WARN_ON in drop_nlink(). Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45983", "url": "https://ubuntu.com/security/CVE-2026-45983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: never defer requests during idmap lookup During v4 request compound arg decoding, some ops (e.g. SETATTR) can trigger idmap lookup upcalls. When those upcall responses get delayed beyond the allowed time limit, cache_check() will mark the request for deferral and cause it to be dropped. This prevents nfs4svc_encode_compoundres from being executed, and thus the session slot flag NFSD4_SLOT_INUSE never gets cleared. Subsequent client requests will fail with NFSERR_JUKEBOX, given that the slot will be marked as in-use, making the SEQUENCE op fail. Fix this by making sure that the RQ_USEDEFERRAL flag is always clear during nfs4svc_decode_compoundargs(), since no v4 request should ever be deferred.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45862", "url": "https://ubuntu.com/security/CVE-2026-45862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush cache for PASID table before using it When writing the address of a freshly allocated zero-initialized PASID table to a PASID directory entry, do that after the CPU cache flush for this PASID table, not before it, to avoid the time window when this PASID table may be already used by non-coherent IOMMU hardware while its contents in RAM is still some random old data, not zero-initialized.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45860", "url": "https://ubuntu.com/security/CVE-2026-45860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: increase the connection clean up limit to 64 After the optimization to only perform one GC per jiffy, a new problem was introduced. If more than 8 new connections are tracked per jiffy the list won't be cleaned up fast enough possibly reaching the limit wrongly. In order to prevent this issue, only skip the GC if it was already triggered during the same jiffy and the increment is lower than the clean up limit. In addition, increase the clean up limit to 64 connections to avoid triggering GC too often and do more effective GCs. This has been tested using a HTTP server and several performance tools while having nft_connlimit/xt_connlimit or OVS limit configured. Output of slowhttptest + OVS limit at 52000 connections: slow HTTP test status on 340th second: initializing: 0 pending: 432 connected: 51998 error: 0 closed: 0 service available: YES", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45969", "url": "https://ubuntu.com/security/CVE-2026-45969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: playstation: Add missing check for input_ff_create_memless The ps_gamepad_create() function calls input_ff_create_memless() without verifying its return value, which can lead to incorrect behavior or potential crashes when FF effects are triggered. Add a check for the return value of input_ff_create_memless().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-71304", "url": "https://ubuntu.com/security/CVE-2025-71304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: /smack/doi: accept previously used values Writing to /smack/doi a value that has ever been written there in the past disables networking for non-ambient labels. E.g. # cat /smack/doi 3 # netlabelctl -p cipso list Configured CIPSO mappings (1) DOI value : 3 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (3) domain: \"_\" (IPv4) protocol: UNLABELED domain: DEFAULT (IPv4) protocol: CIPSO, DOI = 3 domain: DEFAULT (IPv6) protocol: UNLABELED # cat /smack/ambient _ # cat /proc/$$/attr/smack/current _ # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.964 ms # echo foo >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.956 ms unknown option 86 # echo 4 >/smack/doi # echo 3 >/smack/doi !> [ 214.050395] smk_cipso_doi:691 cipso add rc = -17 # echo 3 >/smack/doi !> [ 249.402261] smk_cipso_doi:678 remove rc = -2 !> [ 249.402261] smk_cipso_doi:691 cipso add rc = -17 # ping -c1 10.1.95.12 !!> ping: 10.1.95.12: Address family for hostname not supported # echo _ >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.617 ms This happens because Smack keeps decommissioned DOIs, fails to re-add them, and consequently refuses to add the “default” domain map: # netlabelctl -p cipso list Configured CIPSO mappings (2) DOI value : 3 mapping type : PASS_THROUGH DOI value : 4 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (2) domain: \"_\" (IPv4) protocol: UNLABELED !> (no ipv4 map for default domain here) domain: DEFAULT (IPv6) protocol: UNLABELED Fix by clearing decommissioned DOI definitions and serializing concurrent DOI updates with a new lock. Also: - allow /smack/doi to live unconfigured, since adding a map (netlbl_cfg_cipsov4_map_add) may fail. CIPSO_V4_DOI_UNKNOWN(0) indicates the unconfigured DOI - add new DOI before removing the old default map, so the old map remains if the add fails (2008-02-04, Casey Schaufler)", "cve_priority": "low", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-45904", "url": "https://ubuntu.com/security/CVE-2026-45904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling The recent commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug safe\") restructured the EEH driver to improve synchronization with the PCI hotplug layer. However, it inadvertently moved pci_lock_rescan_remove() outside its intended scope in eeh_handle_normal_event(), leading to broken PCI error reporting and improper EEH event triggering. Specifically, eeh_handle_normal_event() acquired pci_lock_rescan_remove() before calling eeh_pe_bus_get(), but eeh_pe_bus_get() itself attempts to acquire the same lock internally, causing nested locking and disrupting normal EEH event handling paths. This patch adds a boolean parameter do_lock to _eeh_pe_bus_get(), with two public wrappers: eeh_pe_bus_get() with locking enabled. eeh_pe_bus_get_nolock() that skips locking. Callers that already hold pci_lock_rescan_remove() now use eeh_pe_bus_get_nolock() to avoid recursive lock acquisition. Additionally, pci_lock_rescan_remove() calls are restored to the correct position—after eeh_pe_bus_get() and immediately before iterating affected PEs and devices. This ensures EEH-triggered PCI removes occur under proper bus rescan locking without recursive lock contention. The eeh_pe_loc_get() function has been split into two functions: eeh_pe_loc_get(struct eeh_pe *pe) which retrieves the loc for given PE. eeh_pe_loc_get_bus(struct pci_bus *bus) which retrieves the location code for given bus. This resolves lockdep warnings such as: [ 84.964298] [ T928] ============================================ [ 84.964304] [ T928] WARNING: possible recursive locking detected [ 84.964311] [ T928] 6.18.0-rc3 #51 Not tainted [ 84.964315] [ T928] -------------------------------------------- [ 84.964320] [ T928] eehd/928 is trying to acquire lock: [ 84.964324] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964342] [ T928] but task is already holding lock: [ 84.964347] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964357] [ T928] other info that might help us debug this: [ 84.964363] [ T928] Possible unsafe locking scenario: [ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928] lock(pci_rescan_remove_lock); [ 84.964378] [ T928] lock(pci_rescan_remove_lock); [ 84.964383] [ T928] *** DEADLOCK *** [ 84.964388] [ T928] May be due to missing lock nesting notation [ 84.964393] [ T928] 1 lock held by eehd/928: [ 84.964397] [ T928] #0: c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964408] [ T928] stack backtrace: [ 84.964414] [ T928] CPU: 2 UID: 0 PID: 928 Comm: eehd Not tainted 6.18.0-rc3 #51 VOLUNTARY [ 84.964417] [ T928] Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_022) hv:phyp pSeries [ 84.964419] [ T928] Call Trace: [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130 (unreliable) [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [ 84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c00000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46253", "url": "https://ubuntu.com/security/CVE-2026-46253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pstore/ram: fix buffer overflow in persistent_ram_save_old() persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz->old_log when it is NULL, but it unconditionally updates prz->old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1) 9. ramoops_get_next_prz() → persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-45919", "url": "https://ubuntu.com/security/CVE-2026-45919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/rt: Skip currently executing CPU in rto_next_cpu() CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts. The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45871", "url": "https://ubuntu.com/security/CVE-2026-45871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Fix missing cleanup on get_burstcount() error get_burstcount() can return -EBUSY on timeout. When this happens, st33zp24_send() returns directly without releasing the locality acquired earlier. Use goto out_err to ensure proper cleanup when get_burstcount() fails.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45941", "url": "https://ubuntu.com/security/CVE-2026-45941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_infineon: Fix locality leak on get_burstcount() failure get_burstcount() can return -EBUSY on timeout. When this happens, the function returns directly without releasing the locality that was acquired at the beginning of tpm_tis_i2c_send(). Use goto out_err to ensure proper cleanup when get_burstcount() fails.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45984", "url": "https://ubuntu.com/security/CVE-2026-45984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix use-after-free in iomap inline data write path The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45960", "url": "https://ubuntu.com/security/CVE-2026-45960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: return error when node already exists in hfs_bnode_create When hfs_bnode_create() finds that a node is already hashed (which should not happen in normal operation), it currently returns the existing node without incrementing its reference count. This causes a reference count inconsistency that leads to a kernel panic when the node is later freed in hfs_bnode_put(): kernel BUG at fs/hfsplus/bnode.c:676! BUG_ON(!atomic_read(&node->refcnt)) This scenario can occur when hfs_bmap_alloc() attempts to allocate a node that is already in use (e.g., when node 0's bitmap bit is incorrectly unset), or due to filesystem corruption. Returning an existing node from a create path is not normal operation. Fix this by returning ERR_PTR(-EEXIST) instead of the node when it's already hashed. This properly signals the error condition to callers, which already check for IS_ERR() return values.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23243", "url": "https://ubuntu.com/security/CVE-2026-23243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umad: Reject negative data_len in ib_umad_write ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-23242", "url": "https://ubuntu.com/security/CVE-2026-23242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix potential NULL pointer dereference in header processing If siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(), qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data() dereferences qp->rx_fpdu->more_ddp_segs without checking, which may lead to a NULL pointer deref. Only check more_ddp_segs when rx_fpdu is present. KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50", "cve_priority": "medium", "cve_public_date": "2026-03-18 11:16:00 UTC" }, { "cve": "CVE-2026-23235", "url": "https://ubuntu.com/security/CVE-2026-23235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix out-of-bounds access in sysfs attribute read/write Some f2fs sysfs attributes suffer from out-of-bounds memory access and incorrect handling of integer values whose size is not 4 bytes. For example: vm:~# echo 65537 > /sys/fs/f2fs/vde/carve_out vm:~# cat /sys/fs/f2fs/vde/carve_out 65537 vm:~# echo 4294967297 > /sys/fs/f2fs/vde/atgc_age_threshold vm:~# cat /sys/fs/f2fs/vde/atgc_age_threshold 1 carve_out maps to {struct f2fs_sb_info}->carve_out, which is a 8-bit integer. However, the sysfs interface allows setting it to a value larger than 255, resulting in an out-of-range update. atgc_age_threshold maps to {struct atgc_management}->age_threshold, which is a 64-bit integer, but its sysfs interface cannot correctly set values larger than UINT_MAX. The root causes are: 1. __sbi_store() treats all default values as unsigned int, which prevents updating integers larger than 4 bytes and causes out-of-bounds writes for integers smaller than 4 bytes. 2. f2fs_sbi_show() also assumes all default values are unsigned int, leading to out-of-bounds reads and incorrect access to integers larger than 4 bytes. This patch introduces {struct f2fs_attr}->size to record the actual size of the integer associated with each sysfs attribute. With this information, sysfs read and write operations can correctly access and update values according to their real data size, avoiding memory corruption and truncation.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23234", "url": "https://ubuntu.com/security/CVE-2026-23234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid UAF in f2fs_write_end_io() As syzbot reported an use-after-free issue in f2fs_write_end_io(). It is caused by below race condition: loop device\t\t\t\tumount - worker_thread - loop_process_work - do_req_filebacked - lo_rw_aio - lo_rw_aio_complete - blk_mq_end_request - blk_update_request - f2fs_write_end_io - dec_page_count - folio_end_writeback \t\t\t\t\t- kill_f2fs_super \t\t\t\t\t - kill_block_super \t\t\t\t\t - f2fs_put_super \t\t\t\t\t : free(sbi) : get_pages(, F2FS_WB_CP_DATA) accessed sbi which is freed In kill_f2fs_super(), we will drop all page caches of f2fs inodes before call free(sbi), it guarantee that all folios should end its writeback, so it should be safe to access sbi before last folio_end_writeback(). Let's relocate ckpt thread wakeup flow before folio_end_writeback() to resolve this issue.", "cve_priority": "low", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23236", "url": "https://ubuntu.com/security/CVE-2026-23236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: smscufx: properly copy ioctl memory to kernelspace The UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data from userspace to kernelspace, and instead directly references the memory, which can cause problems if invalid data is passed from userspace. Fix this all up by correctly copying the memory before accessing it within the kernel.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23266", "url": "https://ubuntu.com/security/CVE-2026-23266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: rivafb: fix divide error in nv3_arb() A userspace program can trigger the RIVA NV3 arbitration code by calling the FBIOPUT_VSCREENINFO ioctl on /dev/fb*. When doing so, the driver recomputes FIFO arbitration parameters in nv3_arb(), using state->mclk_khz (derived from the PRAMDAC MCLK PLL) as a divisor without validating it first. In a normal setup, state->mclk_khz is provided by the real hardware and is non-zero. However, an attacker can construct a malicious or misconfigured device (e.g. a crafted/emulated PCI device) that exposes a bogus PLL configuration, causing state->mclk_khz to become zero. Once nv3_get_param() calls nv3_arb(), the division by state->mclk_khz in the gns calculation causes a divide error and crashes the kernel. Fix this by checking whether state->mclk_khz is zero and bailing out before doing the division. The following log reveals it: rivafb: setting virtual Y resolution to 2184 divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 2187 Comm: syz-executor.0 Not tainted 5.18.0-rc1+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:nv3_arb drivers/video/fbdev/riva/riva_hw.c:439 [inline] RIP: 0010:nv3_get_param+0x3ab/0x13b0 drivers/video/fbdev/riva/riva_hw.c:546 Call Trace: nv3CalcArbitration.constprop.0+0x255/0x460 drivers/video/fbdev/riva/riva_hw.c:603 nv3UpdateArbitrationSettings drivers/video/fbdev/riva/riva_hw.c:637 [inline] CalcStateExt+0x447/0x1b90 drivers/video/fbdev/riva/riva_hw.c:1246 riva_load_video_mode+0x8a9/0xea0 drivers/video/fbdev/riva/fbdev.c:779 rivafb_set_par+0xc0/0x5f0 drivers/video/fbdev/riva/fbdev.c:1196 fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1033 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1109 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1188 __x64_sys_ioctl+0x122/0x190 fs/ioctl.c:856", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2025-71233", "url": "https://ubuntu.com/security/CVE-2025-71233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Avoid creating sub-groups asynchronously The asynchronous creation of sub-groups by a delayed work could lead to a NULL pointer dereference when the driver directory is removed before the work completes. The crash can be easily reproduced with the following commands: # cd /sys/kernel/config/pci_ep/functions/pci_epf_test # for i in {1..20}; do mkdir test && rmdir test; done BUG: kernel NULL pointer dereference, address: 0000000000000088 ... Call Trace: configfs_register_group+0x3d/0x190 pci_epf_cfs_work+0x41/0x110 process_one_work+0x18f/0x350 worker_thread+0x25a/0x3a0 Fix this issue by using configfs_add_default_group() API which does not have the deadlock problem as configfs_register_group() and does not require the delayed work handler. [mani: slightly reworded the description and added stable list]", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71232", "url": "https://ubuntu.com/security/CVE-2025-71232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Free sp in error path to fix system crash System crash seen during load/unload test in a loop, [61110.449331] qla2xxx [0000:27:00.0]-0042:0: Disabled MSI-X. [61110.467494] ============================================================================= [61110.467498] BUG qla2xxx_srbs (Tainted: G OE -------- --- ): Objects remaining in qla2xxx_srbs on __kmem_cache_shutdown() [61110.467501] ----------------------------------------------------------------------------- [61110.467502] Slab 0x000000000ffc8162 objects=51 used=1 fp=0x00000000e25d3d85 flags=0x57ffffc0010200(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [61110.467509] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1 [61110.467513] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023 [61110.467515] Call Trace: [61110.467516] [61110.467519] dump_stack_lvl+0x34/0x48 [61110.467526] slab_err.cold+0x53/0x67 [61110.467534] __kmem_cache_shutdown+0x16e/0x320 [61110.467540] kmem_cache_destroy+0x51/0x160 [61110.467544] qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467607] ? __do_sys_delete_module.constprop.0+0x178/0x280 [61110.467613] ? syscall_trace_enter.constprop.0+0x145/0x1d0 [61110.467616] ? do_syscall_64+0x5c/0x90 [61110.467619] ? exc_page_fault+0x62/0x150 [61110.467622] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [61110.467626] [61110.467627] Disabling lock debugging due to kernel taint [61110.467635] Object 0x0000000026f7e6e6 @offset=16000 [61110.467639] ------------[ cut here ]------------ [61110.467639] kmem_cache_destroy qla2xxx_srbs: Slab cache still has objects when called from qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467659] WARNING: CPU: 53 PID: 455206 at mm/slab_common.c:520 kmem_cache_destroy+0x14d/0x160 [61110.467718] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G B OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1 [61110.467720] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023 [61110.467721] RIP: 0010:kmem_cache_destroy+0x14d/0x160 [61110.467724] Code: 99 7d 07 00 48 89 ef e8 e1 6a 07 00 eb b3 48 8b 55 60 48 8b 4c 24 20 48 c7 c6 70 fc 66 90 48 c7 c7 f8 ef a1 90 e8 e1 ed 7c 00 <0f> 0b eb 93 c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 [61110.467725] RSP: 0018:ffffa304e489fe80 EFLAGS: 00010282 [61110.467727] RAX: 0000000000000000 RBX: ffffffffc0d9a860 RCX: 0000000000000027 [61110.467729] RDX: ffff8fd5ff9598a8 RSI: 0000000000000001 RDI: ffff8fd5ff9598a0 [61110.467730] RBP: ffff8fb6aaf78700 R08: 0000000000000000 R09: 0000000100d863b7 [61110.467731] R10: ffffa304e489fd20 R11: ffffffff913bef48 R12: 0000000040002000 [61110.467731] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [61110.467733] FS: 00007f64c89fb740(0000) GS:ffff8fd5ff940000(0000) knlGS:0000000000000000 [61110.467734] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [61110.467735] CR2: 00007f0f02bfe000 CR3: 00000020ad6dc005 CR4: 0000000000770ee0 [61110.467736] PKRU: 55555554 [61110.467737] Call Trace: [61110.467738] [61110.467739] qla2x00_module_exit+0x93/0x99 [qla2xxx] [61110.467755] ? __do_sys_delete_module.constprop.0+0x178/0x280 Free sp in the error path to fix the crash.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71238", "url": "https://ubuntu.com/security/CVE-2025-71238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix bsg_done() causing double free Kernel panic observed on system, [5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000 [5353358.825194] #PF: supervisor write access in kernel mode [5353358.825195] #PF: error_code(0x0002) - not-present page [5353358.825196] PGD 100006067 P4D 0 [5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI [5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el9_5.x86_64 #1 [5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025 [5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10 [5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246 [5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000 [5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000 [5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000 [5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090 [5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000 [5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000 [5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0 [5353358.825221] PKRU: 55555554 [5353358.825222] Call Trace: [5353358.825223] [5353358.825224] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825229] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825232] ? sg_copy_buffer+0xc8/0x110 [5353358.825236] ? __die_body.cold+0x8/0xd [5353358.825238] ? page_fault_oops+0x134/0x170 [5353358.825242] ? kernelmode_fixup_or_oops+0x84/0x110 [5353358.825244] ? exc_page_fault+0xa8/0x150 [5353358.825247] ? asm_exc_page_fault+0x22/0x30 [5353358.825252] ? memcpy_erms+0x6/0x10 [5353358.825253] sg_copy_buffer+0xc8/0x110 [5353358.825259] qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx] [5353358.825317] qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx] Most routines in qla_bsg.c call bsg_done() only for success cases. However a few invoke it for failure case as well leading to a double free. Validate before calling bsg_done().", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23221", "url": "https://ubuntu.com/security/CVE-2026-23221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: fix use-after-free in driver_override_show() The driver_override_show() function reads the driver_override string without holding the device_lock. However, driver_override_store() uses driver_set_override(), which modifies and frees the string while holding the device_lock. This can result in a concurrent use-after-free if the string is freed by the store function while being read by the show function. Fix this by holding the device_lock around the read operation.", "cve_priority": "low", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23228", "url": "https://ubuntu.com/security/CVE-2026-23228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection() On kthread_run() failure in ksmbd_tcp_new_connection(), the transport is freed via free_transport(), which does not decrement active_num_conn, leaking this counter. Replace free_transport() with ksmbd_tcp_disconnect().", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23169", "url": "https://ubuntu.com/security/CVE-2026-23169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race in mptcp_pm_nl_flush_addrs_doit() syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id() and/or mptcp_pm_nl_is_backup() Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit() which is not RCU ready. list_splice_init_rcu() can not be called here while holding pernet->lock spinlock. Many thanks to Eulgyu Kim for providing a repro and testing our patches.", "cve_priority": "high", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-37786", "url": "https://ubuntu.com/security/CVE-2025-37786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: free routing table on probe failure If complete = true in dsa_tree_setup(), it means that we are the last switch of the tree which is successfully probing, and we should be setting up all switches from our probe path. After \"complete\" becomes true, dsa_tree_setup_cpu_ports() or any subsequent function may fail. If that happens, the entire tree setup is in limbo: the first N-1 switches have successfully finished probing (doing nothing but having allocated persistent memory in the tree's dst->ports, and maybe dst->rtable), and switch N failed to probe, ending the tree setup process before anything is tangible from the user's PoV. If switch N fails to probe, its memory (ports) will be freed and removed from dst->ports. However, the dst->rtable elements pointing to its ports, as created by dsa_link_touch(), will remain there, and will lead to use-after-free if dereferenced. If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirely possible because that is where ds->ops->setup() is, we get a kasan report like this: ================================================================== BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568 Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42 Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 The simplest way to fix the bug is to delete the routing table in its entirety. dsa_tree_setup_routing_table() has no problem in regenerating it even if we deleted links between ports other than those of switch N, because dsa_link_touch() first checks whether the port pair already exists in dst->rtable, allocating if not. The deletion of the routing table in its entirety already exists in dsa_tree_teardown(), so refactor that into a function that can also be called from the tree setup error path. In my analysis of the commit to blame, it is the one which added dsa_link elements to dst->rtable. Prior to that, each switch had its own ds->rtable which is freed when the switch fails to probe. But the tree is potentially persistent memory.", "cve_priority": "low", "cve_public_date": "2025-05-01 14:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2026-23237", "url": "https://ubuntu.com/security/CVE-2026-23237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: classmate-laptop: Add missing NULL pointer checks In a few places in the Classmate laptop driver, code using the accel object may run before that object's address is stored in the driver data of the input device using it. For example, cmpc_accel_sensitivity_store_v4() is the \"show\" method of cmpc_accel_sensitivity_attr_v4 which is added in cmpc_accel_add_v4(), before calling dev_set_drvdata() for inputdev->dev. If the sysfs attribute is accessed prematurely, the dev_get_drvdata(&inputdev->dev) call in in cmpc_accel_sensitivity_store_v4() returns NULL which leads to a NULL pointer dereference going forward. Moreover, sysfs attributes using the input device are added before initializing that device by cmpc_add_acpi_notify_device() and if one of them is accessed before running that function, a NULL pointer dereference will occur. For example, cmpc_accel_sensitivity_attr_v4 is added before calling cmpc_add_acpi_notify_device() and if it is read prematurely, the dev_get_drvdata(&acpi->dev) call in cmpc_accel_sensitivity_show_v4() returns NULL which leads to a NULL pointer dereference going forward. Fix this by adding NULL pointer checks in all of the relevant places.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-23238", "url": "https://ubuntu.com/security/CVE-2026-23238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: romfs: check sb_set_blocksize() return value romfs_fill_super() ignores the return value of sb_set_blocksize(), which can fail if the requested block size is incompatible with the block device's configuration. This can be triggered by setting a loop device's block size larger than PAGE_SIZE using ioctl(LOOP_SET_BLOCK_SIZE, 32768), then mounting a romfs filesystem on that device. When sb_set_blocksize(sb, ROMBSIZE) is called with ROMBSIZE=4096 but the device has logical_block_size=32768, bdev_validate_blocksize() fails because the requested size is smaller than the device's logical block size. sb_set_blocksize() returns 0 (failure), but romfs ignores this and continues mounting. The superblock's block size remains at the device's logical block size (32768). Later, when sb_bread() attempts I/O with this oversized block size, it triggers a kernel BUG in folio_set_bh(): kernel BUG at fs/buffer.c:1582! BUG_ON(size > PAGE_SIZE); Fix by checking the return value of sb_set_blocksize() and failing the mount with -EINVAL if it returns 0.", "cve_priority": "medium", "cve_public_date": "2026-03-04 15:16:00 UTC" }, { "cve": "CVE-2026-31687", "url": "https://ubuntu.com/security/CVE-2026-31687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: omap: do not register driver in probe() Commit 11a78b794496 (\"ARM: OMAP: MPUIO wake updates\") registers the omap_mpuio_driver from omap_mpuio_init(), which is called from omap_gpio_probe(). However, it neither makes sense to register drivers from probe() callbacks of other drivers, nor does the driver core allow registering drivers with a device lock already being held. The latter was revealed by commit dc23806a7c47 (\"driver core: enforce device_lock for driver_match_device()\") leading to a potential deadlock condition described in [1]. Additionally, the omap_mpuio_driver is never unregistered from the driver core, even if the module is unloaded. Hence, register the omap_mpuio_driver from the module initcall and unregister it in module_exit().", "cve_priority": "medium", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2025-71235", "url": "https://ubuntu.com/security/CVE-2025-71235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Delay module unload while fabric scan in progress System crash seen during load/unload test in a loop. [105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086 [105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0 [105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000 [105954.384923] FS: 0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000 [105954.384925] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0 [105954.384928] PKRU: 55555554 [105954.384929] Call Trace: [105954.384931] [105954.384934] qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx] [105954.384962] ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx] [105954.384980] ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx] [105954.384999] ? __wake_up_common+0x80/0x190 [105954.385004] ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx] [105954.385023] ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx] [105954.385040] ? __handle_irq_event_percpu+0x3d/0x190 [105954.385044] ? handle_irq_event+0x58/0xb0 [105954.385046] ? handle_edge_irq+0x93/0x240 [105954.385050] ? __common_interrupt+0x41/0xa0 [105954.385055] ? common_interrupt+0x3e/0xa0 [105954.385060] ? asm_common_interrupt+0x22/0x40 The root cause of this was that there was a free (dma_free_attrs) in the interrupt context. There was a device discovery/fabric scan in progress. A module unload was issued which set the UNLOADING flag. As part of the discovery, after receiving an interrupt a work queue was scheduled (which involved a work to be queued). Since the UNLOADING flag is set, the work item was not allocated and the mapped memory had to be freed. The free occurred in interrupt context leading to system crash. Delay the driver unload until the fabric scan is complete to avoid the crash.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71236", "url": "https://ubuntu.com/security/CVE-2025-71236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Validate sp before freeing associated memory System crash with the following signature [154563.214890] nvme nvme2: NVME-FC{1}: controller connect complete [154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Set ZIO exchange threshold to 3. [154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: SET ZIO Activity exchange threshold to 5. [154565.539974] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 0080 0000. [154565.545744] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 00a0 0000. [154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate). [154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate). [154565.553079] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [154565.553080] #PF: supervisor read access in kernel mode [154565.553082] #PF: error_code(0x0000) - not-present page [154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0 [154565.553089] Oops: 0000 1 PREEMPT SMP PTI [154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: loaded Tainted: G OE ------- --- 5.14.0-503.11.1.el9_5.x86_64 #1 [154565.553096] Hardware name: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 09/30/2024 [154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553141] Code: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 <4c> 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b [154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286 [154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002 [154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47 [154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a [154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0 [154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000 [154565.553152] FS: 0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000 [154565.553154] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0 [154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [154565.553159] PKRU: 55555554 [154565.553160] Call Trace: [154565.553162] [154565.553165] ? show_trace_log_lvl+0x1c4/0x2df [154565.553172] ? show_trace_log_lvl+0x1c4/0x2df [154565.553177] ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx] [154565.553215] ? __die_body.cold+0x8/0xd [154565.553218] ? page_fault_oops+0x134/0x170 [154565.553223] ? snprintf+0x49/0x70 [154565.553229] ? exc_page_fault+0x62/0x150 [154565.553238] ? asm_exc_page_fault+0x22/0x30 Check for sp being non NULL before freeing any associated memory", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2025-71237", "url": "https://ubuntu.com/security/CVE-2025-71237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: Fix potential block overflow that cause system hang When a user executes the FITRIM command, an underflow can occur when calculating nblocks if end_block is too small. Since nblocks is of type sector_t, which is u64, a negative nblocks value will become a very large positive integer. This ultimately leads to the block layer function __blkdev_issue_discard() taking an excessively long time to process the bio chain, and the ns_segctor_sem lock remains held for a long period. This prevents other tasks from acquiring the ns_segctor_sem lock, resulting in the hang reported by syzbot in [1]. If the ending block is too small, typically if it is smaller than 4KiB range, depending on the usage of the segment 0, it may be possible to attempt a discard request beyond the device size causing the hang. Exiting successfully and assign the discarded size (0 in this case) to range->len. Although the start and len values in the user input range are too small, a conservative strategy is adopted here to safely ignore them, which is equivalent to a no-op; it will not perform any trimming and will not throw an error. [1] task:segctord state:D stack:28968 pid:6093 tgid:6093 ppid:2 task_flags:0x200040 flags:0x00080000 Call Trace: rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272 nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline] nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684 [ryusuke: corrected part of the commit message about the consequences]", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23229", "url": "https://ubuntu.com/security/CVE-2026-23229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add spinlock protection with virtqueue notification When VM boots with one virtio-crypto PCI device and builtin backend, run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head! It seems that the data virtqueue need protection when it is handled for virtio done notification. If the spinlock protection is added in virtcrypto_done_task(), openssl benchmark with multiple processes works well.", "cve_priority": "medium", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23222", "url": "https://ubuntu.com/security/CVE-2026-23222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly The existing allocation of scatterlists in omap_crypto_copy_sg_lists() was allocating an array of scatterlist pointers, not scatterlist objects, resulting in a 4x too small allocation. Use sizeof(*new_sg) to get the correct object size.", "cve_priority": "high", "cve_public_date": "2026-02-18 16:22:00 UTC" }, { "cve": "CVE-2026-23392", "url": "https://ubuntu.com/security/CVE-2026-23392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.", "cve_priority": "high", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-45988", "url": "https://ubuntu.com/security/CVE-2026-45988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix re-decryption of RESPONSE packets If a RESPONSE packet gets a temporary failure during processing, it may end up in a partially decrypted state - and then get requeued for a retry. Fix this by just discarding the packet; we will send another CHALLENGE packet and thereby elicit a further response. Similarly, discard an incoming CHALLENGE packet if we get an error whilst generating a RESPONSE; the server will send another CHALLENGE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46195", "url": "https://ubuntu.com/security/CVE-2026-46195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46135", "url": "https://ubuntu.com/security/CVE-2026-46135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.", "cve_priority": "critical", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31402", "url": "https://ubuntu.com/security/CVE-2026-31402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.", "cve_priority": "critical", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43071", "url": "https://ubuntu.com/security/CVE-2026-43071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dcache: Limit the minimal number of bucket to two There is an OOB read problem on dentry_hashtable when user sets 'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260 There will be only one bucket in dentry_hashtable when dhash_entries is set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then, following process will access more than one buckets(which memory region is not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB! Fix it by limiting the minimal number of dentry_hashtable bucket to two, so that 'd_hash_shift' won't exceeds the bit width of type u32.", "cve_priority": "low", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-46119", "url": "https://ubuntu.com/security/CVE-2026-46119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix slab-out-of-bounds access in auth message processing If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY contains a positive value in its result field, it is treated as an error code by ceph_handle_auth_reply() and returned to handle_auth_reply(). Thereafter, an attempt is made to send the preallocated message of type CEPH_MSG_AUTH, where the returned value is interpreted as the size of the front segment to send. If the result value in the message is greater than the size of the memory buffer allocated for the front segment, an out-of-bounds access occurs, and the content of the memory region beyond this buffer is sent out. This patch fixes the issue by treating only negative values in the result field as errors. Positive values are therefore treated as success in the same way as a zero value. Additionally, a BUG_ON is added to __send_prepared_auth_request() comparing the len parameter to front_alloc_len to prevent sending the message if it exceeds the bounds of the allocation and to make it easier to catch any logic flaws leading to this.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-43501", "url": "https://ubuntu.com/security/CVE-2026-43501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: \tskb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards.", "cve_priority": "critical", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46043", "url": "https://ubuntu.com/security/CVE-2026-46043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43493", "url": "https://ubuntu.com/security/CVE-2026-43493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications.", "cve_priority": "high", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-31637", "url": "https://ubuntu.com/security/CVE-2026-31637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: reject undecryptable rxkad response tickets rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether crypto_skcipher_decrypt() succeeded. A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes. Check the decrypt result and abort the connection with RXKADBADTICKET when ticket decryption fails.", "cve_priority": "critical", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31657", "url": "https://ubuntu.com/security/CVE-2026-31657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: hold claim backbone gateways by reference batadv_bla_add_claim() can replace claim->backbone_gw and drop the old gateway's last reference while readers still follow the pointer. The netlink claim dump path dereferences claim->backbone_gw->orig and takes claim->backbone_gw->crc_lock without pinning the underlying backbone gateway. batadv_bla_check_claim() still has the same naked pointer access pattern. Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate on a stable gateway reference until the read-side work is complete. This keeps the dump and claim-check paths aligned with the lifetime rules introduced for the other BLA claim readers.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31685", "url": "https://ubuntu.com/security/CVE-2026-31685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_eui64: reject invalid MAC header for all packets `eui64_mt6()` derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address. The existing guard only rejects an invalid MAC header when `par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()` can still reach `eth_hdr(skb)` even when the MAC header is not valid. Fix this by removing the `par->fragoff != 0` condition so that packets with an invalid MAC header are rejected before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43117", "url": "https://ubuntu.com/security/CVE-2026-43117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() If overlay is used on top of btrfs, dentry->d_sb translates to overlay's super block and fsid assignment will lead to a crash. Use file_inode(file)->i_sb to always get btrfs_sb.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43114", "url": "https://ubuntu.com/security/CVE-2026-43114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry New test case fails unexpectedly when avx2 matching functions are used. The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo. This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f - This is expected to work, because its the same set after all and it was already loaded once. But with avx2, this fails: nft reports a clashing element. The reported clash is of following form: We successfully re-inserted a . b c . d Then we try to insert a . d avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next. Due to incorrect masking, the skip-step finds the next matching element *only considering the first field*, i.e. we return the already reinserted \"a . b\", even though the last field is different and the entry should not have been matched. No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback. Bisection points to 7711f4bb4b36 (\"netfilter: nft_set_pipapo: fix range overlap detection\") but that fix merely uncovers this bug. Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate. The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31478", "url": "https://ubuntu.com/security/CVE-2026-31478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len() After this commit (e2b76ab8b5c9 \"ksmbd: add support for read compound\"), response buffer management was changed to use dynamic iov array. In the new design, smb2_calc_max_out_buf_len() expects the second argument (hdr2_len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31668", "url": "https://ubuntu.com/security/CVE-2026-31668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: separate dst_cache for input and output paths in seg6 lwtunnel The seg6 lwtunnel uses a single dst_cache per encap route, shared between seg6_input_core() and seg6_output_core(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup. Fix this by splitting the cache into cache_input and cache_output, so each path maintains its own cached dst independently.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31659", "url": "https://ubuntu.com/security/CVE-2026-31659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject oversized global TT response buffers batadv_tt_prepare_tvlv_global_data() builds the allocation length for a global TT response in 16-bit temporaries. When a remote originator advertises a large enough global TT, the TT payload length plus the VLAN header offset can exceed 65535 and wrap before kmalloc(). The full-table response path still uses the original TT payload length when it fills tt_change, so the wrapped allocation is too small and batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object before the later packet-size check runs. Fix this by rejecting TT responses whose TVLV value length cannot fit in the 16-bit TVLV payload length field.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31649", "url": "https://ubuntu.com/security/CVE-2026-31649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix integer underflow in chain mode The jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb->len (total length including page fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc); When a packet has a small linear portion (nopaged_len <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax * i pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware. Fix this by introducing a buf_len local variable clamped to min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmac_xmit() handles page fragments afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31669", "url": "https://ubuntu.com/security/CVE-2026-31669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix slab-use-after-free in __inet_lookup_established The ehash table lookups are lockless and rely on SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability during RCU read-side critical sections. Both tcp_prot and tcpv6_prot have their slab caches created with this flag via proto_register(). However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into tcpv6_prot_override during inet_init() (fs_initcall, level 5), before inet6_init() (module_init/device_initcall, level 6) has called proto_register(&tcpv6_prot). At that point, tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab remains NULL permanently. This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so when these sockets are freed without SOCK_RCU_FREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcu_read_lock can then access freed memory, triggering a slab-use-after-free in __inet_lookup_established. Fix this by splitting the IPv6-specific initialization out of mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called from mptcp_proto_v6_init() before protocol registration. This ensures tcpv6_prot_override.slab correctly inherits the SLAB_TYPESAFE_BY_RCU slab cache.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43011", "url": "https://ubuntu.com/security/CVE-2026-43011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix potential double free of skb When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain: x25_queue_rx_frame returns 1 | v x25_state3_machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25_process_rx_frame returns queued=0 | v x25_backlog_rcv at line 452 sees queued=0 and calls kfree_skb(skb) again This would free the same skb twice. Looking at x25_backlog_rcv: net/x25/x25_in.c:x25_backlog_rcv() { ... queued = x25_process_rx_frame(sk, skb); ... if (!queued) kfree_skb(skb); }", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43037", "url": "https://ubuntu.com/security/CVE-2026-43037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip4ip6_err() Oskar Kjos reported the following problem. ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr value. __ip_options_echo() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->__data, a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE). To fix this we clear skb2->cb[], as suggested by Oskar Kjos. Also add minimal IPv4 header validation (version == 4, ihl >= 5).", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43038", "url": "https://ubuntu.com/security/CVE-2026-43038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31682", "url": "https://ubuntu.com/security/CVE-2026-31682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: linearize skb before parsing ND options br_nd_send() parses neighbour discovery options from ns->opt[] and assumes that these options are in the linear part of request. Its callers only guarantee that the ICMPv6 header and target address are available, so the option area can still be non-linear. Parsing ns->opt[] in that case can access data past the linear buffer. Linearize request before option parsing and derive ns from the linear network header.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-23450", "url": "https://ubuntu.com/security/CVE-2026-23450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1]. smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release(). This leads to two issues: 1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed. The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race): CPU A (softirq) CPU B (process ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* No lock on listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash! Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed. Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight. - Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock(). - Use rcu_read_lock() to protect reading sk_user_data. - Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely. Note: smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected. Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied. [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23428", "url": "https://ubuntu.com/security/CVE-2026-23428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of share_conf in compound request smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without validating tcon->t_state. ksmbd_tree_conn_lookup() checks t_state == TREE_CONNECTED on the initial lookup path, but the compound reuse path bypasses this check entirely. If a prior command in the compound (SMB2_TREE_DISCONNECT) sets t_state to TREE_DISCONNECTED and frees share_conf via ksmbd_share_config_put(), subsequent commands dereference the freed share_conf through work->tcon->share_conf. KASAN report: [ 4.144653] ================================================================== [ 4.145059] BUG: KASAN: slab-use-after-free in smb2_write+0xc74/0xe70 [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44 [ 4.145772] [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY [ 4.145871] 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 [ 4.145875] Workqueue: ksmbd-io handle_ksmbd_work [ 4.145888] Call Trace: [ 4.145892] [ 4.145894] dump_stack_lvl+0x64/0x80 [ 4.145910] print_report+0xce/0x660 [ 4.145919] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 4.145928] ? smb2_write+0xc74/0xe70 [ 4.145931] kasan_report+0xce/0x100 [ 4.145934] ? smb2_write+0xc74/0xe70 [ 4.145937] smb2_write+0xc74/0xe70 [ 4.145939] ? __pfx_smb2_write+0x10/0x10 [ 4.145942] ? _raw_spin_unlock+0xe/0x30 [ 4.145945] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 4.145948] ? smb2_tree_disconnect+0x31c/0x480 [ 4.145951] handle_ksmbd_work+0x40f/0x1080 [ 4.145953] process_one_work+0x5fa/0xef0 [ 4.145962] ? assign_work+0x122/0x3e0 [ 4.145964] worker_thread+0x54b/0xf70 [ 4.145967] ? __pfx_worker_thread+0x10/0x10 [ 4.145970] kthread+0x346/0x470 [ 4.145976] ? recalc_sigpending+0x19b/0x230 [ 4.145980] ? __pfx_kthread+0x10/0x10 [ 4.145984] ret_from_fork+0x4fb/0x6c0 [ 4.145992] ? __pfx_ret_from_fork+0x10/0x10 [ 4.145995] ? __switch_to+0x36c/0xbe0 [ 4.145999] ? __pfx_kthread+0x10/0x10 [ 4.146003] ret_from_fork_asm+0x1a/0x30 [ 4.146013] [ 4.146014] [ 4.149858] Allocated by task 44: [ 4.149953] kasan_save_stack+0x33/0x60 [ 4.150061] kasan_save_track+0x14/0x30 [ 4.150169] __kasan_kmalloc+0x8f/0xa0 [ 4.150274] ksmbd_share_config_get+0x1dd/0xdd0 [ 4.150401] ksmbd_tree_conn_connect+0x7e/0x600 [ 4.150529] smb2_tree_connect+0x2e6/0x1000 [ 4.150645] handle_ksmbd_work+0x40f/0x1080 [ 4.150761] process_one_work+0x5fa/0xef0 [ 4.150873] worker_thread+0x54b/0xf70 [ 4.150978] kthread+0x346/0x470 [ 4.151071] ret_from_fork+0x4fb/0x6c0 [ 4.151176] ret_from_fork_asm+0x1a/0x30 [ 4.151286] [ 4.151332] Freed by task 44: [ 4.151418] kasan_save_stack+0x33/0x60 [ 4.151526] kasan_save_track+0x14/0x30 [ 4.151634] kasan_save_free_info+0x3b/0x60 [ 4.151751] __kasan_slab_free+0x43/0x70 [ 4.151861] kfree+0x1ca/0x430 [ 4.151952] __ksmbd_tree_conn_disconnect+0xc8/0x190 [ 4.152088] smb2_tree_disconnect+0x1cd/0x480 [ 4.152211] handle_ksmbd_work+0x40f/0x1080 [ 4.152326] process_one_work+0x5fa/0xef0 [ 4.152438] worker_thread+0x54b/0xf70 [ 4.152545] kthread+0x346/0x470 [ 4.152638] ret_from_fork+0x4fb/0x6c0 [ 4.152743] ret_from_fork_asm+0x1a/0x30 [ 4.152853] [ 4.152900] The buggy address belongs to the object at ffff88810430c180 [ 4.152900] which belongs to the cache kmalloc-96 of size 96 [ 4.153226] The buggy address is located 20 bytes inside of [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0) [ 4.153549] [ 4.153596] The buggy address belongs to the physical page: [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c [ 4.154000] flags: 0x ---truncated---", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23455", "url": "https://ubuntu.com/security/CVE-2026-23455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read. Add a check to ensure len is positive after the decrement.", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43186", "url": "https://ubuntu.com/security/CVE-2026-43186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43185", "url": "https://ubuntu.com/security/CVE-2026-43185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix signededness bug in smb_direct_prepare_negotiation() smb_direct_prepare_negotiation() casts an unsigned __u32 value from sp->max_recv_size and req->preferred_send_size to a signed int before computing min_t(int, ...). A maliciously provided preferred_send_size of 0x80000000 will return as smaller than max_recv_size, and then be used to set the maximum allowed alowed receive size for the next message. By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow. This fix replaces min_t(int, ...) with min_t(u32)", "cve_priority": "critical", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43341", "url": "https://ubuntu.com/security/CVE-2026-43341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31607", "url": "https://ubuntu.com/security/CVE-2026-31607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: validate number_of_packets in usbip_pack_ret_submit() When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the *original* number_of_packets from the CMD_SUBMIT. A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region. KASAN confirmed this with kernel 7.0.0-rc5: BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69 The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40) The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 (\"usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input\") and b78d830f0049 (\"usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input\"). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets. This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size. Kelvin Mbogo's series (\"usb: usbip: fix integer overflow in usbip_recv_iso()\", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit. Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43383", "url": "https://ubuntu.com/security/CVE-2026-43383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-md5: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2025-68263", "url": "https://ubuntu.com/security/CVE-2025-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: ipc: fix use-after-free in ipc_msg_send_request ipc_msg_send_request() waits for a generic netlink reply using an ipc_msg_table_entry on the stack. The generic netlink handler (handle_generic_event()/handle_response()) fills entry->response under ipc_msg_table_lock, but ipc_msg_send_request() used to validate and free entry->response without holding the same lock. Under high concurrency this allows a race where handle_response() is copying data into entry->response while ipc_msg_send_request() has just freed it, leading to a slab-use-after-free reported by KASAN in handle_generic_event(): BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd] Write of size 12 at addr ffff888198ee6e20 by task pool/109349 ... Freed by task: kvfree ipc_msg_send_request [ksmbd] ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd] Fix by: - Taking ipc_msg_table_lock in ipc_msg_send_request() while validating entry->response, freeing it when invalid, and removing the entry from ipc_msg_table. - Returning the final entry->response pointer to the caller only after the hash entry is removed under the lock. - Returning NULL in the error path, preserving the original API semantics. This makes all accesses to entry->response consistent with handle_response(), which already updates and fills the response buffer under ipc_msg_table_lock, and closes the race that allowed the UAF.", "cve_priority": "critical", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2026-46243", "url": "https://ubuntu.com/security/CVE-2026-46243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key.", "cve_priority": "medium", "cve_public_date": "2026-06-01 17:17:00 UTC" }, { "cve": "CVE-2026-43414", "url": "https://ubuntu.com/security/CVE-2026-43414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Completely fix fcport double free In qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free(). When an error happens, this function is called by qla2x00_sp_release(), when kref_put() releases the first and the last reference. qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport(). Doing it one more time after kref_put() is a bad idea.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43407", "url": "https://ubuntu.com/security/CVE-2026-43407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply() This patch fixes an out-of-bounds access in ceph_handle_auth_reply() that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In ceph_handle_auth_reply(), the value of the payload_len field of such a message is stored in a variable of type int. A value greater than INT_MAX leads to an integer overflow and is interpreted as a negative value. This leads to decrementing the pointer address by this value and subsequently accessing it because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. This patch fixes the issue by changing the data type of payload_len to u32. Additionally, the data type of result_msg_len is changed to u32, as it is also a variable holding a non-negative length. Also, an additional layer of sanity checks is introduced, ensuring that directly after reading it from the message, payload_len and result_msg_len are not greater than the overall segment length. BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph] Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262 CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ceph-msgr ceph_con_workfn [libceph] Call Trace: dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x620 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x72/0x210 kasan_report+0xe7/0x130 ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] __asan_report_load_n_noabort+0xf/0x20 ceph_handle_auth_reply+0x642/0x7a0 [libceph] mon_dispatch+0x973/0x23d0 [libceph] ? apparmor_socket_recvmsg+0x6b/0xa0 ? __pfx_mon_dispatch+0x10/0x10 [libceph] ? __kasan_check_write+0x14/0x30i ? mutex_unlock+0x7f/0xd0 ? __pfx_mutex_unlock+0x10/0x10 ? __pfx_do_recvmsg+0x10/0x10 [libceph] ceph_con_process_message+0x1f1/0x650 [libceph] process_message+0x1e/0x450 [libceph] ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] ? save_fpregs_to_fpstate+0xb0/0x230 ? raw_spin_rq_unlock+0x17/0xa0 ? finish_task_switch.isra.0+0x13b/0x760 ? __switch_to+0x385/0xda0 ? __kasan_check_write+0x14/0x30 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 ceph_con_workfn+0x248/0x10c0 [libceph] process_one_work+0x629/0xf80 ? __kasan_check_write+0x14/0x30 worker_thread+0x87f/0x1570 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_try_to_wake_up+0x10/0x10 ? kasan_print_address_stack_frame+0x1f7/0x280 ? __pfx_worker_thread+0x10/0x10 kthread+0x396/0x830 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? __pfx_kthread+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? recalc_sigpending+0x180/0x210 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3f7/0x610 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x385/0xda0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 [ idryomov: replace if statements with ceph_decode_need() for payload_len and result_msg_len ]", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43406", "url": "https://ubuntu.com/security/CVE-2026-43406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in process_message_header() If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in process_message_header(). Perform an explicit bounds check before decoding the message header.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43304", "url": "https://ubuntu.com/security/CVE-2026-43304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.", "cve_priority": "critical", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-37924", "url": "https://ubuntu.com/security/CVE-2025-37924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in kerberos authentication Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbd_free_user but before sess->user is set to NULL.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-37778", "url": "https://ubuntu.com/security/CVE-2025-37778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix dangling pointer in krb_authenticate krb_authenticate frees sess->user and does not set the pointer to NULL. It calls ksmbd_krb5_authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2_sess_setup, which calls krb_authenticate, will be accessing free'd memory when it later uses sess->user.", "cve_priority": "high", "cve_public_date": "2025-05-01 14:15:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1104.109 -proposed tracker (LP: #2157390)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] resync retpoline extraction", "", " [ Ubuntu: 5.15.0-186.196 ]", "", " * jammy/linux: 5.15.0-186.196 -proposed tracker (LP: #2157405)", " * [Jammy] Priority inversion problem in epoll for rt kernel (LP: #2154194)", " - eventpoll: Replace rwlock with spinlock", " * CVE-2026-46137", " - mptcp: pm: ADD_ADDR rtx: fix potential data-race", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901)", " - Linux 5.15.208", " - ALSA: asihpi: avoid write overflow check warning", " - can: mcp251x: add error handling for power enable in open and resume", " - ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg0xxx", " - ASoC: soc-core: call missing INIT_LIST_HEAD() for card_aux_list", " - ALSA: usb-audio: Fix quirk flags for NeuralDSP Quad Cortex", " - pinctrl: intel: Fix the revision for new features (1kOhm PD, HW", " debouncer)", " - HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3", " - ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585", " - ASoC: stm32_sai: fix incorrect BCLK polarity for DSP_A/B, LEFT_J", " - soc: aspeed: socinfo: Mask table entries for accurate SoC ID matching", " - arm64: dts: imx8mq: Set the correct gpu_ahb clock frequency", " - PCI: hv: Set default NUMA node to 0 for devices without affinity info", " - drm/vc4: Protect madv read in vc4_gem_object_mmap() with madv_lock", " - epoll: use refcount to reduce ep_mutex contention", " - tracing/probe: reject non-closed empty immediate strings", " - e1000: check return value of e1000_read_eeprom", " - gpio: tegra: fix irq_release_resources calling enable instead of disable", " - i3c: fix uninitialized variable use in i2c setup", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - mips: mm: Allocate tlb_vpn array atomically", " - MIPS: Always record SEGBITS in cpu_data.vmbits", " - MIPS: mm: Suppress TLB uniquification on EHINV hardware", " - MIPS: mm: Rewrite TLB uniquification for the hidden bit feature", " - ALSA: usb-audio: Update for native DSD support quirks", " - usb: storage: Expand range of matched versions for VL817 quirks entry", " - USB: serial: option: add Telit Cinterion FN990A MBIM composition", " - fsl-mc: Use driver_set_override() instead of open-coding", " - checkpatch: add support for Assisted-by tag", " - gfs2: Improve gfs2_consist_inode() usage", " - PCI/ACPI: Restrict program_hpx_type2() to AER bits", " - netfilter: nft_set_pipapo: do not rely on ZERO_SIZE_PTR", " - powerpc64/bpf: do not increment tailcall count when prog is NULL", " - arm64: dts: imx8mq-librem5: Set the DVS voltages lower", " - arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage to 0.81V", " - Revert \"arm64: dts: imx8mq-librem5: Set the DVS voltages lower\"", " - arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V", " - ocfs2: add inline inode consistency check to", " ocfs2_validate_inode_block()", " - rxrpc: Fix key quota calculation for multitoken keys", " - fs/ocfs2: fix comments mentioning i_mutex", " - MPTCP: fix lock class name family in pm_nl_create_listen_socket", " - Revert \"nvme: nvme-fc: Ensure ->ioerr_work is cancelled in", " nvme_fc_delete_ctrl()\"", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", " - s390/xor: Fix xor_xc_2() inline assembly constraints", " - net: add skb_header_pointer_careful() helper", " - x86/uprobes: Fix XOL allocation failure for 32-bit tasks", " - iio: imu: inv_icm42600: fix odr switch when turning buffer off", " - vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check", " - net: usb: lan78xx: Fix double free issue with interrupt buffer", " allocation", " - SAUCE: Revert \"fs/ntfs3: Fixed overflow check in mi_enum_attr()\"", " - SAUCE: Revert \"fs/ntfs3: Sequential field availability check in", " mi_enum_attr()\"", " - SAUCE: Revert \"ntfs3: Add bounds checking to mi_enum_attr()\"", " - cpufreq: governor: Free dbs_data directly when gov->init() fails", " - scripts/dtc: Remove unused dts_version in dtc-lexer.l", " - rxrpc: Fix anonymous key handling", " - iommu: fix a reference count leak in iommu_sva_bind_device()", " - fuse: quiet down complaints in fuse_conn_limit_write", " - ALSA: usb-audio: apply quirk for MOONDROP JU Jiu", " - tty: n_gsm: fix flow control handling in tx path", " - ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free", " - ALSA: usb-audio: Avoid false E-MU sample-rate notifications", " - ALSA: usb-audio: Fix Audio Advantage Micro II SPDIF switch", " - usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable()", " - ALSA: usb-audio: Evaluate packsize caps at the right place", " - firmware: google: framebuffer: Do not mark framebuffer as busy", " - device property: Make modifications of fwnode \"flags\" thread safe", " - driver core: Don't let a device probe until it's ready", " - um: drivers: call kernel_strrchr() explicitly in cow_user.c", " - Revert \"ALSA: usb: Increase volume range that triggers a warning\"", " - lib/ts_kmp: fix integer overflow in pattern length calculation", " - media: i2c: imx219: Check return value of devm_gpiod_get_optional() in", " imx219_probe()", " - ALSA: aoa: i2sbus: fix OF node lifetime handling", " - ALSA: seq_oss: return full count for successful SEQ_FULLSIZE writes", " - nvme-pci: add NVME_QUIRK_DISABLE_WRITE_ZEROES for Kingston OM3SGP4", " - parisc: _llseek syscall is only available for 32-bit userspace", " - selftests/mqueue: Fix incorrectly named file", " - ALSA: caiaq: Fix control_put() result and cache rollback", " - ALSA: 6fire: Fix input volume change detection", " - iio: adc: ad7768-1: fix one-shot mode data acquisition", " - drm/arcpgu: fix device node leak", " - tpm: avoid -Wunused-but-set-variable", " - power: supply: axp288_charger: Do not cancel work before initializing it", " - mmc: block: use single block write in retry", " - tpm: tpm_tis: add error logging for data transfer", " - rtc: ntxec: fix OF node reference imbalance", " - userfaultfd: allow registration of ranges below mmap_min_addr", " - KVM: nSVM: Mark all of vmcb02 dirty when restoring nested state", " - KVM: SVM: Explicitly mark vmcb01 dirty after modifying VMCB intercepts", " - KVM: nSVM: Ensure AVIC is inhibited when restoring a vCPU to guest mode", " - KVM: nSVM: Always inject a #GP if mapping VMCB12 fails on nested VMRUN", " - KVM: nSVM: Clear GIF on nested #VMEXIT(INVALID)", " - KVM: nSVM: Add missing consistency check for nCR3 validity", " - io_uring/poll: fix EPOLL_URING_WAKE sometimes not being honored", " - io_uring/poll: fix backport of io_poll_add() changes", " - mtd: docg3: Convert to platform remove callback returning void", " - taskstats: set version in TGID exit notifications", " - crypto: arm64/aes - Fix 32-bit aes_mac_update() arg treated as 64-bit", " - crypto: atmel-ecc - Release client on allocation failure", " - crypto: hisilicon - Fix dma_unmap_single() direction", " - IB/core: Fix zero dmac race in neighbor resolution", " - ktest: Fix the month in the name of the failure directory", " - seg6: fix seg6 lwtunnel output redirect for L2 reduced encap mode", " - driver core: Add kernel-doc for DEV_FLAG_COUNT enum value", " - ALSA: caiaq: Fix potentially leftover ep1_in_urb at error path", " - ALSA: caiaq: Don't abort when no input device is available", " - drm/amdgpu: fix zero-size GDS range init on RDNA4", " - ALSA: caiaq: fix usb_dev refcount leak on probe failure", " - ACPI: scan: Use acpi_dev_put() in object add error paths", " - ACPI: CPPC: Fix related_cpus inconsistency during CPU hotplug", " - ACPI: video: force native backlight on HP OMEN 16 (8A44)", " - spi: rockchip: fix controller deregistration", " - um: virt-pci: Fix build failure", " - ipmi:ssif: Fix a shutdown race", " - ipmi:ssif: Remove unnecessary indention", " - ipmi:ssif: NULL thread on error", " - ALSA: usb-audio: Fix UAC3 cluster descriptor size check", " - USB: omap_udc: DMA: Don't enable burst 4 mode", " - USB: serial: option: add Telit Cinterion LE910Cx compositions", " - usb: ulpi: fix memory leak on ulpi_register() error paths", " - ALSA: firewire-tascam: Do not drop unread control events", " - xfrm: provide message size for XFRM_MSG_MAPPING", " - spi: zynqmp-gqspi: fix controller deregistration", " - parisc: Fix IRQ leak in LASI driver", " - hwmon: (ltc2992) Clamp threshold writes to hardware range", " - hwmon: (ltc2992) Fix u32 overflow in power read path", " - hwmon: (corsair-psu) Close HID device on probe errors", " - extcon: ptn5150: handle pending IRQ events during system resume", " - hv_sock: fix ARM64 support", " - udf: reject descriptors with oversized CRC length", " - thermal/drivers/sprd: Fix temperature clamping in", " sprd_thm_temp_to_rawdata", " - thermal/drivers/sprd: Fix raw temperature clamping in", " sprd_thm_rawdata_to_temp", " - cpuidle: powerpc: avoid double clear when breaking snooze", " - ASoC: fsl_easrc: fix comment typo", " - ASoC: Intel: bytcr_wm5102: Fix MCLK leak on platform_clock_control error", " - dm: don't report warning when doing deferred remove", " - dm-verity-fec: correctly reject too-small FEC devices", " - dm-verity-fec: correctly reject too-small hash devices", " - s390/debug: Reject zero-length input in debug_input_flush_fn()", " - PCI/AER: Clear only error bits in PCIe Device Status", " - PCI/AER: Stop ruling out unbound devices as error source", " - power: supply: max17042: avoid overflow when determining health", " - mptcp: use MPJoinSynAckHMacFailure for SynAck HMAC failure", " - mptcp: use MPTCP_RST_EMPTCP for ACK HMAC validation failure", " - mptcp: sockopt: set timestamp flags on subflow socket, not msk", " - platform/x86: hp-wmi: Ignore backlight and FnLock events", " - media: uvcvideo: Enable VB2_DMABUF for metadata stream", " - media: i2c: ov8856: free control handler on error in", " ov8856_init_controls()", " - regulator: max77650: fix OF node reference imbalance", " - media: rc: streamzap: Error handling in probe", " - regulator: act8945a: fix OF node reference imbalance", " - regulator: bd9571mwv: fix OF node reference imbalance", " - media: dib8000: avoid division by 0 in dib8000_set_dds()", " - media: i2c: imx412: Assert reset GPIO during probe", " - spi: mtk-nor: fix controller deregistration", " - spi: imx: fix runtime pm leak on probe deferral", " - spi: orion: fix clock imbalance on registration failure", " - drm/radeon: add missing revision check for CI", " - drm/amdgpu/gfx9: drop unnecessary 64-bit fence flag check in KIQ", " - drm/amdgpu/pm: add missing revision check for CI", " - drm/amdgpu/pm: align Hawaii mclk workaround with radeon", " - drm/amdgpu/vcn3: Avoid overflow on msg bound check", " - bcache: fix uninitialized closure object", " - fs/omfs: reject s_sys_blocksize smaller than OMFS_DIR_START", " - drbd: Balance RCU calls in drbd_adm_dump_devices()", " - nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()", " - pstore/ram: fix resource leak when ioremap() fails", " - devres: fix missing node debug info in devm_krealloc()", " - thermal/drivers/spear: Fix error condition for reading st,thermal-flags", " - debugfs: check for NULL pointer in debugfs_create_str()", " - irqchip/irq-pic32-evic: Address warning related to wrong printf()", " formatter", " - locking: Fix rwlock support in ", " - firmware: dmi: Correct an indexing error in dmi.h", " - wifi: mwifiex: Fix memory leak in mwifiex_11n_aggregate_pkt()", " - wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished", " irq_prepare_bcn_tasklet", " - dpaa2: add independent dependencies for FSL_DPAA2_SWITCH", " - [Config] Disable FSL_DPAA2_SWITCH on armhf, ppc64el", " - dpaa2: compile dpaa2 even CONFIG_FSL_DPAA2_ETH=n", " - kernel: param: rename locate_module_kobject", " - kernel: globalize lookup_or_create_module_kobject()", " - params: Replace __modinit with __init_or_module", " - module: Fix freeing of charp module parameters when CONFIG_SYSFS=n", " - bpf, devmap: Remove unnecessary if check in for loop", " - bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path", " - r8152: fix incorrect register write to USB_UPHY_XTAL", " - powerpc/crash: fix backup region offset update to elfcorehdr", " - macvlan: annotate data-races around port->bc_queue_len_used", " - wifi: brcmfmac: Fix error pointer dereference", " - bpf-lsm: Make bpf_lsm_userns_create() sleepable", " - bpf: Drop task_to_inode and inet_conn_established from lsm sleepable", " hooks", " - net: bcmgenet: fix off-by-one in bcmgenet_put_txcb", " - netfilter: xt_socket: enable defrag after all other checks", " - netfilter: nft_fwd_netdev: check ttl/hl before forwarding", " - 6pack: propagage new tty types", " - net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf", " - net/rds: Optimize rds_ib_laddr_check", " - net/rds: Restrict use of RDS/IB to the initial network namespace", " - ppp: require CAP_NET_ADMIN in target netns for unattached ioctls", " - bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb", " - Bluetooth: L2CAP: Fix printing wrong information if SDU length exceeds", " MTU", " - Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error", " - Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER", " - Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp", " - net: phy: qcom: at803x: Use the correct bit to disable extended next", " page", " - sctp: fix missing encap_port propagation for GSO fragments", " - net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master", " - drm/komeda: fix integer overflow in AFBC framebuffer size check", " - ASoC: sti: Return errors from regmap_field_alloc()", " - ASoC: sti: use managed regmap_field allocations", " - dm cache: fix null-deref with concurrent writes in passthrough mode", " - dm cache: fix write path cache coherency in passthrough mode", " - dm cache policy smq: fix missing locks in invalidating cache blocks", " - dm cache: fix concurrent write failure in passthrough mode", " - dm cache: support shrinking the origin device", " - dm cache: fix dirty mapping checking in passthrough mode switching", " - dm cache metadata: fix memory leak on metadata abort retry", " - dm log: fix out-of-bounds write due to region_count overflow", " - spi: fsl-qspi: Use reinit_completion() for repeated operations", " - drm/sun4i: Fix resource leaks", " - dm init: ensure device probing has finished in dm-mod.waitfor=", " - fbdev: matroxfb: Mark variable with __maybe_unused to avoid W=1 build", " break", " - spi: hisi-kunpeng: prevent infinite while() loop in hisi_spi_flush_fifo", " - drm/msm/dsi: rename MSM8998 DSI version from V2_2_0 to V2_0_0", " - drm/panel: simple: Correct G190EAN01 prepare timing", " - ALSA: core: Validate compress device numbers without dynamic minors", " - drm/amd/pm/ci: Use highest MCLK on CI when MCLK DPM is disabled", " - drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs", " - drm/amd/pm/smu7: Fix SMU7 voltage dependency on display clock", " - drm/amd/pm/ci: Fix powertune defaults for Hawaii 0x67B0", " - drm/amd/pm/ci: Clear EnabledForActivity field for memory levels", " - drm/amd/pm/ci: Fill DW8 fields from SMC", " - drm/amd/pm/smu7: Add SCLK cap for quirky Hawaii board", " - ALSA: hda/realtek: Whitespace fix", " - ALSA: hda/realtek: fix code style (ERROR: else should follow close brace", " '}')", " - drm/msm/a6xx: Fix HLSQ register dumping", " - drm/msm/a6xx: Use barriers while updating HFI Q headers", " - pmdomain: ti: omap_prm: Fix a reference leak on device node", " - pmdomain: imx: scu-pd: Fix device_node reference leak during ->probe()", " - ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_arc_mode_put()", " - ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_mode_put()", " - ASoC: fsl_easrc: Check the variable range in fsl_easrc_iec958_put_bits()", " - ASoC: fsl_easrc: Fix value type in fsl_easrc_iec958_get_bits()", " - ASoC: fsl_easrc: Change the type for iec958 channel status controls", " - PCI: Enable AtomicOps only if Root Port supports them", " - Documentation: fix a hugetlbfs reservation statement", " - selftest: memcg: skip memcg_sock test if address family not supported", " - PCI: Add PCIE_PME_TO_L2_TIMEOUT_US L2 ready timeout value", " - PCI: tegra194: Fix polling delay for L2 state", " - PCI: tegra194: Increase LTSSM poll time on surprise link down", " - PCI: tegra194: Disable LTSSM after transition to Detect on surprise link", " down", " - PCI: tegra194: Use devm_gpiod_get_optional() to parse \"nvidia,refclk-", " select\"", " - PCI: tegra194: Disable direct speed change for Endpoint mode", " - ALSA: sc6000: Use standard print API", " - ALSA: sc6000: Keep the programmed board state in card-private data", " - ktest: Avoid undef warning when WARNINGS_FILE is unset", " - ktest: Honor empty per-test option overrides", " - ktest: Run POST_KTEST hooks on failure and cancellation", " - quota: Fix race of dquot_scan_active() with quota deactivation", " - gfs2: add some missing log locking", " - gfs2: prevent NULL pointer dereference during unmount", " - efi/capsule-loader: fix incorrect sizeof in phys array reallocation", " - ksmbd: fix use-after-free from async crypto on Qualcomm crypto engine", " - ARM: dts: mediatek: mt7623: fix efuse fallback compatible", " - memory: tegra124-emc: Fix dll_change check", " - memory: tegra30-emc: Fix dll_change check", " - soc: qcom: ocmem: use scoped device node handling to simplify error", " paths", " - soc: qcom: ocmem: register reasons for probe deferrals", " - soc: qcom: ocmem: return -EPROBE_DEFER is ocmem is not available", " - arm64: dts: qcom: sdm845-xiaomi-beryllium: Mark l1a regulator as powered", " during boot", " - unshare: fix nsproxy leak in ksys_unshare() on set_cred_ucounts()", " failure", " - ocfs2/dlm: validate qr_numregions in dlm_match_regions()", " - ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison", " - soc: qcom: aoss: compare against normalized cooling state", " - ocfs2: fix listxattr handling when the buffer is full", " - ocfs2: validate bg_bits during freefrag scan", " - ocfs2: validate group add input before caching", " - dmaengine: dw-axi-dmac: Remove unnecessary return statement from void", " function", " - dmaengine: mxs-dma: Fix missing return value from", " of_dma_controller_register()", " - tracing: Rebuild full_name on each hist_field_name() call", " - ima: check return value of crypto_shash_final() in boot aggregate", " - HID: asus: make asus_resume adhere to linux kernel coding standards", " - HID: asus: do not abort probe when not necessary", " - mtd: physmap_of_gemini: Fix disabled pinctrl state check", " - mtd: spi-nor: core: correct the op.dummy.nbytes when check read", " operations", " - mtd: spi-nor: swp: check SR_TB flag when getting tb_mask", " - mtd: parsers: ofpart: call of_node_put() only in ofpart_fail path", " - mtd: parsers: ofpart: call of_node_get() for dedicated subpartitions", " - mtd: rawnand: sunxi: fix sunxi_nfc_hw_ecc_read_extra_oob", " - HID: usbhid: fix deadlock in hid_post_reset()", " - pinctrl: pinctrl-pic32: Fix resource leak", " - perf branch: Avoid incrementing NULL", " - perf: tools: cs-etm: Fix print issue for Coresight debug in ETE/TRBE", " trace", " - pinctrl: abx500: Fix type of 'argument' variable", " - perf expr: Return -EINVAL for syntax error in expr__find_ids()", " - perf util: Kill die() prototype, dead for a long time", " - i3c: mipi-i3c-hci: fix IBI payload length calculation for final status", " - driver core: device.h: remove extern from function prototypes", " - driver core: Move dev_err_probe() to where it belogs", " - dev_printk: add new dev_err_probe() helpers", " - backlight: sky81452-backlight: Check return value of", " devm_gpiod_get_optional() in sky81452_bl_parse_dt()", " - platform/surface: surfacepro3_button: Drop wakeup source on remove", " - leds: lgm-sso: Remove duplicate assignments for priv->mmap", " - tty: hvc: remove HVC_IUCV_MAGIC", " - tty: hvc_iucv: fix off-by-one in number of supported devices", " - platform/x86: panasonic-laptop: Fix OPTD notifier registration and", " cleanup", " - mfd: mc13xxx-core: Fix memory leak in mc13xxx_add_subdevice_pdata()", " - nfs/blocklayout: Fix compilation error (`make W=1`) in", " bl_write_pagelist()", " - fs/ntfs3: terminate the cached volume label after UTF-8 conversion", " - platform/x86: dell_rbu: avoid uninit value usage in packet_size_write()", " - platform/x86: dell-wmi-sysman: bound enumeration string aggregation", " - RDMA/core: Prefer NLA_NUL_STRING", " - scsi: sg: Resolve soft lockup issue when opening /dev/sgX", " - scsi: target: core: Fix integer overflow in UNMAP bounds check", " - dt-bindings: clock: qcom,gcc-sc8180x: Add missing GDSCs", " - clk: qcom: gcc-sc8180x: Add missing GDSCs", " - clk: qcom: gcc-sc8180x: Use retention for USB power domains", " - clk: qcom: gcc-sc8180x: Use retention for PCIe power domains", " - clk: qcom: dispcc-sm8250: Use shared ops on the mdss vsync clk", " - clk: qcom: dispcc-sm8250: Enable parents for pixel clocks", " - clk: imx: imx6q: Fix device node reference leak in pll6_bypassed()", " - clk: imx: imx6q: Fix device node reference leak in", " of_assigned_ldb_sels()", " - clk: imx8mq: Correct the CSI PHY sels", " - clk: qoriq: avoid format string warning", " - clk: xgene: Fix mapping leak in xgene_pllclk_init()", " - dt-bindings: clock: qcom,dispcc-sc7180: Define MDSS resets", " - clk: qcom: dispcc-sc7180: Add missing MDSS resets", " - lib/hexdump: print_hex_dump_bytes() calls print_hex_dump_debug()", " - crypto: sa2ul - Fix AEAD fallback algorithm names", " - crypto: ccp - copy IV using skcipher ivsize", " - PCMCIA: Fix garbled log messages for KERN_CONT", " - net/sched: sch_cake: fix NAT destination port not being updated in", " cake_update_flowkeys", " - nexthop: fix IPv6 route referencing IPv4 nexthop", " - net/sched: taprio: stop going through private ops for dequeue and peek", " - net/sched: taprio: replace safety precautions with comments", " - net/sched: taprio: continue with other TXQs if one dequeue() failed", " - net/sched: taprio: refactor one skb dequeue from TXQ to separate", " function", " - net/sched: taprio: rename close_time to end_time", " - net/sched: taprio: fix use-after-free in advance_sched() on schedule", " switch", " - tcp: annotate data-races around (tp->write_seq - tp->snd_nxt)", " - i40e: don't advertise IFF_SUPP_NOFCS", " - e1000e: Unroll PTP in probe error handling", " - ipv6: fix possible UAF in icmpv6_rcv()", " - sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks", " - dissector: do not set invalid PPP protocol", " - flow_dissector: Add number of vlan tags dissector", " - flow_dissector: Add PPPoE dissectors", " - pppoe: drop PFC frames", " - netfilter: nft_osf: restrict it to ipv4", " - netfilter: conntrack: remove sprintf usage", " - netfilter: xtables: restrict several matches to inet family", " - ipvs: fix MTU check for GSO packets in tunnel mode", " - netfilter: nfnetlink_osf: fix out-of-bounds read on option matching", " - netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check", " - arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number", " - ksmbd: destroy tree_conn_ida in ksmbd_session_destroy()", " - ksmbd: scope conn->binding slowpath to bound sessions only", " - net/rds: zero per-item info buffer before handing it to visitors", " - net_sched: sch_hhf: annotate data-races in hhf_dump_stats()", " - net/sched: sch_pie: annotate data-races in pie_dump_stats()", " - net/sched: sch_fq_codel: remove data-races from fq_codel_dump_stats()", " - net: sched: gred/red: remove unused variables in struct red_stats", " - net/sched: sch_red: annotate data-races in red_dump_stats()", " - net/sched: sch_sfb: annotate data-races in sfb_dump_stats()", " - nfp: fix swapped arguments in nfp_encode_basic_qdr() calls", " - tipc: fix double-free in tipc_buf_append()", " - vhost_net: fix sleeping with preempt-disabled in vhost_net_busy_poll()", " - fs/adfs: validate nzones in adfs_validate_bblk()", " - rtc: abx80x: Disable alarm feature if no interrupt attached", " - fbdev: offb: fix PCI device reference leak on probe failure", " - mailbox: mailbox-test: free channels on probe error", " - cgroup/rdma: fix integer overflow in rdmacg_try_charge()", " - mailbox: add sanity check for channel array", " - mailbox: mailbox-test: don't free the reused channel", " - mailbox: mailbox-test: initialize struct earlier", " - mailbox: mailbox-test: make data_ready a per-instance variable", " - btrfs: fix double-decrement of bytes_may_use in", " submit_one_async_extent()", " - tracing: branch: Fix inverted check on stat tracer registration", " - drm/amdgpu: fix spelling typos", " - drm/amdgpu/uvd3.1: Don't validate the firmware when already validated", " - drm/amdgpu/gfx6: Support harvested SI chips with disabled TCCs (v2)", " - netfilter: xt_policy: fix strict mode inbound policy matching", " - netfilter: nf_conntrack_sip: don't use simple_strtoul", " - scsi: sr: Add memory allocation failure handling for get_capabilities()", " - cdrom, scsi: sr: propagate read-only status to block layer via", " set_disk_ro()", " - netdevsim: zero initialize struct iphdr in dummy sk_buff", " - net: sched: sch_netem: Refactor code in 4-state loss generator", " - net/sched: netem: fix probability gaps in 4-state loss model", " - net/sched: netem: fix queue limit check to include reordered packets", " - net/sched: netem: validate slot configuration", " - net: sched: choke: remove unused variables in struct choke_sched_data", " - net/sched: sch_choke: annotate data-races in choke_dump_stats()", " - net/sched: sch_fq_pie: annotate data-races in fq_pie_dump_stats()", " - vrf: Fix a potential NPD when removing a port from a VRF", " - net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()", " - net: usb: rtl8150: free skb on usb_submit_urb() failure in xmit", " - NFC: trf7970a: Ignore antenna noise when checking for RF field", " - net: phy: dp83869: fix setting CLK_O_SEL field.", " - ASoC: codecs: ab8500: Fix casting of private data", " - netfilter: skip recording stale or retransmitted INIT", " - sctp: discard stale INIT after handshake completion", " - ipv4: rename and move ip_route_output_tunnel()", " - ipv4: remove \"proto\" argument from udp_tunnel_dst_lookup()", " - ipv4: add new arguments to udp_tunnel_dst_lookup()", " - ipv6: rename and move ip6_dst_lookup_tunnel()", " - net/sched: sch_cake: annotate data-races in cake_dump_stats() (V)", " - ALSA: hda/conexant: add a new hda codec SN6140", " - ALSA: hda/conexant: fix some typos", " - ALSA: hda/conexant: Renaming the codec with device ID 0x1f86 and 0x1f87", " - ALSA: hda/conexant: Fix missing error check for jack detection", " - drm/amd/display: Allow DCE link encoder without AUX registers", " - drm/amd/display: Read EDID from VBIOS embedded panel info", " - btrfs: tracepoints: fix sleep while in atomic context in", " btrfs_sync_file()", " - flow_dissector: do not dissect PPPoE PFC frames", " - flow_dissector: Do not count vlan tags inside tunnel payload", " - net/sched: sch_pie: annotate more data-races in pie_dump_stats()", " - crypto: af_alg - Cap AEAD AD length to 0x80000000", " - i40e: Cleanup PTP pins on probe failure", " - audit: fix incorrect inheritable capability in CAPSET records", " - netfilter: nft_ct: fix missing expect put in obj eval", " - net: atlantic: preserve PCI wake-from-D3 on shutdown when WOL enabled", " - audit: enforce AUDIT_LOCKED for AUDIT_TRIM and AUDIT_MAKE_EQUIV", " - KVM: Reject wrapped offset in kvm_reset_dirty_gfn()", " - KVM: x86: Fix Xen hypercall tracepoint argument assignment", " - drm/i915/dp: Fix VSC dynamic range signaling for RGB formats", " - ALSA: usb-audio: Bound MIDI endpoint descriptor scans", " - ceph: fix a buffer leak in __ceph_setxattr()", " - powerpc/warp: Fix error handling in pika_dtm_thread", " - libceph: Fix potential out-of-bounds access in osdmap_decode()", " - libceph: Fix potential null-ptr-deref in decode_choose_args()", " - libceph: Fix potential out-of-bounds access in crush_decode()", " - libceph: handle rbtree insertion error in decode_choose_args()", " - iommu/vt-d: Disable DMAR for Intel Q35 IGFX", " - drm/i915: skip __i915_request_skip() for already signaled requests", " - drm/panfrost: Fix wait_bo ioctl leaking positive return from", " dma_resv_wait_timeout()", " - drm/gma500/oaktrail_hdmi: fix i2c adapter leak on setup", " - s390/debug: Reject zero-length input before trimming a newline", " - Revert \"x86/vdso: Fix output operand size of RDPID\"", " - sysfs: don't remove existing directory on update failure", " - hwmon: (pmbus/adm1266) widen blackbox-info buffer to I2C_SMBUS_BLOCK_MAX", " - ALSA: ua101: Reject too-short USB descriptors", " - ALSA: asihpi: Fix potential OOB array access at reading cache", " - net: wwan: iosm: fix potential memory leaks in ipc_imem_init()", " - Bluetooth: bnep: Fix UAF read of dev->name", " - phonet/pep: disable BH around forwarded sk_receive_skb()", " - net: bcmgenet: keep RBUF EEE/PM disabled", " - netfilter: ip6t_hbh: reject oversized option lists", " - netfilter: nf_queue: hold bridge skb->dev while queued", " - netfilter: ipset: stop hash:* range iteration at end", " - ring-buffer: Fix reporting of missed events in iterator", " - vsock/vmci: fix UAF when peer resets connection during handshake", " - wifi: ath11k: clear shared SRNG pointer state on restart", " - ipv4: raw: reject IP_HDRINCL packets with ihl < 5", " - ixgbevf: fix use-after-free in VEPA multicast source pruning", " - wifi: cfg80211: advance loop vars in cfg80211_merge_profile()", " - tracing: Do not call map->ops->elt_free() if elt_alloc() fails", " - scsi: isci: Fix use-after-free in device removal path", " - spi: sprd: fix error pointer deref after DMA setup failure", " - spi: ti-qspi: fix use-after-free after DMA setup failure", " - RDMA/siw: Reject MPA FPDU length underflow before signed receive math", " - device property: set fwnode->secondary to NULL in fwnode_init()", " - drm/bridge: it66121: acquire reset GPIO in probe", " - drm/bridge: megachips: remove bridge when irq request fails", " - drm/amd/display: Fix integer overflow in bios_get_image()", " - drm/amd/display: Validate payload length and link_index in", " dc_process_dmub_aux_transfer_async", " - batman-adv: mcast: fix use-after-free in orig_node RCU release", " - batman-adv: clear current gateway during teardown", " - batman-adv: dat: handle forward allocation error", " - batman-adv: fix fragment reassembly length accounting", " - batman-adv: fix tp_meter counter underflow during shutdown", " - batman-adv: frag: disallow unicast fragment in fragment", " - batman-adv: bla: fix report_work leak on backbone_gw purge", " - batman-adv: tp_meter: avoid use of uninit sender vars", " - batman-adv: tt: fix negative last_changeset_len", " - batman-adv: tt: fix negative tt_buff_len", " - hwmon: (pmbus/adm1266) seed timestamp from the real-time clock", " - hwmon: (pmbus/adm1266) reject implausible blackbox record_count", " - hwmon: (pmbus/adm1266) include PEC byte in pmbus_block_xfer read buffer", " - hwmon: (pmbus/adm1266) bounce blackbox records through a protocol-sized", " buffer", " - hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR", " - hwmon: (pmbus/adm1266) don't clobber GPIO bits before PDIO read in", " get_multiple", " - hwmon: (pmbus/adm1266) register the gpio_chip after pmbus_do_probe()", " - hwmon: (pmbus/adm1266) register the nvmem device after pmbus_do_probe()", " - hwmon: (pmbus/adm1266) reject short block-read responses in the GPIO", " accessors", " - firmware: arm_ffa: Check for NULL FF-A ID table while driver", " registration", " - firmware: arm_ffa: Skip free_pages on RX buffer alloc failure", " - kunit: config: Enable KUNIT_DEBUGFS by default", " - kunit: config: KUNIT_DEBUGFS should depend on DEBUG_FS", " - ARM: integrator: Fix early initialization", " - netfilter: x_tables: unregister the templates first", " - tcp: Fix imbalanced icsk_accept_queue count.", " - ice: fix locking in ice_dcb_rebuild()", " - phy: marvell: mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register", " access", " - irqchip/ath79-cpu: Remove unused function", " - net: ethernet: cortina: Make RX SKB per-port", " - net: ethernet: cortina: Drop half-assembled SKB", " - net: ethernet: cortina: Carry over frag counter", " - net: ethernet: cs89x0: remove stale CONFIG_MACH_MX31ADS reference", " - wifi: ath11k: fix error path leaks in some WMI WOW calls", " - HID: quirks: really enable the intended work around for appledisplay", " - ethtool: fix ethnl_bitmap32_not_zero() bit interval semantics", " - drm/msm: Fix iommu_map_sgtable() return value check and avoid WARN", " - net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring", " - net: tls: prevent chain-after-chain in plain text SG", " - drm/msm/snapshot: fix dumping of the unaligned regions", " - net: dsa: mt7530: sync driver-specific behavior of MT7531 variants", " - net: dsa: mt7530: fix FDB entries not aging out with short timeout", " - net: dsa: mt7530: rename mt753x_bpdu_port_fw enum to mt753x_to_cpu_fw", " - net: dsa: mt7530: preserve VLAN tags on trapped link-local frames", " - net: mana: Fix TOCTOU double-fetch of hwc_msg_id from DMA buffer", " - platform/x86: adv_swbutton: Check ACPI_HANDLE() against NULL", " - platform/x86: hp_accel: Check ACPI_COMPANION() against NULL", " - platform/x86: intel-hid: Check ACPI_HANDLE() against NULL", " - platform/x86: intel-vbtn: Check ACPI_HANDLE() against NULL", " - RDMA/rtrs: Fix use-after-free in path file creation cleanup", " - net: bridge: Flush multicast groups when snooping is disabled", " - bridge: mcast: Fix a possible use-after-free when removing a bridge port", " - tracing: Avoid NULL return from hist_field_name() on truncation", " - net: ag71xx: check error for platform_get_irq", " - string: add mem_is_zero() helper to check if memory area is all zeros", " - gpiolib: cdev: use !mem_is_zero() instead of memchr_inv(s, 0, n)", " - gpio: cdev: check if uAPI v2 config attributes are correctly zeroed", " - net: mana: validate rx_req_idx to prevent out-of-bounds array access", " - Linux 5.15.209", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46275", " - Bluetooth: hci_uart: fix UAFs and race conditions in close and init", " paths", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-23141", " - KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory", " accesses", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43052", " - wifi: mac80211: check tdls flag in ieee80211_tdls_oper", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-22107", " - net: dsa: sja1105: fix kasan out-of-bounds warning in", " sja1105_table_delete_entry()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-21863", " - io_uring: prevent opcode speculation", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46274", " - io-wq: check that the predecessor is hashed in io_wq_remove_pending()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45846", " - bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45844", " - netfilter: arp_tables: fix IEEE1394 ARP payload parsing", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45843", " - slip: bound decode() reads against the compressed packet length", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45842", " - slip: reject VJ receive packets on instances with no rstate array", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45841", " - netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45840", " - openvswitch: cap upcall PID array size and pre-size vport replies", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46319", " - net/sched: act_ct: Only release RCU read lock after ct_ft", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45839", " - bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45838", " - bpf: fix end-of-list detection in cgroup_storage_get_next_key()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46214", " - vsock/virtio: fix accept queue count leak on transport mismatch", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46234", " - vsock: fix buffer size clamping order", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45836", " - Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46231", " - batman-adv: bla: put backbone reference on failed claim hash insert", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46233", " - batman-adv: bla: only purge non-released claims", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46212", " - batman-adv: bla: prevent use-after-free when deleting claims", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46238", " - batman-adv: stop caching unowned originator pointers in BAT IV", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46206", " - batman-adv: reject new tp_meter sessions during teardown", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46198", " - batman-adv: fix integer overflow on buff_pos", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46227", " - sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in", " SCTP_SENDALL", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46220", " - drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46197", " - drm/amdkfd: validate SVM ioctl nattr against buffer size", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46209", " - drm/gem: Fix inconsistent plane dimension calculation in", " drm_gem_fb_init_with_funcs()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46230", " - drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46219", " - spi: mpc52xx: fix use-after-free on unbind", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46236", " - media: rc: xbox_remote: heed DMA restrictions", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46205", " - staging: media: atomisp: Disallow all private IOCTLs", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46168", " - mptcp: fix scheduling with atomic in timestamp sockopt", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46189", " - RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46133", " - RDMA/rxe: Reject unknown opcodes before ICRC processing", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46127", " - RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46178", " - RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46112", " - RDMA/hns: Fix unlocked call to hns_roce_qp_remove()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46304", " - nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46161", " - md/raid10: fix divide-by-zero in setup_geo() with zero far_copies", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46124", " - isofs: validate block number from NFS file handle in isofs_export_iget", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46303", " - isofs: validate Rock Ridge CE continuation extent against volume size", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46294", " - dm: fix a buffer overflow in ioctl processing", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46107", " - dm-thin: fix metadata refcount underflow", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46301", " - spi: topcliff-pch: fix use-after-free on unbind", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46273", " - ibmveth: Disable GSO for packets with small MSS", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43502", " - net/rds: handle zerocopy send cleanup before the message is queued", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46120", " - ip6_gre: Use cached t->net in ip6erspan_changelink().", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46184", " - sound: ua101: fix division by zero at probe", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46132", " - net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in", " rtnl_fill_vfinfo", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46150", " - fanotify: fix false positive on permission events", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45834", " - Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45835", " - Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46186", " - Bluetooth: virtio_bt: validate rx pkt_type header length", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46123", " - Bluetooth: virtio_bt: clamp rx length before skb_put", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46172", " - ipv6: xfrm6: release dst on error in xfrm6_rcv_encap()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46146", " - ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46167", " - usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46151", " - usb: usblp: fix heap leak in IEEE 1284 device ID via short response", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46122", " - wifi: b43: enforce bounds check on firmware key index in b43_rx()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46307", " - wifi: ath5k: do not access array OOB", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46187", " - wifi: rsi: fix kthread lifetime race between self-exit and external-stop", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46163", " - wifi: b43legacy: enforce bounds check on firmware key index in RX path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46044", " - ipmi:ssif: Clean up kthread on errors", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43496", " - net/sched: sch_red: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-56727", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31489", " - spi: meson-spicc: Fix double-put in remove path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31476", " - ksmbd: do not expire session on binding failure", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43497", " - fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46108", " - ipmi:si: Return state to normal if message allocation fails", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46128", " - ipmi: Check event message buffer response for bad data", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46177", " - ipmi: Add limits to event and receive message requests", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46149", " - scsi: target: configfs: Bound snprintf() return in", " tg_pt_gp_members_show()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46101", " - netfilter: reject zero shift in nft_bitwise", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46099", " - net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46033", " - crypto: authencesn - reject short ahash digests during instance creation", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46062", " - ntfs3: fix integer overflow in run_unpack() volume boundary check", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46072", " - ntfs3: add buffer boundary checks to run_unpack()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46023", " - dm mirror: fix integer overflow in create_dirty_log()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46077", " - crypto: atmel-tdes - fix DMA sync direction", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45986", " - crypto: ccree - fix a memory leak in cc_mac_digest()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46019", " - crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46015", " - tcp: call sk_data_ready() after listener migration", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46040", " - inotify: fix watch count leak when fsnotify_add_inode_mark_locked()", " fails", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46070", " - md/raid5: validate payload size before accessing journal metadata", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46051", " - md/raid5: fix soft lockup in retry_aligned_read()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46046", " - ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46285", " - mtd: docg3: fix use-after-free in docg3_release()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46082", " - KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45987", " - KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46024", " - libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46037", " - ipv4: icmp: validate reply type before using icmp_pointers", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46027", " - net/smc: avoid early lgr access in smc_clc_wait_msg", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46053", " - net: rds: fix MR cleanup on copy error", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46004", " - ALSA: caiaq: Handle probe errors properly", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46050", " - md/raid10: fix deadlock with check operation and nowait requests", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46049", " - ALSA: ctxfi: Add fallback to default RSR for S/PDIF", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46002", " - ext2: reject inodes with zero i_nlink and valid mode in ext2_iget()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46047", " - net: qrtr: ns: Fix use-after-free in driver remove()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46009", " - PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46102", " - net: strparser: fix skb_head leak in strp_abort_strp()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46098", " - net: caif: clear client service pointer on teardown", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46088", " - ALSA: control: Validate buf_len before strnlen() in", " snd_ctl_elem_init_enum_names()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46080", " - ocfs2: split transactions in dio completion to avoid credit exhaustion", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-21739", " - scsi: ufs: core: Fix use-after free in init error and remove paths", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46064", " - ibmasm: fix heap over-read in ibmasm_send_i2o_message()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-45994", " - ibmasm: fix OOB reads in command_file_write due to missing size checks", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46022", " - misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46006", " - drm/nouveau: fix u32 overflow in pushbuf reloc bounds check", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-46018", " - ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31696", " - rxrpc: Fix missing validation of ticket length in non-XDR key preparsing", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31697", " - crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31698", " - crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command", " failed", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31699", " - crypto: ccp: Don't attempt to copy CSR to userspace if PSP command", " failed", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31701", " - ALSA: caiaq: take a reference on the USB device in create_card()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31694", " - fuse: reject oversized dirents in page cache", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31716", " - fs/ntfs3: validate rec->used in journal-replay file record check", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31676", " - rxrpc: only handle RESPONSE during service challenge", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31409", " - ksmbd: unset conn->binding on failed binding request", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-53596", " - drivers: base: Free devm resources when unregistering a device", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-50012", " - cpufreq: Avoid a bad reference count on CPU node", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38192", " - net: clear the dst when changing skb protocol", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-21712", " - md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43328", " - cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error", " path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23066", " - rxrpc: Fix recvmsg() unconditional requeue", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-50248", " - ntfs3: Add bounds checking to mi_enum_attr()", " - fs/ntfs3: Sequential field availability check in mi_enum_attr()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-27407", " - fs/ntfs3: Fixed overflow check in mi_enum_attr()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-45896", " - fs/ntfs3: Add more attributes checks in mi_enum_attr()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-52737", " - btrfs: lock the inode in shared mode before starting fiemap", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38626", " - f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-46770", " - ice: Add netif_device_attach/detach into PF reset flow", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38105", " - ALSA: usb-audio: Kill timer properly at removal", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-27389", " - pstore: inode: Only d_invalidate() is needed", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-52682", " - f2fs: fix to wait on block writeback for post_read case", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-56719", " - net: stmmac: fix TSO DMA API usage causing oops", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-41079", " - nvmet: always initialize cqe.result", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-53545", " - drm/amdgpu: unmap and remove csa_va properly", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-68239", " - binfmt_misc: restore write access before closing files opened by", " open_exec()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38659", " - gfs2: No more self recovery", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-49961", " - bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-47809", " - dlm: fix possible lkb_resource null dereference", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38250", " - Bluetooth: hci_core: Fix use-after-free in vhci_flush()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43281", " - mailbox: Prevent out-of-bounds access in of_mbox_index_xlate()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23157", " - btrfs: do not strictly require dirty metadata threshold for metadata", " writepages", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23141", " - btrfs: send: check for inline extents in range_is_hole_in_parent()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-40005", " - spi: cadence-quadspi: Implement refcount to handle unbind during busy", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2023-53629", " - fs: dlm: fix use after free in midcomms commit", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-71221", " - dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23204", " - net/sched: cls_u32: use skb_header_pointer_careful()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-71161", " - dm-verity: disable recursive forward error correction", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-50552", " - blk-mq: use quiesced elevator switch when reinitializing queues", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-36922", " - wifi: iwlwifi: read txq->read_ptr under lock", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-53221", " - f2fs: fix null-ptr-deref in f2fs_submit_page_bio()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-56657", " - ALSA: control: Avoid WARN() for symlink errors", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-49803", " - netdevsim: Fix memory leak of nsim_dev->fa_cookie", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-50116", " - tty: n_gsm: fix deadlock and link starvation in outgoing data path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31586", " - mm: blk-cgroup: fix use-after-free in cgwb_release_workfn()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31598", " - ocfs2: fix possible deadlock between unlink and dio_end_io_write", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31642", " - rxrpc: Fix call removal to use RCU safe deletion", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31664", " - xfrm: clear trailing padding in build_polexpire()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43075", " - ocfs2: fix out-of-bounds write in ocfs2_write_end_inline", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43076", " - ocfs2: validate inline data i_size during inode read", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23444", " - wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2025-38710", " - gfs2: Validate i_depth for exhash directories", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23442", " - ipv6: add NULL checks for idev in SRv6 paths", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31594", " - PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2022-50073", " - net: tap: NULL pointer derefence in dev_parse_header_protocol when", " skb->dev is null", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31576", " - media: hackrf: fix to not free memory after the device is registered in", " hackrf_probe()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43058", " - media: vidtv: fix pass-by-value structs causing MSAN warnings", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31577", " - nilfs2: fix NULL i_assoc_inode dereference in", " nilfs_mdt_save_to_shadow_map", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31578", " - media: as102: fix to not free memory after the device is registered in", " as102_usb_probe()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31580", " - bcache: fix cached_dev.sb_bio use-after-free and crash", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31581", " - ALSA: 6fire: fix use-after-free on disconnect", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31583", " - media: em28xx: fix use-after-free in em28xx_v4l2_open()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31585", " - media: vidtv: fix nfeeds state corruption on start_streaming failure", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31686", " - mm/kasan: fix double free for kasan pXds", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31588", " - KVM: x86: Use scratch field in MMIO fragment to hold small write values", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31630", " - rxrpc: proc: size address buffers for %pISpc output", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-23399", " - nf_tables: nft_dynset: fix possible stateful expression memleak in error", " path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2024-35865", " - smb: client: fix potential UAF in smb2_is_valid_oplock_break()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31590", " - KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31596", " - ocfs2: handle invalid dinode in ocfs2_group_extend", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31597", " - ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31599", " - media: vidtv: fix NULL pointer dereference in", " vidtv_channel_pmt_match_sections", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31602", " - ALSA: ctxfi: Limit PTP to a single page", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31603", " - staging: sm750fb: fix division by zero in ps_to_hz()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31605", " - fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31615", " - usb: gadget: renesas_usb3: validate endpoint index in standard request", " handlers", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31616", " - usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31617", " - usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31618", " - fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31619", " - ALSA: fireworks: bound device-supplied status before string array lookup", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31622", " - NFC: digital: Bounds check NFC-A cascade depth in SDD response handler", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31623", " - net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31624", " - HID: core: clamp report_size in s32ton() to avoid undefined shift", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31625", " - HID: alps: fix NULL pointer dereference in alps_raw_event()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31626", " - staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31627", " - i2c: s3c24xx: check the size of the SMBUS message before using it", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31532", " - can: raw: fix ro->uniq use-after-free in raw_rcv()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31629", " - nfc: llcp: add missing return after LLCP_CLOSED checks", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31407", " - netfilter: conntrack: add missing netlink policy validations", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43079", " - perf/x86/intel/uncore: Skip discovery table for offline dies", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43080", " - l2tp: Drop large packets with UDP encap", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31673", " - af_unix: read UNIX_DIAG_VFS data under unix_state_lock", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31681", " - netfilter: xt_multiport: validate range encoding in checkentry", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43085", " - netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43089", " - xfrm_user: fix info leak in build_mapping()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43093", " - xsk: tighten UMEM headroom validation to account for tailroom and min", " frame", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43098", " - nfc: s3fwrn5: allocate rx skb before consuming bytes", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43099", " - ipv4: icmp: fix null-ptr-deref in icmp_build_probe()", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43103", " - net: lapbether: handle NETDEV_PRE_TYPE_CHANGE", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-31684", " - net: sched: act_csum: validate nested VLAN headers", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43074", " - eventpoll: defer struct eventpoll free to RCU grace period", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43104", " - drm/vc4: Fix a memory leak in hang state error path", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43105", " - drm/vc4: Fix memory leak of BO array in hang state", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43110", " - wifi: brcmfmac: validate bsscfg indices in IF events", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43111", " - HID: roccat: fix use-after-free in roccat_report_event", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43112", " - fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath", " * Jammy update: v5.15.209 upstream stable release (LP: #2156901) //", " CVE-2026-43113", " - wifi: wl1251: validate packet IDs before indexing tx_frames", " * Jammy update: v5.15.207 upstream stable release (LP: #2156629)", " - Buffer overflow in drivers/xen/sys-hypervisor.c", " - xen/privcmd: fix double free via VMA splitting", " - Linux 5.15.204", " - Linux 5.15.205", " - Linux 5.15.206", " - Linux 5.15.207", " * Jammy update: v5.15.207 upstream stable release (LP: #2156629) //", " CVE-2025-54518 // CVE-2026-46174", " - x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op", " cache", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550)", " - ARM: clean up the memset64() C wrapper", " - Revert \"UBUNTU: SAUCE: Fix skb_vlan_inet_prepare() usage\"", " - ip6_tunnel: Fix usage of skb_vlan_inet_prepare()", " - scsi: lpfc: Properly set WC for DPP mapping", " - scsi: ufs: core: Always initialize the UIC done completion", " - scsi: ufs: core: Move link recovery for hibern8 exit failure to", " wl_resume", " - ALSA: usb-audio: Cap the packet size pre-calculations", " - ALSA: usb-audio: Use inclusive terms", " - btrfs: fix incorrect key offset in error message in", " check_dev_extent_item()", " - memory: mtk-smi: Convert to platform remove callback returning void", " - ARM: OMAP2+: add missing of_node_put before break and return", " - ARM: omap2: Fix reference count leaks in omap_control_init()", " - scsi: ata: Call scsi_done() directly", " - ata: libata-scsi: drop DPRINTK calls for cdb translation", " - ata: libata: remove pointless VPRINTK() calls", " - ata: libata-scsi: refactor ata_scsi_translate()", " - drm/tegra: dsi: fix device leak on probe", " - mfd: qcom-pm8xxx: switch away from using chained IRQ handlers", " - mfd: qcom-pm8xxx: Convert to platform remove callback returning void", " - mfd: qcom-pm8xxx: Fix OF populate on driver rebind", " - mfd: omap-usb-host: Convert to platform remove callback returning void", " - mfd: omap-usb-host: Fix OF populate on driver rebind", " - clk: tegra: tegra124-emc: fix device leak on set_rate()", " - usb: cdns3: remove redundant if branch", " - usb: cdns3: call cdns_power_is_lost() only once in cdns_resume()", " - ALSA: hda/conexant: Add quirk for HP ZBook Studio G4", " - hwmon: (max16065) Use READ/WRITE_ONCE to avoid compiler optimization", " induced race", " - fbcon: Use delayed work for cursor", " - fbcon: Extract fbcon_open/release helpers", " - fbcon: move more common code into fb_open()", " - ALSA: hda/conexant: Fix headphone jack handling on Acer Swift SF314", " - net: arcnet: com20020-pci: fix support for 2.5Mbit cards", " - eventpoll: Fix integer overflow in ep_loop_check_proc()", " - platform/x86: dell-wmi: Add audio/mic mute key codes", " - selftests: mptcp: more stable simult_flows tests", " - platform/x86: thinkpad_acpi: Fix errors reading battery thresholds", " - net: ethernet: ti: am65-cpsw-nuss/cpsw-ale: Fix multicast entry handling", " in ALE table", " - net: dpaa2: replace dpaa2_mac_is_type_fixed() with", " dpaa2_mac_is_type_phy()", " - net: dpaa2-switch: assign port_priv->mac after dpaa2_mac_connect() call", " - net: dpaa2-switch replace direct MAC access with", " dpaa2_switch_port_has_mac()", " - net: dpaa2-switch: serialize changes to priv->mac with a mutex", " - dpaa2-switch: do not clear any interrupts automatically", " - dpaa2-switch: Fix interrupt storm after receiving bad if_id in IRQ", " handler", " - indirect_call_wrapper: do not reevaluate function pointer", " - xen/acpi-processor: fix _CST detection using undersized evaluation", " buffer", " - amd-xgbe: fix sleep while atomic on suspend/resume", " - net: nfc: nci: Fix zero-length proprietary notifications", " - nfc: nci: clear NCI_DATA_EXCHANGE before calling completion callback", " - net: stmmac: Fix error handling in VLAN add and delete paths", " - ACPI: PM: Save NVS memory on Lenovo G70-35", " - ACPI: OSI: Add DMI quirk for Acer Aspire One D255", " - scsi: ses: Fix devices attaching to different hosts", " - ALSA: usb-audio: Avoid implicit feedback mode on DIYINHK USB Audio 2.0", " - ALSA: usb-audio: Check max frame size for implicit feedback mode, too", " - powerpc/uaccess: Fix inline assembly for clang build on PPC32", " - remoteproc: sysmon: Correct subsys_name_len type in QMI request", " - remoteproc: mediatek: Unprepare SCP clock during system suspend", " - powerpc: 83xx: km83xx: Fix keymile vendor prefix", " - bonding: handle BOND_LINK_FAIL, BOND_LINK_BACK as valid link states", " - ASoC: soc-core: drop delayed_work_pending() check before flush", " - ASoC: soc-core: accept zero format at snd_soc_runtime_set_dai_fmt()", " - ASoC: core: Exit all links before removing their components", " - ASoC: core: Do not call link_exit() on uninitialized rtd objects", " - can: hi311x: hi3110_open(): add check for hi3110_power_enable() return", " value", " - regulator: pca9450: Make IRQ optional", " - regulator: pca9450: Correct interrupt type", " - sched: idle: Make skipping governor callbacks more consistent", " - i40e: fix src IP mask checks and memcpy argument names in cloud filter", " - ACPI: OSL: fix __iomem type on return from acpi_os_map_generic_address()", " - ASoC: detect empty DMI strings", " - octeontx2-af: devlink: fix NIX RAS reporter recovery condition", " - net: usb: lan78xx: fix silent drop of packets with checksum errors", " - net: usb: lan78xx: skip LTM configuration for LAN7850", " - usb/core/quirks: Add Huawei ME906S-device to wakeup quirk", " - usb: misc: uss720: properly clean up reference in uss720_probe()", " - usb: core: don't power off roothub PHYs if phy_set_mode() fails", " - usb: cdc-acm: Restore CAP_BRK functionnality to CH343", " - USB: usbcore: Introduce usb_bulk_msg_killable()", " - usb: mdc800: handle signal and read racing", " - mm/tracing: rss_stat: ensure curr is false from kthread context", " - mmc: mmci: Fix device_node reference leak in of_get_dml_pipe_index()", " - libceph: reject preamble if control segment is empty", " - libceph: admit message frames only in CEPH_CON_S_OPEN state", " - time: add kernel-doc in time.c", " - time/jiffies: Mark jiffies_64_to_clock_t() notrace", " - device property: Allow secondary lookup in fwnode_get_next_child_node()", " - irqchip/gic-v3-its: Limit number of per-device MSIs to the range the ITS", " supports", " - net: mana: Ring doorbell at 4 CQ wraparounds", " - ice: fix retry for AQ command 0x06EE", " - parisc: Increase initial mapping to 64 MB with KALLSYMS", " - parisc: Fix initial page table creation for boot", " - net: ethernet: arc: emac: quiesce interrupts before requesting IRQ", " - tracing: Fix trace_buf_size= cmdline parameter with sizes >= 2G", " - lib/bootconfig: fix off-by-one in xbc_verify_tree() unclosed brace error", " - lib/bootconfig: fix snprintf truncation check in", " xbc_node_compose_key_after()", " - lib/bootconfig: check bounds before writing in __xbc_open_brace()", " - btrfs: abort transaction on failure to update root in the received", " subvol ioctl", " - iio: dac: ds4424: reject -128 RAW value", " - iio: chemical: sps30_serial: fix buffer size in sps30_serial_read_meas()", " - iio: potentiometer: mcp4131: fix double application of wiper shift", " - iio: chemical: bme680: Fix measurement wait duration calculation", " - iio: gyro: mpu3050-i2c: fix pm_runtime error handling", " - iio: imu: inv_icm42600: fix odr switch to the same value", " - i3c: mipi-i3c-hci: Use ETIMEDOUT instead of ETIME for timeout errors", " - i3c: mipi-i3c-hci: Restart DMA ring correctly after dequeue abort", " - i3c: mipi-i3c-hci: Add missing TID field to no-op command descriptor", " - l2tp: do not use sock_hold() in pppol2tp_session_get_sock()", " - mmc: sdhci-pci-gli: fix GL9750 DMA write corruption", " - mmc: sdhci: fix timing selection for 1-bit bus width", " - mtd: rawnand: pl353: make sure optimal timings are applied", " - mtd: rawnand: cadence: Fix error check for dma_alloc_coherent() in", " cadence_nand_init()", " - iommu/vt-d: Fix intel iommu iotlb sync hardlockup and retry", " - serial: 8250_pci: add support for the AX99100", " - serial: 8250: Add late synchronize_irq() to shutdown to handle DW UART", " BUSY", " - serial: uartlite: fix PM runtime usage count underflow on probe", " - drm/radeon: apply state adjust rules to some additional HAINAN vairants", " - mm/hugetlb: make detecting shared pte more reliable", " - mm/hugetlb: fix copy_hugetlb_page_range() to use ->pt_share_count", " - mm/hugetlb: fix two comments related to huge_pmd_unshare()", " - mm/rmap: fix two comments related to huge_pmd_unshare()", " - mm/hugetlb: fix excessive IPI broadcasts when unsharing PMD tables using", " mmu_gather", " - net: stmmac: dwmac-loongson: Set clk_csr_i to 100-150MHz", " - net: Handle napi_schedule() calls from non-interrupt", " - ext4: always allocate blocks only from groups inode can use", " - wifi: cfg80211: move scan done work to wiphy work", " - drm/amd/display: Use GFP_ATOMIC in dc_create_stream_for_sink", " - mptcp: pm: avoid sending RM_ADDR over same subflow", " - btrfs: tree-checker: fix misleading root drop_level error message", " - of: Add cleanup.h based auto release via __free(device_node) markings", " - firmware: arm_scpi: Fix device_node reference leak in probe path", " - Bluetooth: LE L2CAP: Disconnect if received packet's SDU exceeds IMTU", " - Bluetooth: LE L2CAP: Disconnect if sum of payload sizes exceed SDU", " - Bluetooth: SMP: make SM/PER/KDU/BI-04-C happy", " - Bluetooth: qca: fix ROM version reading on WCN3998 chips", " - netfilter: xt_time: use unsigned int for monthday bit shift", " - net: bcmgenet: increase WoL poll timeout", " - net: mana: Improve the HWC error handling", " - sched: idle: Consolidate the handling of two special cases", " - igc: fix missing update of skb->tail in igc_xmit_frame()", " - wifi: wlcore: Return -ENOMEM instead of -EAGAIN if there is not enough", " headroom", " - ACPI: processor: Fix previous acpi_processor_errata_piix4() fix", " - net: macb: fix uninitialized rx_fs_lock", " - net: dsa: bcm_sf2: fix missing clk_disable_unprepare() in error paths", " - hwmon: (pmbus/isl68137) Fix unchecked return value and use sysfs_emit()", " - i2c: fsi: Fix a potential leak in fsi_i2c_probe()", " - mtd: rawnand: brcmnand: skip DMA during panic write", " - lib/bootconfig: check xbc_init_node() return in override path", " - tools/bootconfig: fix fd leak in load_xbc_file() on fstat failure", " - sh: platform_early: remove pdev->driver_override check", " - bpf: Release module BTF IDR before module unload", " - platform/x86: intel-hid: Add Dell 14 Plus 2-in-1 to dmi_vgbs_allow_list", " - nvme-pci: cap queue creation to used queues", " - platform/x86: intel-hid: Enable 5-button array on ThinkPad X1 Fold 16", " Gen 1", " - platform/x86: touchscreen_dmi: Add quirk for y-inverted Goodix", " touchscreen on SUPI S10", " - HID: magicmouse: fix battery reporting for Apple Magic Trackpad 2", " - net: usb: r8152: add TRENDnet TUC-ET2G", " - HID: mcp2221: cancel last I2C command on read error", " - ASoC: fsl_easrc: Fix event generation in fsl_easrc_iec958_set_reg()", " - ASoC: fsl_easrc: Fix event generation in fsl_easrc_iec958_put_bits()", " - dma-buf: Include ioctl.h in UAPI header", " - ALSA: hda/realtek: Add headset jack quirk for Thinkpad X390", " - xfrm: call xdo_dev_state_delete during state update", " - xfrm: Fix the usage of skb->sk", " - can: statistics: add missing atomic access in hot path", " - pinctrl: mediatek: common: Fix probe failure for devices without EINT", " - ionic: fix persistent MAC address override on PF", " - rtnetlink: count IFLA_INFO_SLAVE_KIND in if_nlmsg_size", " - platform/olpc: olpc-xo175-ec: Fix overflow error message to print inlen", " - net: enetc: fix the output issue of 'ethtool --show-ring'", " - dma-mapping: add missing `inline` for `dma_free_attrs`", " - netlink: introduce NLA_POLICY_MAX_BE", " - netfilter: nft_payload: reject out-of-range attributes via policy", " - netlink: hide validation union fields from kdoc", " - netlink: introduce bigendian integer types", " - netlink: allow be16 and be32 types in all uint policy checks", " - regmap: Synchronize cache for the page selector", " - RDMA/rw: Fall back to direct SGE on MR pool exhaustion", " - RDMA/irdma: Update ibqp state to error if QP is already in error state", " - RDMA/irdma: Remove a NOP wait_event() in irdma_modify_qp_roce()", " - RDMA/irdma: Clean up unnecessary dereference of event->cm_node", " - RDMA/irdma: Remove reset check from irdma_modify_qp_to_err()", " - RDMA/irdma: Return EINVAL for invalid arp index error", " - scsi: scsi_transport_sas: Fix the maximum channel scanning issue", " - x86/efi: efi_unmap_boot_services: fix calculation of ranges_to_free size", " - drm/i915/gmbus: fix spurious timeout on 512-byte burst reads", " - ASoC: Intel: catpt: Fix the device initialization", " - ACPICA: include/acpi/acpixf.h: Fix indentation", " - ACPICA: Allow address_space_handler Install and _REG execution as 2", " separate steps", " - ACPI: EC: Fix EC address space handler unregistration", " - ACPI: EC: Fix ECDT probe ordering issues", " - hwmon: (adm1177) fix sysfs ABI violation and current unit conversion", " - sysctl: fix uninitialized variable in proc_do_large_bitmap", " - ASoC: adau1372: Fix unchecked clk_prepare_enable() return value", " - ASoC: adau1372: Fix clock leak on PLL lock failure", " - s390/barrier: Make array_index_mask_nospec() __always_inline", " - cpufreq: conservative: Reset requested_freq on limits change", " - alarmtimer: Fix argument order in alarm_timer_forward()", " - scsi: ses: Handle positive SCSI error from ses_recv_diag()", " - jbd2: gracefully abort on checkpointing state corruptions", " - ext4: make recently_deleted() properly work with lazy itable", " initialization", " - phy: ti: j721e-wiz: Fix device node reference leak in", " wiz_get_lane_phy_types()", " - dmaengine: xilinx: xilinx_dma: Fix dma_device directions", " - dmaengine: xilinx: xilinx_dma: Fix residue calculation for cyclic DMA", " - dmaengine: xilinx: xilinx_dma: Fix unmasked residue subtraction", " - btrfs: fix super block offset in error message in btrfs_validate_super()", " - btrfs: fix lost error when running device stats on multiple devices fs", " - dmaengine: idxd: Remove usage of the deprecated ida_simple_xx() API", " - dmaengine: idxd: Fix freeing the allocated ida too late", " - dmaengine: xilinx_dma: Program interrupt delay timeout", " - dmaengine: xilinx_dma: Fix reset related timeout with two-channel AXIDMA", " - btrfs: don't take device_list_mutex when querying zone info", " - objtool: Fix Clang jump table detection", " - dt-bindings: auxdisplay: ht16k33: Use unevaluatedProperties to fix", " common property warning", " - tg3: Fix race for querying speed/duplex", " - net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec", " - netfilter: ipset: use nla_strcmp for IPSET_ATTR_NAME attr", " - net/mlx5: Avoid \"No data available\" when FW version queries fail", " - net: hsr: fix VLAN add unwind on slave errors", " - hwmon: (pxe1610) Check return value of page-select write in probe", " - hwmon: (tps53679) Fix device ID comparison and printing in", " tps53676_identify()", " - hwmon: (occ) Fix missing newline in occ_show_extended()", " - riscv: kgdb: fix several debug register assignment bugs", " - USB: serial: option: add MeiG Smart SRM825WN", " - MIPS: Fix the GCC version check for `__multi3' workaround", " - drm/ast: dp501: Fix initialization of SCU2C", " - USB: serial: io_edgeport: add support for Blackbox IC135A", " - USB: serial: option: add support for Rolling Wireless RW135R-GL", " - USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam", " - Input: synaptics-rmi4 - fix a locking bug in an error path", " - Input: i8042 - add TUXEDO InfinityBook Max 16 Gen10 AMD to i8042 quirk", " table", " - Input: xpad - add support for Razer Wolverine V3 Pro", " - iio: dac: ad5770r: fix error return in ad5770r_read_raw()", " - iio: light: vcnl4035: fix scan buffer on big-endian", " - iio: imu: st_lsm6dsx: Set FIFO ODR for accelerometer and gyroscope only", " - iio: gyro: mpu3050: Fix out-of-sequence free_irq()", " - usb: quirks: add DELAY_INIT quirk for another Silicon Motion flash drive", " - usb: ehci-brcm: fix sleep during atomic", " - nvmet-tcp: fix use-before-check of sg in bounds validation", " - phy: renesas: rcar-gen3-usb2: Fix role detection on unbind/bind", " - phy: renesas: rcar-gen3-usb2: Move IRQ request in probe", " - phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver", " data", " - phy: renesas: rcar-gen3-usb2: Assert PLL reset on PHY power off", " - cdc-acm: new quirk for EPSON HMD", " - thunderbolt: Fix property read in nhi_wake_supported()", " - usb: gadget: dummy_hcd: fix premature URB completion when ZLP follows", " partial transfer", " - can: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on", " usb_submit_urb() error", " - can: gs_usb: gs_usb_receive_bulk_callback(): fix error message", " - Input: uinput - take event lock when submitting FF request \"event\"", " - media: uvcvideo: Use heuristic to find stream entity", " - arm64: dts: hisilicon: poplar: Correct PCIe reset GPIO polarity", " - arm64: dts: hisilicon: hi3798cv200: Add missing dma-ranges", " - net: qualcomm: qca_uart: report the consumed byte on RX skb allocation", " failure", " - rxrpc: Fix key/keyring checks in setsockopt(RXRPC_SECURITY_KEY/KEYRING)", " - netlink: add nla be16/32 types to minlen array", " - xen/privcmd: unregister xenstore notifier on module exit", " - Revert \"mptcp: add needs_id for netlink appending addr\"", " - ext4: fix the might_sleep() warnings in kvfree()", " - dmaengine: sh: rz-dmac: Move CHCTRL updates under spinlock", " - dmaengine: sh: rz-dmac: Protect the driver specific lists", " - net: macb: Move devm_{free,request}_irq() out of spin lock area", " - x86/cpu: Enable FSGSBASE early in cpu_init_exception_handling()", " - i2c: cp2615: replace deprecated strncpy with strscpy", " - io_uring/poll: correctly handle io_poll_add() return value on update", " - Linux 5.15.203", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-71150", " - ksmbd: Fix refcount leak when invalid session is found on session lookup", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23395", " - Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31549", " - i2c: cp2615: fix serial string NULL-deref at probe", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31433", " - ksmbd: fix potencial OOB in get_file_all_info() for compound requests", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31480", " - tracing: Fix potential deadlock in cpu hotplug with osnoise", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31466", " - mm/huge_memory: fix folio isn't locked in softleaf_to_folio()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43054", " - scsi: target: tcm_loop: Drain commands in target_reset handler", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23401", " - KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO", " SPTE", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31454", " - xfs: save ailp before dropping the AIL lock in push callbacks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31446", " - ext4: fix use-after-free in update_super_work when racing with umount", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31450", " - ext4: publish jinode after initialization", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31726", " - usb: gadget: uvc: fix NULL pointer dereference during unbind race", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31728", " - usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31721", " - usb: gadget: f_hid: move list and spinlock inits from bind to alloc", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31670", " - net: rfkill: prevent unlimited numbers of rfkill events from being", " created", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31634", " - rxrpc: fix reference count leak in rxrpc_server_keyring()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31651", " - mmc: vub300: fix NULL-deref on disconnect", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31656", " - drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31658", " - net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31660", " - nfc: pn533: allocate rx skb before consuming bytes", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31661", " - wifi: brcmsmac: Fix dma_free_coherent() size", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31662", " - tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31665", " - netfilter: nft_ct: fix use-after-free in timeout object destroy", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2024-56557", " - iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2024-36898", " - gpiolib: cdev: fix uninitialised kfifo", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-40016", " - media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31667", " - Input: uinput - fix circular locking dependency with ff-core", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31671", " - xfrm_user: fix info leak in build_report()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31672", " - wifi: rt2x00usb: fix devres lifetime", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43336", " - lib/crypto: chacha: Zeroize permuted_state before it leaves scope", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31695", " - wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2024-56584", " - io_uring/tctx: work around xa_store() allocation error issue", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31720", " - usb: gadget: f_uac1_legacy: validate control request size", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43342", " - usb: gadget: f_rndis: Protect RNDIS options with mutex", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43343", " - usb: gadget: f_subset: Fix unbalanced refcnt in geth_free", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-68256", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-40103", " - smb: client: Fix refcount leak for cifs_sb_tlink", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-38006", " - net: mctp: Don't access ifa_index when missing", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-40323", " - fbcon: Set fb_display[i]->mode to NULL when the mode is released", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23031", " - can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43324", " - USB: dummy-hcd: Fix interrupt synchronization error", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43327", " - USB: dummy-hcd: Fix locking/synchronization error", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31737", " - net: ftgmac100: fix ring allocation unwind on open failure", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31738", " - vxlan: validate ND option lengths in vxlan_na_create", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31747", " - comedi: me4000: Fix potential overrun of firmware buffer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31748", " - comedi: me_daq: Fix potential overrun of firmware buffer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31749", " - comedi: ni_atmio16d: Fix invalid clean-up after failed attach", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43340", " - comedi: Reinit dev->spinlock between attachments to low-level drivers", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31751", " - comedi: dt2815: add hardware detection to prevent crash", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31752", " - bridge: br_nd_send: validate ND option lengths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31754", " - usb: cdns3: gadget: fix state inconsistency on gadget init failure", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31755", " - usb: cdns3: gadget: fix NULL pointer dereference in ep_queue", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31756", " - usb: dwc2: gadget: Fix spin_lock/unlock mismatch in", " dwc2_hsotg_udc_stop()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31758", " - usb: usbtmc: Flush anchored URBs in usbtmc_release", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31759", " - usb: ulpi: fix double free in ulpi_register_interface() error path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31761", " - iio: gyro: mpu3050: Move iio_device_register() to correct location", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31762", " - iio: gyro: mpu3050: Fix irq resource leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31763", " - iio: gyro: mpu3050: Fix incorrect free_irq() variable", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31770", " - hwmon: (occ) Fix division by zero in occ_show_power_1()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43334", " - Bluetooth: SMP: force responder MITM requirements before building the", " pairing response", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31773", " - Bluetooth: SMP: derive legacy responder STK authentication from MITM", " state", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31776", " - ALSA: ctxfi: Fix missing SPDIFI1 index handling", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31778", " - ALSA: caiaq: fix stack out-of-bounds read in init_card", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31780", " - wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31781", " - drm/ioc32: stop speculation on the drm_compat_ioctl path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43333", " - bpf: reject direct access to nullable PTR_TO_BUF pointers", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31415", " - ipv6: avoid overflows in ip6_datagram_send_ctl()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31422", " - net/sched: cls_flow: fix NULL pointer dereference on shared blocks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31421", " - net/sched: cls_fw: fix NULL pointer dereference on shared blocks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31417", " - net/x25: Fix overflow when accumulating packets", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43014", " - net: macb: properly unregister fixed rate clocks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43015", " - net: macb: fix clk handling on PCI glue driver removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31425", " - rds: ib: reject FRMR registration before IB connection is established", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43020", " - Bluetooth: MGMT: validate LTK enc_size on load", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43024", " - netfilter: nf_tables: reject immediate NF_QUEUE verdict", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31424", " - netfilter: x_tables: restrict xt_check_match/xt_check_target extensions", " for NFPROTO_ARP", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43026", " - netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43027", " - netfilter: nf_conntrack_helper: pass helper to expect cleanup", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43028", " - netfilter: x_tables: ensure names are nul-terminated", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31416", " - netfilter: nfnetlink_log: account for netlink header size", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43329", " - netfilter: flowtable: strictly check for maximum number of actions", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31680", " - net: ipv6: flowlabel: defer exclusive option free until RCU teardown", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43030", " - bpf: Fix regsafe() for pointers to packet", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43032", " - NFC: pn533: bound the UART receive buffer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43035", " - net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to", " zero to prevent an info-leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43339", " - ipv6: prevent possible UaF in addrconf_permanent_addr()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31423", " - net/sched: sch_hfsc: fix divide-by-zero in rtsc_min()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43040", " - net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX", " fields to zero to prevent an info-leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43041", " - net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory", " leak", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43043", " - crypto: af-alg - fix NULL pointer dereference in scatterwalk", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43046", " - btrfs: reject root items with drop_progress and zero drop_level", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43047", " - HID: multitouch: Check to ensure report responses match the request", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43050", " - atm: lec: fix use-after-free in sock_def_readable()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43051", " - HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31555", " - futex: Clear stale exiting pointer in futex_lock_pi() retry path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43065", " - ext4: always drain queued discard work in ext4_mb_release()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43066", " - ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31447", " - ext4: reject mount if bigalloc with s_first_data_block != 0", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43068", " - ext4: avoid allocate block from corrupted group in", " ext4_mb_find_by_goal()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31452", " - ext4: convert inline data to extents when truncate exceeds inline size", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31455", " - xfs: stop reclaim before pushing AIL during unmount", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31464", " - scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31467", " - erofs: add GFP_NOIO in the bio completion if needed", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31469", " - virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and", " napi_tx is false", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31473", " - media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31570", " - can: gw: fix OOB heap access in cgw_csum_crc8_rel()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31483", " - s390/syscalls: Add spectre boundary for syscall dispatch table", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31485", " - spi: spi-fsl-lpspi: fix teardown order issue (UAF)", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31565", " - RDMA/irdma: Fix deadlock during netdev reset with active connections", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31494", " - net: macb: use the current queue number for stats", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31495", " - netfilter: ctnetlink: use netlink policy range checks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31427", " - netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in", " process_sdp", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31674", " - netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31428", " - netfilter: nfnetlink_log: fix uninitialized padding leak in", " NFULA_PAYLOAD", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31497", " - Bluetooth: btusb: clamp SCO altsetting table indices", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31498", " - Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31507", " - net/smc: fix double-free of smc_spd_priv when tee() duplicates splice", " pipe buffer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31679", " - openvswitch: validate MPLS set/set_masked payload length", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31508", " - net: openvswitch: Avoid releasing netdev before teardown completes", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31509", " - nfc: nci: fix circular locking dependency in nci_close_device", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31510", " - Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43069", " - Bluetooth: hci_ll: Fix firmware leak on error path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31408", " - Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing", " sock_hold", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31512", " - Bluetooth: L2CAP: Validate PDU length before reading SDU length in", " l2cap_ecred_data_rcv()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31515", " - af_key: validate families in pfkey_send_migrate()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31518", " - esp: fix skb leak with espintcp and async crypto", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31521", " - module: Fix kernel panic when a symbol st_shndx is out of bounds", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31522", " - HID: magicmouse: avoid memory leak in magicmouse_report_fixup()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31523", " - nvme-pci: ensure we're polling a polled queue", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31524", " - HID: asus: avoid memory leak in asus_report_fixup()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31788", " - xen/privcmd: restrict usage in unprivileged domU", " - xen/privcmd: add boot control for restricted usage in domU", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31540", " - drm/i915/gt: Check set_default_submission() before deferencing", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23434", " - mtd: rawnand: serialize lock/unlock against other NAND operations", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23398", " - icmp: fix NULL pointer dereference in icmp_tag_validation()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23438", " - net: mvpp2: guard flow control update with global_tx_fc in buffer", " switching", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23397", " - nfnetlink_osf: validate individual option lengths in fingerprints", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31546", " - net: bonding: fix NULL deref in bond_debug_rlb_hash_show", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23439", " - udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23396", " - wifi: mac80211: fix NULL deref in mesh_matches_local()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23446", " - net: usb: aqc111: Do not perform PM inside suspend callback", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23452", " - PM: runtime: Fix a race condition related to device removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23454", " - net: mana: fix use-after-free in mana_hwc_destroy_channel() by", " reordering teardown", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23391", " - netfilter: xt_CT: drop pending enqueued packets on template removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43060", " - netfilter: nft_ct: drop pending enqueued packets on removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-68206", " - netfilter: nft_ct: add seqadj extension for natted connections", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23456", " - netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23457", " - netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in", " sip_help_tcp()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23458", " - netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-39764", " - netfilter: ctnetlink: remove refcounting in expectation dumpers", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23460", " - net/rose: fix NULL pointer dereference in rose_transmit_link on", " reconnect", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23462", " - Bluetooth: HIDP: Fix possible UAF", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31551", " - wifi: mac80211: Fix static_branch_dec() underflow for aql_disable.", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23463", " - soc: fsl: qbman: fix race condition in qman_destroy_fq", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31683", " - batman-adv: avoid OGM aggregation when skb tailroom is insufficient", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31550", " - pmdomain: bcm: bcm2835-power: Increase ASB control timeout", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23368", " - net: phy: register phy led_triggers during probe to avoid AB-BA deadlock", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23303", " - smb: client: Don't log plaintext credentials in cifs_set_cifscreds", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23335", " - RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23336", " - wifi: cfg80211: cancel rfkill_block work in wiphy_unregister()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23281", " - wifi: libertas: fix use-after-free in lbs_free_adapter()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-38562", " - ksmbd: fix null pointer dereference error in generate_encryptionkey", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45920", " - ext4: fix dirtyclusters double decrement on fs shutdown", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45899", " - ext4: drop extent cache when splitting extent fails", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45985", " - ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting", " I/O", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45924", " - ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23227", " - drm/exynos: vidi: use ctx->lock to protect struct vidi_context member", " variables related to memory alloc/free", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45958", " - drm/exynos: vidi: fix to avoid directly dereferencing user pointer", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45956", " - drm/exynos: vidi: use priv->vidi_dev for ctx lookup in", " vidi_connection_ioctl()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23100", " - mm/hugetlb: fix hugetlb_pmd_shared()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43061", " - serial: 8250: Fix TX deadlock when using DMA", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23474", " - mtd: Avoid boot crash in RedBoot partition table parser", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31393", " - Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43062", " - Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31396", " - net: macb: fix use-after-free access to PTP clock", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31545", " - NFC: nxp-nci: allow GPIOs to sleep", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31399", " - nvdimm/bus: Fix potential use after free in asynchronous initialization", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31400", " - sunrpc: fix cache_request leak in cache_release", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2024-46715", " - driver: iio: add missing checks on iio_info's callback access", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23113", " - io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-39748", " - bpf: Forget ranges when refining tnum after JSET", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43357", " - iio: gyro: mpu3050-core: fix pm_runtime error handling", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43476", " - iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43363", " - x86/apic: Disable x2apic on resume if the kernel expects so", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43365", " - xfs: fix undersized l_iclog_roundoff values", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43370", " - drm/amdgpu: Fix use-after-free race in VM acquire", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43373", " - net: ncsi: fix skb leak in error paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43380", " - hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43381", " - nouveau/dpcd: return EBUSY for aux xfer if the device is asleep", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43382", " - batman-adv: Avoid double-rtnl_lock ELP metric worker", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-31405", " - media: dvb-net: fix OOB access in ULE extension header tables", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43387", " - staging: rtl8723bs: properly validate the data in rtw_get_ie_ex()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43386", " - staging: rtl8723bs: fix potential out-of-bounds read in", " rtw_restruct_wmm_ie", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43420", " - ceph: fix i_nlink underrun during async unlink", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43405", " - libceph: Use u32 for non-negative values in ceph_monmap_decode()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43411", " - tipc: fix divide-by-zero in tipc_sk_filter_connect()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43484", " - mmc: core: Avoid bitfield RMW for claim/retune flags", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43425", " - usb: image: mdc800: kill download URB on timeout", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43426", " - usb: renesas_usbhs: fix use-after-free in ISR during device removal", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43427", " - usb: class: cdc-wdm: fix reordering issue in read code path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43428", " - USB: core: Limit the length of unkillable synchronous timeouts", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43429", " - USB: usbtmc: Use usb_bulk_msg_killable() with user-specified timeouts", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43430", " - usb: yurex: fix race in probe", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43432", " - usb: xhci: Fix memory leak in xhci_disable_slot()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43439", " - cgroup: fix race between task migration and iteration", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43480", " - ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock", " acquisition", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43445", " - e1000/e1000e: Fix leak in DMA error cleanup", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43449", " - nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_set", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43450", " - netfilter: nfnetlink_cthelper: fix OOB read in", " nfnl_cthelper_dump_table()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43451", " - netfilter: nfnetlink_queue: fix entry leak in bridge verdict error path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43452", " - netfilter: x_tables: guard option walkers against 1-byte tail reads", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43453", " - netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43458", " - serial: caif: hold tty->link reference in ldisc_open and ser_release", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43459", " - ASoC: soc-core: flush delayed work before removing DAIs and widgets", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23277", " - net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL", " slave xmit", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43466", " - net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43469", " - xprtrdma: Decrement re_receiving on the early exit paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-54505 // CVE-2026-31628", " - x86/CPU: Fix FPDSS on Zen1", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43472", " - unshare: fix unshare_fs() handling", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43473", " - scsi: mpi3mr: Add NULL checks when resetting request and reply queues", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43475", " - scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23270", " - net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared", " blocks", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23300", " - net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23293", " - net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23381", " - net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23372", " - nfc: rawsock: cancel tx_work before socket teardown", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23339", " - nfc: nci: free skb on nci_transceive early error paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23340", " - net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless", " qdiscs", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23304", " - ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23420", " - wifi: wlcore: Fix a locking bug", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23357", " - can: mcp251x: fix deadlock in error path of mcp251x_open", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23362", " - can: bcm: fix locking for bcm_op runtime updates", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23286", " - atm: lec: fix null-ptr-deref in lec_arp_clear_vccs", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23296", " - scsi: core: Fix refcount leak for tagset_refcnt", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23356", " - drbd: fix \"LOGIC BUG\" in drbd_al_begin_io_nonblock()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23388", " - Squashfs: check metadata block offset is within range", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23379", " - net/sched: ets: fix divide by zero in the offload path", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23289", " - IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23279", " - wifi: mac80211: fix NULL pointer dereference in mesh_rx_csa_frame()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23367", " - wifi: radiotap: reject radiotap with unknown bits", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23318", " - ALSA: usb-audio: Use correct version for UAC3 header validation", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23370", " - platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23352", " - x86/efi: defer freeing of boot services memory", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23382", " - HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23324", " - can: usb: etas_es58x: correctly anchor the urb in the read bulk callback", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23298", " - can: ucan: Fix infinite loop from zero-length messages", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23307", " - can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a", " message", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23290", " - net: usb: pegasus: validate USB endpoints", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23365", " - net: usb: kalmia: validate USB endpoints", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23312", " - net: usb: kaweth: validate USB endpoints", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23291", " - nfc: pn533: properly drop the usb interface reference on disconnect", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23253", " - media: dvb-core: fix wrong reinitialization of ringbuffer on reopen", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-43123", " - fbcon: check return value of con2fb_acquire_newinfo()", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23220", " - ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error", " paths", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-45911", " - usb: cdns3: fix role switching during resume", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2025-71287", " - memory: mtk-smi: fix device leak on larb probe", " * Jammy update: v5.15.203 upstream stable release (LP: #2156550) //", " CVE-2026-23359", " - bpf: Fix stack-out-of-bounds write in devmap", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272)", " - auxdisplay: arm-charlcd: fix release_mem_region() size", " - i3c: remove i2c board info from i2c_dev_desc", " - i3c: Move device name assignment after i3c_bus_init", " - fs: add for 'init_fs'", " - gfs2: Add metapath_dibh helper", " - btrfs: qgroup: return correct error when deleting qgroup relation item", " - md/raid10: fix any_working flag handling in raid10_sync_request", " - iomap: fix submission side handling of completion side errors", " - PM: wakeup: Handle empty list in wakeup_sources_walk_start()", " - PM: sleep: wakeirq: harden dev_pm_clear_wake_irq() against races", " - libbpf: Fix dumping big-endian bitfields", " - libbpf: Fix OOB read in btf_dump_get_bitfield_value", " - ARM: VDSO: Patch out __vdso_clock_getres() if unavailable", " - crypto: cavium - fix dma_free_coherent() size", " - crypto: octeontx - fix dma_free_coherent() size", " - hrtimer: Fix trace oddity", " - crypto: hisilicon/trng - modifying the order of header files", " - crypto: hisilicon/trng - support tfms sharing the device", " - scsi: efct: Use IRQF_ONESHOT and default primary handler", " - EDAC/altera: Remove IRQF_ONESHOT", " - mfd: wm8350-core: Use IRQF_ONESHOT", " - EDAC/i5000: Fix snprintf() size calculation in calculate_dimm_size()", " - EDAC/i5400: Fix snprintf() limit calculation in calculate_dimm_size()", " - clk: qcom: Return correct error code in qcom_cc_probe_by_index()", " - arm64: dts: qcom: sdm630: correct QFPROM byte offsets", " - arm64: dts: qcom: sdm630: fix gpu_speed_bin size", " - arm64: dts: qcom: sdm845-oneplus: Don't mark ts supply boot-on", " - ARM: dts: allwinner: sun5i-a13-utoo-p66: delete \"power-gpios\" property", " - powerpc/uaccess: Move barrier_nospec() out of", " allow_read_{from/write}_user()", " - soc: qcom: cmd-db: Use devm_memremap() to fix memory leak in", " cmd_db_dev_probe", " - ARM: dts: lpc32xx: Set motor PWM #pwm-cells property value to 3 cells", " - arm: dts: lpc32xx: add clocks property to Motor Control PWM device tree", " node", " - arm64: dts: amlogic: axg: assign the MMC signal clocks", " - arm64: dts: amlogic: gx: assign the MMC signal clocks", " - arm64: dts: amlogic: g12: assign the MMC B and C signal clocks", " - arm64: dts: amlogic: g12: assign the MMC A signal clock", " - arm64: dts: qcom: sdm845-db845c: specify power for WiFi CH1", " - smack: /smack/doi must be > 0", " - drm/amdgpu: Use explicit VCN instance 0 in SR-IOV init", " - regulator: core: move supply check earlier in set_machine_constraints()", " - media: ccs: Accommodate C-PHY into the calculation", " - media: uvcvideo: Fix allocation for small frame sizes", " - platform/chrome: cros_ec_lightbar: Fix response size initialization", " - spi: tools: Add include folder to .gitignore", " - PCI: mediatek: Fix IRQ domain leak when MSI allocation fails", " - PCI: Do not attempt to set ExtTag for VFs", " - PCI/portdrv: Fix potential resource leak", " - netfilter: nf_conncount: make nf_conncount_gc_list() to disable BH", " - PCI: Mark 3ware-9650SA Root Port Extended Tags as broken", " - tcp: tcp_tx_timestamp() must look at the rtx queue", " - wifi: ath10k: sdio: add missing lock protection in", " ath10k_sdio_fw_crashed_dump()", " - PCI: Initialize RCB from pci_configure_device()", " - ucount: check for CAP_SYS_RESOURCE using ns_capable_noaudit()", " - bonding: only set speed/duplex to unknown, if getting speed failed", " - netfilter: nft_set_hash: fix get operation on big endian", " - ethtool: add support to set/get tx copybreak buf size via ethtool", " - net: hns3: add support to set/get tx copybreak buf size via ethtool for", " hns3 driver", " - net: hns3: remove the way to set tx spare buf via module parameter", " - net: hns3: fix ethtool tx copybreak buf size indicating not aligned", " issue", " - net: hns3: add max order judgement for tx spare buffer", " - ionic: Rate limit unknown xcvr type messages", " - octeontx2-pf: Unregister devlink on probe failure", " - RDMA/rtrs: server: remove dead code", " - IB/cache: update gid cache on client reregister event", " - RDMA/hns: Notify ULP of remaining soft-WCs during reset", " - power: supply: ab8500_bmdata: Use standard phandle", " - power: supply: ab8500: Use core battery parser", " - power: reset: nvmem-reboot-mode: respect cell size for nvmem_cell_write", " - power: supply: bq27xxx: fix wrong errno when bus ops are unsupported", " - RDMA/rtrs-srv: Refactor the handling of failure case in map_cont_bufs", " - RDMA/rtrs-srv: Correct the checking of ib_map_mr_sg", " - RDMA/rtrs-srv: fix SG mapping", " - mtd: rawnand: cadence: Fix return type of CDMA send-and-wait helper", " - crypto: ccp - Add an S4 restore flow", " - RDMA/core: Fix a couple of obvious typos in comments", " - svcrdma: Remove queue-shortening warnings", " - svcrdma: Clean up comment in svc_rdma_accept()", " - svcrdma: Increase the per-transport rw_ctx count", " - svcrdma: Reduce the number of rdma_rw contexts per-QP", " - RDMA/core: add rdma_rw_max_sge() helper for SQ sizing", " - mtd: parsers: ofpart: fix OF node refcount leak in", " parse_fixed_partitions()", " - RDMA/uverbs: Add __GFP_NOWARN to ib_uverbs_unmarshall_recv() kmalloc", " - pNFS: fix a missing wake up while waiting on NFS_LAYOUT_DRAIN", " - nvdimm: virtio_pmem: serialize flush requests", " - tracing: Remove duplicate ENABLE_EVENT_STR and DISABLE_EVENT_STR macros", " - clk: qcom: rcg2: compute 2d using duty fraction directly", " - clk: meson: gxbb: Limit the HDMI PLL OD to /4 on GXL/GXM SoCs", " - clk: qcom: gcc-msm8953: Remove ALWAYS_ON flag from cpp_gdsc", " - clk: Move clk_{save,restore}_context() to COMMON_CLK section", " - clk: qcom: dispcc-sdm845: Enable parents for pixel clocks", " - dmaengine: mediatek: uart-apdma: Fix above 4G addressing TX/RX", " - dma: dma-axi-dmac: fix SW cyclic transfers", " - serial: imx: change SERIAL_IMX_CONSOLE to bool", " - serial: SH_SCI: improve \"DMA support\" prompt", " - mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms", " - coresight: etm3x: Fix cpulocked warning on cpuhp", " - Revert \"mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms\"", " - drivers: iio: mpu3050: use dev_err_probe for regulator request", " - usb: bdc: fix sleep during atomic", " - pinctrl: equilibrium: Fix device node reference leak in pinbank_init()", " - ovl: Fix uninit-value in ovl_fill_real", " - pinctrl: qcom: Update macro name to LPI specific", " - pinctrl: qcom: Update lpi pin group custiom functions with framework", " generic functions", " - pinctrl: qcom: Extract chip specific LPASS LPI code", " - [Config] Enable CONFIG_PINCTRL_SM8250_LPASS_LPI=m", " - pinctrl: qcom: sm8250-lpass-lpi: Fix i2s2_data_groups definition", " - backlight: qcom-wled: Support ovp values for PMI8994", " - ACPI: CPPC: Fix remaining for_each_possible_cpu() to use online CPUs", " - selftests: mlxsw: tc_restrictions: Fix test failure with new iproute2", " - net/rds: rds_sendmsg should not discard payload_len", " - selftests: forwarding: vxlan_bridge_1d: fix test failure with", " br_netfilter enabled", " - netfilter: nf_conntrack_h323: don't pass uninitialised l3num value", " - ipv6: fix a race in ip6_sock_set_v6only()", " - bpftool: Fix truncated netlink dumps", " - octeontx2-af: Fix default entries mcam entry action", " - apparmor: fix rlimit for posix cpu timers", " - drm/i915/acpi: free _DSM package when no connectors", " - ext4: use optimized mballoc scanning regardless of inode format", " - ata: pata_ftide010: Fix some DMA timings", " - perf callchain: Fix srcline printing with inlines", " - libperf: Don't remove -g when EXTRA_CFLAGS are used", " - libperf build: Always place libperf includes first", " - rtc: interface: Alarm race handling should not discard preceding error", " - hfsplus: fix volume corruption issue for generic/498", " - i3c: master: svc: Initialize 'dev' to NULL in svc_i3c_master_ibi_isr()", " - tools/power cpupower: Reset errno before strtoull()", " - s390/purgatory: Add -Wno-default-const-init-unsafe to KBUILD_CFLAGS", " - x86/xen/pvh: Enable PAE mode for 32-bit guest only when CONFIG_X86_PAE", " is set", " - ACPICA: Abort AML bytecode execution when executing AML_FATAL_OP", " - s390/perf: Disable register readout on sampling events", " - xenbus: Use .freeze/.thaw to handle xenbus devices", " - blk-mq-debugfs: add missing debugfs_mutex in", " blk_mq_debugfs_register_hctxs()", " - sparc: Synchronize user stack on fork and clone", " - sparc: don't reference obsolete termio struct for TC* constants", " - bpf: verifier improvement in 32bit shift sign extension pattern", " - clocksource/drivers/timer-integrator-ap: Add missing Kconfig dependency", " on OF", " - mailbox: bcm-ferxrm-mailbox: Use default primary handler", " - char: tpm: cr50: Remove IRQF_ONESHOT", " - arm64: tegra: smaug: Add usb-role-switch support", " - parisc: Prevent interrupts during reboot", " - media: dvb-core: dmxdevfilter must always flush bufs", " - spi: stm32: fix Overrun issue at < 8bpw", " - media: omap3isp: isp_video_mbus_to_pix/pix_to_mbus fixes", " - media: omap3isp: isppreview: always clamp in preview_try_format()", " - media: omap3isp: set initial format", " - ASoC: wm8962: Add WM8962_ADC_MONOMIX to \"3D Coefficients\" mask", " - ASoC: wm8962: Don't report a microphone if it's shorted to ground on", " plug", " - media: adv7180: fix frame interval in progressive mode", " - drm/amdkfd: Fix GART PTE for non-4K pagesize in svm_migrate_gart_map()", " - hyper-v: Mark inner union in hv_kvp_exchg_msg_value as packed", " - virt: vbox: uapi: Mark inner unions in packed structs as packed", " - drm/atmel-hlcdc: don't reject the commit if the src rect has fractional", " parts", " - HID: multitouch: add eGalaxTouch EXC3188 support", " - HID: elecom: Add support for ELECOM HUGE Plus M-HT1MRBK", " - gpio: aspeed-sgpio: Change the macro to support deferred probe", " - spi: spi-mem: Protect dirmap_create() with spi_mem_access_start/end", " - ASoC: es8328: Add error unwind in resume", " - modpost: Amend ppc64 save/restfpr symnames for -Os build", " - ALSA: usb-audio: Add iface reset and delay quirk for AB13X USB Audio", " - jfs: Add missing set_freezable() for freezable kthread", " - iommu/arm-smmu-v3: Improve CMDQ lock fairness and efficiency", " - ipv6: annotate data-races in ip6_multipath_hash_{policy,fields}()", " - ipv6: exthdrs: annotate data-race over multiple sysctl", " - ext4: mark group add fast-commit ineligible", " - ext4: mark group extend fast-commit ineligible", " - netfilter: nf_conntrack: Add allow_clash to generic protocol handler", " - openrisc: define arch-specific version of nop()", " - net: usb: r8152: fix transmit queue timeout", " - net: hns3: extend HCLGE_FD_AD_QID to 11 bits", " - wifi: iwlegacy: add missing mutex protection in il4965_store_tx_power()", " - wifi: iwlegacy: add missing mutex protection in", " il3945_store_measurement()", " - ipv4: fib: Annotate access to struct fib_alias.fa_state.", " - Bluetooth: hci_conn: use mod_delayed_work for active mode timeout", " - Bluetooth: btusb: Add device ID for Realtek RTL8761BU", " - wifi: ath10k: fix lock protection in", " ath10k_wmi_event_peer_sta_ps_state_chg()", " - net: usb: sr9700: remove code to drive nonexistent multicast filter", " - vmw_vsock: bypass false-positive Wnonnull warning with gcc-16", " - PCI: Mark ASM1164 SATA controller to avoid bus reset", " - PCI/AER: Clear stale errors on reporting agents upon probe", " - PCI: Fix pci_slot_lock () device locking", " - PCI: Add ACS quirk for Qualcomm Hamoa & Glymur", " - PCI: Mark Nvidia GB10 to avoid bus reset", " - myri10ge: avoid uninitialized variable use", " - nfc: nxp-nci: remove interrupt trigger type", " - RDMA/rtrs-clt: For conn rejection use actual err number", " - scsi: buslogic: Reduce stack usage", " - tracing: Fix false sharing in hwlat get_sample()", " - mailbox: sprd: mask interrupts that are not handled", " - remoteproc: mediatek: Break lock dependency to `prepare_lock`", " - mailbox: sprd: clear delivery flag before handling TX done", " - clk: microchip: core: correct return value on *_get_parent()", " - m68k: nommu: fix memmove() with differently aligned src and dest for", " 68000", " - staging: rtl8723bs: fix missing status update on sdio_alloc_irq()", " failure", " - serial: 8250_dw: handle clock enable errors in runtime_resume", " - misc: eeprom: Fix EWEN/EWDS/ERAL commands for 93xx56 and 93xx66", " - serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA", " termination is done", " - fix it87_wdt early reboot by reporting running timer", " - binder: don't use %pK through printk", " - phy: mvebu-cp110-utmi: fix dr_mode property read from dts", " - phy: fsl-imx8mq-usb: disable bind/unbind platform driver feature", " - Revert \"mfd: da9052-spi: Change read-mask to write-mask\"", " - iio: Use IRQF_NO_THREAD", " - iio: magnetometer: Remove IRQF_ONESHOT", " - MIPS: Loongson: Make cpumask_of_node() robust against NUMA_NO_NODE", " - fs/ntfs3: avoid calling run_get_entry() when run == NULL in", " ntfs_read_run_nb_ra()", " - include: uapi: netfilter_bridge.h: Cover for musl libc", " - ARM: 9467/1: mm: Don't use %pK through printk", " - drm/amd/display: Avoid updating surface with the same surface under MPO", " - drm/amdgpu: Adjust usleep_range in fence wait", " - ALSA: usb-audio: Update the number of packets properly at receiving", " - drm/amdgpu: Add HAINAN clock adjustment", " - drm/radeon: Add HAINAN clock adjustment", " - btrfs: replace BUG() with error handling in __btrfs_balance()", " - lan78xx: Fix memory allocation bug", " - net: usb: lan78xx: scan all MDIO addresses on LAN7801", " - wifi: cfg80211: wext: fix IGTK key ID off-by-one", " - Bluetooth: L2CAP: Fix invalid response to L2CAP_ECRED_RECONF_REQ", " - Bluetooth: hci_qca: Cleanup on all setup failures", " - Bluetooth: L2CAP: Fix response to L2CAP_ECRED_CONN_REQ", " - tipc: fix duplicate publication key in tipc_service_insert_publ()", " - RDMA/core: Fix stale RoCE GIDs during netdev events at registration", " - RDMA/efa: Fix typo in efa_alloc_mr()", " - fpga: dfl: use subsys_initcall to allow built-in drivers to be added", " - arm64: Disable branch profiling for all arm64 code", " - media: cx25821: Add missing unmap in snd_cx25821_hw_params()", " - media: i2c: ov5647: Correct pixel array offset", " - media: i2c: ov5647: Correct minimum VBLANK value", " - media: i2c: ov5647: Sensor should report RAW color space", " - media: i2c: ov5647: Fix PIXEL_RATE value for VGA mode", " - media: i2c: ov5647: use our own mutex for the ctrl lock", " - dm-integrity: fix a typo in the code for write/discard race", " - clk: tegra: tegra124-emc: Fix potential memory leak in", " tegra124_clk_register_emc()", " - s390/pci: Handle futile config accesses of disabled devices directly", " - dm-unstripe: fix mapping bug when there are multiple targets in a table", " - arm64: dts: rockchip: Do not enable hdmi_sound node on Pinebook Pro", " - media: venus: vdec: fix error state assignment for zero bytesused", " - drm: of: drm_of_panel_bridge_remove(): fix device_node leak", " - mm, page_alloc, thp: prevent reclaim for __GFP_THISNODE THP allocations", " - selftests/mm/charge_reserved_hugetlb: drop mount size for hugetlbfs", " - xfs: mark data structures corrupt on EIO and ENODATA", " - xfs: fix remote xattr valuelblk check", " - nfsd: fix return error code for nfsd_map_name_to_[ug]id", " - usb: gadget: tegra-xudc: Add handling for BLCG_COREPLL_PWRDN", " - bus: fsl-mc: fix an error handling in fsl_mc_device_add()", " - dm mpath: make pg_init_delay_msecs settable", " - iio: gyro: itg3200: Fix unchecked return value in read_raw", " - PCI/IOV: Fix race between SR-IOV enable/disable and hotplug", " - arm64: Fix non-atomic __READ_ONCE() with CONFIG_LTO=y", " - btrfs: continue trimming remaining devices on failure", " - usb: dwc2: fix resume failure if dr_mode is host", " - mtd: rawnand: pl353: Fix software ECC support", " - tipc: fix RCU dereference race in tipc_aead_users_dec()", " - net: cpsw_new: Fix unnecessary netdev unregistration in cpsw_probe()", " error path", " - parisc: kernel: replace kfree() with put_device() in create_tree_node()", " - MIPS: rb532: Fix MMIO UART resource registration", " - net: ethernet: marvell: skge: remove incorrect conflicting PCI ID", " - tracing: Fix to set write permission to per-cpu buffer_size_kb", " - net: intel: fix PCI device ID conflict between i40e and ipw2200", " - fbdev: ffb: fix corrupted video output on Sun FFB1", " - drm/amdgpu: keep vga memory on MacBooks with switchable graphics", " - NTB: ntb_transport: Fix too small buffer for debugfs_name", " - Linux 5.15.202", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43291", " - net: nfc: nci: Fix parameter validation for packet data", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43283", " - net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43264", " - fbdev: of: display_timing: fix refcount leak in of_get_display_timings()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43202", " - fbdev: vt8500lcdfb: fix missing dma_free_coherent()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43203", " - atm: fore200e: fix use-after-free in tasklets during device removal", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43149", " - net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43273", " - ceph: supply snapshot context in ceph_zero_partial_object()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43159", " - staging: rtl8723bs: fix null dereference in find_network", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43211", " - PCI: Fix pci_slot_trylock() error handling", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43206", " - drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43275", " - scsi: ufs: core: Flush exception handling work when RPM level is zero", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43145", " - remoteproc: imx_rproc: Fix invalid loaded resource table detection", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43147", " - Revert \"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling", " SR-IOV\"", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43289", " - kexec: derive purgatory entry from symbol", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43168", " - ocfs2: fix reflink preserve cleanup issue", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43295", " - rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43148", " - powerpc/smp: Add check for kcalloc() failure in parse_thread_groups()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43163", " - md/bitmap: fix GPF in write_page caused by resize race", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43200", " - PCI: endpoint: Fix swapped parameters in", " pci_{primary/secondary}_epc_epf_unlink() functions", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43158", " - xfs: fix freemap adjustments when adding xattrs to leaf blocks", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43187", " - xfs: delete attr leaf freemap entries when empty", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43130", " - iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in", " scalable mode", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43133", " - KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43196", " - soc: ti: pruss: Fix double free in pruss_clk_mux_setup()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43242", " - soc: ti: k3-socinfo: Fix regmap leak on probe failure", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43278", " - dm: clear cloned request bio pointer when last clone bio completes", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43312", " - media: i2c: ov5647: Initialize subdev before controls", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43182", " - media: ccs: Avoid possible division by zero", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43246", " - media: i2c/tw9906: Fix potential memory leak in tw9906_probe()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43218", " - media: i2c/tw9903: Fix potential memory leak in tw9903_probe()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43135", " - media: cx23885: Add missing unmap in snd_cx23885_hw_params()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43257", " - media: cx88: Add missing unmap in snd_cx88_hw_params()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43231", " - media: radio-keene: fix memory leak in error path", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43136", " - HID: logitech-hidpp: Check maxfield in hidpp_get_report_length()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43251", " - HID: prodikeys: Check presence of pm->input_ep82", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43140", " - HID: magicmouse: Do not crash on missing msc->input", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43152", " - HID: hid-pl: handle probe errors", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43315", " - KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3()", " succeeding", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43270", " - media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43207", " - media: mtk-mdp: Fix error handling in probe function", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43132", " - dm-verity: correctly handle dm_bufio_client_create() failure", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71274", " - rpmsg: core: fix race in driver_override_show() and use core helper", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43233", " - netfilter: nf_conntrack_h323: fix OOB read in decode_choice()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43205", " - dpaa2-switch: validate num_ifs to prevent out-of-bounds write", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43194", " - net: consume xmit errors of GSO frames", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43156", " - net: usb: pegasus: enable basic endpoint checking", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43232", " - net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43134", " - Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43180", " - net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43139", " - xfrm6: fix uninitialized saddr in xfrm6_get_saddr()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43141", " - ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43241", " - ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43279", " - ALSA: usb-audio: Add sanity check for OOB writes at silencing", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71267", " - fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71265", " - fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent", " metadata", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71266", " - fs: ntfs3: check return value of indx_find to avoid infinite loop", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43225", " - staging: rtl8723bs: fix memory leak on failure path", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43230", " - net/rds: Clear reconnect pending bit", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43296", " - octeontx2-af: Workaround SQM/PSE stalls by disabling sticky", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43226", " - net/rds: No shortcut out of RDS_CONN_ERROR", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43190", " - netfilter: xt_tcpmss: check remaining length before reading optlen", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43255", " - wifi: libertas: fix WARNING in usb_tx_block", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43314", " - dm: remove fake timeout to avoid leak request", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71292", " - jfs: nlink overflow in jfs_rename", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43236", " - drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43269", " - drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43287", " - drm: Account property blob allocations to memcg", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43183", " - media: cx25821: Fix a resource leak in cx25821_dev_setup()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43316", " - media: solo6x10: Check for out of bounds chip_id", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43223", " - media: pvrusb2: fix URB leak in pvr2_send_request_ex", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43302", " - drm/v3d: Set DMA segment size to avoid debug warnings", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43124", " - pstore: ram_core: fix incorrect success return when vmap() fails", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43227", " - clocksource/drivers/sh_tmu: Always leave device running after probe", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43313", " - ACPI: processor: Fix NULL-pointer dereference in", " acpi_processor_errata_piix4()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43266", " - EFI/CPER: don't go past the ARM processor CPER record buffer", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43277", " - APEI/GHES: ensure that won't go past CPER allocated record", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43171", " - EFI/CPER: don't dump the entire memory region", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43184", " - rnbd-srv: Zero the rsp buffer before using it", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43261", " - arm64: Add support for TSV110 Spectre-BHB mitigation", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43262", " - gfs2: fiemap page fault fix", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43209", " - minix: Add required sanity checking to minix_check_superblock()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-43268", " - hfsplus: pretend special inodes as regular files", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-23241", " - audit: add missing syscalls to read class", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71239", " - audit: add fchmodat2() to change attributes class", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45964", " - SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45870", " - SUNRPC: auth_gss: fix memory leaks in XDR decoding error paths", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45948", " - ext4: fix memory leak in ext4_ext_shift_extents()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45912", " - ext4: don't cache extent during splitting extent", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46250", " - MIPS: Work around LLVM bug when gp is used as global register variable", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45974", " - btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not", " found", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45965", " - apparmor: fix invalid deref of rawdata when export_binary is unset", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45848", " - apparmor: fix NULL sock in aa_sock_file_perm", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45970", " - bonding: alb: fix UAF in rlb_arp_recv during bond up/down", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45847", " - net: remove WARN_ON_ONCE when accessing forward path array", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45890", " - xen-netback: reject zero-queue configuration from guest", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45968", " - cpuidle: Skip governor when only one idle state is available", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45935", " - fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45864", " - fs/ntfs3: prevent infinite loops caused by the next valid being the same", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45868", " - pinctrl: single: fix refcount leak in pcs_add_gpio_func()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45883", " - iio: sca3000: Fix a resource leak in sca3000_probe()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45875", " - mfd: arizona: Fix regulator resource leak on", " wm5102_clear_write_sequencer() failure", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45978", " - staging: greybus: lights: avoid NULL deref", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45954", " - fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45857", " - scsi: csiostor: Fix dereference of null pointer rn", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45856", " - RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45852", " - RDMA/rxe: Fix double free in rxe_srq_from_init", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45869", " - power: supply: wm97xx: Fix NULL pointer dereference in", " power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45916", " - power: supply: sbs-battery: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46270", " - power: supply: rt9455: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45936", " - power: supply: goldfish: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45885", " - power: supply: cpcap-battery: Fix use-after-free in", " power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45879", " - power: supply: bq25980: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45902", " - power: supply: bq256xx: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45867", " - power: supply: act8945a: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45946", " - power: supply: ab8500: Fix use-after-free in power_supply_changed()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45866", " - serial: caif: fix use-after-free in caif_serial ldisc_close()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-31411", " - net: atm: fix crash due to unvalidated vcc pointer in sigd_send()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46259", " - procfs: fix missing RCU protection when reading real_parent in", " do_task_stat()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45891", " - net: hns3: fix double free issue for tx spare buffer", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45873", " - netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46267", " - nfc: hci: shdlc: Stop timers and work before freeing context", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46249", " - octeontx2-af: Fix PF driver crash with kexec kernel booting", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45915", " - fat: avoid parent link count underflow in rmdir", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45983", " - nfsd: never defer requests during idmap lookup", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45862", " - iommu/vt-d: Flush cache for PASID table before using it", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45860", " - netfilter: nf_conncount: increase the connection clean up limit to 64", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45969", " - HID: playstation: Add missing check for input_ff_create_memless", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2025-71304", " - smack: /smack/doi: accept previously used values", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45904", " - powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event", " handling", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-46253", " - pstore/ram: fix buffer overflow in persistent_ram_save_old()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45919", " - sched/rt: Skip currently executing CPU in rto_next_cpu()", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45871", " - tpm: st33zp24: Fix missing cleanup on get_burstcount() error", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45941", " - tpm: tpm_i2c_infineon: Fix locality leak on get_burstcount() failure", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45984", " - gfs2: Fix use-after-free in iomap inline data write path", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-45960", " - hfsplus: return error when node already exists in hfs_bnode_create", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-23243", " - RDMA/umad: Reject negative data_len in ib_umad_write", " * Jammy update: v5.15.202 upstream stable release (LP: #2156272) //", " CVE-2026-23242", " - RDMA/siw: Fix potential NULL pointer dereference in header processing", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198)", " - crypto: octeontx - Fix length check to avoid truncation in", " ucode_load_store", " - scsi: qla2xxx: Query FW again before proceeding with login", " - ALSA: hda/realtek: Fix headset mic for TongFang X6AR55xU", " - gpio: sprd: Change sprd_gpio lock to raw_spin_lock", " - drm/tegra: hdmi: sor: Fix error: variable ‘j’ set but not used", " - platform/x86: panasonic-laptop: Fix sysfs group leak in error path", " - gpiolib: acpi: Fix gpio count with string references", " - Revert \"wireguard: device: enable threaded NAPI\"", " - selftests: mptcp: pm: ensure unknown flags are ignored", " - crypto: virtio - Remove duplicated virtqueue_kick in", " virtio_crypto_skcipher_crypt_req", " - bus: fsl-mc: Replace snprintf and sprintf with sysfs_emit in sysfs show", " functions", " - scsi: qla2xxx: Use named initializers for port_[d]state_str", " - scsi: qla2xxx: Remove dead code (GNN ID)", " - scsi: qla2xxx: Reduce fabric scan duplicate code", " - PCI: endpoint: Automatically create a function specific attributes group", " - PCI: endpoint: Remove unused field in struct pci_epf_group", " - USB: serial: option: add Telit FN920C04 RNDIS compositions", " - Linux 5.15.201", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23235", " - f2fs: fix out-of-bounds access in sysfs attribute read/write", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23234", " - f2fs: fix to avoid UAF in f2fs_write_end_io()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23236", " - fbdev: smscufx: properly copy ioctl memory to kernelspace", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23266", " - fbdev: rivafb: fix divide error in nv3_arb()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71233", " - PCI: endpoint: Avoid creating sub-groups asynchronously", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71232", " - scsi: qla2xxx: Free sp in error path to fix system crash", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71238", " - scsi: qla2xxx: Fix bsg_done() causing double free", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23221", " - bus: fsl-mc: fix use-after-free in driver_override_show()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23228", " - smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23169", " - mptcp: fix race in mptcp_pm_nl_flush_addrs_doit()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-37786", " - net: dsa: free routing table on probe failure", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23237", " - platform/x86: classmate-laptop: Add missing NULL pointer checks", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23238", " - romfs: check sb_set_blocksize() return value", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-31687", " - gpio: omap: do not register driver in probe()", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71235", " - scsi: qla2xxx: Delay module unload while fabric scan in progress", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71236", " - scsi: qla2xxx: Validate sp before freeing associated memory", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2025-71237", " - nilfs2: Fix potential block overflow that cause system hang", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23229", " - crypto: virtio - Add spinlock protection with virtqueue notification", " * Jammy update: v5.15.201 upstream stable release (LP: #2155198) //", " CVE-2026-23222", " - crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly", " * CVE-2026-23392", " - netfilter: nf_tables: register hooks last when adding new", " chain/flowtable", " - netfilter: nf_tables: release flowtable after rcu grace period on error", " * CVE-2026-45988", " - rxrpc: Fix re-decryption of RESPONSE packets", " * CVE-2026-46195", " - smb: client: validate dacloffset before building DACL pointers", " * CVE-2026-46135", " - nvmet-tcp: fix race between ICReq handling and queue teardown", " * CVE-2026-31402", " - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache", " * CVE-2026-43071", " - dcache: Limit the minimal number of bucket to two", " * CVE-2026-46119", " - libceph: Fix slab-out-of-bounds access in auth message processing", " * CVE-2026-43501", " - ipv6: rpl: reserve mac_len headroom when recompressed SRH grows", " * CVE-2026-46043", " - RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv", " * CVE-2026-43493", " - crypto: pcrypt - Fix handling of MAY_BACKLOG requests", " * CVE-2026-31637", " - rxrpc: reject undecryptable rxkad response tickets", " * CVE-2026-31657", " - batman-adv: hold claim backbone gateways by reference", " * CVE-2026-31685", " - netfilter: ip6t_eui64: reject invalid MAC header for all packets", " * CVE-2026-43117", " - btrfs: tracepoints: get correct superblock from dentry in event", " btrfs_sync_file()", " * CVE-2026-43114", " - netfilter: nft_set_pipapo_avx2: don't return non-matching entry on", " expiry", " * CVE-2026-31478", " - ksmbd: replace hardcoded hdr2_len with offsetof() in", " smb2_calc_max_out_buf_len()", " * CVE-2026-31668", " - seg6: separate dst_cache for input and output paths in seg6 lwtunnel", " * CVE-2026-31659", " - batman-adv: reject oversized global TT response buffers", " * CVE-2026-31649", " - net: stmmac: fix integer underflow in chain mode", " * CVE-2026-31669", " - mptcp: fix slab-use-after-free in __inet_lookup_established", " * CVE-2026-43011", " - net/x25: Fix potential double free of skb", " * CVE-2026-43037", " - ip6_tunnel: clear skb2->cb[] in ip4ip6_err()", " * CVE-2026-43038", " - ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()", " * CVE-2026-31682", " - bridge: br_nd_send: linearize skb before parsing ND options", " * CVE-2026-23450", " - net/smc: Only save the original clcsock callback functions", " - net/smc: Fix slab-out-of-bounds issue in fallback", " - net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()", " * CVE-2026-23428", " - ksmbd: fix use-after-free of share_conf in compound request", " * CVE-2026-23455", " - netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()", " * CVE-2026-43186", " - ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()", " * CVE-2026-43185", " - ksmbd: fix signededness bug in smb_direct_prepare_negotiation()", " * CVE-2026-43341", " - net/ipv6: ioam6: prevent schema length wraparound in trace fill", " * CVE-2026-31607", " - usbip: validate number_of_packets in usbip_pack_ret_submit()", " * CVE-2026-43383", " - net/tcp-md5: Fix MAC comparison to be constant-time", " * CVE-2025-68263", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " * CVE-2026-46243", " - smb: client: reject userspace cifs.spnego descriptions", " * CVE-2026-43414", " - scsi: qla2xxx: Completely fix fcport double free", " * CVE-2026-43407", " - libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply()", " * CVE-2026-43406", " - libceph: prevent potential out-of-bounds reads in", " process_message_header()", " * CVE-2026-43304", " - libceph: define and enforce CEPH_MAX_KEY_LEN", " * CVE-2025-37924", " - ksmbd: fix use-after-free in kerberos authentication", " * CVE-2025-37778", " - ksmbd: Fix dangling pointer in krb_authenticate", "" ], "package": "linux-kvm", "version": "5.15.0-1104.109", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2157390, 1786013, 2157405, 2154194, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156901, 2156629, 2156629, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156550, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2156272, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198, 2155198 ], "author": "Hannah Peuckmann ", "date": "Tue, 30 Jun 2026 09:18:47 +0200" } ], "notes": "linux-modules-5.15.0-1104-kvm version '5.15.0-1104.109' (source package linux-kvm version '5.15.0-1104.109') was added. linux-modules-5.15.0-1104-kvm version '5.15.0-1104.109' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1103-kvm. As such we can use the source package version of the removed package, '5.15.0-1103.108', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-headers-5.15.0-1103-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1103.108", "version": "5.15.0-1103.108" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-5.15.0-1103-kvm", "from_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1103.108", "version": "5.15.0-1103.108" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-kvm-headers-5.15.0-1103", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1103.108", "version": "5.15.0-1103.108" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-modules-5.15.0-1103-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1103.108", "version": "5.15.0-1103.108" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "notes": "Changelog diff for Ubuntu 22.04 jammy image from release image serial 20260713 to 20260716", "from_series": "jammy", "to_series": "jammy", "from_serial": "20260713", "to_serial": "20260716", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }